Incident Response Steps (NIST)

The NIST incident response life-cycle breaks incident response down into four main phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Event Activity.

Phase 1: Preparation

The Preparation phase covers the work an organization does to get ready for incident response, including establishing the right tools and resources and training the team. This phase includes work done to prevent incidents from happening.

Phase 2: Detection and Analysis

Accurately detecting and assessing incidents is often the most difficult part of incident response for many organizations, according to NIST.

Phase 3: Containment, Eradication, and Recovery

This phase focuses on keeping the incident impact as small as possible and mitigating service disruptions.

Phase 4: Post-Event Activity

Learning and improving after an incident is one of the most important parts of incident response and the most often ignored. In this phase the incident and incident response efforts are analyzed. The goals here are to limit the chances of the incident happening again and to identify ways of improving future incident response activity.

Besides the NIST version, there are also other models that are usually used in SOC 2, ISO 27001, etc Incident Response policies. The Preparation step is assumed that is already in place if a company is seeking to achieve compliance – e.g, there is already a security officer dedicated to handle compliance/governance or simply managing security operations within the company. The “Preparation” step is an ongoing iterative process, that should take place as part of the SOC department daily/weekly routines.

Some incidents can be classified also with lower impact, and not requiring all of the steps below. The process outlined is mostly focusing on Critical/High impact vulnerabilities:

1. Detect – this is usually an automated step that a lot of time can just be an event rather than an incident or can be classified as a low impact incident. The more robust the monitoring and detection controls (including Threat Hunting as method of detection) are, the higher chance that the event can be automatically classified as an incident
   
2. Identify / Analysis – once the event has been detected, the next step is to identify and classify it as an incident or simply an event (false positive). The analysis process would result in severity classification of the incident, those with Critical impact will need to be handled with the rest of the steps outlined in this process.
   
   Using Forensic Analysis tools such as Crowdstrike EDR incident analysis tool, can help identify the exact steps of the attack, and the chronological order of these steps (malware delivered to Outlook client, browser elevated permissions or executed a Powershell, etc)
   
3. Containment – before moving forward with any other steps, since most incidents are time sensitive, we need to make sure that we contain the incident ASAP. This could be simply disconnecting a workstation/instance from the network, locking a user account out of all resources (internal accounts, SaaS, etc), removing VPN access, etc.
   
4. Remediation – depending on the severity level of the incident, this step could be the last step of the process. For example a lost/stolen laptop will simply need to be blocked/remotely erased and new laptop provided to the user, no further steps will be needed. A single outdated application, or single user account to a specific SaaS service may not need further steps if the root cause was identified (user password leaked in a hack, etc).
   
   Remediation itself however may not be the last step of the process. For example if the incident is a result of a Zero Day vulnerability for which there is no patch available, the Remediation efforts could have been simply to implement a firewall rule ( WAF) to filter/block access to specific service but further efforts are required.
   
   During the remediation phase further forensic analysis need to be done to make sure that all possible impacted resources are discovered, including back doors, hidden payloads, etc.
   
5. Eradication and Complete Recovery – this step of the process will ensure that the incident has been eradicated from the company’s network/resources/etc at 100%. This could be applying urgent vulnerability patch addressing zero day vulnerability and exploits, it could be replacement of compromised workstations/servers (which could require full OS and Bios updates).
   
   Further forensic analysis need to be done at this stage as well, to assure that the incident has been 100% eradicated and minimize the chance of recurrence. The Root Cause Analysis of the incident need to be completed prior to conclusion of this step.
   
   This stage assumes that all systems are recovered to their original/baseline state and are 100% operational without further security related intervening.
   
6. Postmortem – this is the final step of the process and usually involves one or several meetings, written notes/conclusions, development of actionable items.
   
   This phase involves the review of Root Cause Analysis, impact analysis, and overall conclusion on how similar incidents can be prevented in the future. Tracking of any actionable items, and any sequential meetings need to be in place as well.