Enrichment for Context — Reducing Analyst Burden Without Suppressing Alerts

Not every noisy alert should be suppressed. Sometimes the right answer is to leave the alert in place and give the analyst the context to resolve it in 15 seconds instead of 5 minutes. Enrichment is the practice of appending additional data to an alert at creation time — before the analyst sees it — so triage requires no additional lookups.

Suppression vs Enrichment: Choosing the Right Tool

Scenario	Right tool	Why
Windows Defender accessing LSASS (verified, always benign)	Suppression (exclusion filter)	0% TP probability, no analyst value
PowerShell making network connection from developer workstation	Enrichment	Could be legitimate (Ansible, dev work) or T1571/T1105 — needs context
certutil.exe with -urlcache from unknown parent	Enrichment + high priority	TI check on destination URL determines next action
First-ever login from new country	Enrichment	Risk score + travel context determines if impossible travel

The rule of thumb: suppress only what you’ve verified has zero TP probability. Everything else belongs in the queue with good enrichment, not out of the queue.

Enrichment Source 1: Asset Criticality

Asset criticality is the single highest-value enrichment because it fundamentally changes the response SLA.

Alert: PowerShell download cradle detected

Without enrichment:
  Priority: Medium
  Action: Triage within 4 hours

With asset enrichment:
  Host: dc01 (Tier 0 — Domain Controller)
  Priority: Critical (auto-elevated)
  SLA: 15-minute response required
  Auto-action: Page on-call immediately

The same detection rule on a developer’s workstation (T2) is a medium-priority triage item. On a domain controller (T0), it’s an immediate P1 incident.

Implementation: Maintain an asset inventory with criticality tiers. Query it at alert creation. Most SIEMs support lookup tables or API enrichment for this.

# Splunk: enrich alerts with asset tier
... | lookup asset_inventory hostname AS ComputerName OUTPUT tier, owner, department
| eval priority=case(tier="T0", "Critical", tier="T1", "High", tier="T2", "Medium", true(), "Low")

Enrichment Source 2: User Risk Score

A user risk score contextualizes the alert actor:

Alert: Unusual process creation by jdoe

Without enrichment:
  User: jdoe
  Action: Review the process, check if legitimate

With user enrichment:
  User: jdoe (Finance, non-admin)
  Risk Score: 78/100 — HIGH
  Recent anomalies: 3 in past 7 days
    → Failed MFA challenge 2026-05-18 09:15
    → Login from new location (Chicago) 2026-05-17
    → Accessed HR data outside normal hours 2026-05-16

The risk score converts “probably legitimate dev activity” into “this user has had multiple recent anomalies — escalate.”

Sources for risk score contributors:

Identity provider logs (Azure AD, Okta) — MFA failures, conditional access blocks
Authentication logs — unusual logon times, new locations
DLP logs — unusual data access
HR system — employee status (departing, PIP)

Enrichment Source 3: Threat Intelligence

TI enrichment queries IP/domain/hash reputation at alert creation:

Alert: outbound connection to 185.220.101.47

Without TI:
  Analyst must pivot to TI platform to check IP reputation
  Time: 2–5 minutes per alert

With TI enrichment:
  185.220.101.47 → TOR Exit Node (Recorded Future, 2026-05-19)
  Priority: High (auto-elevated)
  TI tags: anonymization, tor-exit, proxy

A TI match converts a “might be legitimate” connection into a high-priority investigation with known context.

TI enrichment types:

Indicator	Sources	Signal value
Destination IP	Commercial TI feeds, free blocklists, internal IOC db	High for confirmed C2; moderate for scanners
Domain	PDNS analysis, newly-registered domains, public blocklists	High for known malware domains
File hash	VirusTotal API, internal malware db	Very high if AV-detected; zero if just “unseen”
User agent	Known-bad user agents from threat reports	Moderate (easy to change)

Important caveats:

TI miss (indicator not in any feed) is NOT exculpatory — novel malware is unknown
TI hits from free feeds have high false-positive rates — weight commercial feeds higher
TI ages out — a “known-bad” IP from 6 months ago may now host a legitimate CDN

