* Getting to the bottom of security problem
This is another in an occasional series of articles looking at computer incident response team (CIRT) management. In the last column, I discussed incident postmortem analysis. Today I want to look at root-cause analysis.
One aspect that sometimes gets lost in the incident postmortems I’ve been describing is exploring the reasons for the problems. If we don’t pay attention to underlying causes, we may fix specific problems and we may improve particular procedures but we will likely encounter different consequences of the same fundamental errors that caused those particular problems.
We must pursue the analysis deeply enough to identify structural flaws in our processes so that we can correct those problems and thus reduce the likelihood of entire classes of problems. Readers interested in learning more about management style and small-group leadership tools may find some material of value in the Management Skills lectures and in the Leadership lectures on the MSIA section of my Web site.
The National Institute of Standards and Technology _Computer Security Incident Handling Guide_ by Tim Grance, Karen Kent and Brian Kim, specifically recommends a post-incident analysis. The authors’ list of suggested questions is as follows (quoting exactly):
* Exactly what happened, and at what times?
* How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?
* What information was needed sooner?
* Were any steps or actions taken that might have inhibited the recovery?
* What would the staff and management do differently the next time a similar incident occurs?
* What corrective actions can prevent similar incidents in the future?
* What additional tools or resources are needed to detect, analyze, and mitigate future incidents?
The authors also recommend the following (paraphrasing and summarizing):
* Invite people to the postmortem with an eye to increasing cooperation throughout the organization;
* Plan the agenda by polling participants before the meeting;
* Use experienced moderators;
* Be sure the meeting rules are clear to everyone to avoid confusion and conflict;
* Keep a written record of the discussions, conclusions, and action items.
On this last point, I must add that all action items should indicate clearly who intends to deliver precisely what operational result to whom in which form by when.
In my next column on this subject, I’ll be looking at continuous process improvement through knowledge sharing within the organization.
Editor’s Note: Check out Networkworld.com’s latest feature, Microsoft Subnet
Every day, our editors scour the Web to collect the most interesting and important Microsoft-related blogs, news, discussion forums and security alerts and present them to you on one page. At Microsoft Subnet, readers can create their own blogs and comment on the Microsoft news and issues of the day.
