Skip to main content

Command Palette

Search for a command to run...

Incident Response: The NIST SP 800-61 Lifecycle

A blue team guide to the four phases of incident response

Published
7 min read

Incident Response: The NIST SP 800-61 Lifecycle

Every security incident follows a pattern — and having a playbook makes the difference between containing damage and letting it spread. The NIST SP 800-61r2 lifecycle is the standard framework for incident response (IR). This post covers the full lifecycle, the tools, and what each phase actually looks like in practice.


Security Events vs. Security Incidents

Not every alert is an incident. The distinction matters for resource allocation.

  • Security Event — routine occurrence handled by SOC analysts (e.g., a single failed login, antivirus blocking a known file)
  • Security Incident — confirmed violation requiring specialized response (e.g., active compromise, data exfiltration, ransomware)

The SOC triages events. Incidents get escalated to the CSIRT.


The NIST IR Lifecycle

Four phases: Preparation, Detection & Analysis, Containment/Eradication/Recovery, and Lessons Learned.

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Lessons Learned

Phase 1: Preparation

The foundation. Everything you do before an incident — people, processes, tools.

Key Elements

  • Incident Response Plan (IRP) — documented procedures, escalation paths, communication templates
  • CSIRT (Computer Security Incident Response Team) — cross-functional: security, IT, HR, legal, C-suite, PR
  • Asset Inventory — you can't protect what you don't know exists
  • Risk Assessments — identify crown jewels and likely attack paths

Preventive Controls

Layer Controls
Host Antivirus, EDR, host firewall, application whitelisting
Network Firewalls, IDS/IPS, DMZ, network segmentation
Email SPF, DKIM, DMARC, spam filters, attachment sandboxing
Physical Badge access, cameras, secure disposal
Human Security awareness training, phishing simulations

Preparation is the phase most organizations underinvest in. It's also the phase that determines how painful the other phases will be.


Phase 2: Detection and Analysis

Identifying an incident has occurred and understanding its scope.

Detection Sources

  • SIEM alerts — correlation rules trigger on suspicious patterns
  • IDS/IPS signatures — known attack patterns
  • EDR — endpoint behavior anomalies
  • User reports — "I got a weird email"
  • Threat intelligence feeds — IOCs matching known campaigns
  • Baselines & behavioral profiles — deviations from normal patterns

Common Events to Investigate

  • Unauthorized access attempts
  • Malware infections
  • Denial of Service (DoS)
  • Data exfiltration
  • Insider threats
  • Web application attacks
  • Lateral movement signals

Live Response Tools

Windows CMD:

netstat -ano              # Active connections + PID
tasklist /svc             # Running processes + services
schtasks /query /fo LIST  # Scheduled tasks

Note: wmic is deprecated in recent Windows builds (21H1+) — use PowerShell equivalents.

PowerShell:

Get-Process                    # Running processes
Get-EventLog -LogName Security # Security events
Get-NetTCPConnection           # TCP connections
Get-ScheduledTask              # Scheduled tasks

DeepBlueCLI

PowerShell module for rapid Windows Event Log analysis. Detects:

  • Meterpreter shellcode injection
  • Suspicious service creation
  • User account modifications (net user commands)
  • PowerShell obfuscation
  • Password spraying / brute force
  • Pass-the-hash indicators

Run against a .evtx file or live system — gives you a fast triage output before deeper forensics.

Wireshark for Network Analysis

  • Protocol dissection to find C2 traffic
  • Filter for suspicious ports, DNS queries, HTTP POSTs
  • Export objects (files) from captures
  • Follow TCP streams to reconstruct attacker activity

Phase 3: Containment, Eradication, and Recovery

Once an incident is confirmed, the priority is stopping the bleeding.

Containment

Goal: limit the spread and impact without destroying evidence.

Short-term containment:

  • Isolate affected systems (pull network cable, disable switch port)
  • Block malicious IPs/domains at the firewall
  • Disable compromised user accounts
  • Revoke suspicious API tokens

Long-term containment:

  • Apply patches
  • Harden configurations
  • Rebuild systems in parallel while keeping the compromised one for analysis

Critical: Take forensic images BEFORE eradication. You cannot recover evidence that's been deleted.

Eradication

Remove the threat completely.

  • Identify all malicious artifacts:
    • Files and binaries
    • Registry keys
    • Scheduled tasks
    • Services
    • Backdoor accounts
    • WMI subscriptions
  • Remove malware from all affected systems
  • Close the initial attack vector (patch the vulnerability, disable the exploited feature)
  • Verify eradication — don't assume

Recovery

Restore normal operations, but do it carefully.

  • Identify root cause — if you don't know how they got in, they'll be back
  • Restore from clean backups — verify the backup wasn't also compromised
  • Rebuild compromised systems — don't trust an infected machine, even after "cleaning"
  • Reset credentials for any potentially exposed accounts
  • Monitor for re-infection — attackers often try again

Phase 4: Lessons Learned

The most overlooked phase. Conducted within days of incident closure, while details are fresh.

Post-Incident Review

  • What went well? — effective processes, tools, team coordination
  • What could be improved? — detection gaps, slow response, communication breakdowns
  • What should change? — new detection rules, updated playbooks, additional training

Documentation

Maintain detailed records throughout the incident — not just at the end. Documentation supports:

  • Legal proceedings
  • Compliance requirements
  • Insurance claims
  • Future similar incidents
  • Process improvement

IR Metrics

Metric What It Measures
MTTD (Mean Time to Detect) How long before the incident was noticed
MTTR (Mean Time to Respond) How long from detection to initial response
Time to Contain How long to stop the spread
Time to Recover How long to full restoration
Incidents per Category Malware, phishing, insider, etc.
Cost per Incident Financial impact

Report Structure

A proper IR report includes:

  1. Executive Summary — for leadership, non-technical
  2. Incident Timeline — chronological events
  3. Technical Details — IOCs, TTPs, affected systems
  4. Impact Assessment — data, systems, business impact
  5. Recommendations — what to change, what to invest in

Case Management: TheHive

Tracking multiple concurrent incidents manually doesn't scale. Case management platforms help.

TheHive — open-source IR platform:

  • Case/task management
  • Observable analysis (IPs, hashes, URLs, files)
  • Integration with MISP for threat intel enrichment
  • Integration with Cortex for automated analysis
  • Alert ingestion from SIEMs

IR Meets MITRE ATT&CK

MITRE ATT&CK maps adversary tactics and techniques — a shared vocabulary for describing what attackers do.

The 14 Enterprise tactics:

Reconnaissance → Resource Development → Initial Access → Execution 
→ Persistence → Privilege Escalation → Defense Evasion → Credential Access 
→ Discovery → Lateral Movement → Collection → C2 → Exfiltration → Impact

During most incident response work, you'll focus on the post-intrusion tactics (Initial Access onward) since Recon and Resource Development happen outside your visibility.

During IR, map observed adversary behavior to ATT&CK techniques. This helps:

  • Understand what the attacker did and what they're likely to do next
  • Build detection rules for the specific TTPs
  • Structure investigations around known tactics
  • Share findings with the community using a standard vocabulary

Key Takeaways

  • IR is a lifecycle, not a one-time event — the four phases repeat and improve
  • Preparation determines how much the other phases hurt
  • Always image before eradication — you can't unburn evidence
  • Root cause matters — without it, the attacker comes back
  • Document everything — not just at the end, throughout
  • Lessons Learned is not optional — it's where improvement happens
  • Use MITRE ATT&CK as a shared language for TTPs
  • Metrics (MTTD, MTTR) prove value and identify bottlenecks