Ir Playbook Templates

<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
name: ir-playbook-templates
description: Incident response playbook templates following NIST SP 800-61 phases for six common incident types
tags: [playbook, security]
---

# Incident Response Playbook Templates

## Overview

Structured incident response playbooks reduce mean-time-to-contain (MTTC) by 70% compared to ad-hoc responses. These templates follow the NIST SP 800-61r2 framework and provide ready-to-execute runbooks for the six most common security incident types.

**Core principle:** Every minute without a plan during an active incident is a minute of uncontrolled damage.

Each playbook covers the full NIST IR lifecycle:

1. **Preparation** -- readiness posture before incidents occur
2. **Detection & Analysis** -- identifying and classifying the incident
3. **Containment** -- stopping the spread of damage
4. **Eradication** -- removing the root cause
5. **Recovery** -- restoring systems to normal operations
6. **Post-Incident Activity** -- lessons learned and process improvement

## When to Use This Skill

- A security alert fires and you need a structured response plan
- You are building or updating your organization's IR runbooks
- An active incident requires step-by-step guidance for containment
- You need to define escalation criteria and communication plans
- A compliance audit requires documented IR procedures (SOC 2, ISO 27001, GDPR)
- You are running a tabletop exercise or IR drill

## How It Works

### Step 1: Detect and Classify the Incident

Determine the incident type and assign a severity level.

**Severity Classification Matrix:**

| Severity | Criteria | Response SLA | Escalation |
|----------|----------|--------------|------------|
| **SEV-1 Critical** | Active data exfil, ransomware spreading, full compromise | 15 min | CISO + Legal + Exec immediately |
| **SEV-2 High** | Confirmed breach, credential theft, active attacker in network | 30 min | Security Lead + Engineering Lead |
| **SEV-3 Medium** | Suspicious activity, single account compromise, contained DDoS | 2 hours | Security Team on-call |
| **SEV-4 Low** | Failed attack attempts, policy violations, phishing (no click) | 24 hours | Security Team queue |

**Incident Type Decision Tree:**

```
Alert Received
  |
  +-- Is it encrypting/locking files? --> RANSOMWARE
  |
  +-- Is data leaving the network? --> DATA BREACH / EXFILTRATION
  |
  +-- Is service availability impacted by traffic? --> DDoS ATTACK
  |
  +-- Are credentials confirmed compromised? --> ACCOUNT COMPROMISE
  |
  +-- Is the actor an internal employee/contractor? --> INSIDER THREAT
  |
  +-- Is the vector a third-party tool/dependency? --> SUPPLY CHAIN COMPROMISE
```

### Step 2: Activate the Response Team

**Core IR Team Roles:**

| Role | Responsibility | Backup Required |
|------|---------------|-----------------|
| Incident Commander (IC) | Overall coordination, decision authority | Yes |
| Security Analyst | Technical investigation and forensics | Yes |
| Communications Lead | Internal/external messaging | Yes |
| Engineering Lead | System access, containment actions | Yes |
| Legal Counsel | Regulatory obligations, liability | On-call |
| Executive Sponsor | Business decisions, public statements | On-call |

**Activation checklist:**

```
[ ] Incident Commander identified and acknowledged
[ ] War room / incident channel created (Slack: #inc-YYYY-MM-DD-<short-name>)
[ ] Bridge call initiated (for SEV-1/SEV-2)
[ ] Incident ticket created in tracking system
[ ] Initial severity assigned
[ ] Relevant playbook selected
```

### Step 3: Contain the Threat

Containment strategies vary by incident type. Select the appropriate playbook below. General containment principles:

- **Short-term containment** -- stop the bleeding immediately (isolate host, block IP, disable account)
- **Long-term containment** -- stabilize while preparing eradication (segment network, apply temporary rules)
- **Evidence preservation** -- NEVER wipe or reboot a system before capturing forensic data

### Step 4: Eradicate the Root Cause

After containment, identify and remove:

- Malware artifacts, backdoors, persistence mechanisms
- Compromised credentials (rotate ALL affected credentials)
- Vulnerable software or configurations that enabled the attack
- Attacker-created accounts, scheduled tasks, cron jobs

### Step 5: Recover Systems

- Restore from known-good backups (verified pre-compromise)
- Rebuild compromised systems from hardened images
- Re-enable services incrementally with monitoring
- Validate integrity of restored data
- Confirm no residual attacker presence

