Performs initial triage of security incidents to determine severity, scope, and required response actions using the NIST SP 800-61r3 and SANS PICERL frameworks. Classifies incidents by type, assigns priority based on business impact, and routes to appropriate response teams. Activates for requests involving incident triage, security alert classification, severity assessment, incident prioritization, or initial incident analysis.
Performs initial triage of security incidents to determine severity, scope, and required response actions using the NIST SP 800-61r3 and SANS PICERL frameworks. Classifies incidents by type, assigns priority based on business impact, and routes to appropriate response teams. Activates for requests involving incident triage, security alert classification, severity assessment, incident prioritization, or initial incident analysis.
["Executable Denylisting","Execution Isolation","File Metadata Consistency Validation","Content Format Conversion","File Content Analysis"]
nist_csf
["RS.MA-01","RS.MA-02","RS.AN-03","RC.RP-01"]
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.
Detection Gaps & Validation
The most-missed triage error is closing an alert in isolation: before declaring a true/false positive, pivot on the same host, user, and hash across the prior 30 days. An "isolated" encoded-PowerShell or quarantined-malware alert is often one stage of a larger chain (initial access → persistence → lateral movement) that single-alert triage hides.
Decode before you dismiss: never label encoded PowerShell, mshta, rundll32, or LOLBin activity a false positive without decoding the payload and checking the parent-process chain. outlook.exe/winword.exe spawning powershell.exe is abnormal regardless of the rule's confidence score.
Enrichment "clean" ≠ benign: zero detections on VirusTotal/OTX/MISP is common for newly registered C2 and fast-flux domains. Confirm severity with asset criticality, data sensitivity, and active-vs-historical state rather than reputation alone.
Cross-corroborate severity inputs: validate asset criticality from the CMDB (not assumption), confirm the account is genuinely privileged, and verify lateral-movement potential with EDR telemetry before assigning P1/P2 and triggering containment SLAs.
FP tuning: track each detection rule's historical true-positive rate and suppress chronic noisemakers (authorized scanners, admin tooling, sanctioned data flows) to fight alert fatigue. Don't downgrade to P3/P4 until threat-intel, asset context, and historical correlation agree — and preserve volatile memory before any remediation so a mis-triage isn't unrecoverable.
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
TheHive: Open-source incident response platform for case management, task tracking, and team collaboration
MISP: Threat intelligence sharing platform for IOC enrichment during triage
Cortex XSOAR: SOAR platform for automating enrichment playbooks and triage decision trees
Common Scenarios
Scenario: Encoded PowerShell from Email Client
Context: SOC analyst receives a P2 alert showing powershell.exe with a Base64-encoded command spawned as a child process of outlook.exe on a finance department workstation.
Approach:
Decode the Base64 payload to determine the command intent
Check the parent process chain for anomalies (Outlook spawning PowerShell is abnormal)
Query VirusTotal for the decoded payload hash
Correlate with email gateway logs to identify the triggering email and sender
Check if other recipients in the organization received the same email
Isolate the endpoint and escalate to Tier 2 with full triage context
Pitfalls:
Dismissing encoded PowerShell as a false positive without decoding the payload
Failing to check for lateral spread to other recipients of the same phishing email
Remediating the endpoint before capturing volatile memory evidence
Output Format
INCIDENT TRIAGE REPORT
======================
Ticket: INC-[YYYY]-[NNNN]
Date/Time: [ISO 8601 timestamp]
Triage Analyst: [Name]
Time to Triage: [minutes from alert to classification]
CLASSIFICATION
Type: [NIST category]
Severity: [P1-P4] - [Critical/High/Medium/Low]
Confidence: [High/Medium/Low]
MITRE ATT&CK: [Technique ID and name]
AFFECTED SCOPE
Assets: [hostname(s), IP(s)]
Users: [account(s)]
Data at Risk: [classification level]
Business Unit: [department]
EVIDENCE SUMMARY
[Bullet list of key observations]
ENRICHMENT RESULTS
TI Matches: [Yes/No - details]
Historical: [Related prior incidents]
Asset Criticality: [rating]
RECOMMENDED ACTIONS
1. [Immediate action]
2. [Investigation step]
3. [Escalation target]
ESCALATION
Routed To: [Team/Individual]
SLA Target: [Containment deadline]
