Over the last year, AWS has announced its Security Data Lake, aimed at providing a unified, flexible, and scalable data lake for security data sources. The backbone of this service is the open-source OCSF Framework (the Open Cybersecurity Framework), launched by Splunk and built upon Symantec’s ICD Schema which is the core to providing a vendor-agnostic format for security data management.
With the advancement in all areas of security - cloud-native security, application security, DevSecOps and more––many exciting tools have emerged to provide robust security on the many layers of our product stacks. However, with this incredible evolution, comes the challenge of uniformity. Each tool comes with its own proprietary syntax, format, schema, and more. This becomes increasingly difficult to manage at scale with disparate dashboards that make it a complex undertaking to correlate and cross-reference information to make security decisions with the required context.
With context-based security becoming a central topic when it comes to applying good security practices and hygiene, it’s imperative to consolidate the data from these many sources into a single uniform data source and structure. As a DevSecOps orchestration platform that is intended to secure an entire product stack - we encountered just this same challenge when looking to normalize and unify data into a single dashboard.
When you need to perform an interchange of information or data, what is often encountered is that the formats don’t communicate and this alignment is critical. OCSF will provide this important unification layer and schema to power a modern security data lake, alongside additional industry standards that are emerging like Vulnerability Exploitability eXchange (AKA VEX), which is providing much-needed alignment of vulnerability management and context, alongside the benefits of OCSF.
What is OCSF?
The Open Cybersecurity Schema Framework is an open-source project, “delivering an extensible framework for developing schemas, along with a vendor-agnostic core security schema”. It’s intended to enable both vendors and data producers to adopt and extend the schema –– making them more applicable in domain-specific contexts. This then makes it possible for data analysts, engineers, researchers, or anyone else who needs to manipulate the data to map differing schemas to create a common language for threat detection and investigation.
The framework consists of a set of data types, an attribute dictionary, and a taxonomy that is not restricted to the cybersecurity domain nor to events, however, the initial focus is for these to enrich the visibility, causality, and correlation of cybersecurity events.
The intent of OCSF is to make it possible to unify data from many data sources in use today - whether AWS sources and lakes like CloudTrail and S3 or services such as lambda, Route53, and its logs, alongside on-prem and SaaS providers. By creating a unified schema and format it becomes possible to centralize and then analyze security data at scale. The end goal is to provide a simplified and vendor-agnostic taxonomy to remove the overhead of data normalization for security data analysis
With a single standard for security data, it now becomes programmable and queryable in ways that weren’t possible before––which is a huge benefit for developers. That is why it is no surprise that some of the largest security vendors in the industry are getting involved in this project––with initial contributions from major players including Cloudflare, Crowstrike, IBM, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Sumo Logic, TrendMicro and ZScaler.
OCSF - Digging Deeper
In order for OCSF to become a truly useful vendor-agnostic schema, it needs to support a wide range of data sources, and this is exactly what it set out to do. The OCSF framework currently supports a number of event classes relevant to cloud-native ops including:
- File System: Kernel, Memory, Scheduled job, Process
- Security Findings
- Admin Events: i.e. account_change, authn, authz, group_mgt
- Network Activity: https, dns, dhcp, rdp, smb, ssh, ftp, email
- Device Inventory
- App Lifecycle
- API Activity: e.g. web resources access
This is just a snapshot of the different event classes that OCSF is able to support, and if we take a look at a single finding, we’ll see why this emphasizes the problem.
A single security finding will often need to track many different types of information:
- Finding Details: Remediation/events
- Attack: Tactics and Techniques
- Compliance details
- Enrichments
- Malware: CVE, CVSS
- Metadata: Product / Feature
- Observables: IP, Geo
- Process: Attr/File/Parent Process/User/Session
- CIS Control
- Kill Chain
- Resources
- Analytics: Rule, behavioral, stats, learning
- Vulnerabilities: CVE/CWE/Package
While all the fields are optional, this can also be a double-edged sword. On the one hand this makes the format very flexible, which means the upside is that you can enrich the finding information with a lot of data. The downside is that when you query data because the data is optional, it may not turn up relevant data when the data is not included or enriched.
Now imagine having this amount of data for tons of vulnerabilities and alerts from myriad services, sources, and tools - how do we then correlate, contextualize, and cross-reference this data to make better security remediation decisions? This is compounded when engineering resources are already limited and bogged down.
What is VEX?
VEX (Vulnerability Exploitability eXchange), is introducing a common and universal way for products to be able to identify whether vulnerable components actually affect their own product’s stack and its potential for exploitability. This now provides a unified way for tooling and vendors to align around SBOM (software bill of materials) and supply chain security which is becoming an increasingly critical part of securing our end-to-end stacks. With new vulnerabilities being discovered daily, developers are not able to truly gain the value they require from their SBOM, without understanding what is really being used in an ongoing manner, and is directly impacted in the event of a vulnerability being discovered.
VEX helps organizations understand which vulnerabilities are relevant to their systems, enabling them to prioritize their response efforts effectively.
OCSF + VEX for More Streamlined Security
By incorporating VEX information within the OCSF schema, organizations can more easily share detailed information about the exploitability of specific vulnerabilities in different products. This can lead to more informed decision-making processes regarding patch management and vulnerability mitigation strategies.
OCSF can facilitate the exchange of VEX data across different cybersecurity tools and platforms. This ensures that vulnerability exploitability information is readily accessible and usable by all parts of an organization's cybersecurity infrastructure, from threat intelligence platforms to security information and event management (SIEM) systems.
The combination of VEX and OCSF can streamline cybersecurity operations by reducing the need for custom integration efforts. With standardized formats for sharing exploitability information, organizations can save time and resources, focusing more on addressing vulnerabilities rather than managing data inconsistencies.
Integrating VEX data into the OCSF framework can improve risk assessment capabilities by providing a more comprehensive view of an organization's security posture. Knowing which vulnerabilities are actually exploitable in the context of their environment helps security teams prioritize risks more effectively.
If we take an example from the AWS suite of tools, it’s now possible to leverage OCSF as a unified standard via the AWS Security Lake, enabling the many data producers and vendors around the globe to have a universal standard for sharing and interchanging information that is relevant for security gathering, detection, analysis, prioritization, and ultimately remediation.
AWS is betting big on OCSF as the leading standard for security data management, along with many other leading vendors in the industry. The OpenSSF with its OpenVEX project, and other tools that are leveraging VEX, everything from Trivy to Kubescape, is making it an emerging leading standard for vulnerability prioritization and assessment. These together, represent a step towards more unified, efficient, and effective cloud security practices. By facilitating the sharing of crucial vulnerability exploitability information alongside security data in a standardized format, organizations can enhance their ability to respond to and mitigate cyber threats in a timely and coordinated manner.
OCSF a Security Game Changer or Another Passing Trend?
With major players & foundations in the industry heavily involved and invested in both the OCSF and VEX frameworks, they have the buy-in and backing to be a game changer for the security engineering ecosystem. However, we will need to wait and see if the adoption grows sufficiently for OCSF & VEX to truly provide tangible value for security engineering.
They certainly have the potential, and we’re hopeful that greater unification and interchange of data will be possible across the security toolchain, to ensure our decisions are made based on actual, important, and relevant context––giving us greater confidence overall in our security programs and coverage.
Top comments (0)