Best Practices for a Successful Patch Management Programme

The rise in software vulnerability exploits has shed light on how critical security patches have become as part of an organisation’s cybersecurity strategy.

Updates, patches and hotfixes have become cornerstones of cybersecurity hygiene.

Infosecurity dives into some essential elements to keep in mind in order to develop and maintain a healthy patch management programme.

Speaking to Infosecurity, Rose Gupta, threat and vulnerability management lead at AssuredPartners, said that vulnerability management is made up of four steps:

1.     Identify the organisation’s assets
2.     Identify and prioritise vulnerabilities in those assets
3.     Remediate them
4.     Re-evaluate the remediation regularly

Patch management intervenes in the third and fourth steps and is typically managed by an organisation's IT and/or security team.

Nathan Hunter, IT security & operations manager at CBHS Health Fund Limited, is responsible for his company’s patch management.

He shared with Infosecurity the five conditions he believes make a successful patch management programme.

These include:

1.     A good process for determining the criticality of updates so you can prioritise effectively
2.     A good process (and ideally tools) to keep track of the devices that you need to update and to figure out what updates are missing
3.     Good testing/validation processes to ensure patches install successfully and don't impact the functionality of the system/application that is patched
4.     Tools to automate the process of installing updates to make the update process scalable to a large fleet of devices
5.     A process for reporting on the effectiveness of your software update procedures to give your executive team, board and other stakeholders visibility into the program and its effectiveness

Read more: Software Updates, A Double-Edged Sword for Cybersecurity Professionals

Update, patch and vulnerability management processes can be operated by the same or several different teams, depending on the organisation.

AssuredPartners’ Gupta said that in her company, the IT team historically operates patch management and that her task, with her cybersecurity team, is to build a vulnerability management program from the ground up. Both teams report to the company’s chief information officer (CIO).

“The IT team operates the day-to-day patch management lifecycle using an endpoint management solution, while our security team runs the security information and event management (SIEM) solution and creates incidents based on what we're finding,” she explains.

“We then assign tickets to either the patching team or the build team if the issue does not necessitate a patch.”

Although Hunter believes update management and patch management are two different terms for the same process, he agreed that some organisations may handle the process for security updates differently from general software updates.

“Some organisations may have a security team responsible for all software updates on all systems. Other organisations may have different teams that own different systems (e.g. a firewall team, a desktop operating system team, a web applications team…) and each of these teams may have responsibility for updating the systems that they own,” Hunter explained.

To facilitate such complex structures, Gupta argued that organisations should streamline patch management processes using a responsibility assignment matrix (RAM), also known as the responsible, accountable, consulted and informed (RACI) model.

This helps the security teams know who is responsible for which types of patches and assign them quickly if needed.

While all patches may sound urgent, Hunter outlined reasons why all patches should not always be pushed instantaneously.

“First, patches often require outages or reboots to finish installing. This means outages to business or customer-facing systems, which causes an operational impact. Those outages must be coordinated to occur in windows that work best for the business or their customers, he said.

“Second, while software updates have become more reliable over time, there are still risks that an update could cause an unintended functionality issue when installed. Organisations need time to test their updates in a controlled way before they install patches widely to avoid potential business disruption.”

“Third, depending on the number of devices an organisation has, it may not be practical to update all systems at once. In this case, it's important to determine your critical and less critical systems. Focus on updating the critical systems first, then move on to the less critical ones.”

From her experience building a vulnerability programme from the ground up, Gupta agreed that organisations need to prioritise vulnerabilities to patch.

“When identifying a vulnerability, we will apply patches depending on several criteria. For this, we’ve built our own model which is very similar to the Vulnrichment program run by the US Cybersecurity and Infrastructure Security Agency (CISA) but curated for AssuredPartners,” she said.

This model considers the intrinsic severity of the vulnerability (CVSS score), the exploitability likelihood (EPSS score), the criticality of the vulnerability to AssuredPartners and business and financial impact.

“We use the Stakeholder-Specific Vulnerability Categorization (SSVC) framework to prioritise. If critical, we can run tests for 24 hours and then roll out the patch in production,” Gupta explained.

Speaking to Infosecurity, Josh Chessman, an advisor at Lionfish Tech Advisors, highlighted the need for a testing environment in which updates can be pushed first before applying them to the whole business.

He added that this allows organisations to stage their patch deployments based on the defined priorities and develop a multi-stage approach that includes testing labs and testing groups.

While turning on automatic updates can be a rule of thumb for individuals, Chessman says it is a more complex issue for organisations.

On the one hand, organisations with a strong need for availability (e.g. manufacturing companies) would want to avoid disrupting systems without prearrangement and fully automatic updates can have dire consequences.

Meanwhile, organisations cannot push each update manually.

“The larger the business, the greater the multitude of different devices and software applications, the more you need to automate,” Chessman continued.

Hunter commented: “There are advantages to automatic updates as they reduce the effort of patching and ensure systems are always up to date. However, automatic updates create a risk when you have critical systems that you can't afford to go offline outside of controlled timeframes. I believe automatic updates are appropriate for consumer-facing systems but are not always appropriate for business systems.”

Chessman recommended adopting a managed automated software update process rather than a fully automatic update stance.

Despite having a good priority-based patch management programme and implementing staged patching processes, an organisation can be faced with an unexpected emergency to fix a critical vulnerability.

To best respond to such a scenario, Hunter advocated for a patch management programme with a clear risk tolerance policy.

“For example, an organisation may have a policy that says ‘any patch that is fixing a vulnerability that is known to be actively exploited should be patched as soon as possible and outside the normal patching cycle,’ but other organisations may have a policy that says ‘any patch that has a CVE rating of 9.0 or higher must be patched as soon as possible and outside the normal patching cycle,’” he explained.

Some common questions to consider include the following:

•     Is the vulnerable system publicly exposed or only accessible in the organisation’s internal network?
•     Is the vulnerability being patched known to be actively exploited, and is there only potential for it to be exploited?
•     What type of exploit exists in the vulnerable software?
•     How easy is it for an attacker to exploit the vulnerability?
•     What is the CVE rating of the vulnerability?
•     Does the software update contain a security fix or just bug fixes?
•     Does the organisation have any other security controls in place that could reduce the impact if the security vulnerability was exploited?

Patch management leaders should always refer to their organisation’s policy.

ADVERTISEMENT

Crucial tools for a good patch management process include:

•     Endpoint management solutions to identify and map assets in an easily updatable, machine-readable format
•     Vulnerability scanners
•     Software dedicated to managing automated software patches

Key resources for building a software management programme include:

•     The US National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) website and Guide to Enterprise Patch Management
•     MITRE’s CVE.org website
•     The US Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalogue and Vulnrichment GitHub page

Read more: How to Disclose, Report and Patch a Software Vulnerability

Hotfix. A type of small patch specifically designed to address a critical issue that needs to be resolved immediately. It is generally pushed in real-time and typically used to fix urgent bugs, security vulnerabilities, or other problems that can't wait for the next scheduled release.

Update. A version change than an upgrade that can generally be pushed in a few minutes.

Upgrade. A major software version change that can sometimes involve hardware replacement.

Patch. A set of modifications to the software that can include bug fixes, the correction of an error or defect in software code, alongside other changes, such as security updates, performance improvements, or new features. Patches that modify the kernel or core system files almost always require a reboot. Patches that modify specific applications or services may or may not need a reboot, depending on the nature of the changes.

Rollback. When software users or owner needs to remove the latest version and install a previous version for operational or security reasons or because the newest version was faulty.

Enjoyed this article? Make sure to share it!

Looking for something else?