Resistance to change is always present, especially if you think the processes you have in place are efficient and effective. Many organisations feel this way about their software management procedures until they have a security breach or incident and are left wondering where they went wrong.

The reality is that most patch management programs are built on assumptions and recommendations, rather than facts about actively exploited vulnerabilities. Risk-based patch management is the answer to this issue.

In this article, find:

The problems with typical prioritisation

Software feature updates, security fixes, bug fixes, performance enhancements and many other types of software releases have existed since the software industry started. Vendors often assign a severity rating or other score to each of these to let customers know what they think is most important.

Unfortunately, there’s no industry standard associated with these ratings, so we are left to compare and prioritise releases for deployment on our systems based on recommendations. On top of that, such ratings are rarely updated to account for active threat context even as vulnerabilities change.

Overlooking an actively exploited vulnerability

While better than nothing at all, vendor severity ratings often come up short. Consider the Follina vulnerability (CVE-2022-30190) published in May of 2022. This vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT) allows for remote code execution.

Follina was under attack for several months before Microsoft finally responded with several updates. Alarmingly, Microsoft only assigned this vulnerability a Common Vulnerability Scoring System (CVSS) v3 rating of 7.8 and severity of Important. If you’re only patching based on Critical severity, you'd have missed this one, leaving a significant gap in your attack surface.

Worse yet, Follina’s CVSS score remained at 7.8 even after it was revealed the vulnerability was being actively exploited to distribute Bisamware ransomware, exposing organisations that had overlooked the vulnerability to even more risk. 

Ivanti Neurons for Vuln KB
Intelligence on the ransomware threat associated with CVE-2022-30190 displayed in Ivanti Neurons for VULN KB

CVSS shortcomings

Severity ratings are ‘augmented’ with CVSS scores from FIRST. Each CVE is assigned a CVSS number, such as the 7.8 given to CVE-2022-30190 in the example above.

One of the major objectives behind calculating the actual CVSS number is to ensure standardisation so all CVEs are scored consistently and can be accurately compared. The higher the CVSS score for a vulnerability and the associated patch, the more critical it is to deploy in most environments.

For software updates that address multiple CVEs, the highest CVSS value is usually considered for prioritisation. But is this value even accurate?

The results of an analysis of CVSS scores in a recent article showed there's a discrepancy for nearly 20% of CVSS scores (25,000). This analysis was based on a comparison of the scores reported in the NIST National Vulnerability Database (NVD) and those reported directly by the vendors themselves.

Vendor severity inconsistencies

One important point to keep in mind is vendors have historically assigned their own terminology to severity (e.g., critical, important). Using vendor severity scoring as a priority mechanism may work well when comparing all patches by a given vendor, but doesn't always provide an accurate comparison of patches between vendors. In fact, many use different terminology entirely.

Likewise, vendor severity isn't always a positive indicator. Many zero-day vulnerabilities are only rated Important by Microsoft but have high CVSS numbers. You can see how patching using severity and CVSS for prioritisation is using assumptions and recommendations and can result in a vulnerable environment.

Why prioritise active exploits over any other prioritisation method?

According to the US Cybersecurity and Infrastructure Security Agency (CISA), an actively exploited vulnerability is “one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.” In layman’s terms, a vulnerability under active exploitation is one that's been used by a threat actor to launch a cyberattack.

Thus, to minimise the risk of an attack on your organisation, you must prioritise actively exploited vulnerabilities above all others. This is good news as most vulnerabilities aren't being actively exploited and thus pose little to no risk to your organisation. You can identify those that have been exploited through risk-based patch management.

What's risk-based patch management?

According to the Ultimate Guide to Risk-Based Patch Management: 

“Risk-based patch management goes beyond vendor severity and basic CVSS scores to identify and qualify the specific vulnerabilities that pose the most significant risk to an organisation. 

As an extension of risk-based vulnerability management, it brings real-world risk context into the patch management process by incorporating updates with known exploited vulnerabilities that matter most to an organisation’s security posture.”

How can my organisation adopt risk-based patch management?

For organisations ready to adopt a risk-based approach to patch management, a good place to start is the CISA Known Exploited Vulnerabilities (KEV) catalog. CISA took a major step forward to help prioritise vulnerabilities when it introduced Binding Operational Directive 22–01 along with its KEV catalog. When originally released, the catalog contained some 200 actively exploited vulnerabilities. It has since grown to almost 900. 

CISA builds the list with the knowledge the vulnerabilities it contains are being exploited in the wild by active threats. However, the list does have its shortcomings, as it currently excludes 131 vulnerabilities associated with ransomware.

Is the CISA KEV catalog the only resource available for risk-based patch management?

Organisations with more mature risk-based patch management practices leverage advanced risk scoring methodologies in place of or in addition to CVSS. These methodologies assign scores to every vulnerability identified in an organisation’s environment, allowing those organisations to expand their risk-based approach beyond the CISA KEV.

Many vendors in the risk-based vulnerability management space have developed proprietary scoring methodologies that represent the true risk posed by a vulnerability. They do so by delivering dynamic risk ratings that give extra weight to actively exploited vulnerabilities.

For example, Ivanti’s Vulnerability Risk Rating (VRR) has assigned Follina a score of 10, a score that more accurately represents the risk posed by that vulnerability than its CVSS score of 7.8.

Ivanti's VRR rating of Follina.
The difference between the VRR and CVSS v3 scores and severity levels for CVE-2022-30190 as shown in Ivanti Neurons for VULN KB 

Why it’s the perfect time to adopt risk-based patch management 

If you feel you’ve fallen behind on system updates or are overwhelmed by new systems and applications in your company, now is the perfect time to adopt risk-based patch management. 

Even if you feel you have a solid program in place based on severity ratings and CVSS scores, it’s time to remove the resistance to change and start a new process before your business is devastated by a data breach stemming from an exploited vulnerability. 

Start by using the CISA KEV to prioritise your updates and earmark a budget for a risk-based vulnerability and patch management solution. With the proper tools in place, you can quickly identify the highest risk systems to patch first and work down the list to ensure your systems are secure.

Looking to take the first step? Dive into this eBook for a one-stop guide for implementing a modern risk-based patch management program.