Friday, April 28, 2023

Progress to report on the NVD!

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