9.2 Incident Triage, Ticketing, and Prioritization

Incident Intake and Initial Scoping: Determining the Blast Radius

Incident triage begins the moment an anomalous alert or external notification enters the SOC. The primary objective of initial triage is not deep forensic root-cause analysis, but rapid, accurate scoping—establishing the precise boundaries of adversary activity, commonly referred to as the blast radius. Scoping prevents two catastrophic operational errors: underestimating an intrusion (allowing an adversary to maintain secondary footholds) or prematurely executing containment actions that alert the threat actor before all compromised assets are identified.

The Four Dimensions of Blast Radius Scoping

To systematically determine the blast radius, a SOC analyst must interrogate four distinct operational dimensions:

1. Host-Level Scope: Identifying every computing asset exhibiting indicators of compromise (IoCs) or behavioral tactics, techniques, and procedures (TTPs). The analyst identifies Patient Zero (the initial system compromised) and tracks subsequent infected endpoints, virtual machines, cloud instances, and database servers. Analysts execute centralized EDR queries across telemetry data looking for common process execution trees, anomalous parent-child relationships (e.g., svchost.exe spawning powershell.exe), unique file hashes dropped in temporary directories (C:\Users\*\AppData\Local\Temp\ or /tmp), and unauthorized network sockets.
2. Identity and Credential Scope: Mapping every user, service, and administrative account involved in the intrusion. Analysts examine Windows Security Event ID 4624 (Successful Logon) to identify anomalous Logon Types (specifically Type 3 for Network logons indicating lateral movement, and Type 10 for Remote Desktop Protocol sessions). Analysts must determine whether compromised identities possess standard end-user rights, local administrative privileges, service account permissions (evaluating Kerberoasting risks under Event ID 4769), or Domain Admin / Global Admin authority.
3. Network and Segmentation Scope: Identifying all subnets, VLANs, and cloud virtual private clouds (VPCs) traversed by the adversary. Analysts review East-West network flow logs, internal firewall traffic, and proxy logs to determine if the intrusion has jumped network segmentation boundaries—such as moving from a corporate workstation VLAN into a Payment Card Industry (PCI) Cardholder Data Environment (CDE), a production database subnet, or an Operational Technology / Industrial Control System (OT/ICS) network.
4. Data and Regulatory Scope: Evaluating the classification level of data residing on compromised systems. The analyst inspects Configuration Management Databases (CMDB) and data classification repositories to identify whether affected assets store Personally Identifiable Information (PII), Protected Health Information (PHI), Intellectual Property (trade secrets, source code), or financial transaction databases. This assessment dictates statutory breach disclosure obligations.

[Blast Radius Evaluation Formula]
Blast Radius = f(Impacted Hosts, Compromised Identity Tiers, Segment Crossings, Data Criticality)
Example Scenario: 
- 1 Workstation + Standard User Account + Corporate VLAN + No Sensitive Data = Narrow Blast Radius (P3/P4)
- 1 Workstation + Domain Admin Token + Core Server Subnet + PII Database Access = Enterprise Blast Radius (P1)

---

Enterprise Security Ticketing and Incident Management Platforms

A security incident ticket is not merely an IT administrative record; it is a legally discoverable forensic artifact, an operational command document, and an audit trail for compliance regulators. Enterprise SOCs deploy specialized Security Incident Response Platforms (SIRPs) and ticketing solutions engineered for security operations:

• ServiceNow Security Operations (SecOps): Integrates enterprise ITSM with security operations. ServiceNow SecOps correlates security incidents directly with the enterprise Configuration Management Database (CMDB), automatically populating asset criticality, business owners, and server roles. It features automated threat intelligence lookups, vulnerability correlation (integrating with Tenable or Qualys), and structured playbook orchestration.
• Jira Service Management (JSM): Highly flexible issue tracking and workflow management platform favored by engineering-centric organizations. Security teams customize JSM with strict permission controls, automated REST API webhooks connecting to SOAR tools, and Kanban/Scrum boards for CSIRT sprint-based incident resolution.
• TheHive: An open-source, purpose-built Security Incident Response Platform tightly coupled with Cortex (a powerful observable analysis and active response engine) and MISP (Malware Information Sharing Platform). TheHive organizes cases around specific observables (IPs, hashes, domain names, URLs) and allows multiple analysts to collaborate simultaneously on task-based investigations while tracking chain of custody.

Comprehensive Ticket Documentation Standards

Security incident tickets must adhere to strict forensic documentation standards. Analysts must record findings with sufficient precision that an external auditor, legal investigator, or peer analyst can independently reconstruct the incident months later:

• UTC Timestamp Synchronization: All timeline entries must be recorded in Universal Coordinated Time (UTC) with ISO 8601 formatting (YYYY-MM-DDTHH:MM:SSZ) to eliminate timezone ambiguity across distributed environments.
• Defanged Indicators of Compromise (IoCs): To prevent accidental click-throughs, automated URL execution, or email client pre-fetching by analysts or ticketing software, all URLs, IP addresses, and email addresses must be defanged:
  • https://evil-c2.com/stage2.exe becomes hxxps://evil-c2[.]com/stage2[.]exe
  • 198.51.100.44 becomes 198[.]51[.]100[.]44
  • attacker@malicious.org becomes attacker[at]malicious[.]org
