The Reveal Platform
Security teams today face a constant balancing act. They must rapidly onboard new telemetry sources while also ensuring consistency for correlation, investigation, and reporting. Flexibility and standardization often collide, creating friction across tools and teams.
The Open Cybersecurity Schema Framework (OCSF) helps reduce this fragmentation by offering a shared language for security telemetry. It’s a powerful standard, but it’s not the whole story. Modern Next‑Generation SIEM platforms need more than schemas alone—they need architectures that embrace openness, preserve fidelity, and enable intelligence at scale.
Let’s dive in and see how Gurucul uses OCSF today – what it looks like in practice, current mapping, key use cases, and why this approach matters most.
Security teams have two main objectives:
However, these goals often conflict with each other. While standards promote consistency, modern Next-Generation Security Information and Event Management (NG-SIEM) platforms emphasize flexibility. That’s where OCSF (Open Cybersecurity Schema Framework) is valuable — but is commonly misunderstood.
Gurucul’s Next-Gen SIEM is schema-less by design. That doesn’t mean we ignore schemas. It means we don’t force a single rigid schema as the internal truth. Instead, we treat schemas, like OCSF, as interoperability contracts: extremely useful at the edges (ingest, export, integration), while our analytics stay optimized for scale, fidelity, and behavior-based detection.
This post details how Gurucul uses OCSF in the current architecture, highlights the use cases from which customers get value today, and explains why that matters more than just merely “storing everything as OCSF.”
OCSF provides a common vocabulary for security events (classes, categories, fields). It helps vendors and customers communicate effectively while moving data between systems or creating content that works across different tools.
What OCSF is not:
OCSF shines as a standardized interface, not as the entire internal operating system of a SIEM.
Gurucul’s architecture is designed around late binding:
Within that framework, OCSF is supported as a canonical overlay, providing a consistent representation that we can produce and consume without turning it into a single point of failure for your data strategy.
Think of Gurucul’s model in three layers:
This design is intentional: you don’t want your internal detection engine to be limited by the lowest common denominator of any single schema. You do want a clean, predictable contract to exchange data and content across systems.
For customers standardizing telemetry upstream (or adopting tools that output OCSF), Gurucul can consume OCSF-formatted events and preserve them as first-class citizens alongside native logs.
Why it’s useful
Why don’t we stop there?
Even with OCSF input, we still enrich and model behavior beyond what any schema provides.
A common customer asks: “Can I get normalized security events out in a standard format?”
OCSF is a great answer.
Gurucul can generate OCSF-aligned outputs so your downstream systems — data lakes, SOAR, XDR tooling, or partner ecosystems — receive a predictable structure.
Why it’s useful
Use cases (detections, correlations, reports) often break when they depend on vendor-specific field names.
OCSF helps create a shared layer where:
Gurucul’s approach utilizes OCSF to simplify data exchange while allowing our models to draw from richer raw and enriched contexts.
OCSF can also act as a governance tool:
Even if your internal model is more expressive, an OCSF view provides a simple “contract” for security stakeholders and auditors.
Here are the places OCSF matters most in real deployments:
When customers have dozens of tools, integrations become expensive. OCSF reduces the number of bespoke translations required.
Value: lower engineering cost, faster time-to-value.
Mergers, new SOC platforms, co-managed setups — these are common. OCSF helps reduce rework efforts when data moves.
Value: less lock-in, smoother transitions, easier coexistence.
Detection engineers want clarity. OCSF provides a familiar vocabulary that makes rules, documentation, and playbooks easier to share.
Value: shared language → shared outcomes.
Many customers feed security telemetry into broader analytics stacks. OCSF becomes the “clean pipe” that facilitates this.
Value: consistent downstream analytics without losing raw fidelity.
A common mistake in the market is viewing OCSF adoption as a proxy for “modern SIEM.”
Effective security outcomes stem from:
A rigid “everything must be stored as OCSF” approach can unintentionally:
Gurucul’s approach avoids this trap:
It is the best of both worlds: standardized exchange without the blindness that comes with it.
Here’s what to say when someone asks, “Do you leverage OCSF?”
Yes, Gurucul uses OCSF as a standard format for interoperability and ease of use across different use cases, while maintaining schema-less ingestion and providing richer internal context for sophisticated analytics.
Or in a nutshell: OCSF is our common language. Schema-less powers our intelligence.
Standards matter. OCSF is a meaningful step toward reducing fragmentation in security telemetry. But the platforms that win won’t be those locked into a single schema. They’ll be the ones built for openness—able to ingest anything, preserve everything, enrich intelligently, and speak every standard language at the boundaries. That’s exactly how Gurucul approaches OCSF today: not as the destination, but as part of a broader commitment to flexibility, interoperability, and future‑proof security.
Contributors:
Naveen Vijay
Steve Holmes
OCSF (Open Cybersecurity Schema Framework) is a standardized language for security events. It reduces fragmentation by providing a common vocabulary across tools, making integrations, detections, and reporting more consistent and portable.
Gurucul supports OCSF as a canonical interface for ingesting, exporting, and sharing data. While the core remains schema‑less for flexibility and fidelity, OCSF is leveraged at the boundaries to simplify interoperability and accelerate onboarding.
Rigidly forcing all telemetry into OCSF can strip away source‑specific fields and limit future analytics. Gurucul avoids this trap by preserving raw data, enriching it with context, and only mapping into OCSF when it adds value for integration or portability.
Gurucul treats OCSF as a “common language” for interoperability while maintaining a schema‑less core for advanced analytics. This dual approach ensures openness, scalability, and future‑proof security without sacrificing fidelity or intelligence.
