Network Incident Response Playbook

You are a senior incident responder, digital forensics expert, and network security engineer. Generate a detailed, actionable incident response playbook using the NIST SP 800-61r3 framework, built on the six CSF 2.0 Functions.

## Incident
- Type: [Incident type]
- Current phase: [Current phase]
- Environment: [Network environment]
- Status / IOCs: [What you know so far]
- Constraints: [Constraints / considerations]

---

## NIST IR Framework: Complete Playbook for [Incident type]

### Phase 1 — Preparation (verify before next incident)
- Incident response team contacts and escalation path defined?
- IR runbooks approved and accessible offline?
- Network diagrams current and accessible?
- Backup status verified — are backups isolated from production network (cannot be encrypted by ransomware)?
- Out-of-band communication channel (not email/Slack — attacker may be reading them)?

### Phase 2 — Detection and Analysis

**Verify the incident is real**:
- Correlate across multiple data sources: SIEM alerts + EDR alerts + network flow anomalies
- Rule out false positives: scheduled maintenance, legitimate scanning, authorized pen test
- Determine scope: how many systems affected? What data is involved?

**Scope assessment commands** (provide exact commands for [Network environment]):
- Network device: check ARP tables, MAC tables, NetFlow for lateral movement indicators
  - Cisco IOS: `show ip arp`, `show mac address-table`, `show ip cache flow`
  - Cisco NX-OS: `show ip arp`, `show mac address-table`, `show ip flow top-talkers`
  - Palo Alto: `show arp all`, `show session all filter source <IOC-IP>`
- SIEM query templates for [Incident type] detection
- EDR: process tree analysis for the initial compromise host

**Indicators of Compromise to collect**:
- IP addresses (C2, lateral movement sources)
- Domains and DNS queries
- File hashes (MD5, SHA-256)
- Registry keys, scheduled tasks, services (Windows)
- Cron jobs, SUID binaries (Linux)
- Process names and parent-child relationships

### Phase 3 — Containment

**CRITICAL: DO NOT take actions that destroy evidence**:
- Do NOT reimage systems before collecting memory dump and disk image
- Do NOT delete logs — copy them first
- Do NOT alert the insider suspect before disabling their access (they will destroy evidence)
- Do NOT pay ransom before verifying backups are intact and clean

**Short-term containment** (first 15-30 minutes):

For [Incident type], immediate network isolation steps:

*Ransomware*:
- Isolate affected hosts at the switch port level (do not power off — preserve memory for forensics if possible): `interface <port>; shutdown` on Cisco, or via EDR network isolation
- Block C2 domains/IPs at perimeter firewall immediately
- Isolate backup infrastructure from production network — ransomware specifically targets backup systems
- Disable SMB (445) inbound on firewall to prevent EternalBlue-style spread
- Do NOT power off unless ransomware is still actively spreading — powered-on systems allow memory forensics

*Data Breach*:
- Identify and block the exfiltration channel at the firewall (destination IP, port, protocol)
- Preserve evidence: memory dump on the exfiltrating host (`winpmem` on Windows, `lime` kernel module on Linux)
- Place a legal hold on all relevant logs immediately — do not allow rotation or deletion
- GDPR trigger: if EU personal data involved, start 72-hour notification clock from time of confirmed discovery

*DDoS*:
- Contact upstream ISP immediately — request BGP blackhole or scrubbing center activation
- Implement null route for attacked destination: `ip route <destination> 255.255.255.255 Null0` (temporary)
- ACL rate-limit or block source ASNs if attack is from known ranges
- Activate DDoS mitigation service if contracted (Cloudflare, Akamai, Arbor)
- BGP community-based blackholing: advertise /32 with community 65000:666 to trigger upstream null-route

*Insider Threat*:
- Preserve logs BEFORE disabling the account — insiders often have access to delete their own logs
- Coordinate with HR and Legal before taking any action — wrongful termination risk
- Disable account in AD without warning: `Disable-ADAccount -Identity <username>`
- Capture session recording if available (Privileged Access Management solution)
- Preserve all email, file access, and VPN logs under legal hold

*Phishing / Initial Access*:
- Identify all users who received the phishing email (header analysis, mail server logs)
- Reset credentials for all affected users immediately
- Revoke OAuth tokens and active SSO sessions
- Search for persistence mechanisms: new scheduled tasks, new local accounts, registry Run keys

**Long-term containment** (hours to days):
- Deploy network segmentation to isolate affected VLAN/segment
- Implement emergency firewall rules blocking IOC IPs and domains
- Enable enhanced logging: increase verbosity on firewalls, switches, and authentication systems
- Preserve forensic images before any remediation

### Phase 4 — Eradication

- Remove malware/backdoors identified in forensic analysis
- Remove all persistence mechanisms: scheduled tasks, services, registry keys, cron jobs, SSH authorized_keys
- Patch the vulnerability that was exploited (do not re-expose until patched)
- Verify all compromised credentials are reset — assume all credentials on compromised systems are stolen
- For ransomware: do NOT decrypt using attacker's decryptor until you have forensic image (decryptor may contain additional malware)
- Rebuild compromised systems from known-good baseline — do not trust any system that had code execution
- Verify integrity of backup infrastructure before using backups for recovery

### Phase 5 — Recovery

- Restore from clean backup (verify backup date predates the intrusion)
- Monitor restored systems closely for 72 hours — re-infection is common
- Gradually restore services in priority order (most critical first)
- Verify each restored system before re-connecting to production network
- Monitor for re-infection indicators for 30 days post-recovery

### Phase 6 — Post-Incident Activity

**Evidence preservation and chain of custody**:
- Disk images: use `dd` or FTK Imager; document hash (SHA-256) of image and original
- Memory dumps: `winpmem` (Windows), `lime` (Linux), `osxpmem` (macOS)
- Log exports: export from SIEM, EDR, firewall, authentication systems with timestamps
- Document chain of custody: who collected, when, storage location, access log
- Evidence integrity: hash everything immediately after collection; document in case file

**Regulatory notifications** (check if applicable):
- GDPR (EU personal data): notify supervisory authority within 72 hours of confirmed breach
- US state breach notification laws: 30-90 days depending on state
- PCI-DSS: notify card brands and acquiring bank within 24 hours of confirmed cardholder data compromise
- HIPAA: notify HHS within 60 days; patients within 60 days; media if >500 affected in a state

**Lessons learned meeting** (within 2 weeks):
- Timeline reconstruction: when did the attacker first gain access? (may be weeks before detection)
- Detection gap: why was the initial compromise not detected earlier?
- Response gaps: what slowed containment or eradication?
- Control improvements: specific firewall rules, EDR policies, or monitoring rules to add
- Tabletop exercise: schedule a tabletop drill for the same scenario within 90 days

### Summary: Immediate Actions for [Incident type] in Current Phase ([Current phase])
List the top 5 actions to take RIGHT NOW in priority order, with specific commands for [Network environment].