Incident Response Plan Example NIST

Standard Operating Procedure: NIST-Compliant Cyber Incident Response Plan (IRP) Execution

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) operationalizes the National Institute of Standards and Technology (NIST) Special Publication 800-61 Revision 2 framework ("Computer Security Incident Handling Guide") for Template Registry. The purpose of this document is to establish a repeatable, forensically sound, and legally defensible methodology for detecting, containing, eradicating, and recovering from information security incidents. Compliance with this SOP is mandatory for all Engineering, Operations, and Security personnel.

---

2. Scope & Prerequisites

Scope

• Encompasses all production environments, staging clusters, corporate IT infrastructure, container registries, source code repositories, and cloud-hosted assets managed by Template Registry.

Prerequisites & Required Tooling

• SIEM / Log Aggregation: Datadog / Splunk Enterprise Security with read/write access.
• EDR Platform: CrowdStrike Falcon / Microsoft Defender for Endpoint (administrative containment privileges required).
• Network Forensics: Wireshark, tcpdump, AWS VPC Flow Logs / CloudTrail access.
• Incident Tracking: Jira Service Management (Security Project) with PagerDuty integration.
• Secure Communications: Signal Enterprise / PGP-encrypted out-of-band communication channels.

---

3. Roles & Responsibilities

---

4. Step-by-Step Procedure

Phase 1: Preparation

• Ensure continuous telemetry collection via EDR, SIEM, and cloud audit logs.
• Verify quarterly out-of-band contact list rotation for the Incident Response Team (IRT).
• Maintain pre-configured forensic disk and memory capture tooling in cold storage.

Phase 2: Detection & Analysis

• Triage alerts generated by SIEM/EDR within 15 minutes of severity-high classification.
• Correlate anomalies across authentication logs, network telemetry, and host-based indicators of compromise (IOCs).
• Classify the incident severity level (Low, Moderate, High, Critical) based on data confidentiality, integrity, and availability impact.
• Open an emergency PagerDuty incident and create a dedicated Jira ticket using template SEC-INCIDENT-TPL.

Phase 3: Containment, Eradication, & Recovery

• Short-Term Containment: Isolate compromised host instances from the internal network via EDR network containment while maintaining hypervisor memory state for forensics.
• Credential Revocation: Terminate all active sessions, invalidate IAM tokens, and force password resets for impacted users and service principals.
• Forensic Acquisition: Capture volatile memory (RAM) and disk images of impacted assets before executing eradication steps.
• Eradication: Remove malicious artifacts, close exploited vulnerabilities, patch underlying code paths, and purge unauthorized persistence mechanisms (e.g., rogue cron jobs, backdoored binaries).
• Recovery: Restore systems from verified clean backups or redeploy immutable infrastructure via automated CI/CD pipelines.
• Validation: Execute continuous vulnerability scans and integrity checks to confirm threat actor eradication.

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

• Schedule and execute a mandatory Post-Incident Review (PIR) meeting within 72 hours of incident closure.
• Compile a comprehensive timeline of events, root cause analysis (RCA), and impact assessment.
• Update detection signatures, WAF rules, and EDR policies to prevent recurrence of the specific vector.
• Archive all forensic artifacts and ticket logs in encrypted cold storage for legal and compliance retention.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Preserve Chain of Custody: Maintain cryptographic hashes (SHA-256) of all collected forensic images immediately upon acquisition.
• Dual-Channel Logging: Never rely solely on the compromised system's local logs; prioritize centralized, write-once-read-many (WORM) log repositories.

Common Pitfalls

• Pitfall: Powering down a compromised host immediately. Correction: This destroys volatile RAM evidence. Use network containment and acquire memory first.
• Pitfall: Internal communication over compromised collaboration apps (e.g., standard Slack channels). Correction: Pivot to out-of-band, encrypted communication (Signal) immediately upon declaring a Critical incident.

Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes for High/Critical alerts.
• Mean Time to Contain (MTTC): < 45 minutes from initial alert validation.

---

6. Frequently Asked Questions (FAQ)

Q: At what point must external regulatory bodies or legal counsel be notified? A: Legal Counsel must be consulted immediately for any incident involving confirmed exfiltration of Personally Identifiable Information (PII), Customer Financial Data, or Intellectual Property. External notification timelines are strictly governed by jurisdictional compliance mandates (e.g., GDPR Article 33, SEC rules).

Q: Can developers have direct shell access to production systems during containment? A: No. Direct interactive shell access is strictly prohibited. All containment and remediation must be executed via automated infrastructure-as-code updates, immutable deployments, or restricted ephemeral debugging sessions authorized by the Incident Commander.