CVEs: More and better information on vulnerabilities from CISA

Contents

Anyone who has to deal with security vulnerabilities professionally can hardly avoid the National Vulnerability Database (NVD) of the National Institute of Standards and Technology (NIST). The US authority enriches the mother of all vulnerability databases, the Mitre Common Vulnerabilities and Exposures (CVEs), with detailed threat information, information on available updates and other recommendations for action. IT security managers, but also journalists like us at heise security, for example, use the NVD to look up the latest threat details.

This additional information is now being significantly expanded and the players want to thoroughly renovate the system, which is struggling with problems. This is because the NIST cannot keep up with enriching the new NVD entries; since mid-February, a massive backlog of CVE entries that have been left behind has been causing displeasure in the security community. The entries published by the responsible CVE Numbering Authorities (CNAs) often already contain some details, such as CVSS scores, which indicate the severity of the threat. In the vast majority of cases, however, important metadata is missing, which security products such as SIEM and firewalls or tools for vulnerability and patch management depend on being available quickly.

In order to clear the backlog, NIST has increased its staff and also requested external help. The Cybersecurity and Infrastructure Security Agency (CISA), which announced its own solution to the problem in May 2024: the "Vulnrichment" project, which is publicly available on GitHub. Behind the portmanteau of vulnerability and enrichment lies more than just adding missing metadata to CVEs that have been left behind: The project aims to permanently accelerate the addition of missing CVE information and make it more flexible. It also integrates useful, CISA-specific additional information.

CISA can now edit CVEs

First of all, it is interesting to note that CISA does not transmit its vulnerability information to NIST so that it can supplement the NVD. Instead, it has been given the authority to directly supplement the data of existing and newly published entries. According to a blog entry from the CVE programme from June 2024, CISA was appointed as the very first external "CVE Authorized Data Publisher" (ADP) for this purpose. This makes it clear that the US authority intends to participate in enriching the data in the long term.

To put the appointment into context, it is not a big surprise. CISA has been one of the financial sponsors of the CVE program for years and has itself held the role of root CNA in the field of industrial control systems (ICS) since 2020. In addition, CISA employees are also part of the CVE Board, which makes important decisions relating to the project.

The additional information from the NVD then also ends up in the original MITRE CVE entries. Until now, MITRE's own database CVE.org only presented the information that the CNAs had stored in the CVE records and was therefore much less attractive as a data source than the NVD with its extra details. This has now changed: A look at the CVE.org entry for CVE-2024-6730, for example, reveals that CISA's data is now an integral part of the information offered there. MITRE provides it in a separate tab with the heading "ADP".

Anyone looking for an alternative to the web view of the information should take a look at MITRE's GitHub repository CVE List V5. The complete CVE list, which is updated every seven minutes, including vulnerability information, is available for direct download.

A look inside the container

CVE entries follow a defined schema in JSON format. A good example is the entry for CVE-2024-6714 in the vulnerability repository. The "adp" container contained therein forms the fixed framework for CISA's additions; the "cna" container, on the other hand, is taboo.

It is also precisely defined which metadata (can) end up in the ADP container. However, the prerequisite for this is that they are still missing in the CNA container and that sufficient information is available for the assessment:

• CVSS: The aforementioned assessment according to the Common Vulnerability Scoring System includes not only a numerical score and a severity classification from "None" to Critical", but also a vector string based on complex metrics for an exact hazard description.
• CWE: The Common Weakness Enumeration list is a community-based project that makes common vulnerability types easily searchable online. By assigning a numbered entry such as "CWE-79 / Cross-Site Scripting" to a CVE, you specify the type of threat. The CWE list entries that can be called up online then provide suitable background information on the attack process and conditions, possible consequences and typical defensive measures.
• CPE: The Official Common Platform Enumeration is a standardized naming convention whose flexible syntax can describe, among other things, software configurations and combinations that lead to the exploitability of a vulnerability.

An optional container component, as it is only available for selected vulnerabilities, is a reference to CISA's own Known Exploited Vulnerabilities Catalog (KEV). This provides online information on vulnerabilities that are known to have been exploited in the wild. KEV references are nothing completely new in the field of CVE entries, but have been an integral part of the NVD supplementary information researched by NIST for some time –, just like CVSS, CWE and CPE –. What is new, however, is the idea of a KEV block directly in the CVE entry.

In principle, the information that a CNA stores in the CVE entry weighs more heavily than that of the ADP. If the former subsequently adds some of the aforementioned standard metadata, this will "overwrite" the vulnerability information.

New: CVE preselection with SSVC

