You just finished reviewing the latest report from your vulnerability scanner and surprise, surprise, way more vulnerabilities reported than your vulnerability management program can hope to mitigate. As always.
So what’s an enterprising infosec professional to do?
Prioritizing based on CVSS Scores is the most common approach, one that your team has been following for years. With 10’s of thousands of High and Critical CVEs, however, fixing those alone can more than swamp your team. And that doesn’t even account for other exploited CVEs that might be mobilized against your organization’s defenses.
It’s time for a new strategy.
Risk-based vulnerability management (RBVM) has started to take off in recent years, and for good reason. Many have tired of the inconsistent results achieved by prioritizing based on CVSS score, but haven’t had good alternatives for data-driven decision making, so the fallback prioritization scheme has typically been some combination of severity scores and gut feeling. RBVM aims to solve this challenge by quantifying risk for every unpatched CVE (and hundreds of other attack vectors), providing a sound basis for prioritizing vulnerability mitigation – a basis based on data and individualized enterprise risk rather than on gut feel and a generic severity rating. These risk ratings look at a number of factors.
6 factors to consider when evaluating CVE risk
- Inventory – it’s important to identify all assets in your environment so that you have the full picture of what you’re protecting, but most organizations miss 15-35% of their assets when creating an inventory, not to mention difficulty in categorizing each asset. Modern RBVM tools create accurate inventory of all assets, automatically and continuously.
- Vulnerabilities – This represents CVEs and their corresponding CVSS scores. These are important and definitely an important factor in determining whether or not to prioritize a vulnerability. It’s also important to remember that while this post is focused on CVEs in particular, vulnerabilities are not just CVEs. You could have a weak password, an easy to phish user, some misconfiguration, and so on, in addition to unpatched software.
- Threats – 95% of CVEs are never actually exploited in the wild. If nobody is exploiting a vulnerability, is it as important as one that is popular with adversaries? Must time and effort is wasted in vulnerability management programs by focusing on CVEs that are theoretical in nature. Taking active exploits into account ensures that your team is focused on CVEs that matter.
- Exposure – Since 37% of enterprise software is unused, it doesn’t make sense to prioritize unpatched vulnerabilities in that software. Ensure that you put higher priority on heavily used software. An additional tip is to reduce your overall attack surface by uninstalling software that isn’t in use – saving your organization money as well.
- Compensating Controls – some unpatched CVEs can’t be exploited because you have other controls in your network that prohibit the steps required for the attacker to launch the attack. Such controls might mean that a high severity vulnerability that is being actively exploited in the wild really doesn’t represent much risk to you at all.
- Business Criticality – business criticality asks the simple question, “Just how bad would it be if said asset were to get breached.” A database server that contains sensitive financial or customer information represents much more risk to the organization than a BYOD asset on your guest network. Mean time to patch (MTTP) should be lower for the high criticality asset than for the BYOD asset. This is a critical distinction – there’s no reason to respond equally quickly for all assets with unpatched vulnerabilities.
Follow these steps and you’ll ensure success in your vulnerability management program, even if you have fewer resources than you had hoped.