### Step 6: Conduct Post-Mortem

```
Post-Incident Review Template:
================================
Incident ID:       INC-YYYY-NNNN
Date of incident:  YYYY-MM-DD
Date of review:    YYYY-MM-DD
Severity:          SEV-N
Type:              [Incident Type]

Timeline:
  - HH:MM  Detection
  - HH:MM  Triage started
  - HH:MM  Containment achieved
  - HH:MM  Eradication complete
  - HH:MM  Recovery verified

Root Cause:
  [Description]

What Went Well:
  - [Item]

What Needs Improvement:
  - [Item]

Action Items:
  - [ ] [Action] -- Owner: [Name] -- Due: [Date]
```

## Examples

### Example 1: Complete Ransomware Response Playbook

**Trigger conditions:** Endpoint detection alert for file encryption activity, user reports of locked files, ransom note displayed on screen.

**Severity:** SEV-1 Critical (assume lateral movement until proven otherwise)

```
RANSOMWARE RESPONSE PLAYBOOK
==============================

PHASE 1: DETECTION & ANALYSIS (0-15 min)
------------------------------------------
[ ] Confirm ransomware (check file extensions, ransom note content)
[ ] Identify ransomware variant (use ID Ransomware or similar)
[ ] Determine patient zero (first infected host, timestamp)
[ ] Assess scope: how many hosts show encryption activity?
[ ] Check if backups are accessible and unaffected
[ ] Capture initial indicators of compromise (IoCs):
    - File hashes of ransomware binary
    - C2 server IPs/domains
    - Ransom note text (for variant identification)

PHASE 2: CONTAINMENT (15-60 min)
----------------------------------
IMMEDIATE (first 5 minutes):
[ ] Isolate infected hosts from network (disconnect, do NOT power off)
[ ] Block known C2 IPs/domains at firewall and DNS
[ ] Disable SMB/lateral movement protocols on affected VLANs
[ ] Suspend compromised service accounts

NETWORK-LEVEL:
[ ] Segment affected network zones
[ ] Enable enhanced logging on all boundary devices
[ ] Block ransomware-associated file extensions at email gateway
[ ] Review and block suspicious scheduled tasks across domain

DECISION TREE -- TO PAY OR NOT TO PAY:
  |
  +-- Are backups available and verified clean?
  |     YES --> Do NOT pay. Proceed to eradication.
  |     NO  --> Continue assessment:
  |
  +-- Is the data critical with no alternative recovery?
  |     YES --> Engage legal counsel and law enforcement.
  |              Negotiate through professional negotiator ONLY.
  |     NO  --> Accept data loss. Proceed to eradication.
  |
  NOTE: FBI and CISA recommend AGAINST paying ransom.
        Payment does not guarantee decryption keys.

PHASE 3: ERADICATION (1-24 hours)
------------------------------------
[ ] Identify initial access vector (phishing, RDP, vulnerability)
[ ] Remove all ransomware artifacts from affected hosts
[ ] Scan entire environment for dormant payloads
[ ] Reset ALL credentials (assume domain-wide compromise):
    - Domain admin accounts
    - Service accounts
    - Local admin accounts
    - KRBTGT (twice, 12 hours apart for Kerberos)
[ ] Patch the exploited vulnerability
[ ] Revoke and reissue certificates if CA was compromised

PHASE 4: RECOVERY (24-72 hours)
---------------------------------
[ ] Restore from verified clean backups (test restore first)
[ ] Rebuild systems that cannot be verified clean
[ ] Re-enable services incrementally:
    1. Core infrastructure (AD, DNS, DHCP)
    2. Internal business applications
    3. External-facing services
[ ] Monitor for re-infection indicators for 72 hours minimum
[ ] Validate data integrity of restored systems

PHASE 5: POST-INCIDENT (72 hours - 2 weeks)
----------------------------------------------
[ ] Conduct blameless post-mortem within 5 business days
[ ] File law enforcement report (FBI IC3, local CERT)
[ ] Notify cyber insurance carrier
[ ] Update detection rules based on observed TTPs
[ ] Schedule follow-up vulnerability assessment
```

### Example 2: Data Breach Notification Timeline (GDPR 72-Hour Rule)

**Trigger conditions:** Confirmed unauthorized access to personal data of EU residents.

