I strongly believe that this type of guidance is long overdue. Too many security professionals are obsessed with tools and technology. Because many incident-response teams lack a management-level understanding of security, they tend to focus on dealing with the technical symptoms of an incident and not focus on root cause analysis. By implementing the CERT guidelines, it will help put incidents in the context of an enterprise and help the incident-response team focus on making the procedural and/or technical changes to mitigate damages of future incidents.
While the new security incident-response project is a great move by CERT, to many IT security pros it looks and feels like it has too much management speak. For example, on its website it mentions the goals of the CERT Incident Response Project as being focused on performance standards and management best practices. These are things that are usually the object of humor in Dilbert cartoons.
Keep in mind, though, that the first step in the process is to obtain management buy-in. Remember, management controls budgets, and we as security professionals need to speak their language. This applies not only to incident response, but also to architecture and penetration testing as well.
Another thing to keep in mind regarding any template-based procedures for incident response is that there is no such thing as one size fits all. Plans need to be tailored to specific environments. Take anything from CERT, NIST, and SANS as a starting point.
One of the nice things I see in this project is that it is goal- and metric-based. I feel that having goals and metrics are great tools to demonstrate the value of having a dedicated security/incident-response team. By utilizing goals and metrics, security pros can demonstrate to upper management that they provide value to the enterprise, which is a skill that many security teams lack.
This was first published in July 2008