Pop quiz: What’s the goal of your vulnerability management (VM) program?
If the first thing that came to mind was, “keeping systems patched and up-to-date,” this might be one of those times to take a step back to reassess. In today’s unfortunate reality of smaller teams and scaled back budgets, everyone in the organization must ensure that their programs are getting maximum return, and VM is no different.
Since patching is such a central (and time consuming) component of most vulnerability management programs, it can be easy to forget that the real objective of vulnerability management is risk reduction.
What’s the difference and why does it matter?
The big difference is in what you tackle first. When focused on patching, it can be all too easy to view metrics like mean-time-to-patch (MTTP), critical CVEs, or % of unpatched systems as the ultimate objective of your VM program. The problem is that these speed and coverage focused metrics don’t necessarily equate to risk reduction, and lead to wasted effort by infosec teams.
Since speed and coverage metrics don’t necessarily lead to maximum impact, a risk-focused model helps maximize impact while minimizing wasted effort. In such a model, it is critical to incorporate not only the unpatched vulnerability, but also business criticality of the impacted system(s), mitigating controls already in place, exposure, and whether that vulnerability is actually being exploited by adversaries.
For example, a recent blog post highlighted the following customer story. This particular customer was concerned about a Firefox CVE that they wanted to patch as quickly as possible. Turns out that they had 5,700 end user machines that needed the patch. In a patch-focused VM program, where the team was measured by MTTP and % of unpatched systems, the focus would have been on patching all 5,700 systems as quickly as possible.
This organization, however, had internalized what it meant to take a risk-based approach to VM. They quickly determined that, of those 5700 systems, only 171 had Firefox in active use, and of those, only 5 belonged to privileged users. The focus immediately dropped by 97%, from 5700 systems, to 171, with 5 of those getting top priority for patch application. Since Firefox wasn’t in use on most of the systems, there really was no exposure to that CVE, and the browser was silently removed from those systems via GPO push.
This seemingly minor shift, from a focus on patching, to a focus on risk reduction, lead to the same risk reduction outcome for the company, with a 97% reduction in effort, giving their infosec team valuable time back to focus on other priorities.