Ir Playbook

Incident Response Playbook -- NIST SP 800-61 Rev 2 / SANS Incident Handler's Handbook

> Frameworks: NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide), SANS Incident Handler's Handbook > Role: SOC Analyst, Security Engineer, vCISO > Time: 30-60 min > Output: Incident response plan with severity classification, containment decision tree, communication templates, escalation criteria, and post-incident handoff checklist

---

1. When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill when any of the following conditions are met:

• Active security incident detected -- An alert, anomaly, or user report indicates a potential or confirmed security event requiring coordinated response.
• Incident classification needed -- An event has been detected and needs to be categorized by type (malware, unauthorized access, data exfiltration, denial of service, insider threat) and severity.
• Containment decision required -- The responder needs guidance on whether to isolate, quarantine, or monitor the affected system based on business impact and threat severity.
• Stakeholder notification planning -- The incident requires communication to internal leadership, legal counsel, regulators, law enforcement, or affected customers.
• Evidence preservation guidance -- Digital evidence must be collected and preserved before containment or eradication actions alter the environment.
• Escalation criteria evaluation -- The responder needs to determine whether the incident warrants escalation to senior leadership, external IR firms, or law enforcement.
• Post-incident handoff -- The active response phase is concluding and the incident must be transitioned to the post-incident review process.

Do not use when: The task is purely forensic evidence collection (use forensics-checklist), focused solely on containment tactics (use containment), or limited to post-incident retrospective (use post-incident-review).

---

2. Context the Agent Needs

Before beginning, gather or confirm the following. Mark each item as obtained or missing and proceed with available information, noting gaps as assumptions.

• [ ] Incident trigger -- What alert, report, or observation initiated the response? (SIEM alert, EDR detection, user report, external notification, threat intel)
• [ ] Affected systems -- Hostnames, IP addresses, cloud resources, applications, and services impacted or suspected of compromise.
• [ ] Timeline -- When was the activity first observed? When was it reported? Known duration of exposure.
• [ ] Indicators of compromise (IOCs) -- File hashes, IP addresses, domains, URLs, email addresses, registry keys, or behavioral indicators observed.
• [ ] Business context -- What business functions do the affected systems support? Revenue impact, customer impact, regulatory exposure.
• [ ] Current state -- Is the attack ongoing, contained, or resolved? What actions have already been taken?
• [ ] Existing IR plan -- Does the organization have a documented IR plan, designated IR team, and established communication channels?
• [ ] Regulatory obligations -- Applicable breach notification requirements (GDPR 72-hour rule, HIPAA, state breach notification laws, SEC 4-day rule, PCI DSS).
• [ ] Third-party dependencies -- Managed security providers (MSSP/MDR), cyber insurance carrier notification requirements, external IR retainer.

---

3. Process

This process follows the NIST SP 800-61 Rev 2 four-phase lifecycle, cross-referenced with the SANS six-step process where the models diverge.

NIST SP 800-61 Rev 2 Phases:
  1. Preparation
  2. Detection & Analysis
  3. Containment, Eradication & Recovery
  4. Post-Incident Activity

SANS Incident Handler's Handbook Steps:
  1. Preparation
  2. Identification
  3. Containment
  4. Eradication
  5. Recovery
  6. Lessons Learned

Mapping:
  NIST Phase 1 = SANS Step 1
  NIST Phase 2 = SANS Step 2
  NIST Phase 3 = SANS Steps 3 + 4 + 5
  NIST Phase 4 = SANS Step 6

Phase 1: Preparation (NIST) / Preparation (SANS)

Verify that the foundational elements for incident response are in place. If gaps exist, document them as findings and proceed.

IR readiness checklist:

| Element | Status | Notes | |---------|--------|-------| | Designated IR team with roles and contact info | [ ] | NIST 800-61 Section 2.4.1 | | Documented IR plan reviewed within last 12 months | [ ] | | | Communication channels (out-of-band, not dependent on compromised infrastructure) | [ ] | Secure messaging, bridge lines | | Forensic toolkit available (disk imaging, memory capture, network capture) | [ ] | | | Log sources centralized and accessible (SIEM, cloud trail, EDR console) | [ ] | | | Legal counsel identified and reachable | [ ] | Internal or external | | Cyber insurance policy and carrier contact | [ ] | Notification within 24-72h typical | | External IR retainer (if applicable) | [ ] | | | Regulatory notification requirements documented | [ ] | GDPR, HIPAA, state laws, SEC | | Evidence storage with chain-of-custody procedures | [ ] | |

Phase 2: Detection and Analysis (NIST) / Identification (SANS)

Step 2.1: Incident Classification

