This morning, the SBOM Forum met with three members of NIST’s NVD team (including the leader of the team) to discuss problems we know about pertaining to the NVD (listed below). We discussed a small number of the most serious problems and – of course – didn’t reach any solutions during the hour. However, the Forum members were quite pleased with NIST’s concern about these problems (almost none of which they knew about), as well as their willingness to discuss solutions. In fact, we’re going to have a follow-up meeting in about a month; I suspect/hope there may be more after that – perhaps every month.
The NIST people immediately
brought up the fact that NIST hasn’t received their share of funding from the
Omnibus funding measure that was passed by Congress at the end of last year. This
means all of NIST is just receiving enough money to keep the lights on. The NVD
group has 25 people at full strength, but at the moment they only have 19 (I
believe that’s the number they said) and can’t hire anyone else. This is really
bare bones.
However, I think they were
surprised at our response (in fact, I was a little surprised at it). There was broad
support (among the 22 or so people on the call, including people from major
software suppliers as well as companies and nonprofits involved with SBOMs) for
the idea of private companies banding together to help NIST address the
problems listed below. Of course, this assistance wouldn’t be with dollars, but
with something even better: Help from some very knowledgeable people.
The interesting thing about the
NVD’s problems is that they’ve all been solved repeatedly; there’s nothing that
requires new technologies, massive investment, etc. They can mostly be solved with
changes in policies and procedures and education (of stakeholders) about those
changes.
We started to discuss having this
meeting a couple of months ago; then, our focus was the naming problem (for
which we outlined a solution – as far as the NVD goes – in this paper last September). However, it seems there are currently
some serious infrastructure problems – made worse as we approach September of
this year, when NIST was planning to end the ability to download a “mirror” of
the NVD (which many organizations do now, some many times a day). After our
conversation today, my guess is mirroring won’t be removed in September,
although there are certainly other infrastructure issues that need to be
addressed (again, none of them huge or involving new technologies).
All good news. I’ll keep you up to
date with new developments.
Issues for the NVD – discussed with NIST 4/28/23
CPE issues raised in SBOM Forum’s Sept. 2023 document
1. If a supplier has never reported a single CVE as
applicable to any of their products, there will be no CPE for them. It is
likely that the great majority of suppliers who have never reported a single
CVE didn’t do this because they have never found a vulnerability in their products,
but rather because they never looked for them. However, if a user searches on
the supplier’s name, they will receive the “There are 0 matching records”
message.
The problem is that this same message will be received when
there is a CPE for the supplier, but there are no CVEs reported for
products that they make. This might possibly mean the supplier is very diligent
about identifying and fixing vulnerabilities. However, since the message will
be the same in both cases, there is no way to determine which is the case.
2. There is no error checking when a new CPE name is
entered in the NVD. Therefore, if the CPE name that was originally created for
the product does not exactly follow the specification as it was entered, a user
who later searches for the same product and enters a properly specified CPE
will receive the same message: “There are 0 matching records”.
In other words, when a user receives this message, they
might interpret this to mean there is a valid CPE for the product they’re
seeking, but a vulnerability (CVE) has never been identified for that product -
i.e., it has a clean bill of health. However, in reality it would mean the CPE
name was created improperly. Even worse, there might be many CVEs attributed to
the off-spec CPE name, but without knowing the name that was actually created,
the user will never be able to learn about those CVEs.
2a. If a user mis-spells the CPE name they are
searching for in the search bar, but there is in fact a legitimate CPE name
already, the user will once again get the “There are 0 matching records” error
message. If the user doesn’t realize they mis-spelled the name, they might once
again believe the CPE is there, but there are no vulnerabilities (CVEs) attributed
to it.
3. When a product or supplier name has changed since
a proprietary product was originally developed (because of a merger,
acquisition, or corporate rebranding), the CPE name for the product may change
as well, but with no link to the previous name. Thus, a user of the original
product may not be able to learn about new vulnerabilities identified in it,
unless they know the name of the current supplier as well as the current name
for the product.
4. Supplier and product names can be written in many
ways, such as “Microsoft™” and “Microsoft™ Inc.”, or “Microsoft™ Word” and
“Microsoft Office™ Word”, etc. However, there is no easy way to distinguish the
correct supplier or product name among a large number of query responses from
the NVD.
5. Sometimes, a single product will have multiple CPE
names in the NVD because they have been entered by different people, each
making a different mistake. For this reason, it will be hard to decide which
name is correct. Even worse, there may be no “correct” name, since each of the
names may have CVEs entered for it. This is the case with OpenSSL in the NVD
now (e.g., “OpenSSL” vs “OpenSSL_Framework”). Because there is no CPE name that
contains all the OpenSSL vulnerabilities, the user needs to find
vulnerabilities associated with each variation of the product's name. But how
could they ever be sure they had identified all the CPEs that have ever been created
for OpenSSL?
6. Often, a vulnerability will appear in one module
of a library. However, because CPE names are not assigned based on an
individual module, the user may not know which module is vulnerable, unless
they read the full CVE report. Thus, if the vulnerable module is not installed
in a software product they use, but other modules of the library are installed
(meaning the library itself is listed as a component in an SBOM), the user may
unnecessarily patch the vulnerability or perform other unnecessary mitigations[1].
7. The supplier of a product doesn’t determine the
CPE name (even if they are a CNA). But if NIST makes a mistake in specifying
the name, the supplier will hear about it from unhappy customers.
8. There’s no way for a supplier to “self-onboard” themselves
to the NVD. They have to wait until there’s a new CVE that applies to them,
then get a CNA (or MITRE) to assign a CPE for them.
9. To reduce or eliminate errors in CPE names, it
would be good for the NVD to automate creation of CPEs, as CVE.org has done with
creation of new CVEs.
10. It would be good if the NVD people just used CPEs
created by the supplier, instead of inventing new ones (and often making
mistakes).
Other NVD issues
1. Many organizations download a “mirror” of the
entire NVD regularly; however, that capability will be removed starting in
September 2023. It has been “replaced” by the API, but there’s already
experience indicating that having multiple large NVD users within one
organization may lead to serious bottlenecks.
2. When a user identifies the need for an update or
correction to any data, they must use email to request it. While NIST usually
responds to the email within a week, a more efficient system than email might
allow updates to be made within a day and require much less human involvement
with each update.
3. A lot of the historical data in the NVD contains
errors. These need to be cleaned up.
4. Because of the coming tsunami of SBOM-based
component vulnerability searches, as well as increased interest in software
supply chain vulnerability management in general, it is important that the NVD
be easily scalable. While the SBOM Forum members don’t have direct knowledge of
whether and how the NVD can scale, we do wish to emphasize that the NVD should
be considered critical infrastructure and treated as such.
5. There are single points of failure in the NVD,
including the CPE dictionary. There is a serious question how well this will
withstand the millions of daily requests that will start hitting it in
September.
6. In the NVD CVE downloads, one cannot determine
which products referenced by CPEs contain the vulnerability. In
CVE-2021-44228, for example, there are many dozens of CPEs from various vendors
such as Cisco, ServiceNow, Bentley, percussion and Net App, to name some.
However, from all the CPE entries, there is no way to determine which of the
many dozens of products referenced by CPEs, contains the vulnerability (in this
case Apache Log4j). Often, the entry is first (Typically
Configuration 1) but that is not always the case. The request is that the
NVD downloads indicate which of the CPEs directly contains the vulnerable code.
7. In addition to general scalability considerations,
it is also important to consider the international dimension: The EU, UK, Japan
and other countries are currently consulting about improving software security
for their nations. They will need a single reliable and trustworthy source of
vulnerability information, as opposed to having separate nation-backed
solutions. Having separate solutions will make tooling inefficient and will
likely lead to misleading results in many cases.
Because the NVD is already widely used worldwide, it is the
best candidate for this solution. Of course, the cost of implementing a
worldwide solution needs to be borne by users (in both private and public
sectors) in all participating countries. The fact that users in many countries
will be contributing to the cost of developing and maintaining a central
vulnerability database, as opposed to users in each country individually
developing and maintaining their own national database, will undoubtedly allow
a much higher level of investment in the central database, resulting in greater
performance and functionality for all.
8. In the NVD CVE downloads, the CVSS score for each
of the CPE entries should be made available if the vendor supplies that
information. Thus, for the Log4j
CVE-2021-44228, there could be the overall CVSS score (10.0 Critical, in this
case) along with the CVSS score for CPEs referencing Siemens products, Cisco
Products, etc. CVSS scores from a
vendor (vs NIST or other sources) should be identified as such, so there is no
confusion. This will greatly aid
organizations reviewing NVD to determine the urgency of applying published
remediation.
9. There is a question whether the NVD query
structure could be optimized to make it more efficient: i.e., to have a greater
likelihood of producing positive results.
10. Greater transparency is needed. All too often,
the NVD mailing list is only informed of an upcoming change when it’s already
been decided on, or even implemented.
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.
[1]
This probably occurred often with log4shell. That vulnerability was only
present in the log4core module of the log4j library, yet the CPE name for a
library always applied to the complete library, not any of the modules.
No comments:
Post a Comment