Gartner Blog Network

Considering Remediation Approaches For Vulnerability Prioritization

by Augusto Barros  |  May 2, 2019  |  Submit a Comment

As Anton said, we are starting our work on vulnerability management this year. One of the points I’ve started to look at more carefully is how much the different patching approaches can affect how we prioritize vulnerabilities for remediation.

Expanding the prioritization of vulnerabilities to go beyond CVSS and include threat context is something we are seeing quickly moving to mainstream. Now it’s not uncommon to see organizations that don’t only look at how bad a vulnerability could be, but how much it is and even will be (great work on prioritization models by some vendors out there). This really helps reducing the noise and focus on what matters.

But this is helpful when you look at vulnerabilities individually only. When they move to other side of the fence, however, the problem has some different nuances. IT operations don’t see vulnerabilities, they see patches. And the relationship between patches and vulnerabilities are not always one-to-one, and not all patches are equal. There are those “applied-periodically-automatically-with-no-intervention” types of patches, there are also the “almost-never-released-and-when-installed-breaks-everything” types of patches. The IT Ops team may not even bother looking at the priority of the former but may want a very thorough justification for why they need to apply the latter.

Many vulnerability management programs, because they are managed by the security team, do not consider the characteristics of the patching process when applying their prioritization criteria. But if they want to be taken seriously by IT Ops, they should. So, my questions here are:

– When you prioritize vulnerabilities, do you incorporate “cost to patch” in your criteria?

– If you do so, how? Does your tool set allow you to do it? Where is that information coming from?

– If you define patching times by categories, have you considered patching characteristics for categorization? For example, do you define categories as something like “non-critical workstations” or like “windows workstations with auto-updates on”?

– Do you look at the vendors of software deployed in your environment as part of this exercise? Patching Microsoft vs. Oracle, for example? Do you take into consideration the quality of the patches or release schedule of the vendor to define the patching times?

We like to stay away from the patching problem as it seems more like an IT operations problem than a security problem. But I believe that proper prioritization (or at least one that will be useful for the goal of fixing vulnerabilities) should include something about the required patches too. If that’s correct, what are the tools available for that and how are organizations doing it?

Please jump in and leave your experiences in the comments section!



Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: security-operations-for-technical-professionals  vulnerability-management  

Tags: vulnerability-management  

Augusto Barros
Research VP
3 years at Gartner
21 years IT Industry

Augusto Barros is Research VP in the Gartner for Technical Professionals (GTP) Security and Risk Management group. Read Full Bio

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.