Open Cybersecurity Alliance – what is it and why is it needed?
The Open Cybersecurity Alliance (OCA) is a new initiative being established by technology vendors and software publishers under the auspices of the OASIS information technology standards consortium. Its aim is to develop open code, standards and tools that can connect technology products across the security ecosystem in order to foster data sharing across the threat lifecycle to enable more effective, real time information security intelligence that can better inform activities that include threat detection and hunting, analysis and incident response.
There are many forces driving the need for greater automation of security controls. These include the need to control costs by automating manually intensive yet routine tasks that provide little added value, which is an ever-growing imperative owing to the widespread shortage of skilled security professionals. Without some level of automation, the speed and scale that organisations would like to achieve in business operations is almost impossible to achieve. However, many are embarking on more extensive automation programmes. Recent research by Enterprise Management Associates shows that, whilst 52% of organisations are planning for automation initiatives or are in the early stages of implementation, 45% are advanced in their automation initiatives. Just 4% have no plans to automate processes.
This push towards automation has led to an explosion in the number of point security products deployed by organisations, designed to solve a particular issue. As a result, even though many are trying to consolidate the number of vendors that they deal with, many security executives report that they are still overwhelmed by the number of vendors and products that they must manage.
But it is not just the executives who are feeling the pain. Staff in security operations centres report alert fatigue – dealing with an excessive number of alerts from disparate vendors. According to the most recent Cisco CISO benchmark survey, almost four-fifths of respondents stated that managing alerts from multiple vendors is challenging. The more vendors that they use, the greater the challenge becomes. As a result, they can only respond to half of the alerts that they receive, resulting in problems being fixed in just 43% of cases. Even more frustrating, only an average of 24% of alerts seen are reported as being legitimate. Anything that could help to sort out this problem would be welcome.
Automation can do much to help, with 77% of respondents to a recent survey by AIIM reporting improved alert monitoring and prioritisation and 71% seeing reduced response times when incidents occur. Yet, just 55% report elimination of alert fatigue and only half state that automation results in better prioritisation of security operation activities.
One of the main problems that remains is the lack of integration among tools aimed at automating security processes. Although the situation is improving, the SANS Institute reports that almost half of organisations find their efforts to benefit from greater automation are hampered by having implemented too many tools that are not integrated. This means that, whilst the number of alerts that must be dealt with can be reduced, there is a lack of correlation among alerts being thrown up by different tools, hindering the ability to delve into contextual information related to how an incident occurred, what systems are impacted and the extent of the potential overall damage. Without integration among tools, organisations are often not able to realise the value of the technology that they have deployed.
Many vendors have taken steps to address problems with lack of integration among tools in an effort to provide their customers with greater resilience to security threats. Vendors now routinely offer application programming interfaces (APIs) to connect products more easily than the traditional method of writing custom interfaces.
Another important initiative is the development of platforms that contain multiple technology capabilities coupled together. An example of this is the development of security intelligence platforms, generally built on the basis of a security information and event management (SIEM) system. Among the tools being added to these platforms are security orchestration, automation and response (SOAR), user and entity behavioural analytics (UEBA), endpoint detection and response (EDR) and network analytics tools. Such tools help organisations in their quest for automation, aiding in their detection and response efforts by looking at contextual information from events seen in order to understand patterns of activity.
Platforms such as these ingest information from a wide range of sources that include not only the tools mentioned, but also a wide range of other sources. Some of those sources will be tightly integrated into the platform, whilst others that could potentially include physical security systems and human resources applications may require the building of one-off integrations.
Goals of the OCA
The establishment of the OCA is built on the realisation that security tools need to speak a common language so that interoperability can be achieved at the communication and data levels. According to IBM Security, the goal of the OCA is to enhance interoperability and collaboration around various different standards, tools, procedures and open source libraries. Through this, organisations will be able to create a more sustainable approach to addressing the increasing volume and sophistication of security threats by being better able to identify, drill into and prioritise remediation more effectively.
The following are the initial contributions to the OCA made by founder members:
- STIX Shifter – developed by IBM Security, STIX Shifter is an open source library of information regarding potential threats that will enable organisations to translate information into a more easily digestible format and that will help create a standardised cybersecurity data model. It can ingest threat information from diverse data sources and then convert them into a common STIX 2 Observations format, getting away from the time-consuming task of cleansing and normalising disparate data feeds before they are usable.
- OpenDXL – developed by McAfee, Open DXL is a foundational transport layer for communicating and sharing security information among technology tools to better enable real time and more accurate security decisions to be made and actions to be taken.
- OpenC2 – now incorporated into OASIS, OpenC2 is an effort to develop an open standards-driven language based on nouns and verbs needed to encode human intent and decisions in machine-readable format to denote the courses of action to be taken by an orchestrator of security response.
Open source is an essential element of the work being done under the auspices of the OCA in order to overcome the challenges presented by the fast paced and constant innovation being seen in technology today. A community that is based on collaboration and a shared approach represents the best way of addressing the future needs of organisations for achieving integration and interoperability and for benefiting from the rapid introduction of new and innovative technologies. It will enable organisations to treat automation, cybersecurity and risk as a business process, not an IT project.
To summarise the benefits that will be offered by the establishment of the OCA, Jason Keirstead, chief architect at IBM Security Threat Management, states: “The mission of the OCA is to create a unified security ecosystem, where businesses no longer have to build one-off manual integrations between every product, but instead can build one integration to work across all, based on a commonly accepted use of standards and code.” The more members that join and the wider its work is disseminated, the greater the benefits will be for all.