Free Cybersecurity Incident Response Plan Template

STANDARD OPERATING PROCEDURE: Enterprise Cybersecurity Incident Response Plan (CSIRP)

Template Registry Engineering Standards

---

1. Document Control Block

---

2. Executive Summary & Purpose

2.1 Purpose

This Standard Operating Procedure (SOP) establishes a rigorous, repeatable framework for identifying, containing, eradicating, and recovering from cybersecurity incidents across all Template Registry cloud infrastructure, on-premise systems, and software supply chains.

2.2 Objective

To minimize dwell time, prevent data exfiltration, ensure operational continuity, and preserve forensic integrity in strict compliance with NIST SP 800-61 Rev. 2 standards.

---

3. Scope & Prerequisites

3.1 Scope

Applies to all systems, network segments, data stores, code repositories, and personnel (employees, contractors, third-party vendors) operating within the Template Registry organizational boundary.

3.2 Prerequisites & Required Tooling

Execution of this procedure requires verified access to the following immutable toolchain:

• SIEM/Log Aggregation: Datadog / Splunk Enterprise Security
• Endpoint Detection & Response (EDR): CrowdStrike Falcon (Admin/Isolate privileges)
• Cloud Security Posture Management (CSPM): AWS GuardDuty / Wiz
• Forensic Acquisition: Volatility Foundation, FTK Imager, or cloud snapshot mechanisms
• Communication Platform: Out-of-band PagerDuty and Signal (Encrypted Workspaces)

---

4. Roles & Responsibilities (RACI Matrix)

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

---

5. Step-by-Step Procedure

Phase 1: Preparation & Triage Readiness

• Ensure all logging agents are actively streaming to the central SIEM with a minimum retention period of 365 days.
• Verify out-of-band communication channels (Signal/PagerDuty) are tested monthly.
• Maintain an up-to-date asset inventory and network topology diagram in the secure configuration management database (CMDB).

Phase 2: Identification & Scoping

• Acknowledge Alert: Triage incoming SIEM, EDR, or external reports within 15 minutes of generation.
• Validate Indicator: Determine whether the alert represents a True Positive (TP) or False Positive (FP).
• Classify Severity: Assign an initial severity level based on impact:
  • Sev-1 (Critical): Active data exfiltration, ransom deployment, infrastructure compromise.
  • Sev-2 (High): Isolated host compromise, credential stuffing with successful auth.
  • Sev-3 (Medium): Scans, probing, non-privileged malware blocked by EDR.
• Initiate Incident Log: Spin up a secure, time-stamped war-room channel and assign the Incident Commander (IC).

Phase 3: Containment (Short-Term & Long-Term)

• Isolate Endpoints: Execute EDR network isolation on all compromised hosts to prevent lateral movement.
• Revoke Credentials: Immediately terminate active sessions and rotate API keys, service account tokens, and IAM roles associated with compromised assets.
• Network Segmentation: Implement emergency firewall rule drops or Security Group updates to isolate subnet zones if lateral propagation is suspected.
• Preserve Evidence: Take memory dumps and cloud storage snapshots prior to making any destructive modifications.

Phase 4: Eradication

• Remove Artifacts: Purge web shells, malicious binaries, scheduled tasks, and unauthorized user accounts identified during scoping.
• Patch Vulnerabilities: Identify and patch the root-cause vector (e.g., CVE exploit, exposed S3 bucket, compromised SSH key).
• Rebuild from Golden Image: If OS-level integrity is in doubt, wipe the compromised host and rebuild from a verified clean immutable pipeline image.

Phase 5: Recovery

• Restore Services: Bring systems back online in a phased, monitored rollout.
• Monitor Telemetry: Increase SIEM logging sensitivity and EDR polling frequency for recovered assets over a 72-hour observation window.
• Verify Integrity: Run cryptographic checksums on application binaries and data stores to confirm zero corruption or unauthorized alteration.

Phase 6: Post-Incident Review (PIR)

• Conduct Blameless Post-Mortem: Schedule the PIR meeting within 5 business days of incident closure.
• Draft Timeline: Construct an accurate, chronological timeline of the attack lifecycle (dwell time, detection, response).
• File Corrective Actions (CAPAs): Create Jira tickets for engineering enhancements required to prevent recurrence.

---

6. Quality Assurance & Pro-Tips

6.1 Pro-Tips & Best Practices

• Never Power Off Hosts: When dealing with volatile system memory forensics, pulling the power cord destroys volatile evidence (RAM). Use network isolation instead.
• Preserve Chain of Custody: Hash all forensic images immediately using SHA-256 and store them in an encrypted, write-once-read-many (WORM) S3 bucket.

6.2 Common Pitfalls to Avoid

• Premature Notification: Do not broadcast internal data leaks publicly or to customers before Legal and Executive Leadership have validated scope and regulatory requirements.
• Incomplete Eradication: Failing to rotate master keys or service accounts often results in immediate reinfection by sophisticated adversaries.

6.3 Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes for Sev-1 incidents.
• Mean Time to Respond (MTTR): < 45 minutes from validation to containment.

---

7. Frequently Asked Questions (FAQ)

Q: At what point must we legally notify regulatory bodies (e.g., GDPR, CCPA)?
A: Legal counsel must be consulted immediately during Phase 2 (Identification) if Personally Identifiable Information (PII) or Protected Health Information (PHI) is confirmed compromised. Notification clocks typically start the moment a breach is reasonably established.

Q: Who has the final authority to shut down production systems during an incident?
A: The Incident Commander (IC), in coordination with the Lead Security Engineer, holds the unilateral authority to sever network connectivity or shut down production clusters to prevent catastrophic data loss.