Classify the incident using the NIST SP 800-61 taxonomy:

| Incident Category | Description | Examples | |-------------------|-------------|----------| | Unauthorized Access | Unauthorized logical access to systems, networks, or data | Compromised credentials, brute force success, privilege escalation | | Malware | Malicious code execution on organization systems | Ransomware, trojan, worm, cryptominer, rootkit | | Destructive / Wiper | Malware designed to destroy data or render systems inoperable, with no recovery mechanism (unlike ransomware) | Wiper malware, MBR overwrite, firmware destruction, partition table corruption | | Data Exfiltration | Unauthorized transfer of data outside the organization | Database dump to external host, email forwarding rule, cloud storage sync | | Denial of Service | Disruption of service availability | DDoS, application-layer flood, resource exhaustion | | Insider Threat | Malicious or negligent actions by authorized users | Data theft by employee, accidental exposure, policy violation | | Supply Chain Compromise | Compromise via trusted third-party software or service | Malicious update, compromised dependency, vendor breach | | Web Application Attack | Exploitation of web application vulnerabilities | SQL injection, XSS, SSRF, API abuse | | Social Engineering | Manipulation of personnel to gain access or information | Phishing, BEC, vishing, pretexting |

Step 2.2: Severity Determination

Assign severity based on the combination of functional impact, information impact, and recoverability (NIST SP 800-61 Table 3-2):

Functional Impact:

| Level | Definition | |-------|------------| | None | No effect on the organization's ability to provide services | | Low | Minimal effect; organization can still provide all critical services | | Medium | Organization has lost the ability to provide a critical service to a subset of users | | High | Organization has lost the ability to provide one or more critical services to all users |

Information Impact:

| Level | Definition | |-------|------------| | None | No information was exfiltrated, changed, deleted, or compromised | | Privacy Breach | PII or PHI of individuals was accessed or exfiltrated | | Proprietary Breach | Trade secrets, IP, or non-public business information was accessed or exfiltrated | | Integrity Loss | Sensitive or critical information was changed or deleted |

Recoverability:

| Level | Definition | |-------|------------| | Regular | Time to recovery is predictable with existing resources | | Supplemented | Time to recovery is predictable but requires additional resources (external IR, vendor support) | | Extended | Time to recovery is unpredictable; requires significant resources | | Not Recoverable | Recovery is not possible (e.g., data destroyed with no backup) |

Severity Matrix:

| Severity | Criteria | Response Posture | |----------|----------|-----------------| | SEV-1 (Critical) | High functional impact OR privacy/integrity breach with extended/not-recoverable timeline | All-hands response; executive notification within 1 hour; external IR engagement; legal counsel activated | | SEV-2 (High) | Medium functional impact OR proprietary breach with supplemented recovery | Dedicated IR team engaged; management notification within 4 hours; consider external support | | SEV-3 (Medium) | Low functional impact OR information impact with regular recovery | IR team investigates during business hours; management notification within 24 hours | | SEV-4 (Low) | None/minimal functional impact; no information impact; regular recovery | Documented and monitored; addressed in normal operations |

Step 2.3: Indicator Analysis

For each IOC, document and cross-reference:

Indicator Analysis Record:
- Indicator Type:    [IP | Domain | Hash (MD5/SHA1/SHA256) | URL | Email | File Path | Registry Key | Behavioral]
- Indicator Value:   [value]
- Source:            [SIEM alert | EDR detection | Threat intel feed | Manual discovery]
- First Seen:        [YYYY-MM-DD HH:MM UTC]
- Last Seen:         [YYYY-MM-DD HH:MM UTC]
- Affected Systems:  [hostname/IP list]
- TI Enrichment:     [VirusTotal | AbuseIPDB | Shodan | MISP | Internal TI]
- ATT&CK Technique:  [T-code and name]
- Confidence:        [Confirmed | Probable | Suspected]

Phase 3: Containment, Eradication, and Recovery (NIST) / Containment + Eradication + Recovery (SANS)

Step 3.1: Containment Decision Tree

Use this decision tree to determine the appropriate containment strategy. Each decision balances security risk against business impact.

