5 Days to Patch – Did The DBIR Get This Wrong?

Just before RSA, Verizon published its annual Data Breach Investigations Report (DBIR). One of the key findings this year was a 3x increase in vulnerability exploitation as a critical path to initiate a breach. The DBIR researchers also report a sharp decrease in the time between when a critical CVE is published to when it becomes exploitable.

Furthermore, the DBIR revealed that organizations took almost two months to patch and remediate 50% of critical vulnerabilities in CISA KEV, while these same vulnerabilities became mass exploitable in five days at the median.

As a key data contributor to DBIR, Balbix has data and insights from hundreds of global organizations, including why vulnerabilities and misconfigurations have exploded and formed a critical path for attackers to initiate a data breach.

First, to answer the question posed by the title of this article, yes, the DBIR paints a fairly accurate picture of the timing of critical vulnerability exploitability. Furthermore, these findings are not good news for vulnerability management programs, based on the metrics we see in most organizations when Balbix first starts working with our customers.

In a typical F500 organization, a vulnerability backlog looks like this:

All open vulnerabilities (CVEs)

• CVEs: 19,555
• CVE Instances: 4.0M
• Affected Assets: 116,555

All CISA KEV-tagged CVEs

• CVEs: 270
• CVE Instances: 76.9K
• Affected Assets: 9,333

To meet the 5-day timeline, security teams at these F500 organizations must patch 9,333 assets within 5 days. The median number of affected assets per CISA KEV open CVE is 102. In short, the security and IT folks must complete a lot of testing, approvals, and patching work in four days each month.

Surely, smaller companies have less burden

For customers (< 3,500 assets), a typical vulnerability backlog looks like this:

All Open Vulnerability Counts

• CVEs: 1,200
• CVE Instances: 22.5K
• Affected Assets: 1,500

CISA KEV tagged CVEs 

• CVEs: 22
• CVE Instances: 300
• Affected Assets: 160

In a smaller company, the teams and resources are limited. To patch 160 assets within 5 days is challenging at best.

Can EPSS help? Yes. But, when using the EPSS prioritization framework, CISA KEV vulnerabilities score higher. Using EPSS alone does not reduce the number of assets impacted or that need patching in this situation.

Leveraging risk-based vulnerability prioritization

Risk-based vulnerability prioritization can be a game-changer for security teams. Rather than considering severity or the likelihood of exploitation alone, Balbix uses additional organizational context to prioritize vulnerabilities. Balbix analyzes five factors – severity, threat, asset exposure, mitigating controls, and business impact (asset criticality) for every vulnerability instance across the entire attack surface.

Using previous examples, with Balbix, the Fortune 500 Balbix customer needed to patch just 20 of the 9,333 affected assets (0.2%) to reduce their cyber risk by 99.6%, associated with 270 CISA KEV vulnerabilities.

The other 9,313 assets were deemed lower risk due to a lower breach impact, or because the affected software was not being used in a way for the vulnerability to be exploited – lower exposure, or due to the presence of a security control considered effective against these CVEs .

A key aspect in risk-based vulnerability management (RBVM), often overlooked, is the ability to quantify the asset’s criticality or breach impact. Traditional vulnerability scanners do not have a model to calculate/estimate the blast radius should a specific vulnerability on an asset get exploited, the type and value of the affected asset to the organization, how it is connected to other assets, and how the breach might spread further. Without considering these aspects in the risk model calculation, risk results will be skewed and the prioritization will be incorrect. You can’t really do risk-based prioritization without being able to quantify the breach’s impact of each CVE instance and its propagation.

Another vulnerability management requirement is coverage: Balbix identifies and prioritizes vulnerabilities for your entire attack surface, which includes on-premises and cloud infrastructure—servers, desktops, IoT/OT, software (OS, browsers, plugins), third-party and open-source software libraries, and applications. Recently, we’ve also seen examples of OSS (open-source software) and SBOM (software bill of materials), which need special attention. From Log4j to XZ Utils, an organization’s ability to build and maintain an accurate and up-to-date software inventory is important in the overall time-to-detect and time-to-remediate of such vulnerabilities.

Finally we come back to speed and efficiency: Balbix also automates and speeds up the patching of critical vulnerabilities by recommending superseding patches, automating tickets and ownership, and validating applied patches.

Behind the scenes, Balbix leverages an ensemble of AI models powered by several large language models (LLMs) and classic machine learning techniques to deduplicate, classify, and categorize assets, infer and prioritize vulnerabilities, and remediate risk based on the five factors mentioned above. You can read more about the Balbix AI-powered approach to mapping out the attack surface,  prioritizing vulnerabilities, and quantifying risk in dollars.

To learn more and get a free trial, sign up for a Balbix demo here.