Tuesday, September 14, 2021

Followup to yesterday’s post on VEX


My post yesterday discussed the concept of VEX, a document that can be described as a “negative security advisory”. The format for this document was recently developed by a working group in the NTIA software component transparency initiative, working in conjunction with the OASIS CSAF project. At the end of the post, I suggested that VEX could solve not just the problem it was designed to address - the fact that a large percentage of vulnerabilities found in components included in a software product aren’t in fact exploitable in the product itself - but a much wider problem.

The wider problem is that security advisories today (both positive and negative) are normally delivered in proprietary, non-machine-readable formats. If those advisories would be provided in the VEX format, there could be huge improvements in efficiency of vulnerability management, both in private industry and in government. In yesterday’s post, I suggested that this might happen someday, although I was careful not to say it was coming anytime soon.

After I put up the post, I decided to watch a video that Allan Friedman (leader of the US government effort to promote SBOMs, until recently at NTIA and now at CISA) had provided to the VEX working group that morning – and I realized afterwards that this should change the tone of what I wrote in that post. But since I don’t want my posts to be too long (God knows they’re long enough!), I decided I’d write this followup post today.

The video was of a presentation that Allan made with Jens Wiesner. Jens is with the German Federal Office for Information Security, which Jens explains is “more or less” the German CISA. Although Jens doesn’t say it, it seems he and the people who work for him are responsible for the government’s cyber vulnerability reporting in Germany. One of his staff members, Thomas Schmidt, worked with the NTIA VEX working group to create the VEX format as a profile in CSAF, the new open source vulnerability reporting standard that will be implemented soon (CSAF replaces the current CVRF standard, which was developed by the same OASIS group). A lot of large organizations worldwide, including Cisco and Oracle, are committed to using CSAF (and by implication VEX, since a VEX just uses a particular set of fields in CSAF) when it’s approved.

While Allan gave a good introduction to the concept of VEX in the first half of the video, I was most impressed by Jens’ discussion (in the second half) of a big problem that his team is experiencing:

1.      Since security advisories nowadays are in proprietary formats (i.e. Cisco’s advisories don’t look like Microsoft’s, which don’t look like Oracle’s, etc.) and they aren’t machine-readable, his staff members spend lots of time just reading advisories and summarizing them in a standard format.

2.      Once the advisories have been summarized, the data are published in a machine-readable format. Of course, if the advisories themselves were all machine-readable, the data could be transferred directly to the publishing formats – completely eliminating the huge amount of time spent having expert humans read and summarize the advisories.

3.      Jens discussed this at length, and you could hear the pain in his voice about the time wasted doing this (even worse, he’s aware that staff members are bored by this work, which of course means he’s probably always worried that some of them will quit). Ironically, there are probably lots of other governments and private organizations that have the same problem Jens has: they pay security professionals a lot of money to read and summarize security advisories.

4.      Another problem with non-automated advisories is that they have to be emailed out. If you’re looking for a particular advisory from a software company you don’t normally deal with, you’re going to have to do some digging around and perhaps calling to find it, since you’re probably not on the supplier’s mailing list to receive advisories. Machine-readable advisories can simply be made available at a URL and updated in real time. Wouldn’t that be nice?

5.      However, there is something holding up Germany’s officially adopting CSAF as the vulnerability reporting framework for government and industry. Jens said it’s the lack of “asset matching” tools on the user side. While he didn’t elaborate on what he meant, I can guess: There aren’t good tools now that will take the machine-readable vulnerability information reported through CSAF and figure out how this applies to individual devices, so they can be scanned and remediated. IMO, this is also the biggest issue holding up full adoption of SBOMs.

6.      Allan and Jens both pointed to this lack of tools as a business opportunity and called on existing or new companies to move to fill these gaps.

7.      However, Jens also pointed to another possible solution to this problem: Third party service providers could ingest VEX (and SBOM) data and perform the asset matching services needed to map vulnerabilities to individual devices on the user’s network. So the lack of asset matching tools doesn’t mean that VEXes and SBOMs can’t be used in an automated fashion; it just means the automation will usually be operated by a service provider, not by the individual user organization.

8.      Ultimately, I’m sure there will be inexpensive and effective tools that will allow at least larger and better-resourced organizations to directly utilize SBOMs and VEXes for vulnerability management; but this might not happen for a few years. In the meantime, I think third party service providers will provide a “bridge” to SBOMs and VEXes for these larger organizations. And medium- and smaller-sized organizations will perhaps always find it more effective and efficient to use these third parties.

9.      Allan and Jens both agreed that machine-readability is the only good solution for vulnerability management in both the near and longer terms, and that it seems inevitable that most security advisories will be machine-readable in the not-too-distant future.[i]

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.


[i] It’s also likely that human-readable security advisories won’t disappear, simply because a lot of people still like to read the advisories themselves, rather than let an automated process have all the fun. But, especially for larger software and device suppliers, it’s just about certain that all vulnerability advisories will be provided in machine-readable format, whether or not they also provide human-readable advisories.

No comments:

Post a Comment