Triages security alerts in Splunk Enterprise Security by classifying severity, investigating notable events, correlating related telemetry, and making escalation or closure decisions using SPL queries and the Incident Review dashboard. Use when SOC analysts face queued alerts from correlation searches, need to prioritize investigation order, or must document triage decisions for handoff to Tier 2/3 analysts.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Triages security alerts in Splunk Enterprise Security by classifying severity, investigating notable events, correlating related telemetry, and making escalation or closure decisions using SPL queries and the Incident Review dashboard. Use when SOC analysts face queued alerts from correlation searches, need to prioritize investigation order, or must document triage decisions for handoff to Tier 2/3 analysts.
Do not use for deep forensic investigation — escalate to Tier 2/3 after initial triage confirms malicious activity.
Detection Gaps & Validation
Triaging notables in isolation: sorting the Incident Review queue by urgency and closing one event at a time misses the attack chain — the same src/dest may have a low brute-force notable plus a separate TI match plus a proxy block that together are a confirmed intrusion. Group by src/dest and pivot across index=proxy OR index=firewall before dispositioning.
Brute force "no compromise" called too early: counting 4625 failures without checking for a trailing 4624 success (or a 4648 explicit-credential logon to a new host) closes a real account-takeover as benign. Always confirm whether the failures were followed by success from the same src.
Urgency ≠ truth: ES urgency depends on asset/identity priority lookups — a stale or unpopulated asset_lookup_by_cidr/identity_lookup_expanded mislabels a domain controller as low priority, burying a critical event. Verify the asset/identity context resolved before trusting the queue order.
CIM/TI gaps hide corroboration: if a source isn't CIM-normalized, tstats/datamodel and TI-match searches return nothing and the alert looks uncorroborated when it isn't. Confirm the relevant data model is populated for the hosts in scope, and that TI weight reflects a current feed, not an expired one.
Validate before disposition: a true positive needs corroborating evidence across at least two sources (e.g. endpoint alert + proxy C2 callback); a false positive needs the benign root cause identified and a tuning/suppression note so it doesn't recur. Record sources examined and rationale in the notable comment so Tier 2 can act without re-triaging — an undocumented close is itself a gap.
Prerequisites
Splunk Enterprise Security 7.x+ with Incident Review dashboard configured
CIM-normalized data sources (Windows Event Logs, firewall, proxy, endpoint)
Role with ess_analyst capability for notable event status updates
Familiarity with SPL (Search Processing Language)
Workflow
Step 1: Access Incident Review and Prioritize Queue
Open the Incident Review dashboard in Splunk ES. Sort notable events by urgency (calculated from severity x priority). Apply filters to focus on unassigned events:
| `notable`
| search status="new" OR status="unassigned"
| sort - urgency
| table _time, rule_name, src, dest, user, urgency, status
| head 50
Focus on Critical and High urgency events first. Group related alerts by src or dest to identify attack chains rather than treating each alert independently.
Step 2: Investigate the Notable Event Context
For each notable event, pivot to raw events. Example for a brute force alert:
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4625
src_ip="192.168.1.105"
earliest=-1h latest=now
| stats count by src_ip, dest, user, status
| where count > 10
| sort - count
Check if the source IP is internal (lateral movement) or external (perimeter attack). Cross-reference with asset and identity lookups:
| `notable`
| search rule_name="Brute Force Access Behavior Detected"
| lookup asset_lookup_by_cidr ip AS src OUTPUT category, owner, priority
| lookup identity_lookup_expanded identity AS user OUTPUT department, managedBy
| table _time, src, dest, user, category, owner, department
Step 3: Correlate Across Data Sources
Check if the same source appears in other telemetry:
index=proxy OR index=firewall src="192.168.1.105" earliest=-24h
| stats count by index, sourcetype, action, dest_port
| sort - count
Look for corroborating evidence: Did the same IP also trigger DNS anomalies, proxy blocks, or endpoint detection alerts?
Alert fired correctly but activity is authorized (e.g., pen test)
Close with comment, add suppression if recurring
False Positive
Alert logic matched benign behavior
Close, tune correlation search, document pattern
Undetermined
Insufficient data to classify
Assign to Tier 2 with investigation notes
Update via Splunk ES UI or REST API:
| sendalert update_notable_event param.status="2" param.urgency="critical"
param.comment="Confirmed brute force from compromised workstation. Escalated to IR-2024-0431."
param.owner="analyst_jdoe"
