What is OCSF and How Do You Implement It? | Datadog

What is the Open Cybersecurity Schema Framework (OCSF)?

The OCSF is an open, vendor-agnostic standard intended for organizations to ingest and manage security data across platforms. OCSF was announced in 2022 and quickly gained industry support backed by vendors such as Amazon Web Services (AWS), Splunk, IBM, Palo Alto Networks, CrowdStrike, and many others. The OCSF framework is hosted on GitHub.

DevSecOps (a combination of development, security, and operations) is a software development practice that integrates security considerations throughout an organization’s entire software development lifecycle (SDLC). Security teams collaborate closely with DevOps and managed services to detect and resolve security threats that are presented through log and message data.

Log and event data originate from multiple sources with vastly different formats, resulting in fragmentation. Fragmentation can be a significant challenge for anyone trying to understand this data. The level of effort required for data normalization can slow security responses to threats.

OCSF addresses these challenges. The purpose of OCSF is to provide:

• A common schema available across multiple formats and vendors.
• Custom fields and extended classes to improve extensibility, allowing teams to tailor-fit OCSF to the needs of their organizations’ IT environments as their environments evolve.
• Reduced time for DevSecOps and security teams to normalize logging and event data, improved reaction times, and faster insights.

What are the benefits of adopting OCSF?

OCSF offers several advantages that can significantly reduce operational overhead, enhance visibility, and expedite incident response times.

Logs are records of activity that contain vital information. Systems, computers, and environments produce logs of varying types, the most common of which are listed below:

• Application logs: Records of what an application is doing, including errors and warnings
• Access logs: Records of every attempt to access a given server; this can help understand login attempts and user identities
• Network logs: Records of traffic flow across networks, including IP addresses and other details
• System logs: Operating system (OS)-level records tracking hardware and kernel events
• Transaction logs: Records, especially for databases, tracking changes for rollback or auditing
• Security logs: Alerts of suspicious activity and intrusion detection system (IDS)/intrusion prevention system (IPS) alerts
• Audit logs: Records for regulatory compliance, reconstructing security breaches, and more

With so many input sources, plus additional custom log formats from endpoint detection and response (EDR) tools, firewalls, APIs, and identity providers, security teams can be easily overwhelmed by the volume of data and the resulting analysis.

Important benefits and reasons for adopting OCSF include:

Simplifying data ingestion

Data normalization is one of the biggest bottlenecks in security information and event management (SIEM) and extended detection and response (XDR) deployments. Log sources have unique formats, naming conventions, and nested structures. This forces security teams to build and maintain custom parsers and field mappers to ingest data into their tools. A slight change or difference in format can break brittle transformation sequences, forcing teams to manage format changes instead of managing security detection and responses. OCSF’s shared schema ensures reliable data ingestion, transformation, and analysis.

Better correlation and detection

Security detection for intrusion, spoofing, malware, and other risks depends on identifying and correlating information from disparate sources. These sources include authentication events, processing activity from API endpoints, network events from firewalls, and so on. This messaging complexity increases the risk of errors. OCSF addresses these challenges by normalizing common fields (such as source IP, username, and event date/time) across sources and data types. These advantages mean:

• Detections can be source-agnostic and reusable.
• Teams do not have to rewrite ingestion and formatting rules for new tools.
• Detections scale with the environment while supporting hybrid and multicloud infrastructure.

Improved investigations

Teams that must pivot between differing tools, dashboards, queues, and reports can lose context and waste valuable time piecing together an event’s narrative. This can delay response time and increase the likelihood of missed detections and false positives. OCSF streamlines investigations through consistent field names and formats across logs. It adds richer context through classes, categorizations, and attributes (for example, device info, user roles, and geographic data).

Paired with Datadog Cloud SIEM, OCSF’s consistency extends directly into detection workflows. Security teams benefit from simplified alert rules, faster triage, and investigations enriched with observability context, without having to translate or map fields manually.

Vendor neutrality and flexibility

Every SIEM, EDR, and other tool can use its logging format or proprietary data framework. These differences can make it difficult for teams to integrate a solid, singular threat intelligence platform. OCSF is open, extensible, and vendor-agnostic by design. This makes it possible for teams to add, manage, or change tools and platforms without rebuilding ingestion, normalization, and interpretation logic. By decoupling data structure from specific tools, the data layer becomes portable and future-proof. OCSF helps teams stay agile, and it avoids vendor lock-in, which can be critical for large organizations or teams managing federated environments.

Compliance reporting

For teams working in regulated industries like finance, healthcare, and government, ensuring compliance is essential. Audit logs, access controls, and event trails should be complete, well-organized, and easy to report. OCSF’s schema simplifies the process of creating standardized compliance dashboards and reports, tracking important events (such as logins, privilege escalations, and policy violations) across different tools, and aggregating and correlating data. For compliance needs, the benefits of using OCSF help teams in collecting and reporting audit information.

What are the key components of OCSF?

Although the OCSF schema is expressed in JavaScript Object Notation (JSON) format, the standard is agnostic to how an organization stores data. The OCSF model is built upon three major components:

• Data types, attributes, and arrays
• Event classes and categories
• Profiles and extensions

Data types, attributes, and arrays

