Measure twice, cut once – true when building anything, especially incident response plans. Whether you are building an Incident Response Program from the ground up, or revising an existing plan there are a few things we need to make clear prior to diving into a tabletop exercise or live incident.
There were a number of things we listed in our last entry which should be collected/addressed prior to building your plan:
- A statement which embodies the commitment of senior leadership to address incident response as a business priority.
- The specific purpose and objectives of the policy, which should include (but are not limited to): An appropriately formed scope (who the policy applies to, and under what circumstances), definition of security incidents, threats, vulnerabilities, and other related terms.
- A chart depicting the roles, responsibilities, and decision-making authority rights of different members of the incident response team on everything from investigation/isolation of systems/assets when suspicious activity is detected or suspected, the requirements for reporting incidents by type, breach reporting requirements/connection to your Breach Notification Policy, information sharing guidelines for 3rd parties/customers, and the gates/associated process for escalation of incidents
- A chart depicting the baseline/definitions of incidents by severity and scope/scale
- A statement outlining the analysis/review methodology and what data is collected/needed during incidents for such purposes. For example, the number of hours spent by type of resource on incidents, related threats and vulnerabilities that were observed/addressed per incident, number of hours spent on recovery/remediation mid/post-incident, time to contain, time to remediate, and other such metrics/KPIs
- Contact Forms/Links to appropriate communication channels for reporting and general communication before/during/after incidents
Using these resources, it is important to break down your response into the phases of activity which represent the stages of your incident response plan. You can name these whatever you want, however it is best to base this structure on a well-known and accepted standard such as NIST Special Publication 800-61 R2: Computer Security Incident Handling Guide. As described in this standard, the phases of activity should minimally include the top level outcome and should be informed by/include the appropriate items listed beneath each phase heading below:
Preparation – This represents the actions taken proactively/prior to an incident
- A statement which embodies the commitment of senior leadership to address incident response as a business priority.
- The specific purpose and objectives of the incident response policy, which should include (but are not limited to): An appropriately formed scope (who the policy applies to, and under what circumstances), definition of security incidents, threats, vulnerabilities, and other related terms.
- Contact Forms/Links to appropriate communication channels for reporting and general communication before/during/after incidents
- A chart depicting the roles, responsibilities, and decision-making authority rights of different members of the incident response team on everything from investigation/isolation of systems/assets when suspicious activity is detected or suspected, the requirements for reporting incidents by type, breach reporting requirements/connection to your Breach Notification Policy, information sharing guidelines for 3rd parties/customers, and the gates/associated process for escalation of incidents
Detection & Analysis – This represents the initial triage/identification/classification of threats
- A chart depicting the baseline/definitions of incidents by severity and scope/scale
- Contact Forms/Links to appropriate communication channels for reporting and general communication before/during/after incidents
Containment, Eradication, & Recovery – This represents the bulk of incident response activity, including containing, eradicating, and recovering from threats
- A statement outlining the analysis/review methodology and what data is collected/needed during incidents for such purposes. For example, the number of hours spent by type of resource on incidents, related threats and vulnerabilities that were observed/addressed per incident, number of hours spent on recovery/remediation mid/post-incident, time to contain, time to remediate, and other such metrics/KPIs
- Contact Forms/Links to appropriate communication channels for reporting and general communication before/during/after incidents
Post-Incident Activity – This represents the post-incident activity the organization should engage in every time an incident occurs
- Contact Forms/Links to appropriate communication channels for reporting and general communication before/during/after incidents
Your focus as you step through each section and build to a given outcome should foment those components into a set of living documents which allow you and your incident response team to accomplish two things specifically:
- Document all relevant details clearly and store them in referenced locations so that future individuals receiving this training/needing to reference the related materials are able to easily do so
- Create a lifecycle of activity within each phase that is clear and easy to understand, which minimally addresses the focus of that phase and provides the foundation of information necessary to execute the next phase or terminate activity as appropriate.
To find out more about how to structure each phase/lifecycle, check out these relevant NIST SP 800-61 R2 sections:
Preparation
Detection & Analysis
Containment, Eradication, & Recovery
Post-Incident Activity
If you need help building your Incident Response Plan – book time with us here.
