9.1 Incident Response Frameworks and the SOC-IRT Interface

Foundations of Incident Response: Events, Alerts, and Incidents

In modern enterprise security operations, terminology precision directly dictates operational response velocity. A common vulnerability in Tier 1 Security Operations Center (SOC) workflows is confusing benign telemetry with actionable security breaches. Security practitioners must clearly differentiate among three core operational concepts: events, alerts, and incidents.

• Event: An observable occurrence in a system, network, or environment. Events represent the raw, high-volume state changes of computing infrastructure. Examples include a user successfully authenticating to Active Directory (Windows Security Event ID 4624), a network firewall permitting an outbound HTTPS packet (Event ID 5156), a web server logging an HTTP 200 GET request, or an operating system booting up. In an enterprise with 10,000 endpoints, billions of raw events are generated daily, the vast majority of which represent standard, benign business operations.
• Alert: A specialized notification generated by a security monitoring system—such as a Security Information and Event Management (SIEM) correlation engine, an Endpoint Detection and Response (EDR) agent, or an Intrusion Detection System (IDS)—when an event or sequence of correlated events matches a predefined detection rule, behavioral anomaly, or heuristic threshold. An alert signals that an event warrants human or automated inspection. For example, fifty failed logon attempts (Event ID 4625) followed by a successful logon (Event ID 4624) within sixty seconds generates a "Potential Brute Force Succeeded" alert. Alerts filter raw event volume down to manageable analytical queues, yet many alerts represent false positives or benign administrative anomalies.
• Incident: An adverse event or series of events that compromises the confidentiality, integrity, or availability (CIA) of an organization's information assets, systems, or data, or constitutes a confirmed violation of computer security policies, acceptable use policies, or standard security practices. An alert becomes an incident only after a SOC analyst verifies that unauthorized activity, system compromise, data exfiltration, or operational disruption has occurred or is imminently threatening the environment. For example, a confirmed Cobalt Strike beacon executing from memory within lsass.exe on a domain controller constitutes an incident demanding formal response protocols.

[Operational Telemetry Funnel]
Raw System & Network Events   --> ~1,000,000,000 / day  (Filtered by logging policies)
  └── Correlated Security Alerts --> ~5,000 / day       (Triaged by Tier 1 / SOAR)
      └── True Positive Findings --> ~25 / day          (Investigated by Tier 2)
          └── Confirmed Incidents    --> ~1-3 / week        (Escalated to CSIRT / IR Plan)

---

Current Incident Response Frameworks: NIST SP 800-61 Rev. 3 and SANS PICERL

NIST finalized SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, in April 2025. Rev. 3 supersedes Rev. 2 and expresses incident response as an organization-wide cybersecurity risk-management capability aligned to the six NIST Cybersecurity Framework (CSF) 2.0 Functions:

1. Govern: Establish policy, authority, roles, risk tolerance, oversight, and supply-chain expectations.
2. Identify: Understand assets, dependencies, vulnerabilities, threats, and risk so response priorities have context.
3. Protect: Apply safeguards that reduce the likelihood and impact of incidents and support resilient operations.
4. Detect: Find and analyze anomalies, indicators, and potentially adverse events.
5. Respond: Manage, analyze, contain, mitigate, report, and communicate about detected incidents.
6. Recover: Restore affected assets and operations, communicate recovery status, and incorporate improvements.

The familiar four phases—Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity—belong to Rev. 2, not Rev. 3. They remain a useful operational crosswalk and may appear in older courseware, but candidates should not present Rev. 2 as current NIST guidance.

The SANS PICERL mnemonic separates six operational activities: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It is a practical sequence for playbooks, but real response is iterative: new evidence discovered during containment can send analysts back to identification and scoping.

---

SOC vs. CSIRT / IRT Roles, Responsibilities, and Handoff Protocols

In mature enterprise organizations, a structural boundary separates the Security Operations Center (SOC) from the Computer Security Incident Response Team (CSIRT) or Incident Response Team (IRT). While closely integrated, their operational mandates, time horizons, and technical skill sets differ significantly.

Operational Roles Across Tiers

• Tier 1 (Triage Analyst):
  • Focus: Queue monitoring, alert intake, and rapid initial validation during the organization’s defined coverage period.
  • Actions: Performs initial enrichment, queries threat intelligence feeds for observable reputation, distinguishes false positives from true positives, and executes initial ticket tagging. If true positive activity exceeds defined risk thresholds, Tier 1 initiates a warm handoff to Tier 2 within the organization’s severity-based service targets.
