The Value in Root Cause Analysis for Vulnerability Management
Since the publishing of common vulnerabilities and exposures (CVEs) began more than 20 years ago, the number of discovered vulnerabilities each year has grown significantly. In 2023, a whopping 28,961 vulnerabilities were published. Just three years prior, in 2020, the total number of vulnerabilities published was 18,375, a notable jump from the 6,457 CVEs published in 2017. The growing volume of CVEs each year is a trend that seems unlikely to change anytime soon.
Organizations often find themselves frustrated and challenged by this influx of vulnerabilities amid growing IT complexity and an evolving threat landscape. To address this, some businesses have tried to add budget, but often observe security metrics and KPIs that remain flat despite this investment. As more and more vulnerabilities are discovered, the traditional reactive, find-and-fix approach is not scalable. To help modernize and improve vulnerability management, businesses should emphasize root cause analysis. Identifying and addressing underlying issues and their root causes can lead to risk reduction, cost savings and better overall performance of a vulnerability management program.
Identifying Root Causes
With the volume of vulnerabilities ever increasing, prioritization plays a huge role in modern vulnerability management. There are simply too many CVEs to fix them all, and security professionals are tasked with deciding what to fix now vs. what to add to the growing to-do list for later. With this approach, security teams often remain hyper-focused on patching the vulnerabilities at hand, and don’t ever take a moment to step back and ask why a given vulnerability has come along in the first place.
The first step toward identifying underlying issues and root causes for vulnerabilities in our environment begins with asking why a vulnerability has surfaced until we get enough information to come up with an informed answer to the question.
I’ll give a quick example of how asking why helps. Imagine your security team is noticing a plethora of Firefox vulnerabilities appearing. The simple answer to why these are popping up is likely because our organization uses Firefox, and they have a lot of security vulnerabilities. But we can dig a bit deeper by asking why a few more times.
- Why do we use Firefox? In this instance, it’s because some people use special Firefox plugins to help do their work, and Microsoft Edge doesn’t have those plugins.
- Why do some people use Firefox plugins to help with their work? Employees are using these plugins because they couldn’t get the software they needed from corporate IT.
- Why couldn’t these employees get the software from Corporate IT? Because Corporate IT has too much bureaucracy and red tape to approve new software, at this given organization.
In the end, just by asking why, we’re left with having identified a key root cause that’s contributing to the risk our organization is taking on via newly identified vulnerabilities that need patching. It’s because of an issue with Corporate IT’s red tape process for requesting and approving new software. We can fix this by addressing the red-tape problem, and helping give people the software they need to effectively and securely do their jobs, eliminating Firefox from our tech stack and avoiding having to patch all these vulnerabilities moving forward.
People, Process and Technologies
By asking and answering why a vulnerability has appeared, we get to the root cause. Doing this repeatedly, we’ll find that the root cause will more than likely fit into one of three categories: People, process or technology.
We identified an example where technology was to blame for vulnerabilities already, as it often is. But another quick example highlights how people or the process may be the root cause for a vulnerability: Imagine one of your development teams is generating far more vulnerabilities than the rest. Why is this the case?
It could be because this development team lacks AppSec training and experience compared to the other teams. A simple solution would be to put the team through more security training or add more experienced security professionals to the team.
It could also be because this development team’s workflow has a weak QA process, and lacks the proper vulnerability scanning earlier in the CI/CD pipeline. If that’s the case, we can adjust the process to beef up QA and vulnerability scanning earlier in development.
When we pivot from finding a vulnerability and deciding whether to fix it now or later, to asking why this vulnerability has appeared, we unlock insights that can improve the overall vulnerability management process. We can identify the root cause behind large chunks of vulnerabilities, and make changes to address them. Ultimately, instead of trying to find a way to fix every vulnerability, we can focus on making sure less of them appear in the first place, making everyone’s job easier in the long run, and making our organization more secure.