Enrichment Source 4: Behavioral Baseline

“How often does this entity do this behavior?”

Alert: PowerShell network connection from ws-dev-12

Without baseline:
  Analyst: "Is this normal for dev workstations?"

With baseline:
  ws-dev-12 PowerShell network connections (30-day baseline): 0
  This is the FIRST TIME this behavior has been seen on this host.
  Similar hosts (developer workstations): 3.2 connections/day average

First-time behavior is high signal. A user who never accesses HR systems suddenly accessing them at 2am — even if no TI hit — is worth investigating.

Implementation: Precompute baselines per entity (host, user, user+host pair) using a 30-day rolling window. Alert on first-time occurrences or significant deviations from baseline.

Putting It Together: Enriched Alert Template

ALERT: PowerShell Network Connection [HIGH]
Rule: T1071.001 — Web Protocols C2 via PowerShell
Time: 2026-05-20 09:41:23 UTC

SOURCE PROCESS:
  Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  CommandLine: powershell.exe -enc <base64>
  Parent: C:\Windows\explorer.exe (user-launched)
  User: jdoe@corp.com

DESTINATION:
  IP: 185.220.101.47
  Port: 443
  TI: TOR Exit Node (Recorded Future 2026-05-19) ← TI enrichment

ACTOR CONTEXT:
  jdoe: Risk Score 78 (HIGH) — 3 anomalies in 7 days ← user enrichment

ASSET CONTEXT:
  ws-finance-04: Tier 2 workstation | Owner: jdoe | Dept: Finance ← asset enrichment

BEHAVIORAL BASELINE:
  PowerShell outbound from ws-finance-04: 0 times in 30 days ← baseline
  First-time behavior for this host

PRIORITY: AUTO-ELEVATED TO HIGH
  Reason: T0/T1 host check: T2 (standard). TI match: TOR exit. First-time behavior.

RUNBOOK: https://wiki/runbooks/ps-c2

An analyst reads this and makes a triage decision in under 30 seconds: TOR exit + high-risk user + encoded PowerShell + first-time behavior = likely real. Escalate.

Red Canary Threat Detection Report— Red Canary

Retrieval Practice

You have an alert for unusual logon time (user jdoe logging in at 3am on Saturday). Without enrichment it's a 15-minute investigation to determine if it's suspicious. With enrichment, list the four data points that would allow the analyst to resolve this in under 60 seconds.

Reveal answer

(1) Asset tier of the system logged into — a 3am Saturday login to a Domain Controller (T0) is immediately suspicious regardless of other context; to a developer's own workstation it's more likely legitimate remote work. (2) User risk score and recent anomalies — if jdoe has 0 anomalies in 30 days, this may be planned weekend work; if risk is high and there were other anomalies this week, it's a red flag. (3) Geographic/impossible travel check — is the login from jdoe's typical location (home IP) or from a new country? MFA success or failure? (4) Baseline: how often does jdoe log in on weekend nights? If it's a regular pattern (every Saturday for months), it's likely legitimate. If it's first-ever, it's suspicious. These four data points fit in an enriched alert and resolve 80% of cases in under 60 seconds.

Retrieval Practice

Your TI enrichment system flags a destination IP as 'known Cobalt Strike C2' based on a threat intel feed. The analyst closes the alert as FP because 'the IP is now owned by a CDN — the TI is stale.' What process failure does this reveal and how do you fix it?

Reveal answer

Two failures: (1) TI staleness — the enrichment system is using a feed with no TTL or expiry on indicators. An IP that hosted Cobalt Strike 6 months ago may now be reassigned to legitimate infrastructure. Fix: all TI indicators should have a confidence score and expiry date. Indicators older than 90 days without re-validation should be deprioritized or removed. (2) Analyst closure without escalation — even if the TI is stale, the analyst should verify: was the destination IP actually a CDN? Was the PowerShell command benign? Closing based solely on 'TI might be stale' is premature. Fix: make TI source and date visible in the alert ('Recorded Future, 2025-11-01' — now 6 months old), and require a secondary data point before closing a TI-matched alert.