risk-based patch management (RBPM)

What is risk-based patch management (RBPM)?

Risk-based patch management (RBPM) is an approach to implementing patches to fix software code that prioritizes patches that address security issues posing the highest risk to the organization.

RBPM is a more sophisticated approach to patch management than traditional methods, which apply patches based on general risk assessments that don't take into account the risks specific to an organization.

Patch management is a longstanding practice in IT departments. Software makers issue patches, or code changes, to fix performance bugs or security vulnerabilities they have identified in their software. They also use patches to add features.

Patch management is an important part of an organization's management of its IT estate. It involves the following steps:

1. Assembling and maintaining an inventory of the operating systems, applications and firmware running in the organization.
2. Identifying the patches that have been issued for software listed in the inventory.
3. Acquiring the patches.
4. Testing the patches, starting with the critical ones.
5. Implementing (applying) the patches.
6. Verifying that the patches have been correctly implemented.
7. Documenting all the patches that have been implemented.

In addition to those standard steps, RBPM calls for the following:

1. Assessing the issue that each available patch is intended to address.
2. Determining the risk to the organization associated with each issue.
3. Prioritizing patch deployment, starting with the patches that address issues presenting the highest risk to the organization.

The objective of RBPM is to maximize the time IT and security teams spend on patching by ensuring their work delivers the biggest returns.

Why is risk-based patch management important?

Patch management is a significant task for most organizations, in large part because of the staggering number of software vulnerabilities.

In 2023, 29,035 new Common Vulnerabilities and Exposures (CVEs) were identified worldwide, according to Statista, a market data provider. That was up from 25,227 in 2022 and drastically higher than the 5,297 reported a decade prior in 2013.

As of spring 2024, counting cumulatively, there were more than 230,000 CVEs, according to the CVE Program, which is sponsored by the U.S. Department of Homeland Security and the Cybersecurity and Infrastructure Security Agency (CISA). The latter agency also maintains the Known Exploited Vulnerabilities (KEV) catalog.

The National Institute of Standards and Technology keeps track of known vulnerabilities in its National Vulnerability Database. NIST typically adds dozens of new CVEs to its dashboard on any given day, or thousands per month. NIST listed nearly 250,000 CVEs on its dashboard in spring 2024.

When a vulnerability or bug is identified, vendors seek to correct it by issuing a patch to update their code.

Organizations that run the impacted software must obtain the patch from the vendor, test it in their IT environment to make sure it works without disrupting other systems and then implement it.

Although automation speeds the process, patch management remains a time-consuming and often daunting task. Yet, it can't be ignored, as it's essential for protecting the organization from cybersecurity attacks. Threat actors actively search for unpatched vulnerabilities to exploit.

Patch management is also never-ending, given the volume of CVEs. Organizations typically lack the resources to implement all the patches available for the known vulnerabilities in their IT environments, which is why prioritizing by risk severity is so important.

Not all patches provide equal value, just as vulnerabilities don't present equal risk. Some patches address vulnerabilities that pose minimal danger or only provide small security improvements. And most vulnerabilities aren't actively exploited by threat actors, which means they pose almost no risk to many organizations.

But other patches fix vulnerabilities that do pose significant risks, or they offer enhanced security features that provide significant protections.

Risk-based patch management acknowledges that organizations are incapable of implementing every available patch and that they don't see equal returns from patches. Consequently, RBPM requires organizations to prioritize implementing patches that deliver the best returns.

How RBPM works

To move from a conventional patch management program to a risk-based one, an organization needs to adopt processes for scoring the risks associated with each patch.

To start, it must understand the generic risk associated with each vulnerability by using the Common Vulnerability Scoring System and other scoring systems, such as those used by software makers to rate their own vulnerabilities. This kind of scoring takes a general approach and considers, for example, whether the vulnerability is actively being exploited by hackers or whether it is easy or difficult to exploit.

The organization next needs to evaluate the importance of each patch to its business operations and IT environment.

To do so, it must determine the risk that each vulnerability presents to its operations by understanding the criticality of the asset that has the vulnerability. For example, a vulnerability in a system that handles core operations presents a higher risk than a vulnerability in a system that performs a niche function or one that doesn't hold any sensitive data. The assessment should also weigh the impact on the organization should a threat actor successfully exploit the vulnerability.

For patches that offer an enhancement, such as an entirely new feature, the organization should assess the potential value of the feature and the risk of not having it.

It should also consider whether a patch is necessary to meet regulatory requirements.

The evaluation process helps the organization use its limited resources to ensure that the most critical work happens first instead of wasting resources on patches that provide little to no value.

RBPM versus RBVM

Risk-based patch management complements risk-based vulnerability management (RBVM), an approach to identifying and addressing vulnerabilities in an organization's technology stack that, like RBPM, prioritizes remediations based on which vulnerabilities pose the greatest threats.

Both are part of an organization's IT operations and overall cybersecurity program, but the two are not synonymous. RBVM identifies many types of vulnerabilities, not just those that require patches. It has a much broader scope than RBPM.

In fact, an organization can adopt RBVM to improve the effectiveness and efficiency of its vulnerability management practice and gain benefits from that approach even if it does not have risk-based patch management in place.

However, using risk-based patch management as part of a risk-based vulnerability management program creates an even more effective and efficient strategy and thus helps improve an organization's overall security posture.

Benefits of RBPM

In surveys, IT teams, which typically have primary responsibility for patch management, have said they face a few big challenges with patch management.

A top challenge consistently has been the volume of work involved.

Although RBPM doesn't reduce the number of patches that are available to implement, the approach does enable IT teams to better focus their energies and have more impact with their efforts.

Other benefits of RBPM include the following:

• Effectiveness. By identifying the patches that should be implemented first because they address issues that hold the highest risk to the organization, RBPM helps IT teams deliver a lot of bang for the buck in a timely manner.
• Efficiency. Similarly, because IT can focus on high-value patches, it's not wasting resources testing and implementing patches that do little to improve the organization's security posture.
• Improved compliance. By weighing whether a patch is necessary to meet regulatory requirements, organizations may improve their compliance rates.
• Improved operational continuity. An organization can help ensure that its business operations continue by including operational risk when assessing whether a vulnerability needs to be patched.
• Better work dynamics for IT. Teams charged with patch management have reported feeling overwhelmed, with some saying they sometimes rush through important steps, like testing and verification. RBPM can alleviate the feeling of running on a hamster wheel by producing a tighter list of patches that need to be applied. It also enables teams to reclaim some time for the critical tasks of testing, verifying and documenting patches to ensure they are applied effectively.
• Reduced risk. All these benefits ultimately help an organization lower its risks by ensuring that IT teams are focused on implementing the patches that deliver the most value and that they have time to test and verify patches.

RBPM best practices

Organizations that want to implement a successful risk-based approach to patch management need to have their IT and security teams working together so they can understand the risks that exist in the organization and establish processes to prioritize patching based on the severity of those risks.

Other best practices for effective RBPM include the following:

• Creating and maintaining an accurate inventory of software assets so teams can quickly and accurately identify which vulnerabilities affect the organization's IT environment and which ones are irrelevant.
• Building catalogs of the CVEs, along with entries from CISA's KEV catalog, that are relevant to their organization.
• Consistently documenting applied patches.
• Implementing patch management software that supports RBPM and automates as much of the patching process as possible.
• Considering alternatives to patching that could help lower risks and perhaps the amount of patching work. Alternatives include modernizing legacy systems and rationalizing or decommissioning software that provides little or no business value. Additional alternatives, particularly if patching would be difficult or patches are unavailable, include reconfiguring access controls and firewalls, as well as segmenting or isolating affected systems.