Monitoring has become the Achilles’ heel of modern applications. Businesses are often overwhelmed with alerts, traces, and log data. Much of the data is hard to assimilate, making it hard to analyze the information and spot performance or security problems in the making and underway.
Security teams must correlate and unify data across multiple products from different vendors, many of which use proprietary formats. So, instead of focusing primarily on detecting and responding to events, security teams spend time normalizing this data as a prerequisite to understanding and responding to threats and incidents.
The problem stems from the fact that networking infrastructures are very complex, typically comprised of on-premises and multiple cloud elements. IT managers and security teams use many disparate tools to monitor conditions. Unfortunately, many of the tools are siloed and generate vast amounts of logs, traces, and alerts.
The industry is under pressure to remedy the situation. A major effort to address this issue was recently announced. The effort is the work of 18 systems and security vendors and is called the Open Cybersecurity Schema Framework (OCSF).
OCSF is led by Amazon Web Services and Splunk and includes Broadcom, Salesforce, Rapid7, Tanium, Cloudflare, Palo Alto Networks, DTEX, CrowdStrike, IBM Security, JupiterOne, Zscaler, Sumo Logic, IronNet, Securonix, and Trend Micro.
The project aims to provide an extensible framework for providing interoperable core security schema not tied to a specific provider. It includes an open specification for the normalization of security telemetry across a wide range of security products and services, as well as open-source tools that support and accelerate the use of the OCSF schema.
The authors of an AWS blog announcing the effort noted: “We believe that use of the OCSF schema will make it easier for security teams to ingest and correlate security log data from different sources, allowing for greater detection accuracy and faster response to security events. We see value in contributing our engineering efforts and also projects, tools, training, and guidelines to help standardize security telemetry across the industry. These efforts benefit our customers and the broader cybersecurity community.”
OCSF extends the ICD Schema specifications originally developed by Broadcom’s Symantec division. It covers numerous data types, an attribute dictionary, and a taxonomy written in JSON. An overview of the specification can be found on GitHub.
The project aims to provide an extensible framework for providing interoperable core security schema not tied to a specific provider. According to a GitHub white paper written by Splunk distinguished engineer Paul Agbabian, “OCSF features an agnostic storage format, data collection, and extract, transform, and load (ETL) processes. The schema browser represents categories, event classes, dictionaries, data types, profiles, and extensions.”
Many have noted that OCSF alone is not a panacea to the security observability interoperability issue. Recent industry efforts are trying to help in other ways, and they could complement OCSF.
For instance, earlier this year, an OpenTelemetry effort was formed. It offered a framework that merged OpenCensus and OpenTracing. OpenCensus was operated by Google with contributions from Microsoft and others, while the Cloud Native Computing Foundation (CNCF) managed OpenTracing.
Bringing these two efforts together has the potential to offer an all-in-one solution for all telemetry needs. OpenTelemetry is still in the early stages of development. It exists as an incubating project managed by the CNCF. One of OpenTelemetry’s key selling points is the standardization of the collection and transmission of telemetry data to cloud-native platforms. Tracing, metrics, and logs, considered to be the three pillars of observability, are unified under the effort. This improves the portability of the data, especially as OpenTelemetry is supported by a wide range of cloud providers and vendors through its backward compatibility.
Many believe OCSF has the potential to help with the problems that arise when managing multiple security solutions. It also has the backing of some major vendors in the market. So, as those vendors adopt the schema, it will be widely used.
However, there are still some issues to consider. First, OCSF is missing MITRE ATT&CK integration. As many security professionals know, MITRE ATT&CK is highly beneficial to understanding threats and attacks. Security personnel will thus still have to incorporate MITRE ATT&CK information and knowledge into any planning and actions.
A second issue is that OCSF adoption will happen over time. As a result, security Ops teams “will have to exist in two worlds, the pre-OCSF and post-OCSF,” says Steve Benton, VP of Threat Research at Anomali. So, while OCSF gains adoption across the vendor community, security Ops teams will have to take that into account while maintaining their security posture and responding to events.
Related articles:
NetOps teams, like Spider Man, have great powers and great responsibilities. Increasingly, they are adopting a Zero Trust approach to network operations to help fight their battles.
Senior stakeholders who want to hold on to their CISOs must ensure that they have sufficient incentives and, more importantly, support to cope with the burden of risk that they are carrying.
The most alarming takeaway from Cisco’s new Cybersecurity Readiness Index report is that even after decades of having the importance of cybersecurity driven home, cyber threats are still taken too lightly.
