Incident Response

NIST SP 800-61 Rev 2 Incident Response Lifecycle

The National Institute of Standards and Technology Special Publication 800-61 Revision 2, the Computer Security Incident Handling Guide, defines the authoritative framework for incident response. The lifecycle consists of four phases:

1. Preparation — establishing tools, policies, and procedures before incidents occur
2. Detection and Analysis — identifying and characterizing incidents as they occur
3. Containment, Eradication, and Recovery — stopping the incident, removing threats, and restoring operations
4. Post-Incident Activity — lessons learned and process improvement

Security incidents addressed by this framework include: malware infections (user clicks an email attachment; malware installs and communicates with command-and-control servers), DDoS attacks (botnet traffic overwhelms services), data theft and extortion (stolen data used as leverage), and unauthorized software installation that exposes internal systems.

Preparation: The Incident Go Bag

The incident go bag is a pre-assembled kit of hardware and software needed to respond to any incident. Having these tools ready before an incident means responders are not scrambling to acquire equipment while an attack is ongoing. Go bag contents:

• Forensic laptops — dedicated systems with forensic software pre-installed (not general-purpose workstations that might be contaminated)
• Removable media — USB drives and external drives for copying evidence from affected systems
• Forensic software — tools for acquiring disk images, capturing memory, and analyzing artifacts without modifying evidence
• Digital cameras — for photographing physical evidence, screen states, cable connections, and documenting the physical scene before anything is moved

Preparation: Resources, Baselines, and Policies

Incident analysis resources must be available before an incident occurs:

• Contact list — up-to-date contact information for all personnel who must be notified when an incident occurs (management, legal, PR, law enforcement liaisons)
• Network diagrams — accurate documentation of network topology so responders can quickly understand traffic flows and identify anomalies
• Security baselines — documented known-good configurations for all system types; used to identify changes introduced by an attacker
• Critical file hash values — cryptographic hashes of critical operating system and application files; used to detect if files have been modified or replaced by malware

Incident mitigation software enables rapid recovery:

• Clean OS images for reimaging compromised systems
• Application installation packages for restoring software after reimaging
• Known-good backup copies verified before the incident occurred

Policies and procedures ensure all personnel know their roles, reporting requirements, and escalation paths during an incident. Without documented procedures, incident response becomes ad hoc and inconsistent, increasing the risk of evidence destruction, missed containment steps, or unauthorized public statements.

Detection Challenges

Detection is one of the most difficult aspects of incident response because:

• Volume: organizations connected to the internet receive constant attack traffic. Distinguishing a legitimate compromise from routine automated scanning is non-trivial.
• Complexity: security incidents rarely present as single clear events. A malware infection may involve dozens of processes, registry changes, network connections, and file modifications occurring across hours or days.
• Lead time: some indicators appear before the actual incident. Exploit announcements (such as Microsoft Patch Tuesday disclosures) and vulnerability scanner activity in web server logs can provide advance warning if responders are monitoring for them.

Detection Sources and Indicators

Multiple detection systems provide different views of potential incidents:

• Intrusion Prevention System (IPS) — detects and blocks known attack patterns; a buffer overflow attempt against a server is a high-fidelity IPS alert
• Antivirus / endpoint detection — identifies malware by signature or behavior; reports malware presence and installation location
• File Integrity Monitoring (FIM) — monitors critical system files and configuration files for unauthorized changes; alerts when a configuration change is detected on a host
• Network traffic analysis — monitors traffic flows for anomalies; a large spike in outbound traffic can indicate data exfiltration in progress
• Web server logs — capture vulnerability scanner activity, enumeration attempts, and exploit traffic against web applications

Isolation and Containment

Once an incident is confirmed, the general principle is to contain it immediately rather than wait to observe attacker behavior. Allowing an incident to continue increases the risk of lateral movement, additional data exfiltration, and harm to other systems. Responders own the consequences of delayed containment.

Sandboxes: a sandbox is an isolated operating system environment used to safely execute and analyze suspicious code. Malware is loaded into the sandbox, executed, and monitored for what it does to the OS (registry changes, file creation, network connections). The sandbox can be analyzed and then reset without affecting production systems.

Isolation challenge — self-destruct malware: some sophisticated malware detects that it is running in a sandbox or isolated environment (checking for VMs, limited network connectivity, absence of user activity) and responds by deleting itself, encrypting its payload, or executing a destructive payload. This makes analysis more difficult: the act of isolating the malware destroys the evidence. Incident responders must consider this risk when deciding whether to isolate a system immediately or first capture a memory image and disk snapshot before disconnecting it.

Eradication

Eradication removes the threat from the environment and closes the pathways that allowed it to enter. Eradication tasks include:

• Remove malware — identify and delete all malicious files, registry entries, scheduled tasks, and persistence mechanisms; do not assume antivirus removal is complete for advanced threats
• Disable compromised accounts — any account used by the attacker, or whose credentials were exposed, must be disabled and have its password reset before being re-enabled
• Patch vulnerabilities — identify the vulnerability exploited to gain initial access and apply the appropriate patch or configuration fix; without this, recovery is temporary
• Close unauthorized access points — remove backdoors, rogue accounts, and unauthorized software installed by the attacker

Recovery

Recovery restores affected systems to a known-good operational state. Options for recovery, in order of preference:

• Restore from verified backups — overwrite affected systems with backup copies taken before the incident; verify the backup is clean before restoring
• Rebuild from scratch — reimage the system using clean OS and application images from the go bag; more thorough than restoration but more time-consuming
• Replace compromised files — if full reimage is not practical, replace specific identified malicious files with known-good versions verified by hash

After restoration, the perimeter must be tightened: firewall rules reviewed, access controls verified, and monitoring enhanced for the affected systems. Systems must not return to production if the vulnerability that allowed the initial compromise has not been patched.

Lessons Learned and Post-Incident Meeting

The final phase of incident response is learning from what occurred to improve future capabilities. The post-incident meeting should include everyone who participated in the response. Timing is critical: the meeting should be held as soon as possible after the incident is resolved, while memories are fresh. Delayed post-mortems produce less accurate timelines and weaker recommendations.

Questions the post-incident meeting must answer:

• What happened exactly? — reconstruct the complete timeline from initial indicator to resolution, using logs, alerts, and forensic evidence
• How did the incident response plan perform? — were procedures followed? Did communication work? Did escalation paths function correctly?
• What would be done differently? — retrospective analysis identifies procedural weaknesses, missing tools, and training gaps
• Which indicators should be monitored in the future? — were there early warning signals that were missed? Can monitoring be updated to detect similar events earlier?

Incident Response Training

Training must occur before incidents, not during them. Active incidents provide no opportunity for on-the-job learning — responders must already know their roles, tools, and procedures when an incident begins. Training approaches:

• Tabletop exercises: scenario-based discussions where the team walks through an incident scenario, makes decisions, and identifies gaps without touching live systems. Low cost, suitable for executive and management participation.
• Simulations: more realistic exercises where technical teams execute actual response procedures against simulated incidents in a test environment. Higher fidelity, more expensive.
• Red team / purple team exercises: adversarial exercises where an attack team attempts realistic intrusions while the defensive team detects and responds. Most realistic, most expensive, most valuable for identifying real detection and response gaps.

Training is expensive, particularly for large teams with multiple incident response roles. However, inadequate training is far more expensive: a poorly handled incident causes greater damage, takes longer to contain, and may result in regulatory penalties for insufficient response. The investment in pre-incident training directly reduces the cost and impact of actual incidents.

NIST SP 800-61 Lifecycle Summary