```
GDPR BREACH NOTIFICATION TIMELINE
====================================

HOUR 0: BREACH CONFIRMED
--------------------------
[ ] Document: what data, how many records, what categories of data subjects
[ ] Assign Data Protection Officer (DPO) as notification coordinator
[ ] Begin risk assessment: likelihood and severity of impact on individuals

HOUR 0-24: INTERNAL ASSESSMENT
--------------------------------
[ ] Complete Data Protection Impact Assessment (DPIA):
    - Nature of breach (confidentiality, integrity, availability)
    - Categories of personal data (Art. 4 GDPR)
    - Approximate number of data subjects affected
    - Likely consequences for data subjects
    - Measures taken or proposed to mitigate
[ ] Determine if notification to supervisory authority is required
    (required unless "unlikely to result in a risk to rights and freedoms")
[ ] Draft notification to supervisory authority (Art. 33)
[ ] Prepare data subject notification if high risk (Art. 34)

HOUR 24-48: LEGAL REVIEW
--------------------------
[ ] Legal counsel reviews notification drafts
[ ] Identify ALL applicable jurisdictions (GDPR, CCPA, state laws)
[ ] Confirm notification obligations per jurisdiction:
    - EU/EEA: 72 hours to supervisory authority (Art. 33)
    - CCPA: "most expedient time possible" to individuals
    - HIPAA: 60 days to HHS, individuals, media (if >500)
    - PCI DSS: Immediately to card brands and acquiring bank

HOUR 48-72: NOTIFICATION
--------------------------
[ ] Submit notification to lead supervisory authority
[ ] Notify additional supervisory authorities if cross-border
[ ] If high risk to individuals: notify data subjects directly
    - Clear, plain language
    - Description of breach
    - DPO contact details
    - Likely consequences
    - Measures taken to mitigate
[ ] Document everything in breach register (Art. 33(5))

POST-72 HOURS: ONGOING
------------------------
[ ] Provide supplementary information to authority as investigation progresses
[ ] Respond to authority inquiries within requested timeframes
[ ] Monitor for evidence of data misuse
[ ] Offer credit monitoring/identity protection if appropriate
```

### Example 3: Slack/PagerDuty Alert Template for Incident Communication

```
INCIDENT COMMUNICATION TEMPLATES
===================================

--- PAGERDUTY ALERT (INITIAL) ---

Title: [SEV-N] [INCIDENT TYPE] - [Brief Description]
Service: [Affected Service]
Urgency: [High/Low]
Details:
  What: [1-sentence description of what was detected]
  Impact: [What is affected -- users, data, systems]
  Status: Investigating
  IC: [Name]
  Channel: #inc-YYYY-MM-DD-<shortname>

--- SLACK: INITIAL NOTIFICATION (#incidents) ---

:rotating_light: **INCIDENT DECLARED**
**Severity:** SEV-N
**Type:** [Ransomware / Data Breach / DDoS / Account Compromise / Insider / Supply Chain]
**Summary:** [1-2 sentence description]
**Impact:** [Who/what is affected]
**Incident Commander:** @[name]
**War Room:** #inc-YYYY-MM-DD-<shortname>
**Bridge:** [Zoom/Meet link]
**Status:** :yellow_circle: Investigating

DO: Join the war room if you are on the response team.
DO NOT: Speculate in public channels. All comms go through IC.

--- SLACK: STATUS UPDATE (every 30 min for SEV-1/2) ---

:loudspeaker: **INCIDENT UPDATE** | [Incident ID]
**Time:** HH:MM UTC
**Status:** :yellow_circle: Containing / :large_blue_circle: Eradicating / :green_circle: Recovering
**Update:** [What changed since last update]
**Next Steps:** [What the team is doing next]
**ETA to Resolution:** [Estimate or "Unknown"]

--- SLACK: RESOLUTION ---

:white_check_mark: **INCIDENT RESOLVED** | [Incident ID]
**Duration:** [X hours Y minutes]
**Root Cause:** [Brief description]
**Impact Summary:** [Users affected, data impacted, downtime]
**Post-Mortem:** Scheduled for [Date] at [Time]
**Action Items:** [Link to tracking ticket]
```

## Best Practices

### Do This

