Incident Response

The Six-Phase IR Framework

Incident Response (IR) is the structured, documented process for detecting, containing, and recovering from security incidents. The NIST SP 800-61 Rev. 2 framework defines six phases that every IR team follows. This is not academic theory — it is the operational backbone that prevents chaos during a real breach.

Phase 1: Preparation

Goal: Make sure the team, tools, and processes are ready before an incident occurs.

This is the most important phase. Organizations that prepare thoroughly detect incidents faster, contain them more effectively, and recover with less damage.

SOC Analyst Checklist

• Runbooks exist and are tested. Each common incident type (ransomware, phishing, BEC, insider threat, DDoS) should have a documented runbook with specific steps, decision trees, and escalation criteria.
• Log sources are configured and collecting. All critical sources enabled: Windows Security Events (4688 with CommandLine), Sysmon, firewall logs, DNS logs, proxy logs, EDR telemetry, cloud audit logs.
• Playbook for evidence preservation. Chain of custody template, forensic image capture procedure (using Velociraptor), memory acquisition steps.
• Communication plan. Who to call, when to call them, and what to say. Internal: SOC manager, legal, PR, executive leadership. External: law enforcement (CISA, FBI), IR retainer, cyber insurance.
• Tool access and permissions. Analysts have the credentials and access needed to quarantine hosts, block IPs, reset passwords, and access SIEM logs (Splunk/Elastic).
• Backups are tested. Regular recovery drills. The backup is only as good as the most recent restore test.
• War room. Physical or virtual space for the IR team to coordinate during active incidents.

Key Decision Point

Phase 2: Detection and Analysis

Goal: Identify that an incident is occurring and determine its scope and impact.

This phase starts with an alert and ends with a confirmed incident classification. It is where SOC analysts spend most of their time.

Detection Sources

Initial Triage — Analyst Decision Tree

Alert fires
    │
    ├─ Is this a false positive?
    │   YES → Document reason, close alert, update tuning
    │   NO  → Continue
    │
    ├─ Is this a known-good event? (approved scan, pentest, maintenance window)
    │   YES → Tag as authorized, close
    │   NO  → Continue
    │
    ├─ What is the severity?
    │   Critical (ransomware, credential theft, active C2) → Immediate escalation
    │   High (phishing with payload, single host compromise) → Assign incident lead
    │   Medium (scan, policy violation) → Investigate same shift
    │   Low (single failed login, single malware detection) → Investigate within 24h
    │
    └─ Escalate to Incident Lead with:
        • Initial assessment (what happened, when, affected systems, confidence)
        • Evidence (screenshots, log extracts, packet captures)
        • Recommended initial containment action

Analyst Actions During Detection

1. Confirm the alert. Review the raw logs. Don’t trust the correlation rule blindly — verify the underlying events exist and make sense.
2. Scope the incident. What systems are affected? What users? What data is at risk? Start with the initial alert and pivot outward.
3. Preserve evidence. Snapshot VMs, capture memory, collect logs, take screenshots. Work from a forensic copy, never the original.
4. Document everything. Timelines, actions taken, findings, decisions made. This documentation is critical for post-incident analysis and potential legal action.
5. Classify the incident. Type (malware, unauthorized access, data breach), severity (Critical/High/Medium/Low), scope (single host, user, department, organization).

Key Decision Point

Phase 3: Containment, Eradication, and Recovery

Goal: Stop the bleeding, remove the adversary, and restore normal operations.

NIST groups these three sub-phases together because they often happen in parallel or iteratively.

Containment — Short-Term

Goal: Prevent the attack from spreading while collecting evidence.

Checklist

• Isolate affected hosts. Disconnect from network (pull the cable or disable the virtual NIC). Do not shut down — you lose volatile evidence (memory, running processes, network connections).
• Block C2 infrastructure. Add C2 IPs/domains to firewall block list and DNS sinkhole. Verify block took effect.
• Disable compromised accounts. Reset passwords, revoke tokens, disable accounts. For service accounts, rotate credentials.
• Block egress paths. Temporarily restrict outbound traffic from affected network segments.
• Preserve system state. Create memory dump, take VM snapshot, capture running processes, active network connections, and logged-on users.

Containment — Long-Term

Goal: Establish a more permanent containment while investigation continues.

• Apply temporary ACLs on firewalls for C2 IPs and attacker infrastructure.
• Set up network monitoring specific to the attacker’s TTPs (e.g., additional DNS logging, network tap on affected segment).
• Create forensic images of affected systems for deep analysis.
• Deploy honeypots if appropriate (decoy credentials, files, or systems to track adversary activity).

Eradication

Goal: Remove all traces of the adversary from the environment.

Checklist

• Remove malware. Delete malicious files, registry entries, scheduled tasks, services.
• Patch vulnerabilities. Apply patches for CVEs that were exploited. If no patch exists, apply workaround (e.g., disable the vulnerable feature).
• Remove persistence mechanisms. Check all autostart locations: registry Run keys, scheduled tasks, services, WMI subscriptions, startup folders, browser extensions.
• Reset ALL credentials that may have been exposed. Not just the initial compromised account — assume the attacker harvested credentials (Kerberos tickets, NTLM hashes, service account passwords).
• Rotate secrets. API keys, service account passwords, certificates that the attacker may have accessed.

Recovery

Goal: Safely return affected systems to production.

Checklist

• Restore from clean backup. Verify the backup was created before the compromise. Scan the restored system.
• Rebuild from known-good image. For critical systems, rebuild completely rather than relying on clean-up scripts.
• Install latest patches and security updates before returning to production.
• Return to production incrementally. Monitor closely for 48-72 hours after restoration. Watch for re-infection.
• Verify all containment measures are working. C2 blocks active, accounts disabled, patches applied.
• Notify affected users. Brief communication: “access has been restored, no action needed.”

Key Decision Points

Phase 4: Post-Incident Activity (Lessons Learned)

Goal: Improve processes, detection, and defenses to prevent recurrence.

This phase is the most commonly skipped — and the most valuable for improving the SOC over time.

Post-Mortem Meeting

Within 2 weeks of recovery, hold a lessons-learned meeting with all parties involved:

Agenda

1. Timeline review. Walk through the incident timeline second-by-second. What happened and when? Were there gaps in detection or response?
2. What went well. Start positive. What processes, tools, or decisions worked effectively?
3. What went wrong. No blame. Identify root causes: missed alerts, slow containment, unclear escalation, insufficient log coverage, communication failures.
4. Action items. Create specific, assigned, dated improvement items.

Post-Mortem Template

Detection Improvement

Based on incident findings, update detection rules:

• New sigma rules for the specific TTPs observed.
• Tune existing rules to reduce false positives for similar scenarios.
• New dashboards for monitoring the attack vector that was exploited.

Playbook Updates

If the incident revealed gaps in existing playbooks, update them:

• Add the new scenario to the playbook library.
• Include specific log sources and queries that were useful.
• Update escalation criteria based on what was learned.

Summary: The IR Phases at a Glance

Related

• Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
• Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
• Active Directory Compromise Response — detection and response for T1558 techniques

Sources

• NIST SP 800-61 Rev 2
• CISA Incident Response Plan Basics
• SANS Incident Handler Handbook
• NIST Cybersecurity Framework