Justifying Vulnerability Prioritization Decisions After a Breach

I want to offer a different way to think about vulnerability prioritization, one that helps you justify today’s decisions in the event you are asked to explain them post-breach.

‍

Every organization is buried in vulnerabilities. There is no way to fix them all. Patching resources are scarce. The problem is only getting worse. Reaching vulnerability “zero” is a fantasy. And despite the best efforts and intentions of defenders, the likelihood of being breached through a remotely exploitable CVE is not zero. Many industry reports suggest this accounts for roughly half of all breaches and financial losses.

‍

Post-Breach, There Are Two Kinds of Vulnerabilities

‍

1. Vulnerabilities where prior to the breach there was existing evidence of real-world exploitation.
   
   
2. Vulnerabilities where, prior to breach, there was no available evidence of in-the-wild use. These are not necessarily zero-days. Older disclosed bugs that have only recently been weaponized qualify too.

‍

So proactively, prior to said breach, which category do you remediate first? That depends on which risk you believe is greater. But hold that thought, don’t answer yet. Instead, consider the post-breach scenario, when the business inevitably asks, “Why did this happen?”. What explanation would you rather provide to executives, lawyers, auditors, customers, and the board?

‍

“Before the breach, we remediated all vulnerabilities we believed were the most critical based on our risk model. Unfortunately, we were breached by a vulnerability that had already impacted others.”

‍

or

‍

“Before the breach, we remediated all vulnerabilities that were required by our industry compliance standards. In particular, all the vulnerabilities rated ‘critical’ and ‘high.’ In this case, the exploited vulnerability was not rated high enough to be in that set and was left unfixed because it was not mandated by policy.”

‍

or

‍

“Before the breach, we had remediated every vulnerability known to have been used in real-world attacks. The one that impacted us had no evidence of ever being exploited by any organization before.”

‍

There are many versions of this conversation, depending on the environment, and each response can technically be defensible, but in my opinion, the last one is the easiest to justify in conversation.

‍

How This Shapes Prioritization

‍

If you are comfortable with the first answer, your strategy will lean more on industry alerts, CVSS criticals, or predictive models like EPSS. These approaches cover newer vulnerabilities, “celebrity” bugs, and potential zero-days that have not necessarily been exploited yet, as well as the ones that have.

‍

In response 2, I think we can all agree at this point that compliance does not equal security. However, many companies are stuck with these compliance mandates and will continue to operate in this way, even if it proves to lead to losses. Also, as an aside, encouraging the business to fix issues without some proof of financial risk is often extremely difficult.

‍

If you prefer the last answer, then treat vulnerabilities already exploited in the wild as the greater risk and fix those first. That means prioritizing Known Exploited Vulnerability (KEV) lists like VulnCheck KEV or CISA KEV.

‍

In vulnerability management, perfection is impossible. But with only about 1% of all known CVEs ever exploited in the wild, perfection is not necessary anyway. What is necessary is finding a way to fix the ‘right’ vulnerabilities in the ‘right’ order. This leads to whether you can defend the strategy that led to your decisions - or not. Because in the end, prioritization is not just about risk reduction. It is also about having a strong position you can stand behind should things go wrong.