Traditionally, a SIEM or EDR vendor produces security findings in some form. Depending on
the product and vendor, those findings can be called alerts, offenses, etc. Organizations buy
security products, learn the data models associated with said products, store their produced
security alerts, investigate, and analyze them. Ideally, everything works well, everyone is happy,
a daily routine is established, and the security team is in control. What a perfect - yet imaginary -
world.
Multiple events can turn all of this upside down: Organizational change through acquisition or
merger, migration to the cloud, the introduction of AI/ML into the detection engineering
strategy, etc. All these events can trigger the following challenges: more than one SIEM/EDR
security product must co-exist in the organization’s ecosystem, a need for integration and
transportation from/to multiple SIEM/EDR systems, cross-system correlation, combined efficient
storage, and federated searches and analytics across data from different SIEM/EDR sources.
Considering that each of the SIEM/EDR products is built around its own unique data/domain
model, with the evolution of Cloud and AI/ML technologies, it requires enormous effort to
address those challenges.
Security threats do not limit themselves; they have no boundaries or borders. When security
products are fragmented, having the upper hand in the war against adversaries is impossible.
Today, organizations and government institutions require access to security data from all
available SIEM/EDR products. But how can we consolidate all security findings without
defining a common domain model and the structure of such findings? It is impossible without
having constructive collaboration between major vendors in the security industry.
In Q3 2022, IBM joined forces with more than eighteen security partners to progress toward a
common goal of security data/domain model unification via the OCSF (Open Cybersecurity
Schema Framework) open-source project. Since then, the community has grown significantly,
and OCSF has also been adopted in production by multiple vendors.
While Open Cybersecurity Schema Framework covers a broader range of security data, the
Security Finding specifically addresses the above-mentioned challenges. Each attribute of
Security Finding has evolved (and continues evolving) through discussions and compromises
from different points of view, business needs, and years of experience from multiple vendors. It
considers the modern needs of analytics, machine learning, threat hunting, correlation and
observation, resource management, and rule/policy engines.
The diagram above demonstrates the high-level structure of the Security Finding. Most objects
enclosed in this schema are optional; however, they provide flexibility to add all relevant
information to help security products and analysts to conduct threat investigations. It is suitable
for event snapshot findings and evolving, transactional findings, enriched while moving through
the processing pipeline.
Security Findings can hold most associated artifacts such as observables, resources, enrichments,
and related events, including other Security Findings. Observable objects may contain any object
defined as an observable, anything from an IP Address to Geo Location. Resources follow the
same logic when an object must be defined as a resource, such as Device or Audit Log.
Enrichment objects can represent anything, from ML-generated scores to a custom object not
covered by the current OCSF schema.
I would like to pay special attention to the Analytic object. It is designed to hold information
about a process that contributed to Security Finding creation. It could be a Rule, Behavioral,
Statistical, Learning (ML/DL), or Other. Analytic also could be a composite of multiple analytic
object types contributing to a decision.
Gradual adoption by security products of OCSF and Security Finding specifically will have a
dramatic impact, turning the tide in the everlasting war between security threats and defense.
In our next post, we will demonstrate by example how IBM QRadar Offenses fit into the OCSF
Security Findings.
References:
1. OCSF: https://github.com/ocsf
2. OCSF Security Finding: https://schema.ocsf.io/classes/security_finding