Create a hierarchy of incident response documents: brief executive-level policy, detailed procedures for technical managers, and playbooks and checklists for responders. Keep them succinct and use bullet points. Organizations often fail at knowing when and how to transition between phases of the incident cycle.
Preparing the right documents to guide the response to cybersecurity incidents is tricky. On the one hand, we need to provide policies and procedures for people involved in the incident response (IR) process. On the other hand, long, tedious documentation 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 to designate a document as a policy, procedure, or playbook. 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-technical executive. I think of this as a policy.
- One or more longer documents that include details regarding the approach to IR that the organization should exercise. 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 or plans.
- Detailed technical documents for the various situations that incident responders might find themselves in. The audience for this is technical staff who are responsible for taking IR steps. I think of this as playbooks, cheat sheets, and checklists.
To decide where a document fits in this hierarchy, ask the questions that Joshua Wright outlines in his book Dynamic Incident Response:
- Policy: “What has the organization decided?” It captures decisions such as “whether to pay ransom, when to involve legal counsel, and under what conditions to disclose publicly.”
- Plan: “Who does what, and when?”
- Playbook: “How do we respond?”
Keep It Brief
No one has the time and patience to read wordy policy documents filled with generalities. Keep your IR policies and procedures succinct and to the point. Use bullet points whenever possible.
An approach that has worked well for me is to use this IR report template to both guide the incident response process and help ensure that the responders capture the right information. The template serves as a procedural document—one that’s pragmatic and free of unnecessary words.
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.
The Security Incident Cycle
Organizations also make the mistake of 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 during an incident. This is hard, in part, due to differences in the technologies and skill sets used in each phase, as well as the different reporting structures of teams that need to collaborate when navigating the cycle.
Josh also tackles this challenge in his book. “I watched responders follow the prescribed steps,” he writes, “only to find that the incident was not over when they thought it was.” He recommends confirming that the incident is real before engaging the broader team. He describes the process of repeating the scoping, containment, eradication, and recovery steps until responders find no new evidence of compromise and decision-makers are confident that the incident has been resolved. He also points out the need to identify the person who’s authorized to consider the incident closed. I listed these steps for the person taking charge of an incident in my Initial Security Incident Questionnaire for Responders.
References for Designing Your IR Program
The following resources provide practical guidance for designing and implementing an incident response program:
- Dynamic Incident Response by Joshua Wright, a free book with a step-by-step guide for each stage of the response
- CSIRT resources from the CERT Division at Carnegie Mellon’s Software Engineering Institute
- CIRT-Level Response to Advanced Persistent Threat by Richard Bejtlich (PDF)
- SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile by NIST
Beyond the report template, which I discuss in How to Write Good Incident Response Reports, I created a number of cheat sheets useful for incident response:
- Initial Security Incident Questionnaire for Responders
- Security Incident Survey Cheat Sheet for System Administrators
- Critical Log Review Checklist for Security Incidents
- DDoS Incident Response Cheat Sheet
Sample Incident Response Plan Documents
If you’re wondering how other organizations document their IR programs, you’ll be surprised by 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.
