Incident Response Plan Template NIST

Standard Operating Procedure: NIST-Aligned Incident Response Plan Execution

Document ID: SOP-SEC-NIST-800-61-042
Effective Date: October 24, 2023
Version: 4.2.0
Review Cadence: Semi-Annual (Every 6 Months)
Author: Julian Vance, Chief Architect, Template Registry

---

1. 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. Grounded in the NIST SP 800-61 Rev. 2 framework (Computer Security Incident Handling Guide), this document establishes a deterministic, auditable protocol to minimize system downtime, data loss, and reputational impact during high-severity events. All engineering, operations, and security personnel must execute incident response strictly in accordance with these mandates.

---

2. Scope & Prerequisites

Scope

• Applies to all cloud-native infrastructure, on-premises data centers, CI/CD pipelines, container registries, and software-as-a-service (SaaS) environments managed by Template Registry.
• Encompasses all data classifications: Public, Internal, Confidential, and Restricted.

Prerequisites & Required Access

• Identity & Access Management: Active Privileged Access Management (PAM) session with Multi-Factor Authentication (MFA).
• Tooling Access:
  • Security Information and Event Management (SIEM): Datadog / Splunk Enterprise Security.
  • Endpoint Detection and Response (EDR): CrowdStrike Falcon.
  • Incident Management & Ticketing: PagerDuty & Jira Service Management (Enterprise Tier).
  • Forensics & Cloud Storage: AWS S3 Forensic Vault (Write-Once-Read-Many enabled).
• Physical/Environmental: Secure communication channel (Signal Enterprise / Wickr Pro) and out-of-band management console access.

---

3. Roles & Responsibilities (RACI Matrix)

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

---

4. Step-by-Step Procedure

Phase 1: Preparation (Continuous Baseline)

• Verify automated log ingestion across all Kubernetes clusters, serverless functions, and database instances to SIEM.
• Confirm out-of-band communication channels (PagerDuty, secure chat) are active and tested monthly.
• Maintain immutable backups of critical stateful data in accordance with the 3-2-1 backup rule.

Phase 2: Detection & Analysis

• Triage Alert: Acknowledge incoming high-severity alerts in PagerDuty within 5 minutes of paging.
• Classify Incident: Assign an initial severity rating (Sev-1 through Sev-4) based on the Template Registry Impact Matrix.
• Scope Boundary: Query SIEM and EDR platforms to determine patient zero, vector of entry, and lateral movement paths.
• Establish War Room: Initialize the bridge (Zoom/Teams) and open an emergency Jira incident ticket.

Phase 3: Containment, Eradication, & Recovery

• Short-Term Containment: Isolate compromised cloud instances via security group lockdown (Deny-All ingress/egress) or network quarantine in EDR without powering off the host (to preserve RAM artifacts).
• Evidence Preservation: Trigger automated forensic snapshotting of compromised EBS volumes, container memory dumps, and relevant log streams to the AWS S3 Forensic Vault.
• Eradication: Patch vulnerabilities, revoke compromised API keys/IAM tokens, rotate cryptographic secrets via HashiCorp Vault, and redeploy immutable infrastructure from verified clean golden images.
• Recovery: Restore services incrementally, executing synthetic transaction testing and integrity checks before routing production traffic back to remediated endpoints.

Phase 4: Post-Incident Activity ("Lessons Learned")

• Post-Mortem Scheduling: Convene a mandatory blameless post-incident review within 48 hours of incident closure.
• Root Cause Analysis (RCA): Document the exact vector, dwell time, and systemic failures using the "5 Whys" methodology.
• Remediation Tracking: Create Jira backlog tickets for architectural or procedural enhancements with strict execution deadlines (maximum 14 days for high-priority fixes).

---

5. Quality Assurance & Pro-Tips

Best Practices (Pro-Tips)

• Preserve State: Never prematurely shut down a compromised virtual machine or container. Memory forensics require the live execution state to extract injected shellcode or active encryption keys.
• Maintain Chain of Custody: When exporting logs or disk images for law enforcement or third-party forensic analysis, immediately generate and record SHA-256 cryptographic hashes of the artifacts.

Common Pitfalls to Avoid

• Premature Communication: Do not release external statements or notify customers without explicit sign-off from Legal, PR, and the CISO.
• Scope Creep: Avoid attempting deep forensic analysis during active containment; focus strictly on stopping the bleeding first.

Metric Thresholds

• Mean Time to Detect (MTTD): < 10 minutes for Sev-1 anomalies.
• Mean Time to Acknowledge (MTTA): < 5 minutes 24/7/365.
• Mean Time to Contain (MTTC): < 30 minutes from initial verification.

---

6. Frequently Asked Questions (FAQ)

Q: What constitutes a Sev-1 incident under this SOP?
A: A Sev-1 incident is defined as active data exfiltration of Restricted customer data, complete disruption of core Template Registry production systems, or a verified ransomware deployment impacting core infrastructure.

Q: Who possesses the authority to disconnect production traffic from the public internet?
A: The Incident Commander (IC) and the Chief Information Security Officer (CISO) possess unilateral authority to sever external network connections to protect organizational assets.

Q: How long must incident artifacts and forensic logs be retained?
A: All forensic snapshots, SIEM extractions, and post-mortem reports must be securely retained for a minimum of seven (7) years to satisfy compliance and auditing mandates.