OpenDXL joined the Open Cybersecurity Alliance (OCA) when it was created last year. Now the OCA is announcing that the OpenDXL Ontology is available. The OCA claims that it is: “The first open source language for connecting cybersecurity tools through a common messaging framework.”
According to Brian Rexroad, Vice President of Security Platforms at AT&T “With the adoption of public cloud and explosion of connected devices, the ability for enterprises to quickly respond to threats across ever-changing technologies, and even beyond perimeters, is critical.
“OCA is driving an industrial shift in interoperability with the OpenDXL Ontology to support security at scale.”
Who are the Open Cybersecurity Alliance?
The OCA was formed in October 2019 with the intention to: “connect the fragmented cybersecurity landscape with common, open source code and practices.” It boasts a membership that includes many high-profile vendors in the cybersecurity space including IBM Security, McAfee, CrowdStrike, CyberArk and 20 other companies.
It sits under the umbrella of OASIS (Organisation for the Advancement of Structured Information Standards). As a language, this is probably a good place for OpenDXL Ontology to sit. OASIS has been responsible for a number of key open standards and languages including SAML, OData, OSLC, TOSCA, UDDI and XDI.
What is the OpenDXL Ontology?
In short, the OpenDXL (Open Data Exchange Layer) is a common messaging framework designed to connect security tools. OpenDXL claims over 4,100 vendors and enterprises already use it to develop and share integrations with other tools. What is new here is the Ontology and that is where this gets interesting.
One of the challenges of any level of integration is accuracy and timeliness. When a product refreshes, all the integrations to it need to be refreshed as well. The larger the product, the more integrations it has. This creates for a complex scenario, especially as an increasing number of integrations, especially in the open source space, are given away free or for low cost. This leads to a lot of orphaned code.
The OCA claims that the OpenDXL Ontology: “now offers a single, common language for these notifications, information and actions across security products that any vendor can adopt in order to communicate in a standard way with all other tools under this umbrella. This provides companies with a set of tooling that can be applied once and automatically reused everywhere across all product categories, while also eliminating the need to update integrations as product versions and functionalities change.”
How would this work?
The release offers up an example of how this would work and it is one that most security teams will recognise. “For example, if a certain tool detects a compromised device, it could automatically notify all other tools and even quarantine that device using a standard message format readable by all.”
Security teams will see this as a big bonus. To be able to get an alert that can quickly update all the tools they support in one go is a major step forward. Those who will gain the most, however, are those supporting multiple customers and having to work across a fractured security landscape.
What will interest many is how quickly OpenDXL Ontology will be adopted. Will it just be the major cybersecurity vendors who will get involved? Will there be an industry push to get a significant percentage of the industry using the tool? What resources will there be in terms of training and education for security teams? How quickly will enterprises who have ‘rolled-their-own’ cybersecurity solution be able to add this?
Enterprise Times: What does this mean?
Anything that simplifies the movement of data between applications is to be welcomed. The challenge here will be how existing OpenDXL integrations can be absorbed into the Ontology. It is unclear from both the OCA and the OpenDXL site as to how much work, if any, will need to be done by end user organisations.
One area that will need looking at is those 4,100 integrations that already exist. While some will have been written and maintained by vendors, other will not. There is a lot of community work around OpenDXL and this means there is ample scope for orphaned or abandoned integrations. These cannot just be dropped. What is needed now is a clear statement as to how integrations will be verified.
There is also the question of education. OpenDXL has done a lot of work to run events alongside security conferences. But there are still challenges with getting people educated and certified. Will this announcement of the OpenDXL Ontology provide the springboard for a range of books and online courses? Hopefully the answer is yes.
For now, one language to bind all the security tools looks interesting but will it get a wide enough adoption to survive?