Security Incident Report Sample Doc

Standard Operating Procedure: Security Incident Report Sample & Lifecycle Management

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory lifecycle, documentation standards, and operational workflows for handling, reporting, and archiving security incidents across all enterprise environments. Adherence ensures data integrity, legal defensibility, and continuous audit readiness.

2.2 Scope

This procedure applies to all internal employees, contractors, third-party vendors, and managed service providers operating within or interfacing with enterprise information systems, cloud infrastructures, physical facilities, and proprietary data repositories.

2.3 Regulatory & Compliance Standards

Operations governed by this document strictly adhere to:

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide.
• ISO/IEC 27001:2022: Information Security Management Systems (specifically Control A.16).
• GDPR (Articles 33 & 34) / CCPA: Statutory data breach notification timelines and protocols.
• PCI-DSS v4.0: Requirements 10 and 12 regarding incident logging and response.

---

3. Prerequisites & Tool Requirements

Execution of this SOP requires authorized access to specific toolsets, cleared security clearances, and operational hardware.

3.1 Software & System Access

• SIEM Platform: Splunk Enterprise Security / Microsoft Sentinel (Tier-3 Analyst privileges).
• Ticketing & Case Management: ServiceNow Security Incident Response (SIR) module.
• Forensic Acquisition: EnCase Forensic, FTK Imager, or Velociraptor endpoint collectors.
• Threat Intelligence Platforms (TIP): MISP / CrowdStrike Falcon Intelligence.
• Secure Collaboration: Out-of-band encrypted communication channel (Signal Enterprise / Wickr Pro).

3.2 Hardware & Physical Equipment

• Hardware write-blockers (Tableau forensic bridges).
• Blank, forensically sanitized evidence storage drives (AES-256 encrypted).
• Isolated triage laptop (air-gapped from corporate network).

3.3 Certifications & Qualifications

• Incident responders must hold at least one of the following active certifications: CISSP, GIAC Certified Incident Handler (GCIH), CompTIA CySA+, or CREST Practitioner in Incident Response (CPIR).

---

4. Roles & Responsibilities (RACI Matrix Table)

Definitions: Responsible (The doer), Accountable (The owner), Consulted (In-the-loop advisors), Informed (Kept updated).

---

5. Step-by-Step Operational Procedure

Phase 1: Identification & Triage

• 1.1 Receive security alert via SIEM automation, automated sentinel, or manual employee reporting channel.
• 1.2 Validate the alert to eliminate false positives using baseline asset inventory and threat intel feeds.
• 1.3 Assign an initial severity rating (Sev-1: Critical Enterprise Impact, Sev-2: Major, Sev-3: Moderate, Sev-4: Minor) within ServiceNow SIR.
• 1.4 Notify the Incident Response Lead (IRL) via secure paging system if severity is rated Sev-1 or Sev-2.

Phase 2: Containment, Eradication & Recovery

• 2.1 Execute immediate containment strategies (network isolation, account suspension, firewall blocklisting) to prevent lateral movement.
• 2.2 Capture volatile memory and disk images of compromised endpoints using forensically sound methodologies.
• 2.3 Perform root-cause analysis (RCA) to identify the initial attack vector and vulnerabilities exploited.
• 2.4 Eradicate malicious artifacts, close exploited vectors, and patch identified vulnerabilities across similar assets.
• 2.5 Restore systems from verified, uncompromised backups and execute integrity validation checks.

Phase 3: Reporting & Documentation

• 3.1 Draft the definitive Security Incident Report (SIR) utilizing the mandatory template structure (Appendix A).
• 3.2 Collate all evidentiary artifacts, system logs, memory dumps, and chain-of-custody forms into the encrypted case file repository.
• 3.3 Submit the incident report to the CISO and Legal Counsel for compliance verification and mandatory external reporting evaluation.

Phase 4: Post-Incident Review (Lessons Learned)

• 4.1 Schedule and execute a mandatory Post-Incident Review (PIR) meeting within 5 business days of incident closure.
• 4.2 Document process failures, tool deficiencies, and detection gaps.
• 4.3 Issue actionable remediation tickets assigned to corresponding infrastructure and engineering leads.

---

6. Quality Assurance & Verification Criteria

To ensure institutional rigor, every security incident report and its underlying operational workflow must satisfy the following quality benchmarks prior to closure:

• Time-to-Detection (TTD) SLA: Initial triage must occur within 15 minutes of alert generation for Sev-1 incidents.
• Time-to-Containment (TTC) SLA: Containment protocols must be deployed within 60 minutes for confirmed Sev-1 breaches.
• Chain of Custody Completeness: 100% of physical and digital forensic acquisitions must feature an unbroken, cryptographically signed chain-of-custody log.
• Report Accuracy Threshold: Zero discrepancies between timeline narratives, system log timestamps, and forensic telemetry.
• Regulatory Compliance Window: External disclosures (if legally mandated by GDPR/CCPA) must be cleared by Legal Counsel and dispatched within the statutory 72-hour window.

---

7. Practical Troubleshooting Scenarios

Scenario A: Compromised Administrative Credentials in Active Directory

• Symptom: Unusually high volume of anomalous authentication requests originating from an enterprise service account outside standard business hours, followed by rapid mass export of directory objects.
• Immediate Corrective Action Protocol:
  1. Force-terminate all active Kerberos sessions for the compromised account via PowerShell (Clear-KDCClientCache and disabling the account).
  2. Isolate the source domain controller/workstation from the network.
  3. Rotate krbtgt password twice sequentially to invalidate all active enterprise tickets.
  4. Initiate an emergency audit of group membership changes made within the last 48 hours.

Scenario B: Ransomware Deployment on Secondary File Server

• Symptom: Massive file-renaming operations detected by File Integrity Monitoring (FIM), accompanied by high CPU utilization and drops in storage read/write efficiency.
• Immediate Corrective Action Protocol:
  1. Disconnect the infected storage array from the physical network switch (unplug uplinks; do not shut down systems to preserve RAM artifacts).
  2. Identify patient zero workstation/user session through active SMB connection tables.
  3. Isolate patient zero from the network immediately.
  4. Verify the integrity and air-gapped status of the last known good backup set before initiating restoration procedures.

Scenario C: Evidence Contamination During Forensic Acquisition

• Symptom: Analyst attempts to acquire a live disk image without deploying a hardware write-blocker or software validation hash, raising integrity verification failure flags during SHA-256 comparison.
• Immediate Corrective Action Protocol:
  1. Immediately halt the acquisition process.
  2. Document the exact point of failure and log the discrepancy in the incident case notes.
  3. Quarantine the compromised drive, mark the current acquisition attempt as legally inadmissible, and restart the extraction utilizing a secondary, pristine clone target with verified write-blocking hardware.
  4. File an internal deviation report to the CISO detailing the procedural breakdown.