Designing for the Analyst — Alert Context and Triage Experience

A detection rule has two customers: the attacker (who you’re trying to catch) and the analyst (who has to act on the alert). Most rules are designed entirely around the first customer. This lesson focuses on the second — because an alert that fires but can’t be triaged quickly is almost as harmful as one that doesn’t fire at all.

The 60-Second Rule

When an alert fires, the analyst needs to decide within 60 seconds:

Real threat, investigate now → escalate, pull timeline, begin response
Likely FP, verify quickly → check one contextual data point, close if confirmed
Need more info → this is the failure mode — analyst opens a second tool and MTTD extends

Every minute the analyst spends looking up context that should have been in the alert is a minute added to Mean Time to Detect (MTTD) and a cost multiplied across every alert in the queue.

The Five Context Categories

Every alert should surface all five:

1. Actor — Who triggered this?

Bad alert (missing actor context)	Good alert (full actor context)
“An alert fired”	User: jdoe@corp.com (Finance, no admin rights)
	Risk Score: 72/100 (high — 3 anomalies in 7 days)
	Last login: 2026-05-19 from New York

High risk score + non-admin user attempting admin-level behavior → very likely real threat. Low risk score + known-admin user at normal working hours → likely FP, verify quickly.

2. Asset — Where did this happen?

Context	Triage impact
Domain Controller (Tier 0)	Escalate immediately regardless of FP probability
Production server (Tier 1)	High priority, fast response
Developer workstation (Tier 2)	Standard priority
Contractor laptop	Elevated scrutiny — limited network visibility

The same detection on a Tier 0 asset vs a Tier 2 asset should generate different response urgency. Asset criticality enrichment enables this without rule duplication.

3. Action — What exactly happened?

The raw event data with full field visibility:

Process: C:\Windows\System32\cmd.exe
CommandLine: cmd.exe /c powershell -enc SGVsbG8gV29ybGQ=
Parent: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Parent PID: 4820
User: CORP\jdoe
Host: ws-finance-04
Time: 2026-05-20 09:41:23 UTC

An analyst reads this and immediately identifies: Word spawning cmd spawning PowerShell with an encoded command. No SIEM pivot needed. The context is in the alert.

4. Context — Why did this rule fire?

Rule: Office App Spawning Shell (T1566.001)
Severity: High
ATT&CK Technique: T1566.001 — Spearphishing Attachment
Rule Description: Detects Office application spawning a scripting engine,
  consistent with macro execution from a malicious attachment.
Analyst SOP: https://wiki/runbooks/t1566-001

The ATT&CK link, the rule description, and the runbook link tell an analyst unfamiliar with this rule exactly what to do without asking the rule author.

5. Timeline — Is this part of a chain?

-10min: jdoe received an email with attachment "Invoice_Q1.docm" (email gateway log)
-05min: WINWORD.EXE opened "Invoice_Q1.docm" (process creation)
[ALERT]: cmd.exe spawned by WINWORD.EXE
+01min: powershell.exe made outbound connection to 185.x.x.x:443 (Sysmon Event 3)

The timeline transforms an isolated alert into a visible attack chain. The analyst sees the spearphish, the macro execution, and the C2 callback — and knows to begin response, not just triage.

The Sigma `fields` Section

The Sigma spec includes a fields list that tells the converter which fields to surface in the SIEM alert view:

fields:
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - User
  - ComputerName
  - ProcessGuid

Without this: many SIEMs show a rule-match hit with a timestamp and nothing else. With this: the analyst sees the full process context inline.

Recommended fields by logsource:

Logsource	Essential fields
`process_creation`	Image, CommandLine, ParentImage, ParentCommandLine, User, ComputerName, ProcessGuid
`network_connection`	Image, DestinationIp, DestinationPort, User, ComputerName
`registry_set`	TargetObject, Details, Image, User
`file_event`	TargetFilename, Image, User, ComputerName
`ps_script`	ScriptBlockText (truncated), ScriptBlockId

Auto-Enrichment Patterns

Beyond the fields logged in the event, enrichment adds data from external sources at alert creation time:

