Tips for Starting a Security Incident Response Program

Creating a structure for handling information security incidents is hard. On the one hand, there is the need to provide policies and procedures for people involved in the incident response (IR) process. On the other hand, documentation that’s too long and tedious is rarely read; moreover, it’s hard to anticipate every IR contingency when preparing the documents.

Here are a few tips for starting and formalizing a security incident response program.

The Hierarchy of Documents

Organizations differ in the criteria they use when designating a document a policy, procedure, guideline, and plan. Regardless of your nomenclature, you should have a hierarchy of documents:

A brief high-level document that describes the goal of the IR program. The level of detail should be appropriate for a non-technological executive manager. (I think of this as a policy.)
One or more longer documents that include details regarding the approach to IR that should be exercised by the organization. The audience for this documentation should be technical managers and other individuals implementing the IR program. (I think of this as procedures, though some might call it policies.)
Detailed technical documents for the various situations that incident responders might find themselves in. The audience for this is technical staff that is responsible for taking IR steps. (I think of this as guidelines, cheat sheets and checklists.)

Keep It Brief

Remember that no one has the time and patience to read wording policy documents filled with generalities. Keep your IR policies and procedures succinct and to the points. Use bullet points whenever possible.

Don’t worry about anticipating every possible contingency. Start with a set of documents that seems reasonable, so that you don’t dwell forever on getting them published. Then, amend them as you gain experience responding to incidents.

Avoid building upon IR document templates without customizing them for your specific needs, as such practices usually produce wordy texts filled with irrelevant concepts.

The Security Incident Cycle

Organizations also make the mistake on focusing on only one of several phases that comprise the security incident cycle. I discussed the big picture of the security incident cycle in an earlier article.

In addition to failing to devote proper attention to each phase of the security incident cycle, organizations often fail at knowing when and how to transition from one phase to another when dealing with an incident. The challenge is in part due to the differences in technologies and skill sets used in each phase, as well as in the different reporting structure of teams that need to collaborate when navigating the cycle.

References for Designing Your IR Program

The following papers and articles provide practical guidance for designing and implementing an incident response program:

Creating a Computer Security Incident Response Team: A Process for Getting Started by CERT Coordination Center
How to Design a Useful Incident Response Policy by Timothy E. Wright
CIRT-Level Response to Advanced Persistent Threat by Richard Bejtlich (PDF)
SP 800-61 Computer Security Incident Handling Guide by NIST (PDF)

In addition, I created a number of cheat sheets useful for incident response:

Sample Incident Response Plan Documents

If you're wondering how other organizations document their IR programs, you’ll be surprised how much you’ll discover by Googling "incident response filetype:pdf".

Keep in mind that even when you prepare for security incidents, you are likely to encounter a situation that catches you by surprise. I put together my thoughts on this topic in a presentation How to Respond to an Unexpected Security Incident (PDF) with full speaker notes.

For a related post, see my article on The Critical Role of the Security Incident Response Coordinator.

Updated February 11, 2015

Lenny Zeltser