Notifications
Clear all
Topic starter
14/08/2026 6:34 pm
TL;DR: Security teams often reconcile events across 83 tools from 29 vendors, and OCSF aims to remove that vocabulary tax by standardising how security products describe events, findings, and objects, according to Anomali. The operational shift is not just cleaner data, but faster investigation, less brittle detection logic, and more reliable AI downstream.
NHIMG editorial — based on content published by Anomali: OCSF, Explained: Why a Common Schema Changes How Security Teams Work
By the numbers:
- The average organization runs 83 security tools from 29 different vendors.
- The project began in August 2022 with 18 founding companies.
- By the time it joined the Linux Foundation in November 2024, it counted more than 200 participating organizations and over 900 contributors.
Questions worth separating out
Q: How should security teams reduce schema drift across endpoint, cloud, and identity tools?
A: Start by defining one canonical event model at ingestion and mapping every source to it before data reaches analytics.
Q: Why does schema drift make investigations slower in mixed-tool environments?
A: Because analysts must first prove that differently named records refer to the same event or asset before they can assess behaviour.
Q: How do you know if schema normalisation is actually improving security operations?
A: Look for fewer one-off field mappings, higher rule reuse across sources, and shorter time to correlate the same incident across endpoint, cloud, and identity telemetry.
Practitioner guidance
- Standardise ingest-time schema mapping Map security telemetry into a common schema as data enters your lake or SIEM, rather than translating fields in every detection or dashboard query.
- Harmonise identity and asset labels Align host, instance, device, and principal naming conventions across endpoint, cloud, and identity systems so analysts can correlate the same entity without manual reconciliation.
- Measure detection logic reuse Track how many rules, hunts, and playbooks can run unchanged across sources after schema normalisation, and use that metric to justify pipeline investment.
What's in the full article
Anomali's full post covers the operational detail this post intentionally leaves for the source:
- How the Intelligent Unification Layer maps sources to OCSF before data reaches the lake
- Examples of schema drift across endpoint, cloud, and identity records
- The shipping-container analogy used to explain why standardisation reduces integration friction
- The IBM and Palo Alto Networks fragmentation finding cited in the article
👉 Read Anomali's explanation of OCSF and schema drift in security operations →
OCSF and schema drift: what it means for security operations?
Explore further
14/08/2026 6:42 pm
Schema drift is now a governance problem, not just a data problem. When one login becomes three differently named records, security teams lose more than convenience. They lose consistent evidence, reproducible detections, and auditability across endpoint, cloud, and identity systems. That makes OCSF relevant to both SOC operations and identity programmes, because the same vocabulary gap that slows investigations also weakens access analysis. Practitioners should treat schema normalisation as part of control design, not a back-office integration task.
A question worth separating out:
Q: What is the difference between normalising data at ingest and after it lands?
A: Ingest-time normalisation converts telemetry into one shared structure once, while post-ingest normalisation forces every query, dashboard, and detection to carry translation logic. The first approach reduces ongoing complexity. The second often preserves the same fragmentation, just in a different part of the pipeline.
👉 Read our full editorial: OCSF reduces security schema drift across tools and investigations
