Notifications
Clear all
Topic starter
08/07/2026 7:08 pm
TL;DR: OCSF should function as a shared interoperability layer, not the internal truth model for next-generation SIEM, because schema-less ingestion preserves fidelity while still enabling normalized export and shared detections, according to Gurucul. The practical takeaway is that identity and security programmes need flexible data models that protect context rather than flatten it.
NHIMG editorial — based on content published by Gurucul: Beyond the Schema, How Gurucul Powers OCSF
Questions worth separating out
Q: How should security teams decide where to use OCSF in a telemetry pipeline?
A: Use OCSF where a shared event language improves exchange, correlation, or downstream reporting, but keep the internal model rich enough to support investigations and behavioural analytics.
Q: Why do schema-less architectures matter for identity and security data?
A: They matter because identity, cloud, endpoint, and workload telemetry rarely share the same shape or investigative value.
Q: What do teams get wrong about standardising security telemetry?
A: The most common mistake is assuming that a single canonical schema can replace analytic design.
Practitioner guidance
- Map where canonical schemas should stop Document which telemetry fields must survive ingestion unchanged because they support investigations, identity stitching, or behavioural detection.
- Preserve raw events before enrichment Keep source logs intact so teams can re-model telemetry later when new use cases emerge.
- Define portability requirements for detections Review whether detection content depends on vendor-specific field names or on portable concepts that can survive a move between platforms.
What's in the full article
Gurucul's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact examples of how OCSF is mapped at ingest, export, and integration boundaries
- The schema-less core design choices behind Gurucul's semantic layer and enrichment flow
- Use-case-level explanations for onboarding, portability, and cross-team detection sharing
- The vendor's own guidance on when OCSF helps and when it should not be forced internally
👉 Read Gurucul's analysis of OCSF in schema-less SIEM architecture →
OCSF in next-gen SIEM: does schema-less architecture solve the tradeoff?
Explore further
08/07/2026 7:33 pm
OCSF should be treated as an interoperability contract, not an identity truth model. Standard schemas solve exchange problems, not analytic ones. The real governance question is whether telemetry can move across tools without losing the source-specific context needed for investigations, detections, and access decisions. Practitioners should treat canonical formats as a boundary control, not the architecture itself.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity context is already fragmented before telemetry normalisation begins.
A question worth separating out:
Q: What is the difference between canonical export and internal detection logic?
A: Canonical export is a clean, shared representation for moving data between systems, while internal detection logic depends on the full context available inside the platform. Teams should use the export layer for interoperability and the internal layer for richer analytics, rather than forcing both to share the same limitations.
👉 Read our full editorial: OCSF and schema-less SIEM: what Gurucul’s approach changes
