Gartner Blog Network

Considering Remediation Approaches For Vulnerability Prioritization

by Augusto Barros  |  May 2, 2019  |  4 Comments

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!



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

Thoughts on Considering Remediation Approaches For Vulnerability Prioritization

  1. Cost to patch is *the* essential parameter for prioritization in the OT space.

  2. George says:

    In addition to vulnerability “badness” score, we look at active threats / exploits targeting the vulnerability, importance of the asset to the business, compensating security controls that mitigate the exploit, internet exposure of the asset.

    • Augusto Barros says:

      True George, but that’s still assessing the ‘badness” of the vulnerability; that’s what we see organizations doing when they evolve past CVSS, but my point in this post is the need to look into the remediation cost too. As much as we can improve in assessing risk, remediation decisions are still a trade-off and we need to know more about the other side of the equation as well.

  3. Tony says:

    It is not just the cost to patch, or perhaps the risk of patching. It is also the organisation’s tolerance for risk.

    If a vulnerability could lead to a compromised Web server that might allow BEC, that’s bad. If it puts a large amount of PII at risk, that’s very bad. If it puts the organisation’s intellectual property at risk, that might be an existential threat. That’s the profile for our business.

    This means thatched IP threat will be patched at any cost, the BEC risk might be managed until patching is convenient.

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.