Incident Response Plan Cyber Security Example

Standard Operating Procedure: Cyber Security Incident Response Plan (CSIRP)

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional-grade framework for detecting, containing, eradicating, and recovering from cyber security incidents affecting Template Registry infrastructure, services, and data assets. The objective is to establish a repeatable, forensically sound, and legally compliant methodology that minimizes operational disruption, preserves evidentiary integrity, and ensures rapid restoration of system availability and confidentiality.

---

3. Scope & Prerequisites

3.1 Scope

This policy applies to all systems, network segments, cloud environments (AWS/GCP), employee endpoints, and data repositories owned, leased, or managed by Template Registry, including third-party SaaS integrations tied to core production infrastructure.

3.2 Prerequisites & Tooling

Execution of this SOP requires pre-configured access and operational readiness of the following technology stack:

• SIEM / Log Management: Datadog / Splunk Enterprise Security.
• EDR (Endpoint Detection & Response): CrowdStrike Falcon (Admin access required).
• Cloud Infrastructure Access: AWS IAM Multi-Factor Authentication (MFA) with AdministratorAccess and Break-Glass roles.
• Forensic Capture Tools: LiME (Linux Memory Extractor), Volatility Foundation, and Autopsy.
• Communication Channels: PagerDuty (Primary Alerting), Out-of-Band Signal Group (tr-sec-incident-bridge), and statuspage.io API.

---

4. Roles & Responsibilities (RACI Matrix)

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

---

5. Step-by-Step Procedure

Phase 1: Identification & Triage

• 1.1 Acknowledge incoming security alerts via PagerDuty within 5 minutes of generation.
• 1.2 Verify the alert against SIEM anomalies, corroborating telemetry from EDR, WAF, and CloudTrail logs.
• 1.3 Classify the incident severity level using the Template Registry Severity Matrix:
  • Sev-1 (Critical): Active data exfiltration, ransomware deployment, root compromise of production control planes.
  • Sev-2 (High): Isolated host malware infection, credential stuffing attack with verified access, unauthorized lateral movement.
  • Sev-3 (Medium): Policy violation, targeted brute-force attack without compromise, vulnerability scan activity.
• 1.4 Spin up the out-of-band incident bridge and assign the Incident Commander (IC) role.

Phase 2: Containment

• 2.1 Execute immediate short-term containment measures to prevent lateral movement without destroying volatile evidence:
  • Endpoint Isolation: Issue network isolation commands via CrowdStrike Falcon for compromised endpoints.
  • Credential Revocation: Terminate all active sessions and rotate API keys/IAM credentials for compromised user identities via AWS CLI:

    aws iam update-login-profile --user-id <COMPROMISED_USER> --password-reset-required
    aws iam revoke-signing-certificate --certificate-id <CERT_ID>
    

  • Network Segmentation: Modify AWS Security Groups to restrict ingress/egress to known-bad IPs while maintaining forensics access:

    aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 22 --cidr <FORENSIC_IP>/32
    

• 2.2 Implement long-term containment strategies, including firewall rule updates and micro-segmentation patches.

Phase 3: Eradication

• 3.1 Identify the root cause vector (e.g., zero-day exploit, phishing credential harvesting, misconfigured S3 bucket).
• 3.2 Remove malware artifacts, unauthorized user accounts, backdoor SSH keys, and malicious cron jobs from affected systems.
• 3.3 Patch vulnerable software libraries or infrastructure components identified during the root-cause analysis.
• 3.4 Verify system integrity against known-good cryptographic hashes and immutable base images (Golden AMIs).

Phase 4: Recovery

• 4.1 Restore production data from verified, malware-free immutable backups stored offsite/cross-region.
• 4.2 Bring systems back online in a phased, monitored rollout (Database Tier $\rightarrow$ Application Tier $\rightarrow$ Edge/CDN Tier).
• 4.3 Execute post-restoration synthetic transaction tests and continuous security monitoring for a mandatory 48-hour observation window.
• 4.4 Formally declare the incident closed on the internal status channel and notify executive leadership.

Phase 5: Post-Incident Activity

• 5.1 Conduct a mandatory blameless Post-Mortem within 5 business days of incident closure.
• 5.2 Compile all forensic artifacts, timelines, and communication logs into an encrypted evidentiary archive.
• 5.3 Draft and assign engineering JIRA tickets for preventative corrective actions (CAPA) with hard deadlines.

---

6. Quality Assurance & Pro-Tips

Best Practices

• Preserve Memory First: Never reboot a live compromised host before capturing RAM for forensic analysis, as critical IOCs reside exclusively in volatile memory.
• Chain of Custody: Maintain a strict cryptographic hash log (SHA-256) for all forensic images collected during the investigation.

Common Pitfalls to Avoid

• Premature Eradication: Deleting malware before dumping memory destroys critical attack lineage and IOC data required for attribution.
• Communication Silos: Failing to engage Legal Counsel early can violate regulatory disclosure requirements (e.g., GDPR, CCPA, SEC rules).

Metric Thresholds

• MTTA (Mean Time to Acknowledge): $< 5$ minutes for Sev-1 incidents.
• MTTC (Mean Time to Contain): $< 30$ minutes for Sev-1 incidents.

---

7. Frequently Asked Questions (FAQ)

Q: At what point do we notify external regulatory bodies or customers of a data breach?
A: External notifications are strictly managed by Legal Counsel and the Communications Lead. Notification triggers are evaluated immediately upon confirmation of PII/PHI exfiltration or where mandated by SLA/statutory frameworks (e.g., 72-hour GDPR window). Engineers must never make public statements.

Q: How do we handle active law enforcement requests during an ongoing cyber attack?
A: Direct all law enforcement inquiries to Legal Counsel. Do not grant third-party external entities access to live internal infrastructure without a signed court order and verified executive sign-off.