6 patch management best practices for businesses

Patching is a thorn in the side of many businesses today: Everything from keeping up with the volume of patches to prioritizing what needs to be patched first can cause major delays in a business’s patching process.   

Needless to say, businesses are looking to streamline their patch management process as much as possible. Patch management refers to applying software updates for operating systems and applications and deploying them to eliminate known security vulnerabilities. With certain patch management best practices, you can help ensure a smoother patching process. 

In this post, we’ll give you six patch management best practices for businesses. 

1. Establish a baseline inventory 

It is essential to start with a baseline inventory of your production systems because you’ll need it to assess the current state of patching in your organization. Here it would be best if you had a solution that uses CVSS 3.1 because the severity of the patch is key to making a decision later.  

Besides CVSS, standardization is an essential part of the patch management process. However, multiple versions of an application running in production drive up support costs and increase security risks. Therefore, one of your primary goals should be to determine the version of each operating system and application your users should be running and devise a plan for standardizing around your preferred version. The process sometimes involves more than just upgrading to the latest version. There may be dependencies that must be upgraded before deploying your chosen version, or hardware requirements to consider.

2. Categorize and group each asset by risk and priority 

Performing all these upgrades and patch deployments at the same time would be incredibly risky; for example, servers that host critical applications require testing (to verify) and scheduling a possible reboot. 

In terms of organization best practices, one recommendation is creating a nested group. Take a group of endpoints in sales, for example, where “revenue recognition” is a subgroup of sales. Grouping and subgrouping in Malwarebytes Nebula allows the administrator to apply critical severity patches to a specific group of endpoints. For further reading, see this document.

3. Test the patch stability 

The need for testing must be balanced against the need to address the security vulnerability. Some organizations use a relatively short testing phase for critical patches but perform more in-depth testing for patches that are designed to address less serious vulnerabilities.

So, what’s the difference between short-testing and in-depth testing? Short testing is installing the patch on one or two target host machines and ensuring the critical application and operating system remain operational after a reboot. Long testing includes the steps in short testing but adds a “soak period” where the testing includes a variety of host systems, and the testing period is extended to ensure compatibility.

4. Identify endpoints that need patching 

The next step in the process is to determine which endpoints to patch. A good patch management application can help you with a nested grouping of your endpoints. The collection of your endpoint should represent how essential they are to your organization. 

Note: If the team decides not to deploy a particular patch, your organization needs a compensating control or solution to mitigate the risk of exploitation (mitigation versus prevention). In addition to an EDR solution, we recommend cyber insurance to mitigate worst-case scenarios. 

5. Pilot deployment of sample of patches 

A pilot deployment to a representative sample of the user base prior to performing an organization-wide deployment helps to verify that the patch is indeed safe for production use. It gives you one last chance to catch any issues that did not surface during lab testing. 

Note: Microsoft VSS snapshots were explicitly designed to roll back an endpoint image if a patch causes a catastrophic failure. Therefore, schedule your patch deployment to be after VSS snapshots, in case you need to roll back an endpoint image quickly. 

6. Document systems pre- and post-patching 

Documenting the state of your systems before and after a patch is applied is essential. That way, if problems begin to occur later, it will be easier to determine if they can be attributed to an applied patch. The documentation can be as simple as a spreadsheet with the hostname, the patch level, the date when the patch was applied, the specific patch, and the type of testing performed (short versus long) if any. Regardless, documentation is important, so that you know what happened, when it happened, and who did it—this information will assist you in troubleshooting problems, should one arise.

Act swiftly through the patching process and neutralize the greatest risks  

In a world where so many data breaches happen because a patch for a known vulnerability was available but not applied, businesses are right to be proactive in their patch management activities. However, patching is still a challenge for many businesses, who can’t easily track whether vulnerabilities are being patched in a timely manner or who are adverse to taking critical applications offline in order to patch them. 

The six patch management best practices we outlined in this post can help frame a logical workflow to your patch management activities, helping you reduce the risk of issues arising during your patching process. 

Want to learn more about what vulnerability assessment and patch management look like in action? Check out our Vulnerability and Patch Management landing page or watch the demos below.