• Data types define the structure for each event class, including strings, numbers, Booleans, arrays, and dictionaries.
• Attributes are individual data points attached to data types. These can include unique identifiers, timestamps, and values for standardizing objects. An attribute dictionary provides a consistent, technical framework containing the foundation for how attributes are applied across datasets.
• Objects and arrays encapsulate related attributes, with objects acting as organized sets and arrays representing lists of similar items.

Event classes and categories

Classes are specific sets of attributes that determine an activity type. Each class has unique names and identifiers that correspond to specific log types.

Each event class has a:

• Caption: Event title (for example, Process Activity [1007])
• Name: Field as formatted in the log (for example, process_activity)
• ID: Numerical identifier (for example, 1007)
• Description: Definition as used by the schema (for example, Process Activity events report when a process launches, injects, opens, or terminates another process, successful or otherwise.)

Categories are high-level groupings of classes that segment an event’s domain and make querying and reporting manageable. The six primary categories are:

• System activity
• Findings
• Identity and access management
• Network activity
• Discovery
• Application activity

Profiles and extensions

Profiles are overlays that add specific attributes to event classes and objects. Profiles give granular details, such as malware detection for endpoint detection tools. For example, the Cloud profile adds cloud and API attributes to each applicable schema.

Extensions enable customization and creation of new schemas or existing schema modifications for specific security tool needs.

OCSF in action: An example

The following is a JSON snippet of OCSF used to capture information from a network connection event.

{
  "class_name": "Network Activity",
  "class_uid": 1001,
  "category_name": "Network",
  "category_uid": 10,
  "severity_id": 3,
  "time": "2024-06-24T10:00:00Z",
  "src_endpoint": {
    "ip": "192.168.1.10",
    "port": 12345
  },
  "dst_endpoint": {
    "ip": "8.8.8.8",
    "port": 53
  },
  "network_protocol": "UDP",
  "metadata": {
    "product": {
      "name": "Example Firewall",
      "vendor_name": "Example Corp"
    }
  },
  "observables": [
    {
      "name": "src_endpoint.ip",
      "value": "192.168.1.10",
      "type_id": 1
    },
    {
      "name": "dst_endpoint.ip",
      "value": "8.8.8.8",
      "type_id": 1
    }
  ]
}

What are the primary challenges facing teams implementing OCSF?

Challenges facing security teams wishing to implement OCSF for their data ingestion and standardization practices include:

• Source schema variability: Many security tools emit logs in differing formats, sometimes with proprietary field names and nested structures. Mapping these to OCSF requires a deep understanding of the source format and the target schema, and some workarounds might require custom parsing logic or field-level transformations.

• Partial schema coverage: Some security tools might not provide enough data or context to fully populate OCSF’s structured fields (for example, missing event_class_id or process metadata). Incomplete mappings can force teams to choose between extending the schema, dropping fields, or degrading the fidelity of normalization.

• Field conflicts and ambiguities: Different security tools might have conflicting versions of the same field name or element. There can be differing definitions of “user” (human versus service account) or “source IP” (NATed versus internal). This overbroad categorization can make data standardization difficult. Teams must implement customization rules or logic to preserve accuracy in mapped data.

• Operational overhead: Setting up and maintaining schema mappings across multiple sources can become resource intensive. Updates to vendor formats or OCSF versions can require ongoing maintenance and regression testing to avoid data quality issues.

• Performance and latency tradeoffs: Real-time data normalization of high-volume telemetry (for example, from cloud providers or EDRs) can introduce processing delays or require costly infrastructure to handle processing load. Efficient OCSF mapping at scale demands careful pipeline design with tradeoffs between speed, accuracy, and completeness.

What features or processes should you look for when considering adopting OCSF?

Teams can struggle with the time-consuming task of normalizing data before they can even begin to detect and investigate threats. Manually standardizing data in-house is not only challenging to maintain but also demands constant effort to ensure scalability and consistency across various security platforms.

The simplest and most adaptable approach is to leverage a log processing layer, often referred to as a telemetry pipeline. Such a tool should aggregate, process, and route logs to multiple destinations. This tool should enable organizations to take control of the log volume and flow of data to:

• Enrich logs
• Direct traffic to different destinations
• Extract metrics
• Scan for sensitive data

Tools like Datadog Observability Pipelines come equipped with processors that can automatically remap incoming logs to align with OCSF fields before they reach your SIEM system.

For teams using Datadog Cloud SIEM, mapping logs to OCSF creates a seamless pipeline from ingestion to detection. OCSF-mapped logs flow directly into the SIEM, where they are immediately usable by Datadog’s out-of-the-box detection rules and custom Detection-as-Code workflows. This enables faster onboarding and reduces the complexity of building detections from scratch.

Datadog Observability Pipelines provides a growing library of prebuilt OCSF mappings for popular log sources, such as AWS CloudTrail, Microsoft Azure Activity Logs, Google Cloud logs, Palo Alto logs, and more. These out-of-the-box mappings are designed to handle the most common log formats and event types across these platforms, reducing the effort required to align telemetry to OCSF.

Learn more

Whether your team is just starting to normalize log data or looking to future-proof threat detection, adopting OCSF is a straightforward way to boost visibility, ensure consistency, and improve security across your entire technology stack.

Learn how Datadog Observability Pipelines helps security teams easily remap logs to OCSF and send them to the desired security destinations or data lakes.