Enrich Before SIEM Ingestion, Not After

Raw security logs miss critical context because tools don't talk to each other.

Logs from that new AI CRM your GTM team is using come without user, business unit, or asset ownership context. When an alert fires, it sends analysts on a 15-30 minute hunt to piece together information that should have been there from the start. Meanwhile, more 'critical' alerts keep landing in the queue.

What if we could add this context before logs ever reach the SIEM?

The Timing Problem

Most security orgs enrich after ingestion. Logs hit the SIEM, detection rules fire, alerts queue up, and analysts start their enrichment loops during triage. Check the user directory. Query the TI feed. Cross-reference the asset inventory. Manually stitch together context that should have been there from the start. 

If you’re a SecOps operator, you know that enrichment happens far too downstream, meanwhile attackers are going from initial access to data exfiltration in under an hour. 

Pre-ingestion enrichment solves the core architectural failure and your data arrives with more answers than questions. Detection rules evaluate with full context. Alerts include the information needed to make a decision immediately. SOAR playbooks and AI SOC solutions become more effective because they’re given a more complete starting point. No more round-trip queries. No more manual lookups. No more stitching together three different tools to figure out if an alert actually matters.

Same Event, Different Story

Here’s an example of what tackling the issue at the root looks like:

Sample Raw OpenAI Enterprise Audit Log record

{
  "object": "organization.audit_log",
  "id": "audit_log-114a7d10-986c-ed2c-c71f-47be04098c36",
  "type": "login.succeeded",
  "effective_at": 1753089116,
  "actor": {
    "type": "session",
    "session": {
      "user": {
        "id": "user-790e575c-2867-d406-9c36-11b32f022a60",
        "email": "john.smith@evilcorp.com"
      },
      "ip_address": "185.234.217.42",
      "user_agent": "Mozilla/5.0",
      "ja3": "c386d18e-0e37-8c67-5c79-ba5f0c1f5549",
      "ja4": "5f26ebd3-1cde-1f1c-6192-7a23a9f8a6a9",
      "ip_address_details": {
        "country": "USA",
        "city": "Austin",
        "region": "Texas",
        "region_code": "TX",
        "asn": "",
        "latitude": "30.2672",
        "longitude": "97.7431"
      }
    }
  }
}

In a traditional SOC, this event would just be ingested and stored for some time before being discarded or sent to cold storage. Without context, there's no way to know if this is a legitimate event or anomalous activity. 

When you enrich seemingly low signal / benign events that can map to important steps within an attack chain, such as a login, you can uncover anomalous activity sooner. 

What Pipeline Enrichment Reveals

{
  "object": "organization.audit_log",
  "type": "login.succeeded",
  "actor": {
    "type": "session",
    "session": {
      "user": {
        "email": "john.smith@evilcorp.com"
      },
      "ip_address": "185.234.217.42"
    }
  },
  "enrichments": {
    "okta_user": {
      "status": "DEPROVISIONED",
      "statusChanged": "2025-10-17T16:44:32.292082Z",
      "profile": {
        "firstName": "John",
        "lastName": "Smith",
        "email": "john.smith@evilcorp.com",
        "login": "john.smith@evilcorp.com"
      }
    },
    "greynoise": {
      "ip": "185.234.217.42",
      "noise": true,
      "classification": "malicious",
      "last_seen": "2025-03-18"
    }
  }
}

Context changes everything. The raw event requires investigation to determine if it matters. The enriched event answers the user's employment status and whether the IP is associated with a threat campaign.

Detection rules fire on enriched data instead of raw logs. Without enrichment, a "successful authentication" rule generates thousands of events. With enrichment, it becomes "successful authentication by deprovisioned account" - which hopefully only fires a handful of times per year.

The rule that previously generated 50 alerts a day doesn't fire at all because the enriched data includes termination status, asset classification, and business context. Teams running pipeline enrichment see false positive rates drop 70-80% - not because they built smarter correlation rules, but because enriched logs prevent irrelevant alerts from triggering in the first place.

Enrichment at the Pipeline Layer

Solving enrichment at the root level means enriching events before they reach the SIEM.

As security logs flow through the pipeline, an in-flight enrichment engine injects context in real time: user status from identity providers, asset criticality from CMDBs, threat intel scores, business unit mappings. Events arrive at the SIEM already contextualized and ready for analysis.

The Measurable Impact

Here are just a few of the benefits you get when enriching in the pipeline: 

The Path Forward

Every security team deserves data architecture that works with them, not against them. Pipeline enrichment delivers context when you need it most, fewer false positives to chase, faster investigations, and more time for proactive threat hunting instead of manual data stitching.

We built pipeline enrichment for exactly this problem. Monad's enrichment engine supports 175+ sources and pairs well with our in-stream transformations and rule-based routing. No post-ingestion workarounds. No manual lookups. No waiting for context while an incident clock runs.

We're launching enrichments shortly. If you're tired of enriching data the hard way, sign up here and we'll let you know when it's live: https://www.monad.com/join-our-list

‍