- **Prepare before incidents happen** -- run tabletop exercises quarterly, keep contact lists updated, and verify backup restoration procedures monthly
- **Follow the playbook even under pressure** -- the playbook exists because calm thinking during chaos is unreliable
- **Preserve evidence first, contain second** -- take memory dumps and disk images before wiping anything
- **Communicate early and often** -- stakeholders tolerate uncertainty far better than silence
- **Assume breach scope is larger than initial findings** -- attackers rarely compromise only one system
- **Document everything with timestamps** -- your incident log is a legal document
- **Rotate ALL credentials in the blast radius** -- partial credential rotation leaves doors open
- **Test your playbooks with realistic drills** -- an untested playbook is a false sense of security

### Don't Do This

- **Don't skip the post-mortem** -- organizations that skip post-mortems repeat the same incidents
- **Don't assign blame** -- blameless post-mortems produce actionable improvements; blame produces silence
- **Don't reboot compromised systems** -- volatile memory evidence is lost forever on reboot
- **Don't communicate through unofficial channels** -- all incident communications must go through the IC
- **Don't negotiate directly with ransomware operators** -- use professional negotiators if payment is being considered
- **Don't assume one playbook fits all** -- each incident type has unique containment and eradication requirements
- **Don't treat the first affected system as patient zero** -- the real initial compromise is usually earlier and elsewhere
- **Don't restore from backups without verifying they pre-date the compromise** -- attackers often persist in backups

## Security Checklist

### IR Readiness

- [ ] IR policy documented and approved by executive leadership
- [ ] IR team roster with primary and backup for each role
- [ ] Contact list for legal counsel, law enforcement, cyber insurance, PR firm
- [ ] Communication templates pre-approved by legal (internal, customer, regulator, media)
- [ ] Playbooks exist for all six incident types listed in this document
- [ ] Playbooks reviewed and updated within the last 6 months
- [ ] Tabletop exercise conducted within the last quarter
- [ ] Full IR simulation (red team + blue team) conducted within the last year

### Communication Plan

- [ ] Internal escalation paths defined for each severity level
- [ ] External notification obligations documented per jurisdiction (GDPR, CCPA, HIPAA, PCI)
- [ ] Pre-drafted holding statements for public communications
- [ ] Designated spokesperson(s) identified and media-trained
- [ ] Customer notification templates prepared
- [ ] Regulatory notification templates prepared with required data fields

### Evidence Chain of Custody

- [ ] Forensic imaging tools available and tested (FTK Imager, dd, AVML)
- [ ] Evidence handling procedures documented (hash verification, chain of custody forms)
- [ ] Secure evidence storage location designated (encrypted, access-controlled)
- [ ] Log retention policies ensure logs are available for investigation (minimum 90 days hot, 1 year cold)
- [ ] Network traffic capture capability available (full PCAP for critical segments)
- [ ] Memory forensics capability available (Volatility, Rekall)

### Lessons Learned Process

- [ ] Post-mortem template standardized across the organization
- [ ] Post-mortem scheduled within 5 business days of incident closure
- [ ] Action items tracked in a ticketing system with owners and due dates
- [ ] Action item completion rate reviewed monthly by security leadership
- [ ] Incident metrics tracked: MTTD, MTTC, MTTR, incidents by type/severity
- [ ] Annual IR maturity assessment conducted

## Related Skills

- @mitre-attck-reference -- map observed attacker techniques to MITRE ATT&CK for better detection and response
- @sigma-rules-guide -- create and deploy detection rules based on incident indicators
- @cve-epss-guide -- prioritize vulnerability remediation to prevent incidents from known CVEs

## Additional Resources

- **NIST SP 800-61r2** -- Computer Security Incident Handling Guide (primary framework)
- **NIST SP 800-86** -- Guide to Integrating Forensic Techniques into Incident Response
- **SANS Incident Handler's Handbook** -- practical field guide for incident responders
- **FIRST CSIRT Services Framework** -- capability maturity model for IR teams
- **GDPR Articles 33-34** -- breach notification requirements for EU personal data
- **CISA Incident Response Playbooks** -- US government IR playbooks for common incident types
- **The Ransomware Response Checklist (CISA)** -- step-by-step ransomware-specific guidance
- **VERIS Framework** -- vocabulary for describing security incidents in a structured format

<!-- Source: .faos/custom/skills/security/ir-playbook-templates/SKILL.md -->