SIEM outbound (Splunk + Sentinel)

What it is

Two notification-channel kinds that push every Umbra finding into your SIEM as a structured event, so the SecOps team can correlate it against the rest of their feeds (network, IAM, endpoint).

• Splunk: via HTTP Event Collector (HEC). Token auth, JSON body with sourcetype=umbra:finding.
• Microsoft Sentinel: via the Azure Log Analytics Data Collector API. Workspace-ID + shared-key HMAC signing, lands in a Kusto table named after your chosen Log-Type.

What it produces

Per finding (one event):

• Trigger, rule, severity, title, summary
• Target (ip:port or hostname), Umbra deeplink URL
• Verbatim PoC excerpt (with secret-pattern redaction applied before signing)
• Custom rule fields you set in the notification rule
• Timestamp (UTC)
• Org id

Plus the platform-specific envelope:

• Splunk: time, host=umbra, source (configurable), sourcetype=umbra:finding, optional index.
• Sentinel: row in <LogType>_CL table, with Fields keys flattened to field_<key> so they become scalar Kusto columns, not nested JSON.

What to use it for

• Correlation. Tie a confirmed-exploitable Umbra finding to a Splunk SIEM alert (“anomalous outbound from this same IP at the same hour”).
• Long-term retention. Most SIEMs already have multi-year retention configured; piping Umbra findings in keeps the evidence trail in one place.
• Alerting workflows. Use the SIEM’s existing alerting on the new sourcetype=umbra:finding events.
• Compliance. A SOC2 / ISO27001 auditor expects security events in the SIEM, not just the originating tool.

Why it matters

A security tool that’s siloed from the SIEM gets ignored. SecOps analysts won’t open another dashboard for the 30th time today. They want their feeds in one place. Sending Umbra findings to the place the analyst is already watching is what makes the findings actually get worked.

Why it’s valuable

• Native auth on each side. Splunk uses its standard HEC token header; Sentinel uses the shared-key HMAC the Azure docs specify. No lowest-common-denominator hack.
• One event per finding. Retry granularity matches the rest of the dispatcher. A failed delivery is one redrive, not a full batch replay.
• Secret-pattern redaction applies. Tokens / keys that match the redaction regex are scrubbed before sign + send, so a leaked-credential finding doesn’t itself leak the credential into your SIEM.
• Sentinel column hygiene. Fields entries are flattened to scalar columns; Kusto queries get clean column names instead of parse_json chains.

How to use it

Splunk HEC

1. In Splunk: Settings → Data inputs → HTTP Event Collector → New Token: copy the token, note the HEC URL (usually https://<host>:8088/services/collector/event).
2. In Umbra: Notifications → Add channel → Splunk (HEC). Paste URL + token; optionally set an index + source.
3. Hit Send test: the test event lands in Splunk with sourcetype=umbra:finding. Search:

   sourcetype=umbra:finding severity=critical
   

Microsoft Sentinel

1. Azure Portal → your Log Analytics workspace → Agents → note the Workspace ID and a Primary key (base64).
2. In Umbra: Notifications → Add channel → Microsoft Sentinel. Paste workspace ID + shared key; optionally set a Log-Type (default Umbra).
3. Hit Send test: within ~5 min a row appears in Umbra_CL (or your chosen Log-Type + _CL). Query in Kusto:

   Umbra_CL | where severity_s == "critical" | take 50