Alert fires for: jdoe on ws-finance-04

Auto-enrichment adds:
  → jdoe: Risk Score 72, Finance dept, non-admin, last anomaly: 2026-05-15
  → ws-finance-04: Tier 2 workstation, asset owner: jdoe, last patched: 2026-05-01
  → DestinationIP 185.x.x.x: TI match — Cobalt Strike C2 (Recorded Future, 2026-05-18)
  → Rule baseline: this rule fires on ws-finance-04 approximately 0 times/month
    (first-ever alert for this host)

Enriched alert output: the analyst sees Risk=HIGH (TI match + first-ever hit + non-admin account + business-hours) and escalates without any lookup.

Worked Example

Designing the alert template for T1003.001 LSASS access

The rule detects any non-system process opening LSASS with PROCESS_VM_READ access rights.

Without alert context design:

Alert: LSASS Memory Access
Rule: proc_access_lsass.yml
Time: 2026-05-20 09:41:23

The analyst has no idea what process accessed LSASS, who triggered it, or whether it’s legitimate.

With alert context design:

Alert: LSASS Memory Access — HIGH
Rule: T1003.001 — Credential Dumping via LSASS
Time: 2026-05-20 09:41:23 UTC

SOURCE PROCESS:
  Image: C:\Users\jdoe\Downloads\procdump64.exe
  User:  CORP\jdoe (Risk: 72 | Non-admin | Finance)
  Parent: C:\Windows\explorer.exe

TARGET:
  TargetImage: C:\Windows\System32\lsass.exe
  GrantedAccess: 0x1410 (includes PROCESS_VM_READ)

ASSET:
  Host: ws-finance-04 (Tier 2 | Owner: jdoe)
  
ENRICHMENT:
  → procdump64.exe is NOT a known-good exclusion for this host
  → No previous LSASS access alerts from this host in 90 days
  → jdoe account: 3 anomalies in past 7 days

RUNBOOK: https://wiki/runbooks/t1003-001
ATT&CK:  https://attack.mitre.org/techniques/T1003/001/

The analyst reads: unknown binary by a non-admin Finance user accessing LSASS memory, with prior account anomalies. Decision: investigate, isolate host. Time to decision: under 30 seconds.

Retrieval Practice

An alert fires with: Image=svchost.exe, CommandLine='-k netsvcs -s wuauserv', User=SYSTEM, Host=dc01. How should enrichment change the triage priority, and what single enrichment source would most change your decision?

Reveal answer

The alert itself looks low-risk: svchost running Windows Update service as SYSTEM on dc01 is expected behavior. BUT — host context changes everything. dc01 is a Domain Controller (Tier 0 asset). Any anomalous process behavior on a DC should be escalated, even if the process name looks legitimate. The most valuable enrichment: verify that svchost.exe's Image path is C:\Windows\System32\ (masquerading check) and confirm OriginalFileName = 'svchost.exe' (Sysmon's PE header check). A renamed malware as svchost on a DC is an immediate P1 incident.

Retrieval Practice

Your team is designing an alert template for a brute-force detection (10+ failed logins from one IP in 5 minutes). What timeline context would most help an analyst determine if this is a real attack vs a misconfigured service account?

Reveal answer

Most valuable timeline context: (1) Did the same IP succeed on any login after the failures? (Security Event 4624 within the 5-minute window) — a success after multiple failures is highly suspicious. (2) What account names were tried? If all attempts targeted the same account (password spray on one user), it suggests targeted attack. If all attempts used one account with wrong passwords, it suggests a misconfigured application. (3) Source IP baseline: is this IP a known corporate VPN endpoint? First-ever source? Known bad actor? These three data points — success indicator, target pattern, source reputation — allow an analyst to classify the alert in under 60 seconds.

The 60-Second Rule

The Five Context Categories

1. Actor — Who triggered this?

2. Asset — Where did this happen?

3. Action — What exactly happened?

4. Context — Why did this rule fire?

5. Timeline — Is this part of a chain?

The Sigma fields Section

Auto-Enrichment Patterns

The Sigma `fields` Section