News from the folks at CVE.org Part II

My previous post described the set of videos that CVE.org posted recently from their annual CNA (CVE Numbering Authority) Workshop earlier this month. I said I found a number of statements very interesting, but first I wanted to introduce readers to how CVEs are identified and used and who the players are, since most readers probably only have vague ideas on these topics.

Since I wrote that introduction on Friday, I’m now ready to tell you about at least some of the nuggets of wisdom that I found (you may find it helpful to refer to the previous post if any of the terms or acronyms below aren’t familiar to you):

CVE.org and the NVD

Since the National Vulnerability Database (NVD) is where most of us learn about CVEs, we often think it is the source of CVE information. That isn’t true. CVE.org, which used to be called just “MITRE”, is the source of information on CVEs. This information is found in “CVE Records” that are available in the CVE.org database.

The CVE records are passed on from CVE.org to the NVD and are incorporated into their database, but the NVD’s CVE records don’t include all the information that is found in the same records in the CVE.org database. One of the speakers in the workshop emphasized that just looking for information about a CVE in the NVD will cause you to miss the additional information that’s available in CVE.org. If you are trying to research a CVE in depth, you need to look in both databases.

The word from Microsoft  

Lisa Olsen of Microsoft, a longtime participant in the CVE ecosystem, made a number of interesting points:

·        Microsoft usually reports 80-100 new CVEs on every Patch Tuesday.

·        For some of their products, they create CPE names and include them in the new CVE records.

·        When they create a CPE for a version of Windows, they include the build number. This is important, since builds are really the “versions” for Windows. Windows 10, 11, etc. are more like separate products, since they are constantly updated during the multiple years they’re usually available. To identify the specific codebase in which a Windows vulnerability is found, you have to know the build number.

·        Lisa pointed out that in some CVE reports, the “affected” version of the product refers to the fixed version of the product (i.e., the version to which the patch has been applied), while in other reports (usually from different CNAs), the “affected” version is the unpatched version. This is a huge difference, of course, since it means some organizations may be applying patches to versions of a product to which the patch has already been applied. Lisa said the new CVE schema will allow the CNA (which is in many cases the developer of the affected product) to indicate which case applies. However, it seems to me there should be a rule: The “affected” product is always the one in which the vulnerability has not been patched.

·        Microsoft also is going to start publishing CVE records that have a new category of CVE: one that doesn’t require customer action to resolve. I believe she meant these are vulnerabilities that have already been resolved by a means other than patching – e.g., a configuration change in the software itself; yet Microsoft believes it is still important for the user to know that the vulnerability is present in their software, even though it is not currently exploitable.

Art Manion

One of the most respected figures in the CVE “universe” is Art Manion, formerly vulnerability analysis technical manager at the CERT Coordination Center at Carnegie-Mellon and someone who continues to be very involved with CVEs as a CISA contractor. He made a number of interesting points, including:

·        The key to CVE.org’s mission is the CNAs, since they identify and report all CVEs. CVE.org greatly prefers the “federated” approach, in which the CNAs are given a lot of freedom in how they report CVEs (in fact, he noted that only three of the many fields in the CVE specification are required; the others are all optional).

·        Another way of saying the above is that using the word “must” with the CNAs won’t usually get you anywhere. The CNAs are volunteers. CVE.org is very careful about not alienating them by threatening to reject CVE reports if certain fields aren’t present, etc. There are a lot of complaints about CVE reports not including this or that field, but these concerns should always be approached with the attitude of, “Do you want a half-full glass or no glass at all?”

·        A number of industries are reporting very low numbers of vulnerabilities, including healthcare and autos. This is why I usually say the vulnerabilities you need to worry about most are the ones that have never been reported to CVE.org (as well as to other vulnerability reporting entities like ICS-CERT and GitHub Security Advisories). Of course, when these are suddenly exploited, they’re known as “zero day vulnerabilities”. However, these are often vulnerabilities that have been known for a while – but just to the developer, which never reported them.

·        It would be nice to have a VEX capability in CVE. That is, instead of saying, “Product X is affected by CVE-2024-12345”, the CVE report would effectively say, “Even though Product X contains component ABC and ABC is affected by CVE-2024-12345, Product X is not affected by that vulnerability.”

·        The new version of the PCI-DSS standards for protection of payment card data by the retail industry requires that vendors to the industry report more vulnerabilities. In other words, “We don’t believe the fact that you haven’t reported any vulnerabilities for your product really means you don’t have any. It just means you have decided to endanger your customers by not reporting them. This has to stop.”

·        It would be good to include in the CVE record whether CISA has placed that vulnerability on its Known Exploited Vulnerabilities (KEV) list. Since almost every organization has many more vulnerabilities to patch than it has hours in the day to patch them, prioritization of vulnerabilities is a key issue. Prioritizing vulnerabilities that are on the KEV list is a great strategy. I agree with Art that this information should be included in the CVE record. 

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 available here!