Friday, April 19, 2024

What’s the deal with the massive backlog of vulnerabilities at the NVD?

What’s the deal with the massive backlog of vulnerabilities at the NVD?

The National Vulnerability Database is usually the single source of truth for all things related to security vulnerabilities.  

But now, they’re facing an uphill battle against a massive backlog of vulnerabilities, some of which are still waiting to be assigned CVEs, and others that still have an inaccurate or altogether missing severity score.  

As of April 9, 5,799 CVEs that have been published since Feb. 15, 2024, remain unanalyzed. 

As the backlog piles up, it’s unclear how, or when, the NVD is going to get back to its regular cadence of processing, scoring and analyzing vulnerabilities that are submitted to the U.S. government repository. At its current pace, the NVD is analyzing about 2.9 percent of all published CVEs it's been sent, well behind its pace in previous years. If there were no new CVEs submitted today, it could take the NVD more than 91 days to empty that backlog and get caught up. 

Given the state of the NVD and vulnerability management, we felt it was worth looking at the current state of the NVD, how we got to this point, what it means for security teams, and where we go from here. 

What is the NVD? 

The U.S.’s National Vulnerability Database provides the most comprehensive list of CVEs anywhere. This tracks security vulnerabilities in hardware and software and distributes that list to the public for anyone to use.  

This data enables organizations and large networks to automate vulnerability management, take appropriate security steps when a new vulnerability is discovered, important references and metrics that indicate how serious a particular vulnerability is.  

The U.S. National Institute of Standards and Technology (NIST) has managed the NVD since 2000, when it was started as the Internet Category of Attack toolkit. It eventually morphed into the NVD, which passed the 150,000-vulnerability mark in 2021.  

In addition to simply listing the CVEs that are regularly disclosed, the NVD scores vulnerabilities using the CVSS system, which often differ from the initial severity score that’s assigned by the researcher that discovers the vulnerability, or the company or organization behind the affected product or software. 

Since the creation of I-CAT, no other organization or private company has as comprehensive of a list of vulnerabilities as the NVD, nor do they offer it for free like NIST does.  

Why is the backlog a problem? 

On the surface, it may seem like the fact that the NVD has been slow to analyze CVEs isn’t all that bad, considering security issues are still being disclosed and patched every day (think: Microsoft Patch Tuesday). 

However, the lack of a single source of all CVEs is detrimental to administrators, security researchers and users, and security experts are warning that the issue needs to be addressed quickly, or an alternative needs to be adopted.  

With the NVD being a collection of all this information, it’s up to the individual vendors to responsibly disclose and release vulnerabilities discovered in their products, which puts the onus on administrators to track that information down. If someone who handles patch management for a network was relying on the NVD for their information, that list is likely outdated at this point, and instead, they need to visit each individual vendor to find out what vulnerabilities were recently disclosed in their products, and how large of a risk they present.  

On any given network, that could be dozens to even hundreds of vendors, and while massive companies like Apple and Microsoft have easy-to-access security and vulnerability information, smaller open-source projects may not have the same resources that administrators need.  

The NVD is also the most trusted source for severity scores. Their calculations are generally what most users see when they read a security advisory. But without their input, it’s on the researcher or vendor to assign a score, instead. Under that system, there is no guarantee that a company may not want to score their vulnerability higher so it does not seem as serious, while researchers may want to bump up the severity of the issue they find so they are credited with discovering a higher-severity issue.  

As Talos has discussed before, a CVSS score is not the only metric worth relying on when patching, but it does play a major role in how the public views vulnerabilities and whether they’re likely to be exploited in the wild. According to Talos’ 2023 Year in Review report, eight of the 10 most-exploited CVEs last year received a severity score of 9.3 or higher. Any sense of uncertainty around CVSS scores can leave administrators scratching their heads and without a “north star” for patch management. 

The recent xz Utility vulnerability that was luckily prevented before any attackers could exploit it still does not have a CVE or Common Weakness Enumeration (CWE) assigned to it as of April 10 because of the backlog. Had an exploit for this been used, defenders would be missing crucial context and information for defending against this backdoor. 

How did this backlog develop? 

NIST has been relatively vague about why the agency has been slow to process new vulnerabilities. The first sign of trouble came in February, when NIST released a statement that a “growing backlog of vulnerabilities” had developed because of “an increase in software and, therefore, vulnerabilities, as well as a change in interagency support.” 

NIST’s budget was cut by about 12 percent after the recent package of funding bills passed by U.S. Congress, as well. 

The agency also said in February that additional NIST staff were being shifted around to address the backlog, and at the recent VulnCon and Annual CNA Summit, the NVD program director promised that NIST was developing a consortium to help address the issues with the NVD.  

The total number of vulnerabilities disclosed continues to increase every year, driven by larger amounts of software on the market and increased visibility into security concerns and research. Last year, there were 28,961 CVEs disclosed, according to the CVE Program, an increase of 15 percent from 2022. The last time there were fewer CVEs assigned in a year compared to the year prior was in 2016. 

What are some potential solutions? 

NIST has continued to publicly support the NVD and says it's preparing to revitalize the database. But it’s unclear what short- or long-term solutions or alternatives exist. 

Jerry Gamblin, a principal threat detection and response engineer for Cisco Vulnerability Management, said there has yet to be a company or organization willing to take on the monstrous task of tracking and scoring *every* CVE, especially for free.  

Other vulnerability catalogs exist like the Mitre Corp.’s and the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, but the Mitre list doesn’t have the funding or trust of the federal government, and the KEV only lists vulnerabilities that have actively been exploited in the wild. 

In short — all the potential alternatives are imperfect. 

“We can get the data from anywhere, and AI data could even help, but people just need to decide,” Gamblin said. “Is there going to be just one source of data? And who is the source of truth for this data? Who owns this data?” 

A private company like MITRE could step up to create its own solution, but it’d likely want to charge for access to that database. Any non-profit organization who also wants to step up would also likely need a massive influx of money and manpower to address the sheer volume of CVEs that come in every day. 

And while NIST says the consortium is in the works, there’s no timetable for how long it could take for that to be established, and which private companies would be involved.  

For now, it’s best to stick to tried-and-true patching strategies that have worked for years. Software, like Cisco Vulnerability Management, which has not been affected by the NVD backlog, can also assist in automating the patching process and prioritizing which vulnerabilities to patch first.  

from Cisco Talos Blog

No comments:

Post a Comment