In the first phase of the project, the Vulnrichment team will work through all CVE list entries that have not been published since February 2024 and all newly published CVE list entries. However, as determining the standard metrics is time-consuming, the US authority makes a pre-selection: Only vulnerabilities that pose a sufficiently high risk are enriched with the metadata just mentioned. CISA's own methodology, which is completely new in the context of CVE entries, comes into play for rapid pre-selection: the so-called Stakeholder-Specific Vulnerability Categorization (SSVC).

Developed in 2019 by CISA and Carnegie Mellon University's Software Engineering Institute (SEI), this approach originally serves to assess and prioritize the risk posed by a vulnerability in the context of a specific (corporate) infrastructure. It can be depicted as a tree diagram in which decisions have to be made at various nodes, so-called "decision points".

Based on the chained selection by the stakeholder, it is ultimately possible to answer how to react to the vulnerability –, namely whether it should only be kept in mind ("Track" status, or somewhat more urgently: "Track*"), requires closer attention and action, for example in the form of an internal notification ("Attend"), or requires an immediate, comprehensive reaction ("Act").

You can find out more about this concept in an article on SSVC on the CISA website. In addition, you can try out the decision tree as a tool for yourself using the SSVC Calculator, which is available online and comes with detailed explanations.

Threat details concisely highlighted

But now back to the ADP container: CISA only uses a slimmed-down SSVC variant with three decision points. The decisions are made in a more general, non-stakeholder-specific context:

• Exploitation clarifies the current status of vulnerability exploitation. Possible values are "none", "poc" (proof of concept, i.e. an exploit exists but is not yet known to have been used by bad actors) and "active" (actively being abused by attackers).
• Automatable asks whether the vulnerability can be exploited automatically and thus whether a large number of exploit attempts are conceivable. The permissible answers are limited to "yes" and "no".
• Technical Impact defines the degree of control that an attacker could in principle gain over systems with the help of the vulnerability. The values "partial" and "total" are available here.

A flow chart in the vulnerability repository shows how CISA makes a decision for or against enriching the ADP container with vulnerability information and KEV based on the values determined. The diagram also shows that CVE records can be subject to constant change: If the responsible CNA adds new information or corrects old information, the inventory (triage) starts again via SSVC, which may require adjustments to the metrics in the ADP container. Timestamps in the entries document such changes.

Quick assessment

The decision points already appear in the ADP tab of the CVE.org entries. For our already known example CVE-2024-6730, they look as follows:

Exploitation: poc
Automatable: no
Technical Impact: partial

This concise information is very useful for an initial assessment of the threat and the resulting need for action. They can also be used to quickly identify and describe the threat, for example in internal company communication or, from a journalist's perspective, in a time-critical heise Security Alert.

The decision points are therefore a good addition to the content of CVEs, which, according to Readme.MD in the vulnerability repository, should in future be included in every entry analyzed by CISA –, i.e. even if the decision to enrich is negative.

Snail's pace and open end

The vulnerability repository is now filled with thousands of analyzed and enriched CVE entries and is constantly updated. It hardly lags behind the new additions to the regular CVE list. In addition, the team has already started to re-triage old, updated entries from 1999 onwards.

Meanwhile, the backlog in the NVD seems to be getting worse: At the time of this article's publication, over 17,000 vulnerabilities were awaiting analysis, according to the NVD dashboard. Although the NIST has included the vulnerability data in its NVD entries since the beginning of July, with the corresponding source cited, according to the announcement it only uses the CVSS and CWE data from CISA as a supplement to its own assessments and other sources.

An NVD entry for CVE-2024-31095 from the end of March 2024 illustrates this quite well: It contains a CISA enrichment in the form of a CVSS v3 score (entry update 1.8.), but is still stuck in "Awaiting Analysis" status; CPE data is still completely missing.

In addition to the piling up vulnerabilities, the NVD is apparently struggling with technical problems: according to the website, there are currently difficulties with the API endpoints and thus the (automated) retrieval of data by software. Server updates and maintenance lasting several days are also affecting the processes.

Light at the end of the tunnel

All these difficulties ultimately underpin the benefits of flexible CVE data processing and, above all, availability that is decoupled from the NVD. In the author's view, however, it would be desirable to involve other ADPs in enrichment in the long term, instead of simply passing sole responsibility from one US authority (NIST) to another (CISA). Another step in the right direction is the so-called CVE Program Container, which the CVE program itself has been using since the end of July 2024 to integrate additional information from various internet sources into CVE entries.

Despite its current slump, the NVD should not be written off as a source of comprehensive threat data. A press spokesperson told heise security that NIST is considering including CISA's decision points in NVD entries in the future (SSVC Decision Points). They are also considering integrating other sources of information. The Exploit Prediction Scoring System (EPSS) of the Forum of Incident Response and Security Teams (FIRST) and data from NIST's own Bugs Framework (BF) are being discussed. This would significantly improve the benefits for the daily work of security managers.

(ju)