Hacking: Fight Back ==> The Day After: Your First Response To A Security Breach

The security incident is over. The techs have all gone home and are snug in their beds, dreaming of flawless code trees and buffer-overflow repellent. Upper management has done all the damage control they can. Everyone's shifting back into their normal activities and schedules. Everyone, that is, except you. What can you do to prevent this from ever happening again?

The best way to understand how a security incident happened is to conduct a post mortem. Incidents can range from an internal configuration error that resulted in system downtime, all the way up through an attack on your company, or even a natural disaster that impacted your company's physical location. Any event that didn't go as well as you hoped, or any set of processes that need to be checked, is a perfect candidate for a post mortem.

A post mortem is a review of what happened; a good post mortem delves into the who, what, how, when, and why of the incident. Even if the incident was clearly documented at the time, you're still going to need to review how things could have gone better in order to improve your processes, tools, and training for the future. These improvements may not prevent all future attacks, but they will allow you to prepare your business for the next incident

La suite : http://www.microsoft.com/technet/technetmag/issues/2005/01/IncidentResponse/