Security operations · 2 MIN READ · KIM MAHONEY · OCT 25, 2023 · TAGS: vulnerability prioritization
Our new white paper explains how vulnerability prioritization cuts noise and maximizes signal in vulnerability management …
If you deal with software vulnerabilities, you probably feel like you’re up to your … hindquarters … in alligators.
- Software vulnerabilities are the second-most reported attack vector.
- 26,448 new ones were reported in 2022.
- Critical vulnerabilities—those with scores of 9-10 on the common vulnerability scoring system (CVSS) scale—were up 59% in 2022 compared with 2021. And 11+% of vulnerabilities have a critical score.
- 66% of security leaders report a backlog of more than 100,000 vulnerabilities. And senior-citizen ‘gators can still bite: the second most common vulnerability our security operations center (SOC) saw in Q2 2023 was ten years old.
- 72% of SOCs reported difficulty in prioritizing what needs patching.
Software is the foundation on which the modern world is built. Financial systems, electrical grids, governmental, educational and social service systems, major business processes, and even physical infrastructure systems rely on computer systems, making them prime targets for attacks by criminals, nation-states, and a host of other garden-variety troublemakers.
A hacker exploiting a security flaw, glitch, or weakness in the code can cripple the software’s ability to control the environment, wreaking havoc on an organization’s operations, finances, and reputation. Or worse.
Dealing with vulnerabilities is difficult. The sheer numbers alone are staggering, but there are other issues, as well.
First, CVSS scores indicate severity, not risk. Severity matters, of course, but how much time should be devoted to a vulnerability with almost no chance of ever being exploited?
Second, other common vulnerability management (VM) metrics (e.g., time-to-detection, vulnerability age, patching rate) aren’t risk-based, either, and they often lead to ineffective, low-value prioritization with poor results and high costs.
Third, VM is controlled partly by security operations (SecOps, which deploys the vulnerability assessment tools and is responsible for determining which vulnerabilities need to be prioritized) and partly by IT operations (responsible for testing and remediating the patches). There can also be other stakeholders—like dedicated VM or risk management teams—defining policies and processes and approving exceptions. If these teams are misaligned (which is often the case), optimizing vulnerability management is going to be difficult, if not chaotic.
Finally, attackers have a pretty good idea of where the holes are, so if you aren’t patching the highest-risk vulnerabilities first, you’re even more susceptible.
Risk-based vulnerability prioritization
There is good news. Very good. Risk-based, stakeholder-specific vulnerability prioritization (VP) can reduce organizational risk and drive better results. VP guides an organization’s efforts toward critical, high-risk vulnerabilities, identifying, prioritizing, and remediating based on the relative danger they pose.
Industry analysts and experts, such as those at CISA, recommend a risk-based, stakeholder-specific model to prioritize which vulnerabilities are placed on the remediation list. This includes enriching vulnerability findings with asset context and criticality and correlating findings with active threats and known exploits. Analysts also recommend using a risk-based vulnerability approach that focuses effort and resources on treating relevant and exploitable vulnerabilities that pose the most significant business risk.
Read the white paper
Expel has devoted a good deal of time to understanding the weaknesses in traditional vulnerability management and to developing a stronger, risk-based approach. Our new white paper dives deep on both the traditional challenges of VM and the benefits of vulnerability prioritization. We invite you to download and spend a few minutes with it. Then, if you have questions or comments, drop us a line.