Home SecurityNetwork Security Key takeaways from the Open Cybersecurity Schema Format

Key takeaways from the Open Cybersecurity Schema Format

Source Link

One of the most pervasive challenges in the current cybersecurity environment is an overabundance of tooling vendors, all of which produce telemetry or data, often in their own native or nuanced schema or format. As cybersecurity’s visibility has risen in organizations, so has the number of cybersecurity vendors and tools that teams need to integrate, implement and govern. Cybersecurity professionals must spend time getting tools to work together as a cohesive portfolio, which detracts from their efforts to identify and address cybersecurity vulnerabilities and threats.

The problem isn’t going unnoticed. Recently Amazon Web Services (AWS) along with other leaders such as Splunk, CrowdStrike, Palo Alto, Rapid7, and JupiterOne announced the release of the Open Cybersecurity Schema Framework (OCSF) project. The announcement acknowledges the problem of security professionals needing to wrestle with proprietary data formats and outputs rather than their actual roles of risks and threats. This is problematic given the industry is already facing significant workforce challenges, burnout and fatigue. By standardizing on security product schemas and formats, security practitioners can spend more time addressing threats that pose risks to organizations.

Below is an explanation of the OCSF, including some of its core aspects such as data types, attribute dictionary and taxonomy, all of which is laid out in the detailed Understanding the Open Cybersecurity Framework guide.

What is the Open Cybersecurity Schema Framework?

The OCSF holds promise to support a vendor-agnostic approach that the industry and security tool vendor community can rally around to help make security portfolios work together more seamlessly. It does this while offering a customizable and capable schema that can be adopted out of the box by organizations but also still tailored to unique profiles, requirements and environments.

The schema aims to standardize and normalize the data generated by cybersecurity tooling. It isn’t restricted to the cyber domain or its associated events, though this was the initial focus of the project. For those interested, you can use the schema browser for OCSF, shown below.

open cybersecurity schema format Chris Hughes

When navigating to the schema browser, you can see current extensions, which for now is only development. You can also see the profiles the schema supports: cloud, domain security, file security, host, malware, reputation and user. The schema is built around four key personas: author, producer, mapper and analyst. Each are associated with activities such as creating and extending the schema, generating events, translating events from other sources to the schema and ultimately searching, writing rules, and creating reports from the schema. The personas align with existing roles in the career field such as a SOC analyst manning an SIEM, for example, or a vendor producing telemetry in the OCSF schema format.

The OCSF categories provide support for popular technologies and activities in the technology domain as mentioned. For example, looking at the container lifecycle activity event class in the schema browser, you can see that it supports the core tenants discussed below such as activity, category and class, but it also can provide additional information such as count, duration, and even HTTP methods used.

These captions, as the schema calls them, reports relevant information about the installation, removal, starting or stopping of containers with a rich out-of-the-box variety of metadata fields. The same goes for cloud activity, which can provide insight into cloud APIs, storage activity and virtual machine events. These fields in the schema can be used to capture and enrich core information such as information about activity in the cloud control and data plan, associated storage and underlying virtual machines, and compute capacity being used to host cloud workloads.

OCSF taxonomy

OCSF’s taxonomy rallies around six fundamental constructs:

  • Data types
  • Attributes and arrays
  • Attribute dictionary
  • Event classes
  • Categories
  • Profiles and extensions

Data types include common forms such as strings and integers but also scalar data types such as timestamps and IP addresses. Attributes are unique identifier names for fields and their corresponding data types. The OCSF attribute dictionary covers all the available attributes with their associated types as the core of the framework. For example, event classes would be a particular set of attributes. Event classes cover specific categories of activities or metrics, such as system and network activity or security findings.

Profiles, as mentioned, align with domains such as cloud and overlay additional attributes onto event classes and objects to facilitate better filtering. Lastly, extensions allow the schema to be extended while keeping the core schema. This is useful when trying to add new attributes and event classes, which makes the schema dynamic and flexible.

OCSF enrichment and categorization support

OCSF also supports what is known as enrichment, which takes a base object and allows the additional information to be added during the collection or processing of events but prior to storage. This supports correlating information collected such as IP and MAC addresses to specific indicators of compromise (IoC) during the processing activities prior to storage.

The OCSF schema supports categorizing events for better organization and understanding. Specific categories could include system, network and audit activity as well as findings, or in the case of a profile, cloud activities.

There is a close relationship between the OCSF and the popular MITRE ATT&CK framework. Profiles such as malware add MITRE ATT&CK information onto system activity classes. There are other similarities with MITRE ATT&CK – for example, correlations with terms such as categories in OCSF and tactics in ATT&CK or for event classes and ATT&CK techniques. Differences include ATT&CK’s support for sub-techniques and the fact that ATT&CK is proprietary and controlled by MITRE while OCSF is open and extensible among the vendor and broader security community.

OCSF participation open to all

The need for vendor-agnostic security schema has been recognized by many security professionals and their respective organizations. While the initial group of project contributors include some of the most notable names in the cybersecurity vendor space, the OCSF supports contributions by others and offers an associated OCSF Contribution Guide.

The dynamic threat landscape has led to tool sprawl for many organizations. Rallying around an industry standard schema and data normalization can help make SIEMs and SOCs more effective and maximize the opportunity for practitioners to identify and respond to relevant threats.

Copyright © 2022 IDG Communications, Inc.

Related Articles

Leave a Comment