Tanya Brewer of NIST, the leader of the National Vulnerability
Database, spoke about their current problems
at a very well-attended special session of the VulnCon conference on Wednesday[i].
Here is how she started out:
·
She didn’t explain what the problem was that
came up in mid-February, although she said the NVD will explain it when the
statement is approved (it sounds like that might be a couple of weeks). I think
they might take some crisis management lessons from the White House and other
government agencies. A cardinal rule is that you need to get as much information
as you can in front of the public as soon as possible. The fact that the
problem appeared six weeks ago and still hasn’t been explained publicly doesn’t
exactly fit that bill.
·
She did say that the cause was some sort of “silly
governmental problem”, which everyone would think was ridiculous if they knew
about it. Unfortunately, the people in the audience (I attended virtually) didn’t
seem to be enjoying a hearty belly laugh with this statement. This incident –
which is ongoing, of course – has caused real pain to real people
worldwide. Moreover, by minimizing it
like she did, she sent exactly the wrong message. People might have been
comforted if they’d learned that what happened in February was an out-of-the-blue
disaster that is unlikely to happen again. Instead, they heard it was something
simple. That means it could easily happen again. Oops.
·
She emphasized that the NVD isn’t shut down. However,
I’ve heard it’s still only operating at about a third of its normal level. Somebody
in the audience pointed out that there are still about 4,000 CVE reports that
have been filed with CVE.org[ii]
but still haven’t appeared in the NVD. I have been told this is a huge increase
from the NVD’s normal backlog.
She talked about some of the things she would like to do
with the NVD, but emphasized that these are very hard to do. Once again, she
sent exactly the wrong message:
·
She said she would like to support the JSON CVE
5.0 specification (the CVE JSON spec is what the CVE reports follow) but
pointed out that it’s hard for them to implement this. She said the same thing
to the OWASP SBOM Forum last May. It’s unfortunate that the NVD hasn’t been
able to make progress on this problem since then, but it’s not at all surprising:
The NVD, built on a foundation that was laid almost 25 years ago, will always
have a hard time adapting any new or updated technologies, even though they
could be implemented much quicker in a modern infrastructure.
·
She said she would like to implement the ability
to use purl identifiers (to search for software in the NVD). This is also
something she told the SBOM Forum last May. We advocated for this in the paper
we published in September 2022. In that paper, we also pointed out that this
goal could be achieved in the CVE JSON 5.1 specification. Tony Turner of the
SBOM Forum submitted a pull request to make the required changes, before the
5.1 spec was finalized in 2022. The pull request was accepted, and the 5.1 spec
includes those changes.
·
She also said they were trying to figure out how
to make purl work in the NVD. In theory, they just need to support the 5.1
spec, but since they can’t even get 5.0 to work yet (she said they were most of
the way there, but “most of the way” doesn’t help very much when you either
support the spec or you don’t), it will clearly be several years before purl
can be implemented in the NVD. But who knows whether it will ever be implemented,
since the NVD seems to lurch from crisis to crisis (in her talk at VulnCon
today, Tanya alluded to some sort of crisis that came up last summer. This was
probably why she stopped communicating with the SBOM Forum, after having two
very promising meetings with us)?
·
So, it will be years before the NVD can get the
5.1 spec working and incorporate purl searches. If you read the SBOM Forum’s
paper, you’ll understand why this is such a problem; the CPE identifiers the
NVD uses now are inadequate in many ways (see pages 4-6 of the paper). When we finalized
the paper a year and a half ago, I honestly thought it would be 1-2 years at
the most before the NVD would have purl working. Now, there’s a serious
question whether they’ll ever be able to do that.
She then turned to the Consortium she’s proposing, which is more
or less like what she described to the SBOM Forum last May (see my previous
post, linked above). She said:
1.
The Consortium will only be open to
organizations that are capable of spending months negotiating a Cooperative R&D
Agreement (CRADA) with NIST. There will probably be a membership fee.
2.
The NVD will release a “letter of intent”, which
will describe what they would like the Consortium to do. I assume that is close
to what she said they wanted last May: Warm bodies that can work onsite for six
months or so for free. They will first spend a couple of months learning the
obscure bits of old technology that the NVD is based on, so they can then be of
assistance in fixing problems. It’s clear that the NVD will tell the Consortium
members what needs to be done, not the other way around (not that I would have
expected anything different from any other government agency, of course).
Another issue: I won’t go through the details, but the
audience members expressed a lot of dissatisfaction with the fact that the NVD
insists on creating the CPE names, CVSS scores, and CWE lists that are added to
the original CVE report. That report is created by the CVE Naming Authority (CNA),
which is usually the developer of the software. Why not let the organization
that discovered the vulnerability in their software create these three things
and include them in the CVE report that they created?
Her short answer to this question was that these tasks are
currently assigned to the NVD, but her longer answer implied that the CNAs can’t
be trusted to be as objective in these matters – when it comes to their software
– as the developers themselves. Of course, that stands to reason, but let’s put
this in perspective:
Vulnerability databases depend on software and device suppliers
reporting vulnerabilities in their own products. However, in another VulnCon session
on Monday, two researchers reported that that only 10 software developers (all
large, of course) report the majority of CVEs – in fact, more than the bottom 60%
of all developers report. These ten developers are exactly the entities that the
NVD doesn’t trust to be objective in evaluating their own products.
I don’t dispute that the developers will likely be biased toward
minimizing the severity of vulnerabilities in their own software, but I want to
compare these ten developers to a huge group of product suppliers that should
also be reporting vulnerabilities to the NVD: manufacturers of intelligent
devices.
It’s become clear to me that almost no manufacturers of
intelligent devices (Cisco being the shining exception to this rule) ever
report a vulnerability in their products. For example, Tom Pace of NetRise told
the SBOM Forum in 2022 that he had identified one device – whose manufacturer
has never reported a vulnerability for any of their products – that had at least
40,000 firmware vulnerabilities. He was clear that this was just a device he
happened to study. He doesn’t have time to do a scientific survey of devices,
but he expects he’d find similar results with almost any device.
In January, a fairly simple search in the NVD led me to realize
that, of the top ten medical device makers worldwide, eight of them either
never report vulnerabilities to CVE.org (aka MITRE) or they have only done so
in a small number of cases. The other two device makers aren’t perfect, but
they can’t be measured, since they’re part of much larger organizations that
make lots of hardware and software products. There’s no way to isolate the numbers
for just that organization’s medical devices in the NVD. Of course, given that
medical devices are subject to more cyber regulation than any other devices or
software, the fact that their manufacturers seldom if ever report
vulnerabilities makes it almost certain that other device manufacturers almost never
report them, either.
Think about this: The NVD doesn’t trust the ten organizations
that are responsible for well over half of all vulnerabilities reported worldwide,
while at the same time, device makers seem to have a clean bill of health when
you look them up in the NVD. This is because, if a device has never reported a
vulnerability, someone who searches the NVD for the device will see the same
results as they would see if the device had never had a vulnerability (even
though the device might well have 40,000 unreported vulnerabilities). Wouldn’t
it be better if the NVD focused their efforts on expanding coverage of devices,
rather than insisting that only the NVD should perform four tasks that the software
developers could do much better, and which they want to perform?
Clearly the NVD has a lot of problems,
but most of these are due to its old, creaking infrastructure. I pointed out in
my last post that the CVE.org database has a much more modern infrastructure;
moreover, that database already has all the data that the NVD does. This is
because the CVE reports come to CVE.org first, before they get passed on to the
NVD. Why not just make CVE.org the nation’s (and the world’s) premier vulnerability
database? After all, CVE.org already supports the JSON 5.1 CVE spec, meaning it
would be easy to add the ability to search on purl identifiers to it.
I certainly can’t say I’m sure that
moving the NVD to the CVE.org infrastructure is the right thing to do now. But
I am sure that the wrong thing is for the private sector to join in a big
project to “Save the NVD!”, when the robust alternative to the NVD is already
in place – it’s just in a different Department. Maybe there needs to be some
sort of commission to study this issue, including people from both the
Departments of Commerce and Homeland Security, plus someone from the White
House to make sure a decision comes out of the process, and it’s fairly arrived
at.
Meanwhile, the NVD obviously needs
to get back on its feet, but let’s be clear: the Consortium will have nothing
to do with that, since it won’t be in place for at least six months and probably
longer than that. Tanya said her staff knows what needs to be done and is working
on doing it. Fine. Let them do it. But we have to decide whether, in the longer
term, the NVD should move to the CVE.org infrastructure or stay where it is.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. 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.
My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For background on the book and the link to order it, see this post.
[i] The
session was different from the previously scheduled panel discussion she
participated in on Wednesday afternoon, which didn’t address the NVD’s problems
at all. The session where she spoke suddenly appeared on the conference
calendar yesterday, replacing another one.
[ii] In
my previous post (already linked), I tried to explain the complex structure
linking the NVD (part of the Department of Commerce) and CVE.org (part of DHS).
You might want to review that now, since calling it Byzantine is to slander Byzantium.
No comments:
Post a Comment