Understanding OCSF: The Universal Translator for Security Data in Microsoft Sentinel (Part 1 of 2)

The Open Cybersecurity Schema Framework (OCSF) addresses one of the most persistent challenges in security operations: inconsistent log formats across vendors. If you've spent hours writing custom parsers for every new data source in Microsoft Sentinel, OCSF offers a standardized schema that normalizes security telemetry before it reaches your SIEM. This post explains what OCSF is, the problems it solves, and why adopting it can dramatically simplify your Sentinel deployment.

Prerequisites

• Active Azure subscription with Microsoft Sentinel workspace

• Basic understanding of log ingestion and data connectors

• Familiarity with KQL (Kusto Query Language)

• Security Architect or SOC Engineer role

What Is OCSF?

OCSF is an open-source framework developed collaboratively by AWS, Splunk, and other industry leaders to create a vendor-agnostic schema for security event data. Rather than each vendor producing logs in proprietary formats, OCSF defines standardized event classes—authentication, network activity, file operations, vulnerability findings—that any product can adopt.

The framework organizes events into categories (like System Activity, Findings, Network Activity) and classes (specific event types within those categories). Each class has well-defined attributes with consistent naming conventions and data types.

For Microsoft Sentinel deployments, this means you can ingest OCSF-compliant logs from multiple sources and query them using a single unified schema instead of maintaining dozens of custom parsers.

The Problem OCSF Solves

Every security vendor formats logs differently. A failed authentication event from Azure AD looks nothing like one from Okta, Palo Alto, or CrowdStrike. This creates three major problems:

Parser Sprawl — You build custom parsers for each data source, resulting in hundreds of transformation rules that must be maintained, updated, and tested.

Query Complexity — Analysts write separate KQL queries for every vendor's data format, even when hunting for the same threat behavior across systems.

Detection Fragmentation — Analytics rules must account for format differences, forcing you to duplicate logic or write overly complex union queries that degrade performance.

OCSF eliminates these issues by normalizing data at the source or during ingestion, so all your authentication events—regardless of origin—share the same field names, data types, and structure.

OCSF Architecture and Event Classes

OCSF defines six high-level categories:

• System Activity — Process execution, file operations, kernel activity

• Findings — Vulnerability scans, compliance results, detection alerts

• Identity & Access Management — Authentication, authorization, account changes

• Network Activity — Connections, HTTP requests, DNS queries

• Discovery — Asset inventory, configuration state

• Application Activity — Cloud API calls, SaaS events

Each category contains multiple event classes. For example, the Identity & Access Management category includes:

• Authentication (3002) — Login attempts, MFA challenges, SSO events

• Authorization (3003) — Permission grants, role assignments

• Account Change (3001) — User provisioning, password resets

Every class has mandatory and optional attributes—fields like actor.user.name, src_endpoint.ip, time, and severity_id—that are consistently named across all data sources.

How OCSF Integrates with Microsoft Sentinel

There are three integration patterns:

1. Native OCSF Data Connectors Some vendors (like AWS Security Lake) emit logs in OCSF format natively. You configure the data connector in Sentinel, and events arrive pre-normalized.

2. Transformation at Ingestion For non-OCSF sources, you use Data Collection Rules (DCR) with KQL transformations to map incoming logs to OCSF schema before they land in custom tables.

3. Post-Ingestion Parsing Functions You ingest raw logs and use KQL functions to query them through an OCSF lens. This approach is less efficient but useful for legacy sources.

The most effective pattern is transformation at ingestion using Azure Monitor Agent and DCR transformations, which we'll configure in Part 2.

Benefits for SOC Teams

Unified Hunting Queries — Write a single KQL query that works across Azure AD, Okta, Duo, and any other OCSF-compliant authentication source.

Reusable Analytics Rules — Build detection logic once and apply it to all normalized data sources without modification.

Faster Onboarding — New data sources that support OCSF require minimal configuration—no custom parser development.

Improved Performance — Querying structured, normalized data is faster than running complex parsers at query time.

Vendor Flexibility — Switching authentication providers or EDR platforms doesn't require rewriting your entire detection library.

OCSF vs. Microsoft's Common Event Format

Microsoft introduced the Advanced Security Information Model (ASIM) to solve similar problems. ASIM provides normalized schemas for authentication, DNS, network sessions, and other event types.

The key differences:

• ASIM is Microsoft-specific and tightly integrated with Sentinel

• OCSF is vendor-agnostic and designed for multi-cloud, hybrid environments

• ASIM uses function-based normalization

• OCSF normalizes at ingestion

You can use both simultaneously. For example, normalize third-party logs to OCSF, then map OCSF tables to ASIM functions for analytics that depend on Microsoft's schema.

Real-World Use Case

Consider a multinational organization using:

• Azure AD for corporate SSO

• Okta for acquired subsidiaries

• AWS IAM for cloud infrastructure

• CrowdStrike Falcon for endpoint telemetry

Without OCSF, hunting for credential stuffing attacks requires four separate queries with different field names and join logic. With OCSF-normalized authentication data, you write one query:

OCSF_Authentication_CL
| where time >= ago(1h)
| where class_uid == 3002  // Authentication event
| where status_id == 2     // Failure
| summarize FailureCount = count() by actor_user_name, src_endpoint_ip
| where FailureCount > 10

This query works identically across all four systems because every authentication event has the same schema.

Conclusion

OCSF provides a vendor-agnostic schema that eliminates parser sprawl, simplifies detection engineering, and improves query performance in Microsoft Sentinel. By normalizing security telemetry at ingestion, you gain the flexibility to adopt new tools without rewriting detection logic.

In Part 2, we'll deploy OCSF to Sentinel using Data Collection Rules, transform sample authentication logs, and build unified analytics rules that query across multiple sources.