• Tier 2 (Incident Responder / Handler):
  • Focus: In-depth technical investigation, scoping, and operational containment.
  • Actions: Correlates cross-platform telemetry (EDR, SIEM, proxy, Active Directory logs), establishes the initial blast radius, analyzes endpoint parent-child execution lineages, and executes tactical containment playbooks (such as EDR host network isolation or disabling Active Directory user accounts). If an incident involves advanced threat actors, ransomware outbreaks, enterprise-wide lateral movement, or data exfiltration, Tier 2 escalates the case to Tier 3 and the dedicated CSIRT.
• Tier 3 / Dedicated CSIRT (Lead Incident Responders & Forensic Specialists):
  • Focus: Advanced incident management, digital forensics, threat hunting, and strategic coordination.
  • Actions: Leads the enterprise war room, performs volatile memory acquisition and dead-box hard drive forensics, reverse-engineers novel malware binaries, analyzes packet capture (PCAP) streams, attributes threat actors via MITRE ATT&CK mapping, and interfaces directly with Legal Counsel, Human Resources, Executive Leadership, and external law enforcement.

Escalation Handoff Protocols and Evidentiary Chain of Custody

When Tier 2 escalates an active intrusion to the CSIRT, the handoff must follow a rigorous, formalized protocol to prevent investigative blind spots and preserve legal admissibility:

1. Synchronous Incident Briefing: Tier 2 conducts a direct verbal or secure out-of-band bridge briefing with the designated CSIRT Incident Commander, summarizing the attack vector, patient zero, compromised accounts, and all containment actions executed to date.
2. Ticketing & Artifact Transfer: All documented indicators of compromise (IoCs), process trees, SIEM query URLs, EDR isolation timestamps, and analyst notes are transferred into the primary incident master ticket (e.g., in ServiceNow SecOps or TheHive).
3. Evidentiary Chain of Custody (RFC 3227): Digital evidence gathered during triage must be handled according to RFC 3227 (Guidelines for Evidence Collection and Archiving). This recommends considering the order of volatility—collecting evidence from the most volatile to least volatile sources:
   • 1. CPU Registers and Cache memory.
   • 1. Routing tables, ARP caches, process tables, kernel statistics, and temporary memory.
   • 1. System physical memory (RAM).
   • 1. Temporary file systems, swap space, and page files.
   • 1. Non-volatile disk storage (physical hard drives, SSDs, VMDKs).
   • 1. Remote logging data, SIEM records, and network device logs.
   • 1. Physical network configuration and media topology.

Forensic procedures normally calculate and record a strong cryptographic hash such as SHA-256 as part of acquisition and verification, while documenting any artifact that cannot be hashed in place. An evidentiary Chain of Custody log must record: unique evidence tracking ID, exact timestamp of acquisition (UTC), acquiring analyst's full name and title, cryptographic hash, physical or cloud storage location, and every subsequent transfer of possession with signatures.

---

Incident Response Plan (IRP) Core Components and Governance

An Incident Response Plan (IRP) is a formal, executive-approved governance document that outlines an organization's procedural framework for detecting, containing, and recovering from cyber incidents. An effective IRP contains six essential components:

1. Executive Mandate & Authority Charter: Explicitly grants the CSIRT and Incident Commander organizational authority to take extreme remediation actions—such as severing enterprise internet connections, isolating critical production domain controllers, or shutting down revenue-generating applications—without prior executive approval during critical emergencies.
2. Roles, Responsibilities, and Team Structure: Delineates roles across the incident response hierarchy, including the Incident Commander (directs technical operations), Scribe (maintains chronological audit log), Technical Lead (coordinates forensic investigation), Communications Lead (liaises with internal PR), and Legal Counsel (manages regulatory notifications).
3. Classification and Severity Matrix: An objective rubric defining incident categories and severity levels (P1 through P4) based on quantifiable business impact and functional disruption.
4. Standard Operating Procedures (SOPs) and Playbooks: Step-by-step operational workflows for handling specific intrusion scenarios, including Ransomware, Business Email Compromise (BEC), Distributed Denial of Service (DDoS), Web Application Exploitation, and Insider Data Theft.
5. Communication and Notification Procedures: Contact trees, escalation triggers, out-of-band communication protocols, and applicable notification decision points and deadlines. For example, GDPR Article 33 generally requires supervisory-authority notice within 72 hours after awareness when a personal-data breach is likely to risk individuals’ rights and freedoms, while U.S. SEC Form 8-K Item 1.05 generally uses four business days after a registrant determines an incident is material, subject to the rule’s exceptions and delay process.
6. Testing, Maintenance, and Training Schedule: A risk-based cadence for plan reviews, exercises, and technical validation, with updates after material organizational, threat, technology, or regulatory changes.

---

Incident Escalation Matrix and Classification Framework

To eliminate subjectivity during high-stress intrusions, security operations rely on a quantitative Incident Escalation Matrix. Severity ratings (Priority 1 through Priority 4) reflect the intersection of business impact, system criticality, and confidentiality/integrity/availability loss.

Enterprise Incident Escalation Matrix