<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: performing-alert-triage
description: >-
  Systematic alert triage methodology for SOC analysts including severity
  classification, IOC enrichment, false positive identification, contextual
  correlation, disposition workflows, and SLA-driven escalation procedures
  across Splunk ES, Elastic Security, and Microsoft Sentinel.
domain: cybersecurity
subdomain: soc-operations
tags:
  - alert-triage
  - soc
  - siem
  - splunk
  - elastic
  - sentinel
  - enrichment
  - false-positive
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1078"]
---

# Performing Alert Triage

## Overview

Alert triage is the frontline SOC function that determines whether security
alerts represent true threats, benign activity, or false positives. Effective
triage reduces noise, accelerates response to real incidents, and provides
data for detection tuning. This skill covers structured triage methodology
across major SIEM platforms.

## Prerequisites

| Requirement | Purpose |
|---|---|
| SIEM access (Splunk ES/Elastic/Sentinel) | Alert queue and investigation |
| Threat intel platform | IOC enrichment |
| EDR console access | Endpoint context |
| Asset inventory / CMDB | Asset criticality context |

## Key Concepts

### Triage Classification Matrix

```
DISPOSITION CATEGORIES:
├── True Positive (TP) — Confirmed malicious activity
│   Action: Escalate, contain, document
├── Benign True Positive (BTP) — Real activity, authorized
│   Action: Close, add to allowlist, tune rule
├── False Positive (FP) — Alert fired incorrectly
│   Action: Close, document FP pattern, tune detection
└── Indeterminate — Insufficient data to classify
    Action: Enrich further, escalate to T2 if SLA at risk
```

### Splunk ES Triage Queries

```spl
-- Prioritized alert queue
| from datamodel:"Notable"
| where status="new"
| eval priority=case(
    urgency=="critical", 1,
    urgency=="high", 2,
    urgency=="medium", 3,
    1==1, 4)
| sort priority, -risk_score
| table time, rule_name, src, dest, user, urgency, risk_score

-- Context: all alerts for same source in 24h
index=notable src="$src_ip$"
| where _time > relative_time(now(), "-24h")
| stats count by search_name, urgency, status_label
| sort -count

-- Context: user risk score breakdown
| from datamodel:"Risk"."All_Risk"
| where risk_object="$username$"
| stats sum(risk_score) as total_risk, values(search_name) as detections
    by risk_object, risk_object_type
```

### Elastic Security Triage

```
// High-severity unacknowledged alerts
kibana.alert.severity:("critical" or "high") AND
kibana.alert.workflow_status:"open"

// Correlate source IP across indices
source.ip:"$src_ip$" AND event.kind:"alert"
| stats count by rule.name, event.severity
```

### Sentinel KQL Triage

```kql
// Active incidents by severity
SecurityIncident
| where Status == "New"
| extend AlertCount = array_length(AlertIds)
| project TimeGenerated, Title, Severity, AlertCount, Owner
| sort by Severity asc, TimeGenerated asc

// Entity investigation
SecurityAlert
| where Entities contains "$entity$"
| summarize count() by AlertName, AlertSeverity
| sort by count_ desc
```

### Enrichment Checklist

```
FOR EACH ALERT:
1. Source IP
   □ Internal or external?
   □ Asset criticality (CMDB lookup)
   □ GeoIP location — expected for user?
   □ Threat intel match (VT, AbuseIPDB, OTX)

2. Destination
   □ Known service or unusual target?
   □ Port/protocol normal for environment?
   □ DNS resolution — legitimate domain?

3. User Context
   □ Service account or human?
   □ Normal working hours?
   □ Recent password change or MFA reset?
   □ HR status (active, terminated, contractor)

4. Historical Context
   □ Similar alerts in last 7 days?
   □ Known FP pattern documented?
   □ Part of ongoing investigation?
```

## Workflow

1. **Queue** — Pull highest-priority unassigned alert
2. **Validate** — Confirm alert logic matches observed events
3. **Enrich** — Add context from TI, CMDB, EDR, identity
4. **Correlate** — Check for related alerts on same entities
5. **Classify** — Assign disposition (TP/BTP/FP/Indeterminate)
6. **Act** — Escalate, contain, tune, or close per disposition
7. **Document** — Record findings, IOCs, and analyst notes

## Detection

```yaml
title: Alert Triage Detection
id: 94d52860-6322-4810-a25a-155c1bd31221
status: experimental
description: Detects suspicious activity related to performing alert triage techniques in soc operations context
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine: "*performing*alert*"
  condition: selection
level: medium
tags:
  - attack.t1078
  - attack.defense_evasion
falsepositives:
  - SOAR platform executing automated response playbooks
```

## Verification

| Check | Method |
|---|---|
| Triage SLA met | Alert timestamp vs. disposition timestamp |
| Enrichment complete | All checklist items addressed |
| Disposition accurate | T2 review of sample escalations |
| FP patterns documented | Tuning backlog populated |
| Context preserved | Case notes include investigation steps |
