Enrich an Alert with Multi-Source Context Before You Escalate

Tier: Core · Workflow area: AI-assisted SOC & detection

This playbook uses an LLM to assemble that context from several sources into one decision-ready brief, while keeping you the judge of what the assembled context actually means.

When to reach for this

• •
  An alert needs asset, identity, and threat-intel context pulled from three or four tools before you can call it.
• •
  You are doing this enrichment by hand for dozens of alerts a shift and want a consistent brief format.
• •
  You have read access to context sources (CMDB export, IdP export, IOC feeds) you can provide as evidence.

Skip AI when the alert is self-contained (a policy violation with all context in the event) — enrichment adds nothing.

The workflow

1. 1.

   Gather the context sources as structured evidence. Pull the relevant CMDB row for the host, the identity record for the user, and the reputation verdicts for any IP/hash/domain — as JSON or a small table. The model synthesizes; it must not fetch.

2. 2.

   Prompt for a grounded enrichment brief.

   Copy

   You are enriching one SOC alert (sample data). Produce a decision brief.
   Use ONLY the context blocks I provide below. For every statement, cite which
   block it came from: [ALERT], [CMDB], [IDENTITY], or [INTEL]. If a piece of
   context needed for a verdict is missing, list it under "Context gaps" — do
   not fill the gap with an assumption.
   
   Output:
   - What fired (one line, cite [ALERT])
   - Asset context (owner, criticality, cite [CMDB])
   - Identity context (role, status, cite [IDENTITY])
   - Threat-intel verdicts (per IOC, cite [INTEL])
   - Context gaps
   - Suggested next step (and what would change it)
   
   [ALERT] ...
   [CMDB] ...
   [IDENTITY] ...
   [INTEL] ...
   

   Expected output: a brief where every line names its source, plus an explicit "Context gaps" list. The gaps section is often the most valuable part — it tells you what to go collect.

3. 3.

   Verify each cited fact against its block. Open the CMDB row and confirm the host really is "criticality: low" as claimed. Confirm the intel verdict the model quoted matches the feed. This takes seconds because the citation points you straight at the source.

4. 4.

   Resolve the gaps yourself. For each item under "Context gaps," decide whether it is worth collecting before you escalate. The model surfaced the gap; you decide the cost of closing it.

5. 5.

   Attach the verified brief to the case. Only the facts you re-confirmed go into the case notes. Mark anything you could not verify as unconfirmed.

Verify before you trust it

• Citation check: every line must name a source block. A statement with no citation ("this host is internet-facing") is the model inferring — treat it as a gap, not a fact.
• Reputation freshness: re-query any IP/domain/hash verdict the model reports against the live feed. A model may echo a "clean" verdict that flipped to malicious yesterday.
• False-positive catch: confirm the identity block actually supports "benign." If the model calls it benign because "user is an admin" but the identity record shows the account was disabled last week, that is a real incident the model waved through.

Pitfalls

• Cross-source conflation. With four blocks in context, models attribute a fact to the wrong source — quoting an intel verdict as if it came from the CMDB. The per-line citation is how you catch it.
• Silent gap-filling. Without the explicit "Context gaps" instruction, models paper over missing data with plausible assumptions. Demand the gaps list.
• Stale intel treated as current. The model has no clock; a reputation verdict in your pasted block is a snapshot. Re-query before acting on it.
• Over-trusting asset criticality. A CMDB that says "low criticality" may be wrong or out of date; the brief inherits that error. Sanity-check high-consequence calls against a second source.

Tools

• SOAR platform with an LLM enrichment step: the enterprise pattern — the playbook fetches context, the model composes the brief; teach the shape even where the product is paid.
• Free threat-intel feeds (CISA KEV, open IOC/reputation sources, MISP/OpenCTI): supply the verifiable intel blocks and are where you re-confirm verdicts.
• Open LLM run locally (Ollama): synthesizes the brief without shipping asset or identity data to a third party.

Client-safe variant

Asset and identity context is some of the most sensitive data a client holds. In a services engagement, run the synthesis on a local Ollama model or the client's sanctioned endpoint, and redact before prompting: replace hostnames, usernames, and internal IPs with stable placeholders (HOST-A, USER-1) and map them back locally. Real IOCs (external IPs, hashes, domains) can usually stay, since they are already public indicators — but confirm against the client's data-handling policy first. Keep the enrichment blocks and the finished brief inside the client's environment; the LLM only ever sees the minimum structure needed to compose the dossier.