Open Cybersecurity Schema Framework and the Long Road Ahead
As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories— Steve Benton of Anomali warns us that while OCSF is a great start, IT teams still have a long road ahead of them in the effort to streamline security.
For too many years, security vendors have brought products and services to market that were difficult – sometimes even impossible – to integrate, leaving IT teams to scramble as they tried to interpret alerts about potential cyber threats. But the recent announcement of a new open data standard for sharing cybersecurity information called Open Cybersecurity Schema Framework (OCSF) promises a change for the better. Once OCSF is put into practice, hard-pressed SOC teams will be able to act on notifications from different cybersecurity monitoring with far more precision and speed. Essentially, OCSF is trying to take the irritation away from the SOC teams of having to do the heavy lifting of integration.
Previously, SOC teams, or vendors of SIEM-style technologies, would have had to stitch together a patchwork fabric with pieces of source event data, a fragmented approach that also let threat actors hide and benefit from gaps or delay in detection. The beauty of having data about potential hacking activity in one format means that internal teams will be able to recognize attacks earlier, as they will no longer be forced to operate several dashboards to monitor multiple events. Instead, they will be able to compile and standardize alerts and rapidly vet incoming data to determine the next steps.
While OCSF marks a good beginning, more still needs to happen.
OCSF and the Long Road Ahead
‘Holy Grail’ Remains Elusive
OCSF must go further to address the challenges facing already overworked SOC teams. The fact remains that many security teams will find themselves overwhelmed as they try to manage this new, wider net of detection data.
The holy grail of ‘one screen’ – the very idea we are looking to move to with XDR – will still not exist. Even though OCSF unifies security events, it still does not unify the execution and coordination of security controls. So, as they respond to the broader event alerts OCSF enables, organizations will still have to go full ‘swivel chair’ mode, screen to screen, with different data and information. They’re already working full bore to get an accurate handle on data, separating real threats from false positives.
During this interregnum, SOC teams will likely find themselves forced to exist in two worlds –the pre-OCSF and post-OCSF – while the new standard gains adoption across their security ecosystem. This will chew up more time as they figure out how to manage a migration journey while still maintaining their security posture to respond to events effectively.
OCSF is a standard for delivering data to the customer’s environment, but there’s no magic super data lake to tap into here. The consortium isn’t building an infrastructure to hold this telemetry. They’re creating a standard that standardizes the structures of the telemetry.
While that’s welcome news, the standard is missing guidance for MITRE ATT&CK integration/linkage, a puzzling omission. As all SOC and CTI teams know, MITRE ATT&CK is hugely beneficial to our understanding of threats and attacks. The MITRE ATT&CK is the centerpiece of everything from threat intelligence all the way through to incidents. Most good organizations with a strong security team are heavy users of MITRE ATT&CK because it is so fundamental in understanding and codifying what’s happening.
No doubt the standard will, in time, evolve to allow the analysis of a wider and deeper range of security issues as teams accumulate a back history of OCSF events. The key to channeling the priorities remains threat intelligence to know where to look and for what.
It’s still unclear how soon we’ll see available OCSF feeds from the security vendors. This essentially will mean taking the native events data from the source, mapping it to the OCSF schema, and making it available as an OCSF feed. Indeed, this may be the initial approach from vendors themselves as they rush to release ‘OCSF compliant’ products.
That raises questions on (a) the processing overheads this might place on tools/sensors and (b) the integrity of the OCSF feed compared to the native events from which they are derived. It will surely be some time before tools and sensors produce OCSF events fully natively. And for some time, tools and sensors will have to continue to provide their current events feeds alongside OCSF as organizations migrate and adopt OCSF.
It’s all part of a longer contest, a crucial long game that requires persistence and true commitment. As a history buff, I recall what Winston Churchill famously said in 1942, after the UK won a significant victory at El Alamein. That looked to have finally reversed a demoralizing trend of defeats from Dunkirk to Singapore. But Churchill knew there was still a great deal to be done against a determined adversary.
“This is not the end,” Churchill cautioned, during a much celebrated 1942, address. “It is not even the beginning of the end. But it is, perhaps, the end of the beginning.”
As we look for new ways to improve our odds in the ongoing battle against cyber marauders, it’s a valuable lesson to keep in mind. And, remember what came afterward: A coalition of allies that worked together, persisted, turned the tide, and ultimately secured a lasting victory.