Over the past few years, Enterprise Strategy Group has promoted the security operations and analytics platform architecture (SOAPA). Just what is SOAPA? A multi-layered heterogenous architecture designed to integrate disparate security analytics and operations tools. This architecture glues incongruent security analytics tools together to improve threat detection, and then tightly-couples security analytics with operations tools to accelerate and automate risk mitigation and incident response. After all, you can have great security analytics for investigations, threat hunting, and root-cause analysis, but this all means diddlysquat if you can’t use these analytics to make and execute timely incident response and risk mitigation decisions.
Now we’ve certainly seen security analytics and operations come together in the market. In 2016, IBM acquired Resilient Systems to marry security operations with QRadar. Splunk followed suit in 2018 when it gobbled up Phantom. Most recently, Palo Alto Networks acquired Demisto to accelerate its Networks Application Framework strategy and serve as a critical step forward in the company’s aim to deliver immediate threat prevention and response for security teams.
SOAPA and these industry efforts have a similar purpose: Turn security insights into automated actions through closed-loop communications between security analytics engines and controls. When a security analytics system discovers a cyber-attack in progress, it can immediately alert Cisco firewalls, Blue Coat proxies, FireEye sandboxes, Trend Micro IDS/IPS, or McAfee endpoints with specific instructions on which files, hashes, network packets, and IP addresses to block.
This is a great strategy for security operations process automation but unfortunately there’s a catch. To make this work, security analytics systems must be programmed to “talk” to every type of security control out there. Not surprisingly, this is a slow and arduous process with lots of nuances. You may be covered in you have a Check Point firewall, but out of luck if you are a Forcepoint NGFW customer.
Enter OpenC2, a standards effort from OASIS. The OpenC2 forum’s mission is to define a language at a layer of abstraction that will enable unambiguous command-and-control of cyber defense technologies.
Remember that connection I described between security analytics engines and actual security controls? OpenC2 would standardize this communication. This could lead to a situation where security analytics tools could communicate in a common way with any security technology control from any vendor. No more need for custom coding, integration, proprietary APIs, etc.
Who would benefit from OpenC2? How about everyone! Users could have a standard way to modify security controls to defend against cyber-attacks or mitigate new risks as they arise. Security analytics vendors could go beyond threat detection to automate responses. Meanwhile, security tools’ efficacy could vastly improve if they could be “programmed” with new rule sets from security analytics engines in real time.
Our cyber-adversaries are well-organized, patient, and good at finding our vulnerabilities. What’s our response? We rely on point tools and manual processes and then hope for the best. As they say down south, “that dog don’t hunt.” To have any hope against hackers, cyber-criminals, and nation-states, we need to be able to use data analysis to accelerate our insights and then turn these insights into accurate and timely responses. Since OpenC2 has the potential to help here, I’m encouraging the cybersecurity diaspora to join the effort.