START: Is the attack actively ongoing?
  |
  +-- YES --> Is data actively being exfiltrated?
  |             |
  |             +-- YES --> IMMEDIATE CONTAINMENT
  |             |           - Network isolation (disable switchport / security group)
  |             |           - Block egress to C2 IPs/domains at firewall
  |             |           - Capture memory before power-off if possible
  |             |           - Notify legal (potential breach notification trigger)
  |             |
  |             +-- NO --> Is the attacker moving laterally?
  |                         |
  |                         +-- YES --> SHORT-TERM CONTAINMENT
  |                         |           - Isolate affected subnet/VLAN
  |                         |           - Disable compromised accounts
  |                         |           - Deploy emergency firewall rules
  |                         |           - Preserve evidence before changes
  |                         |
  |                         +-- NO --> MONITORED CONTAINMENT
  |                                     - Increase logging/monitoring
  |                                     - Deploy network capture on affected segments
  |                                     - Prepare containment actions for rapid execution
  |                                     - Set time limit for observation (max 24h)
  |
  +-- NO --> Is the affected system business-critical?
              |
              +-- YES --> SURGICAL CONTAINMENT
              |           - Minimal disruption actions only
              |           - Block specific IOCs (IPs, domains, hashes)
              |           - Rotate compromised credentials
              |           - Schedule full containment during maintenance window
              |
              +-- NO --> STANDARD CONTAINMENT
                          - Isolate system from network
                          - Image disk for forensics
                          - Rebuild from known-good baseline

Step 3.1b: Wiper / Destructive Malware Response Track

Wiper malware destroys data irrecoverably (unlike ransomware which preserves encrypted data for ransom). This demands a fundamentally different response posture.

Immediate actions (first 30 minutes):

1. Isolate aggressively -- Disconnect affected segments at switch/firewall level. Wipers propagate via SMB, WMI, or GPO. Do not wait for forensic imaging.
2. Preemptively shut down unaffected systems if propagation vector is unknown. A wiper that has not triggered is stopped by cold shutdown.
3. Verify backup integrity -- Wipers target Volume Shadow Copies, backup agents, and NAS/SAN. Confirm offline/immutable backups exist before recovery planning.
4. Preserve one affected system (powered off, disk intact) for forensics and attribution.

Key differences from ransomware:

| Factor | Ransomware | Wiper / Destructive | |--------|-----------|---------------------| | Recovery | Via decryption key | Only from immutable backups | | Motivation | Financial | Disruption, sabotage, geopolitical | | Containment urgency | High | Critical -- every second is permanent data loss | | Attribution | Lower priority (criminal) | Higher priority (often nation-state; FBI/CISA/ISAC engagement) |

Nation-state context: State-sponsored actors (Iranian, Russian, North Korean) increasingly deploy wipers against healthcare and defense supply chains. The 2026 Stryker medtech wiper attack demonstrates ePHI custodians are active targets. IR teams must account for pre-positioned backdoors beyond the wiper payload, potential prior data exfiltration, and the need for FBI/CISA/H-ISAC notification.

Step 3.2: Eradication

After containment, remove the threat from the environment:

1. Identify root cause -- Determine the initial access vector (MITRE ATT&CK Initial Access TA0001)
2. Remove malware and artifacts -- Delete malicious files, scheduled tasks, registry keys, persistence mechanisms
3. Patch exploited vulnerabilities -- Apply security updates that address the exploited vulnerability
4. Revoke compromised credentials -- Reset passwords, rotate API keys, revoke tokens, regenerate certificates
5. Validate removal -- Scan with updated signatures; review logs to confirm no residual attacker activity
6. Harden against re-entry -- Close the initial access vector; apply additional controls (MFA, network segmentation, WAF rules)

Step 3.3: Recovery

Restore systems to normal operations:

1. Restore from known-good state -- Use verified backups or rebuild from golden images; never restore from potentially compromised backups
2. Validate system integrity -- Compare file hashes against known-good baselines; verify configuration integrity
3. Phased reconnection -- Reconnect systems to the network in stages; monitor each phase for signs of re-compromise
4. Enhanced monitoring -- Increase logging verbosity and alerting sensitivity for a minimum of 30 days post-recovery
5. Stakeholder confirmation -- Obtain business owner sign-off before declaring systems operational
6. Update IOC blocklists -- Ensure all identified IOCs remain blocked across perimeter and endpoint controls

Step 3.4: Stakeholder Notification

Use the appropriate communication template based on the audience.

Internal Executive Notification (SEV-1/SEV-2):

Subject: [SEVERITY] Security Incident - [Category] - [Incident ID]

Status: [Active | Contained | Eradicated | Recovered]
Severity: [SEV-1 | SEV-2]
Classification: [Unauthorized Access | Malware | Data Exfiltration | ...]
Time Detected: [YYYY-MM-DD HH:MM UTC]
Affected Systems: [Summary of affected systems/services]
Business Impact: [Description of impact to business operations]
Data Impact: [Type and estimated volume of data affected, if applicable]
Current Actions: [What the IR team is doing now]
Next Update: [Scheduled time for next update]
Incident Commander: [Name and contact]

**Legal/Regulatory Notificat

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.