Last updated at Wed, 13 Dec 2017 19:42:35 GMT
Synopsis
In the series of blog posts titled “Incident Response Life Cycle in NIST and ISO standards” we review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.
In previous article in this series we reviewed NIST’s approach to incident response team and explained how security automation can help mitigate issues related to building and maintaining a security incident response team.
In this blog post we introduce the incident response life cycle as described in NIST Special Publication 800-61.
Why the cycle? Isn’t the incident response a linear activity?
Well, there’s one simple reason for that – it is not possible to learn and improve with linear approach.
We all should reflect on our own actions, shouldn’t we? 🙂
This applies to any area – and strongly applies to security and incident management.
We already talked shortly on why security teams should defend in graphs.
If incident management team (and/or team manager) doesn’t reflect on the results of team activities when managing incidents and on the results of these activities, then any possible mistakes made will not be corrected, time spent on an incident can’t be shortened, procedures can’t be brushed up etc.
All so called ISO “management” standards are based on so called PDCA cycle (Plan – Do – Check – Act), which is also called the Deming cycle. We’ll discuss it when we will be discussing ISO/IEC 27035 standard (“Information security incident management”).
The core of NIST Special Publication 800-61 (“Computer Security Incident Handling Guide”) is also the incident management cycle.
The NIST SP 800-61 incident response life cycle phases
The NIST recommendation defines four phases of incident response life cycle:
- Preparation
- Detection and analysis
- Containment, eradication and recovery
- Post-incident activity
Very often the popular view of incident management is limited to phases 2 and 3. This is where most of “visible” activities take place. For example, colleagues from other departments rarely see incident response team preparing for incidents.
But all four phases of incident management life cycle are equally important.
Let’s look at each of them shortly and how they relate to each other, as described in NIST SP 800-61.
What’s happening in each phase?
The “Preparation” phase allows an organization and its incident response team to prepare for incident handling (and, if possible, to reduce probability of an incident occurring).
During the “Detection and analysis” phase the incident response team analyzes symptoms that might indicate an incident and decides whether it indeed is an incident.
The “Containment, eradication and recovery” phase is the period in which incident response team tries to contain the incident and, if necessary, recover from it (restore any affected resources, data and/or processes).
In the “Post-incident activity phase” the incident and all relevant incident handling procedures are analyzed with two goals in mind: to reduce the probability of similar incident happening again and to improve incident handling procedures.
We will discuss all these four phases mentioned in NIST SP 800-61 later in more detail.
For now, let’s look shortly at how they relate to each other.
Correlations among four phases of incident management
There is more than one correlation between these four phases – and they are not simply linear.
NIST recommendation states that:
- output from “Post-incident activity” phase is an input for “Preparation” phase;
- output from “Containment, eradication and recovery” phase is an input for “Detection and analysis” phase.
It is very important to stop thinking of incident management in linear way.
The incident response team should have an SOP (standard operating procedure) that correlates detection and analysis phase with the results of containment phase. It might sound counter-intuitive, because the latter comes later than the former. But our intuition for incident management should not be the linear one.
There should also be SOPs in place to:
- spend time (after each incident is closed) on analyzing every aspect of that incident, including procedures used in each phase of incident response (preferably standardized internal report forms/databases should be used for that);
- feed the preparatory phase with post-incident analysis results.
We’ll discuss these recommendations in more detail when we are discussing the incident life cycle phases in more detail in next blog posts in this series.
Ask yourself these questions
If you are responsible for incident management, ask yourself these questions:
- Have your incident response team been spending enough time on analyzing the closed incidents?
- Have your incident response team been feeding preparatory activities with output from incident analysis?
- Have your incident response team been correlating incident indicators with actual incidents and feeding these correlations to “Detection and analysis” phase?
Question c. is very important for speeding up decision process that ends Phase 2 for particular incident (“Detection and analysis”), when incident response team starts containment phase (Phase 3). Timely decision to start containment might mean simpler containment, fewer losses and shorter recovery.
Properly used security automation can help automate correlating incident indicators with actual incidents and even automate feeding these correlations to the detection phase.
(In next articles in these series, we will be discussing NIST SP 800-61 incident response life cycle phases in more detail.)
References and further reading
NIST SP 800-61 – Computer Security Incident Handling Guide
