SANS Institute Incident Response Plan Template

Standard Operating Procedure: SANS-Aligned Incident Response Plan Template Execution

Document ID: SOP-TR-IR-042
Effective Date: October 24, 2023
Version: 3.1.0
Review Cadence: Semi-Annual
Classification: Restricted – Internal Template Registry Engineering Use Only

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional execution framework for deploying, operationalizing, and executing the SANS Institute Incident Response Plan Template within Template Registry infrastructure. The objective is to standardize containment, eradication, and recovery workflows, ensuring immutable chain-of-custody, minimal business interruption, and deterministic alignment with NIST SP 800-61 Rev. 2 guidelines.

---

2. Scope & Prerequisites

Scope

Applies to all cloud-native environments, on-premises infrastructure, containerized registries, and CI/CD pipelines managed by Template Registry.

Prerequisites & Required Toolset

• Forensic Toolkit: The Sleuth Kit (TSK), Autopsy, Volatility 3 (for memory dumps).
• Endpoint Detection & Response (EDR): CrowdStrike Falcon / SentinelOne API access with pre-configured isolation tokens.
• Log Aggregation & SIEM: Splunk Enterprise Security / Datadog Security Monitoring with root-level search capabilities.
• Out-of-Band Communication: PagerDuty, Wickr Pro / Signal Enterprise (isolated from primary corporate directory).
• Physical/Virtual PPE: MFA-secured jump hosts, encrypted air-gapped storage drives (AES-256), Write-Blockers (for physical media).

---

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Procedure

Phase 1: Preparation

• Verify access credentials to the SANS-aligned incident response repository and out-of-band communication channels.
• Ensure all forensic jump hosts are patched, isolated, and running verified forensic binaries.
• Conduct bi-annual dry runs of the incident notification tree and escalation paths.

Phase 2: Identification

• Triage incoming alerts from SIEM, EDR, or external user reports to determine baseline anomaly vs. true positive.
• Classify the incident severity level (Severity 1: Critical/Data Breach, Severity 2: Major/Localized Compromise, Severity 3: Minor/Suspicious Activity).
• Open the Master Incident Ticket, initialize the immutable timeline log, and notify the Incident Commander.

Phase 3: Containment

• Short-Term Containment: Isolate compromised network segments, host endpoints, or cloud IAM roles using automated EDR scripts or manual routing table updates.
• Pro-Tip: Do not power down live hosts; volatile RAM must be preserved for forensic analysis.
• Implement firewall drop rules or security group modifications at the perimeter to halt lateral movement and C2 communications.
• Long-Term Containment: Patch initial vector vulnerabilities, rotate compromised service accounts, and establish secure staging environments for forensics.

Phase 4: Eradication

• Identify and remove all attacker artifacts, webshells, backdoors, and persistence mechanisms (cron jobs, registry keys, unauthorized SSH keys).
• Validate system integrity against known-good golden images or immutable container registries.
• Update perimeter and endpoint signature rules to detect re-entry attempts using the identified indicators of compromise (IoCs).

Phase 5: Recovery

• Restore systems from verified, malware-free backups or redeploy via automated Infrastructure-as-Code (IaC) pipelines.
• Gradually reintroduce assets to production under heightened monitoring and rate-limiting thresholds.
• Conduct rigorous functional and security validation testing prior to closing public-facing access.

Phase 6: Lessons Learned (Post-Mortem)

• Schedule the mandatory Post-Incident Review (PIR) meeting within 5 business days of incident closure.
• Populate the root-cause analysis (RCA) register and update the SANS Incident Response Plan Template with newly discovered IoCs and tactical gaps.
• Archive all forensic artifacts, memory dumps, and ticket logs in encrypted cold storage with strict retention policies.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Immutability First: Ensure all incident logs are written directly to a WORM (Write Once, Read Many) storage bucket to prevent tampering.
• Parallel Workflows: Decouple forensic data gathering from remediation tasks to prevent evidence destruction.

Common Pitfalls

• Premature Remediation: Wiping a system before capturing volatile memory and disk images, destroying critical attribution evidence.
• Information Leakage: Discussing incident details on unencrypted internal chat channels (Slack/Teams) rather than dedicated out-of-band tools.

Metric Thresholds

• Mean Time to Detect (MTTD): $\le 15\text{ minutes}$ for Severity 1 incidents.
• Mean Time to Contain (MTTC): $\le 45\text{ minutes}$ from initial validation.
• Post-Mortem Execution: Completed within 120 hours of incident resolution.

---

6. Frequently Asked Questions (FAQ)

Q1: What should be done if the Incident Commander is unreachable during a Severity 1 event?
A: The next designated technical lead on the escalation roster automatically assumes the role of Incident Commander. Execute the PagerDuty override protocol immediately and spin up the emergency bridge.

Q2: How do we handle third-party cloud provider compromises within this framework?
A: Engage the cloud provider’s security operations center (CSIRT) via pre-established enterprise support channels while simultaneously isolating local API tokens, revoking IAM federation, and capturing cloud audit logs (AWS CloudTrail / Azure Activity Logs).

Q3: Are the containment actions authorized without prior legal sign-off?
A: Yes. Under the authority delegated by the Chief Architect, life-cycle preservation and immediate network containment to prevent active data exfiltration supersede standard change-management approvals. Legal counsel must be informed asynchronously during Phase 2.