Notifications
Clear all
Topic starter
01/08/2026 10:46 pm
TL;DR: Legacy SIEM schemas create lock-in, slow correlation, and make AI-driven detection harder to operationalise. DataBahn argues that the Open Cybersecurity Schema Framework, or OCSF, gives security teams a vendor-neutral model for telemetry flow, lakehouse architectures, and compliance-driven correlation as NIS2 and DORA deadlines tighten. The architectural shift is no longer optional when data fragmentation becomes a governance problem.
NHIMG editorial — based on content published by DataBahn: Why are Legacy SIEMs a problem?
By the numbers:
- The project has since grown from 17 founding companies to over 900 contributors and 200 participating organizations.
Questions worth separating out
Q: How should security teams implement schema normalisation in a mixed-vendor SOC?
A: Start by mapping the highest-value telemetry sources, especially identity, cloud, endpoint, and firewall events, into a shared schema before they reach analytics.
Q: Why do proprietary security schemas create operational risk?
A: They tie detections, dashboards, and investigation workflows to one vendor’s field model, which makes migration expensive and slows response when data must be correlated across platforms.
Q: What breaks when telemetry is not normalised before analysis?
A: Cross-source correlation becomes unreliable, identity and network events are harder to match, and AI tools have to learn around inconsistent labels instead of analysing behaviour.
Practitioner guidance
- Standardise the event model before expanding the analytics stack Map identity, cloud, endpoint, and network telemetry to a shared schema such as OCSF before building new correlation content.
- Decouple detection content from destination-specific schemas Refactor rules, dashboards, and enrichment logic so they operate on normalised events rather than vendor-native field names.
- Build schema governance into the data pipeline Assign ownership for field mapping, schema versioning, and exception handling at the pipeline layer.
What's in the full article
DataBahn's full article covers the operational detail this post intentionally leaves for the source:
- Version-by-version OCSF implementation details, including the event classes added in 1.4.0 and how they map to downstream use cases.
- Pipeline architecture specifics for normalising heterogeneous telemetry before SIEM ingestion or lakehouse storage.
- Examples of how OCSF support changes migration planning, detection portability, and enrichment workflows across vendor environments.
- The article's discussion of how compliance deadlines and AI-driven SOC tooling are shaping OCSF adoption decisions.
👉 Read DataBahn's analysis of why OCSF matters for modern security data pipelines →
OCSF and SIEM normalization: what security teams need to change?
Explore further
01/08/2026 10:55 pm
OCSF is becoming the interoperability layer security operations have lacked. The article shows that schema standardisation is no longer a hygiene discussion, because AI-assisted detection, lakehouse architectures, and cross-platform analytics all depend on the same underlying data structure. That puts OCSF closer to a control plane than a formatting convention. For practitioners, the implication is clear: if telemetry cannot move cleanly across tools, the rest of the stack inherits the fragmentation.
A question worth separating out:
Q: Who is accountable for telemetry schema governance in a modern security programme?
A: Accountability should sit with the team that owns the pipeline and the detection architecture, not with individual tool owners. If schema changes are unmanaged, every source becomes its own mini-standard, which is how translation debt accumulates and resilience erodes.
👉 Read our full editorial: OCSF is becoming the control plane for AI-ready security data
