OCSF and schema-less SIEM: what Gurucul’s approach changes

At a glance

What this is: This is Gurucul’s argument that OCSF should sit at the edges of a next-generation SIEM architecture, while the core remains schema-less to preserve telemetry fidelity and behavioural analytics.

Why it matters: IAM, NHI, and security operations teams should care because the way telemetry is modelled affects correlation quality, portability, and how much identity and context survives normalisation.

Context

OCSF is a shared security telemetry language, but a schema alone does not decide how much identity, cloud, endpoint, or investigative context survives ingestion. The governance problem is where to place normalisation without flattening the raw data that analytics depend on.

Gurucul’s article argues that a next-generation SIEM should keep a schema-less core and use OCSF as a boundary contract for ingest, export, and integration. That matters for teams trying to balance onboarding speed, detection fidelity, and cross-tool interoperability.

For identity programmes, the practical question is whether normalised telemetry improves control or quietly removes the fields needed for correlation, investigation, and reporting. This is a design choice about data governance as much as it is about security operations.

Key questions

Q: How should teams use OCSF in a SIEM without losing context?

A: Use OCSF as a shared exchange format at ingest and export, but keep the internal analytics model richer than the schema. That approach preserves source-specific fields for investigation while still giving teams a common language for portability, reporting, and cross-tool integration.

Q: What breaks when a SIEM forces everything into one canonical schema?

A: Source-specific fields can disappear, future use cases become harder to support, and teams spend more time remapping data than improving detections. In practice, the platform starts to reflect schema limitations instead of telemetry reality, which weakens correlation and investigative depth.

Q: Why does telemetry fidelity matter for identity and security operations?

A: Because investigations depend on sequence, context, and source detail. If normalisation strips those elements too early, analysts lose the evidence needed to connect identity events, cloud activity, and endpoint behaviour into one coherent picture.

Q: How do teams balance interoperability and behavioural analytics?

A: Keep interoperability at the boundaries and analytical richness in the core. Standard formats help data move cleanly between tools, but behavioural detection still needs raw signals, enrichment, and context that no shared schema can fully capture.

Technical breakdown

Why schema-less ingestion matters for SIEM fidelity

Schema-less ingestion means the platform preserves raw events in their native structure before deciding how, or whether, to normalise them. That matters because security telemetry often arrives with source-specific fields that are useful for identity stitching, behavioural detection, or later investigations. If those fields are discarded too early, the platform inherits the limitations of the schema instead of the richness of the source. In Gurucul’s model, normalisation happens after preservation, so analytics can use raw, enriched, and canonical forms as needed.

Practical implication: Treat ingestion as preservation first and normalisation second, so source context remains available for detection and investigation.

OCSF as an interoperability contract, not a storage model

OCSF is designed to standardise how security events are described across tools. In this article, Gurucul uses it as a common language at the boundaries: to consume upstream OCSF data, generate OCSF-aligned exports, and move detections between environments. That is different from making OCSF the internal truth model. The architectural point is that a canonical exchange format is valuable precisely because it does not have to constrain every internal analytic decision. The schema becomes an interface, not the engine.

Practical implication: Use OCSF to reduce mapping friction and improve portability, but do not force internal analytics to conform to the lowest-common-denominator schema.

Why the schema versus intelligence tradeoff is false

The article’s core claim is that security teams do not need to choose between standardisation and analytic depth. A rigid schema-first model can strip out source-specific detail, create repeated remapping work, and weaken future use cases as telemetry evolves. A schema-less core with canonical OCSF views avoids that trap by keeping raw fidelity while still supporting shared detections and downstream exchange. That pattern is especially relevant where identity events, cloud audit trails, and endpoint telemetry must be analysed together.

Practical implication: Design the SIEM around preserved context and late binding so standards improve exchange without reducing detection quality.

NHI Mgmt Group analysis

Schema-less architecture is the real control plane, not OCSF itself: OCSF is useful only when the underlying platform can preserve telemetry richness before mapping it. The article’s strongest point is that normalisation should not be allowed to dictate what the analytic core can see. Practitioners should read this as a governance choice about where truth lives in the pipeline, not a format preference.

Telemetry fidelity is now an identity governance issue: Once identity, cloud, SaaS, and endpoint signals are flattened into a single rigid schema, the programme loses the contextual detail needed for correlation and investigation. That is a structural weakness for NHI and human IAM alike, because investigation quality depends on preserving source nuance. The implication is that data modelling decisions now shape control effectiveness, not just reporting convenience.

OCSF should be treated as an exchange language at the boundaries: Standardised export is valuable when teams need shared detections, data-lake feeds, or multi-tool interoperability. But the article shows that portability and analytic depth can coexist only if the internal model remains richer than the export contract. Practitioners should separate internal detection design from external transport design.

Identity blast radius grows when schemas hide context: When a schema removes fields that identify who did what, on which asset, and in which sequence, the blast radius of an alert widens because investigators must reconstruct context elsewhere. That makes telemetry modelling a security decision, not a plumbing decision. Teams should judge schema choices by how much investigative context they preserve under pressure.

Market pressure is shifting from data normalisation to context preservation: The article reflects a broader SIEM trend: buyers increasingly want interoperability without sacrificing behavioural depth. That signals a move away from rigid schema purity and toward architectures that can absorb change without forcing repeated re-engineering. Practitioners should expect evaluation criteria to focus more on fidelity, portability, and semantic enrichment.

What this signals

Schema choice now functions as a governance decision: Teams should evaluate whether their telemetry model preserves enough context to support investigation, not just enough structure to move data between tools. In practice, the best architecture is the one that keeps fidelity available until the point where standardisation actually adds value.

Schema-less cores reduce lock-in pressure: A platform that can ingest native logs, enrich them, and only then project into OCSF gives practitioners more room to change tools, environments, or use cases later. That flexibility matters most where identity, cloud, and endpoint signals must coexist in one operational view.

For practitioners

• Preserve raw telemetry before normalising Require the SIEM pipeline to keep source-native events intact so later enrichment, correlation, and investigation still have access to original fields and structure.
• Use OCSF as an export contract Standardise cross-tool and downstream exchanges with OCSF, but keep the internal analytic model richer than the schema you share externally.
• Validate identity context survives mapping Test whether user, device, session, and asset context still survives after schema mapping, especially for identity events and cloud audit logs.
• Separate detection logic from transport format Design detections against behavioural context and enriched entities, not against field names that only exist in one canonical schema.

Key takeaways

• The article argues that OCSF is most useful as a boundary standard, not as the internal truth model for SIEM analytics.
• Preserving raw telemetry before normalisation protects context that identity and security investigations depend on.
• Practitioners should separate exchange format decisions from detection design so interoperability does not degrade analytic depth.

Key terms

• Schema-less ingestion: An approach that accepts raw telemetry without forcing it into one fixed internal structure at the point of entry. This preserves source fidelity, which matters when identity, cloud, and workload logs need to be reinterpreted later for investigation or detection.
• Canonical export: A standardised output format used to send telemetry or findings to downstream systems. It improves interoperability and portability, but it should not become the limit of what the platform can analyse internally.
• Telemetry integrity: Telemetry integrity is the confidence that logs, metrics, and traces accurately reflect what happened. If an attacker can alter, redirect, or suppress telemetry, the security team may still see data, but it can no longer trust that data for investigation, detection, or compliance evidence.
• Late Binding Closure: A late binding closure is a function that refers to a variable from an enclosing scope and resolves that variable when the function is called, not when it is created. In loops, this can make every closure see the final loop value unless the current value is captured explicitly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.