Triaging Security Incidents

When to Use

• A SIEM or EDR alert fires and requires human classification before escalation
• Multiple concurrent alerts arrive and the SOC must prioritize response order
• An end user reports suspicious activity and the incident needs initial categorization
• A threat intelligence feed matches an IOC observed in the environment

Do not use for routine vulnerability scanning results or compliance audit findings that do not represent active security incidents.

Prerequisites

• Access to SIEM platform (Splunk, Elastic, Microsoft Sentinel) with current alert data
• Incident classification taxonomy aligned to NIST SP 800-61r3 categories
• Predefined severity matrix mapping asset criticality to threat type
• Contact roster for escalation paths (Tier 1 through Tier 3 and CIRT)
• Asset inventory with business criticality ratings

Workflow

Step 1: Collect Initial Alert Data

Gather all available context from the triggering alert before making classification decisions:

• Alert source: Which detection system generated the alert (EDR, SIEM, IDS/IPS, firewall, user report)
• Timestamp: When the event occurred and when it was detected (dwell time gap)
• Affected assets: Hostnames, IP addresses, user accounts involved
• Alert fidelity: Historical true-positive rate for this detection rule
• Raw evidence: Log entries, packet captures, process execution chains

Example SIEM alert context:
Source:       CrowdStrike Falcon
Detection:    Suspicious PowerShell Execution (T1059.001)
Host:         WORKSTATION-FIN-042
User:         jsmith@corp.example.com
Timestamp:    2025-11-15T14:23:17Z
Severity:     High (detection rule confidence: 92%)
Process:      powershell.exe -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...
Parent:       outlook.exe (PID 4812)

Step 2: Classify the Incident Type

Map the alert to a standard incident category per NIST SP 800-61r3:

Step 3: Assign Severity Using Impact Matrix

Calculate severity by combining asset criticality with threat severity:

Severity = f(Asset Criticality, Threat Type, Data Sensitivity, Lateral Movement Potential)

Critical (P1): Crown jewel systems compromised, active data exfiltration, ransomware spreading
High (P2):     Production system compromise, confirmed malware execution, privileged account takeover
Medium (P3):   Non-production compromise, unsuccessful exploitation attempt, single endpoint malware
Low (P4):      Reconnaissance activity, policy violation, benign true positive

Response SLA targets:

• P1: Acknowledge within 15 minutes, containment within 1 hour
• P2: Acknowledge within 30 minutes, containment within 4 hours
• P3: Acknowledge within 2 hours, investigation within 24 hours
• P4: Acknowledge within 8 hours, investigation within 72 hours

Step 4: Perform Initial Enrichment

Before escalation, enrich the alert with contextual data:

• Threat intelligence: Check IOCs (IP, hash, domain) against TI platforms (VirusTotal, OTX, MISP)
• Asset context: Query CMDB for asset owner, business function, data classification
• User context: Check identity provider for recent authentication anomalies, MFA status
• Historical correlation: Search for related alerts on the same host/user in the past 30 days
• Network context: Verify if source/destination IPs are internal, known partners, or external threat actors

Step 5: Document and Escalate

Create a structured triage record and route to the appropriate response tier:

Incident Triage Record
━━━━━━━━━━━━━━━━━━━━━
Ticket ID:       INC-2025-1547
Triage Analyst:  [analyst name]
Triage Time:     2025-11-15T14:35:00Z (12 min from alert)
Classification:  Malicious Code - Macro-based initial access
Severity:        P2 - High
Affected Assets: WORKSTATION-FIN-042 (Finance dept, handles PII)
Affected Users:  jsmith@corp.example.com
IOCs Identified: powershell.exe spawned by outlook.exe, encoded command

…