• Forensic Evidence Pointers: Keep large or sensitive evidence out of ordinary ticket attachments unless an approved system and policy explicitly support it. Reference the authorized evidence repository, object/version identifier, access controls, acquisition hash, and chain-of-custody record. Describe storage as immutable only when the configured retention mode and privileges support that claim.

Comprehensive Ticket Documentation Checklist

---

Incident Prioritization Matrix and SLA Management

Not all incidents warrant equal operational urgency. A SOC handling hundreds of alerts daily must allocate finite analytical and engineering resources objectively. Incident priority is calculated using an objective mathematical relationship:

$\text{Priority} = \text{Impact} \times \text{Urgency}$

• Business Impact: Evaluates the potential or realized harm to the organization. Factors include financial loss, regulatory exposure (GDPR, HIPAA, PCI DSS), system downtime, data theft (confidentiality loss), data alteration (integrity loss), and reputational brand damage.
• Operational Urgency: Evaluates the speed with which the adversary is progressing, the speed of threat propagation, and the time sensitivity of containment. An uncontained, actively propagating ransomware strain exhibits maximum urgency; a dormant web shell discovered during a retrospective log review exhibits high impact but lower operational urgency.

Incident Prioritization & Severity Grid

Service Level Agreement (SLA) Governance

SLAs define contractually or organizationally mandated deadlines for handling tickets. Security operations measure performance against two primary SLA metrics:

1. Response SLA (Mean Time to Acknowledge - MTTA): The time elapsed from when an alert or ticket is generated until an analyst actively assigns the ticket, opens the investigation, and begins triage.
2. Resolution / Containment SLA (Mean Time to Contain - MTTC / MTTR): The time elapsed from ticket generation until active threat propagation is completely halted (Containment SLA) or until full eradication, recovery, and post-incident closure are achieved (Resolution SLA).

[Enterprise SLA Targets by Priority]
- P1 (Critical): MTTA ≤ 15 Minutes   | MTTC ≤ 1 Hour    | Status Updates: Every 30 mins
- P2 (High):     MTTA ≤ 30 Minutes   | MTTC ≤ 4 Hours   | Status Updates: Every 2 hours
- P3 (Medium):   MTTA ≤ 2 Hours      | MTTC ≤ 24 Hours  | Status Updates: Daily
- P4 (Low):      MTTA ≤ 8 Hours      | MTTC ≤ 72 Hours  | Status Updates: On resolution

---

Stakeholder Communication Protocols and Out-of-Band Channels

Technical containment is only half of incident management; the other half is controlled, secure stakeholder communication. Uncoordinated or premature disclosures can destroy evidentiary value, violate statutory non-disclosure requirements, cause brand damage, or tip off an embedded adversary.

Stakeholder Coordination Matrix

• Internal Technical Teams (IT Operations, Cloud Engineering, Network Engineering): Must be given concise, actionable technical instructions (e.g., specific IP blocks, port disconnections, snapshot requests) without exposing sensitive attribution hypotheses.
• Executive Leadership (CISO, CIO, CEO, Board of Directors): Require non-technical, high-level risk assessments summarizing business impact, regulatory liability, operational downtime estimates, and remediation roadmaps.
• Legal Counsel: Involves both internal and external cybersecurity attorneys. Engaging external counsel early establishes Attorney-Client Privilege over forensic investigation reports. Legal counsel dictates external disclosure timelines under laws such as GDPR Article 33 (72 hours), HIPAA Breach Notification Rule (60 days), and the SEC Form 8-K mandate (4 business days following determination of a material cybersecurity incident).
• Human Resources (HR): Engaged immediately when an incident involves internal employee malfeasance, insider threats, policy violations, or when employee workstations require discreet forensic seizure.
• Public Relations / Corporate Communications: Prepares external holding statements, customer advisories, and media briefings. No technical staff or SOC analysts may speak to the press or post on social media regarding an ongoing incident.

Out-of-Band (OOB) Communication Protocols

When an advanced threat actor compromises enterprise infrastructure, standard internal communication channels must be presumed hostile. Threat actors with administrative access routinely monitor Microsoft Exchange / M365 mailboxes (configuring hidden inbox forwarding rules), inspect internal Slack or Microsoft Teams channels, and tap enterprise Voice over IP (VoIP) systems. If the adversary observes the CSIRT discussing containment strategies, they frequently accelerate data exfiltration or detonate ransomware prematurely.

Out-of-Band (OOB) communications utilize dedicated, external, cryptographically isolated infrastructure completely decoupled from the organization's corporate Active Directory, DNS, and cloud tenants.

Enterprise Out-of-Band Communication Protocols