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