NIST 800 61 Incident Response Plan Template

Standard Operating Procedure: NIST SP 800-61 Revision 2 Computer Security Incident Response Plan (CSIRP)

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational lifecycle for detecting, containing, eradicating, and recovering from information security incidents at Template Registry. The framework strictly operationalizes the guidelines set forth in NIST Special Publication 800-61 Revision 2 (Computer Security Incident Handling Guide).

The primary objective is to establish an institutional-grade, repeatable, and legally defensible methodology that minimizes operational disruption, preserves forensic integrity, maintains regulatory compliance, and ensures root-cause remediation across all on-premises, cloud-native, and hybrid infrastructure.

---

3. Scope & Prerequisites

3.1 Scope

This procedure applies to all personnel, contractors, cloud workloads (AWS/GCP/Azure), endpoints (macOS, Windows, Linux), and network segments managed by Template Registry.

3.2 Required Tools & Infrastructure

• SIEM / Log Aggregation: Datadog / Splunk Enterprise Security.
• EDR (Endpoint Detection & Response): CrowdStrike Falcon / SentinelOne.
• Forensic Toolkit: SIFT Workstation, Volatility Framework, FTK Imager.
• Out-of-Band Communications: Signal Enterprise / PagerDuty / Dedicated Bridge.
• Ticketing & Case Management: Jira Service Management (Security Project).

3.3 Prerequisites

• Personnel executing Phases 3 and 4 must hold active GIAC Certified Incident Handler (GCIH) or equivalent certifications.
• Unfettered Read/Write access to Security Information and Event Management (SIEM) and AWS IAM administrative controls.

---

4. Roles & Responsibilities (RACI Matrix)

(R = Responsible, A = Accountable, C = Consulted, I = Informed)

---

5. Step-by-Step Procedure

Phase 1: Preparation

Establish baselines, preventive controls, and operational readiness before an event occurs.

• 1.1 Maintain and periodically validate continuous logging across all perimeter devices, identity providers, and cloud control planes.
• 1.2 Ensure out-of-band communication channels (e.g., dedicated Slack/Teams war room, encrypted cellular bridges) are tested monthly.
• 1.3 Conduct quarterly tabletop exercises simulating ransomware, data exfiltration, and supply chain compromise scenarios.
• 1.4 Maintain an up-to-date, cryptographically isolated backup strategy adhering to the 3-2-1-1 rule (3 copies, 2 media types, 1 offsite, 1 immutable).

Phase 2: Detection & Analysis

Identify indicators of compromise (IoCs), validate alerts, and scope the blast radius.

• 2.1 Triage incoming alerts from SIEM, EDR, or external threat intelligence feeds within 15 minutes of generation.
• 2.2 Classify the event according to Template Registry Severity Levels (Sev-1: Critical/Active Breach; Sev-2: Major Incident; Sev-3: Minor/Isolated).
• 2.3 Open an immutable incident ticket in Jira Security, recording timestamps in Coordinated Universal Time (UTC).
• 2.4 Determine the initial vector, attack surface utilized, and whether PII/PHI or proprietary source code has been accessed or exfiltrated.
• 2.5 Convene the Incident Response Team (IRT) via out-of-band bridge if severity is evaluated at Sev-1 or Sev-2.

Phase 3: Containment, Eradication, and Recovery

Halt lateral movement, purge threat actors, and restore secure operations.

Containment

• 3.1 Execute short-term containment protocols (e.g., network isolation via EDR, revoking compromised IAM tokens, blocking malicious IPs at the Edge/WAF).
• 3.2 Preserve volatile system memory (RAM) and disk state prior to any reboot or patching action for forensic analysis.
• 3.3 Implement long-term containment strategies (e.g., segmenting affected subnetworks, resetting enterprise-wide domain credentials if Active Directory is compromised).

Eradication

• 3.4 Identify and eliminate root vulnerabilities (e.g., patch zero-days, remove unauthorized backdoors, revoke rogue SSH keys or service principals).
• 3.5 Scan enterprise endpoints and cloud workloads with updated signature and behavioral rules to ensure absolute threat removal.

Recovery

• 3.6 Rebuild systems from known-good, cryptographically verified immutable golden images or restore clean backups.
• 3.7 Validate system integrity, monitor network traffic anomalies, and verify log ingestion pipelines are fully operational.
• 3.8 Formally declare system restoration to the Incident Commander.

Phase 4: Post-Incident Activity (Lessons Learned)

Analyze performance, update controls, and compile regulatory filings.

• 4.1 Conduct a mandatory Post-Mortem / "Blameless Retrospective" meeting within 72 hours of incident closure.
• 4.2 Draft the formal Incident Report detailing Root Cause Analysis (RCA), timeline of events, and financial/operational impact.
• 4.3 Update detection rules (SIEM/EDR) and firewall signatures to prevent recurrence of the specific attack vector.
• 4.4 Submit mandatory regulatory disclosures to relevant authorities (e.g., GDPR, CCPA, SEC) via Legal Counsel if data exfiltration threshold is breached.

---

6. Quality Assurance & Pro-Tips

Best Practices (Pro-Tips)

• Chain of Custody: Treat every compromised endpoint as potential evidence for legal proceedings. Maintain strict chain-of-custody logs for any disk or memory images extracted.
• Avoid Premature Destruction: Never power down a live compromised host unless operational safety mandates it; memory artifacts are vital for root-cause tracking.
• Preserve Communication Logs: Record all decisions made during the incident response war room in the primary ticket. Do not rely on ephemeral verbal agreements.

Common Pitfalls to Avoid

• Premature Eradication: Purging a backdoor before identifying the persistence mechanism, allowing the attacker to immediately re-compromise the asset.
• Communication Silos: Failing to loop in Legal and PR early, leading to unverified internal leaks or non-compliance with statutory disclosure windows.

Key Performance Indicators (KPIs) & Thresholds

• Mean Time to Detect (MTTD): $\le 15 \text{ minutes}$ for Sev-1 anomalies.
• Mean Time to Respond (MTTR): $\le 60 \text{ minutes}$ from detection to complete containment.
• Post-Mortem Execution: $\le 72 \text{ hours}$ post-resolution.

---

7. Frequently Asked Questions (FAQ)

Q: At what point must an incident be escalated to external legal counsel and regulatory bodies?
A: Any incident resulting in confirmed unauthorized access, exfiltration, or destruction of Personally Identifiable Information (PII), payment card data (PCI-DSS), or proprietary intellectual property must be escalated to Legal within 2 hours of validation to assess statutory notification requirements.

Q: Should we communicate with customers or the public during an active Sev-1 incident?
A: No operational personnel outside of designated Executive Leadership and the PR/Communications lead (coordinated through the Incident Commander) are authorized to release statements. Premature external communications jeopardize containment strategies and legal positioning.

Q: What is the mandatory protocol if an attacker demands a ransomware payment?
A: Template Registry maintains a strict zero-payment policy for ransomware extortion. Immediately notify the CISO and Executive Leadership, isolate the affected environment, and initiate recovery operations from immutable backups.