Three New Standards Compound Security Engineering Challenges

Written by Nick Heudecker

September 7, 2022

A recent ESG/ISSA survey highlighted that security professionals are overwhelmed with competing proprietary data standards and integration challenges. Today’s security landscape often comprises dozens of tools, each with its own unique format. Even if the format is defined and widely adopted, like Syslog, implementations vary widely from tool to tool, or even from release to release for the same tool.

How big of a problem are these differing data formats? According to research from Ponemon, the average enterprise spends just over $2.7M on what it terms security engineering. Security engineering is how you get data into your platforms. This simple act of getting data in, or GDI, is a constant struggle for overworked security teams.

As a response to these challenges, security practitioners are requesting open standards for security tooling. In the ESG/ISSA survey, 77% of respondents want vendors to promote and support open standards, while 84% consider cybersecurity integration capabilities an important consideration when procuring new security tools and platforms.

Security professionals are getting what they asked for. At last week’s Black Hat conference, two new standards were announced. In the first, Splunk and AWS, along with a raft of other vendors, announced the Open Cybersecurity Schema Framework, or OCSF. This mouthful of a standard is designed to be a vendor-neutral security schema driving more interoperability between security tools.

However, if one standard is good, two are better. The XDR Alliance, headed by Exabeam, announced its own Common Information Model. While arguably not as robust as the OCSF, the intent around standardization here is largely the same, but a different group of vendors is represented.

Both of these emerging standards compete with a third open standard, the Cloud Security Notification Framework, or CSNF. As the name suggests, this standard focuses on unifying the various notification formats issued by security tools. The CNSF also provides a mechanism for enriching notifications with additional context to identify the most important alerts.

Despite end user calls for open standardization, vendors aren’t incentivized to adhere to these standards. Portability means reduced vendor lock-in, disrupting business models designed around data ingest volumes or nebulous abstractions around workload pricing. In fact, each of these standards offers different mechanisms for extensions or other customization. The early excitement will fade as vendors get back to the business of improving their own products and using their own pre-existing data formats. (The only instance where this isn’t true is for new products, with no install base or technical debt. We’ll have to see what happens there.)

If you’re an end user of security products and platforms, recognize that these standards, if implemented, will take years to make a meaningful impact in your day-to-day security work. As we’ve seen with syslog, uneven or incorrect implementations will be the norm, and you’ll be left with the same challenges around getting data in as before. The need to translate data formats from originating sources to destinations will remain constant, despite the real need to lower the burden around security data management.

Questions about our technology? We’d love to chat with you.