Cyber Security Incident Response Plan Template NIST

Standard Operating Procedure: NIST-Aligned Cybersecurity Incident Response Plan (CSIRP) Deployment & Execution

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational lifecycle for executing, maintaining, and auditing the Cybersecurity Incident Response Plan (CSIRP) based on the National Institute of Standards and Technology (NIST) Special Publication 800-61 Revision 2 framework.

The purpose of this document is to establish a deterministic, repeatable, and legally defensible methodology for detecting, containing, eradicating, and recovering from information security incidents across all cloud-native and on-premises infrastructure managed by Template Registry. Compliance with this procedure is mandatory for all engineering, operations, and security personnel.

---

3. Scope & Prerequisites

3.1 Scope

• Encompasses all production environments, staging pipelines, corporate networks, and endpoint devices owned, leased, or managed by Template Registry.
• Applies to all third-party vendors and contractors with direct or indirect access to system perimeters.

3.2 Prerequisites & Required Tooling

• SIEM / Log Aggregation: Splunk Enterprise Security / Datadog Security Monitoring.
• EDR (Endpoint Detection & Response): CrowdStrike Falcon Insight.
• Forensic Acquisition: Volatility Foundation, FTK Imager, Autopsy.
• Out-of-Band Communications: PagerDuty (Primary Alerting), Signal / Wickr Enterprise (Encrypted War Room).
• Ticketing & Case Management: Jira Service Management (Security Project).

---

4. Roles & Responsibilities

---

5. Step-by-Step Procedure

Phase 1: Preparation (NIST SP 800-61 Phase 1)

Establish baseline defenses, communication channels, and tooling prior to an event.

• Verify automated log shipping to SIEM is functional for all edge firewalls, identity providers (IdP), and Kubernetes clusters.
• Confirm PagerDuty escalation policies are synchronized with active rotation schedules.
• Validate read/write permissions for forensic storage buckets (s3://tr-sec-forensics-vault-prod).
• Conduct quarterly tabletop exercises simulating data exfiltration and ransomware vectors.

Phase 2: Detection & Analysis (NIST SP 800-61 Phase 2)

Identify anomalies, validate indicators of compromise (IoCs), and scope the incident vector.

• Acknowledge Alert: Ingest security alert from SIEM/EDR within 5 minutes of generation and spin up a dedicated Jira incident ticket (SEC-INC-YYYY-XXXX).
• Triage & Validation: Assess telemetry data to eliminate false positives. Check threat intelligence feeds (AlienVault, VirusTotal) against observed hashes, IPs, and domain names.
• Establish War Room: If severity is classified as SEV-1 (Critical) or SEV-2 (High), spin up the out-of-band encrypted comms channel and bridge the Incident Commander and relevant Leads.
• Initial Scoping: Determine compromised endpoints, user accounts, and data classifications affected.

Phase 3: Containment, Eradication, & Recovery (NIST SP 800-61 Phase 3)

Isolate the threat, remove malicious artifacts, and restore systems to trusted baselines.

• Short-Term Containment: Execute network isolation protocols via EDR (e.g., CrowdStrike containment toggle) for infected hosts. Disable compromised IAM credentials and force global session invalidation in the IdP.
• Forensic Snapshot: Capture volatile memory (RAM) and disk images of impacted systems before executing eradication routines.
• Eradication: Remove malicious persistence mechanisms (cron jobs, registry keys, backdoored binaries, unauthorized IAM roles). Patch underlying vulnerabilities exploited during the vector entry.
• System Recovery: Rebuild production assets from known-clean, immutable Infrastructure-as-Code (IaC) templates or gold master images.
• Validation: Run continuous vulnerability scans and integrity checks for a minimum of 72 hours post-recovery to ensure zero lateral movement persistence.

Phase 4: Post-Incident Activity (Lessons Learned) (NIST SP 800-61 Phase 4)

Analyze response performance, remediate systemic gaps, and fulfill regulatory disclosures.

• Post-Mortem Meeting: Schedule a mandatory post-incident review (PIR) within 5 business days of incident closure.
• Root Cause Analysis (RCA): Draft formal RCA documentation detailing the exact vector, dwell time, impact radius, and control failures.
• Regulatory Notification: If Personally Identifiable Information (PII) or Protected Health Information (PHI) was compromised, initiate legal/PR disclosure protocols within required statutory windows (e.g., GDPR 72-hour rule).
• Remediation Tracking: Create Jira tasks for all engineering hardening recommendations derived from the RCA and assign strict SLAs (SLA: 14 days for Critical patches).

---

6. Quality Assurance & Pro-Tips

Best Practices (Pro-Tips)

• Preserve Chain of Custody: Never analyze a live forensic target directly; always work from a bit-stream forensic duplicate to maintain evidentiary admissibility.
• Assume Breach Mindset: Treat every anomalous lateral movement alert as a potential advanced persistent threat (APT) until proven otherwise.

Common Pitfalls to Avoid

• Premature Eradication: Do not reboot or power down compromised systems prematurely; volatile memory artifacts critical to root-cause attribution will be permanently lost.
• Siloed Communication: Avoid using internal corporate Slack/Teams for SEV-1 incidents where administrative accounts might be compromised; utilize out-of-band channels exclusively.

Key Performance Indicators (KPIs) & Metric Thresholds

• Mean Time to Detect (MTTD): $\le 15 \text{ minutes}$
• Mean Time to Respond (MTTR): $\le 30 \text{ minutes}$ (for SEV-1 containment)
• Containment Efficiency Rate: $\ge 98% $ of incidents contained prior to secondary lateral movement.

---

7. Frequently Asked Questions (FAQ)

Q1: What triggers an immediate escalation to a SEV-1 classification?
A: Active ransomware encryption, confirmed external access to production database clusters containing PII/Financial records, unauthorized privilege escalation to Root/Domain Admin accounts, or active data exfiltration exceeding 1GB to un-whitelisted external IPs.

Q2: Who possesses the sole authority to declare an incident resolved?
A: Only the designated Incident Commander (IC), in direct concurrence with the Lead Security Architect and CISO, can formally transition an incident ticket status to "Closed/Resolved."

Q3: How long must forensic artifacts and incident audit logs be retained?
A: All forensic images, SIEM raw exports, and Jira incident audit logs must be cryptographically hashed and archived in cold storage for a minimum of seven (7) years to satisfy regulatory compliance requirements.