6 Software Patch Management Policy Mistakes (and How to Fix Them) 

Hackers spent 2021 wreaking havoc by exploiting software vulnerabilities, so now is a great time to check when you last updated your organization’s patch management policy. From the recent Log4j exploit to a series of Microsoft Exchange vulnerabilities—which hackers have leveraged to deploy ransomware, steal emails and more—or the previous Kaseya ransomware attacks that spread throughout the globe, the damage caused by software exploits in 2021 has been immense.

Even the Equifax breach—one of the largest in US history that exposed personal data for 143 million people—resulted from an unpatched vulnerability. According to Equifax, criminals exploited an unpatched web application vulnerability for which a patch was release two months prior to the attack. This massive breach could have been avoided if Equifax had promptly patched its software. It’s important that organizations review their patch management policy at least once a year to ensure it meets the current best practices.

How Safe is Your Organization?

All too often, patches are available and not deployed due to time, budget, personnel, or technical issues.  According to a survey conducted by the Ponemon Institute, 42% of the respondents that had been breached stated that the cause was a known, unpatched vulnerability for which a patch was available but not applied.

To compound the problem, patch management risks aren’t limited to YOUR environment. Criminals can also leverage unpatched vulnerabilities in your vendors’ environments—and your data is at risk. For example, in December of 2020, Florida Healthy Kids Corporation was informed that due to an unpatched vulnerability in their web hosting provider’s environment, criminals had access to the protected health information for 3.5 million of their applicants. It’s clear that having a strong patch management policy is a crucial way for your organization to reduce your risks.

Avoiding 6 Common Software Patch Management Policy Mistakes

The good (and bad) news is that many software-related hacks could easily have been prevented with proper patch management. Read on to hear about six common software patch management policy mistakes and how you can successfully address them to protect your organization.

Mistake #1: Not Knowing What to Patch

Everybody knows to patch your operating systems—but what about those pesky third-party applications, or software deployed by your vendors? As you can see in the example above, one unpatched vulnerability in a vendor’s system can lead to a major breach. The 2020 Ponemon Institute survey also found that over a six-month period, the average organization had a backlog of 57,555 identified, unpatched vulnerabilities. If you calculate that average backlog by the number of vendors with access to your environment, the numbers get scary. Let’s look at core components of your patch management policy that can help reduce these risks. You should:

• Start by maintaining an inventory of your software. This will help you understand the scope of work and the resources you will need.
• Prioritize your software patching based on the level of access to sensitive data, the criticality of the vulnerability, and the risk that it represents.
• Understand and minimize the risk from your suppliers. Read this Supply Chain Security Checklist for tips on how to vet your vendors and reduce this risk.

Mistake #2: Patching Too Slowly

Many organizations have a patch management policy that calls for monthly or bimonthly patching cycles. The problem is that when a critical vulnerability is announced, hackers may actively try to exploit your server within hours or days, not weeks. Other organizations are struggling with resource constraints that cause even longer backlogs for patching. This increases the risk that by the time you patch, you may have already been hacked. To limit this risk, you can:

• Discuss ahead of time how to handle critical patches for different software types. Carefully consider the risks of waiting versus the time needed to fully test and deploy a patch.
• Document your standard patch time frames and audit routinely to make sure you are meeting your goals.
• Set up automated patch management in order to ensure that your myriad applications are patched consistently and quickly. This can save your organization time and money, as well as reduce your risk of exploitation.

Mistake #3: Ignoring Outdated Software 

You may have software on your network that is so outdated that the vendor no longer releases patches—meaning these systems are highly vulnerable to attack. Many organizations throw up their hands and decide there’s nothing they can do. This situation is all too common, particularly in environments when you rely on specialized vendor software. Here are some strategies that can help:

• Track your outdated software in a central asset management database.
• Regularly review the use of these systems and determine whether you can decommission or replace them with more modern software.
• Place outdated operating systems on their own, isolated network segment with very limited traffic. This will reduce the risk of compromise.

Mistake #4: It’s Never a Good Time

Many organizations don’t apply patches regularly (whether or not they have a patch management policy) because it is difficult (or even impossible) to find a good time to apply patches and restart critical systems. Try these tips:

• Make sure you architect your infrastructure to have redundancy. Ideally, you should be able to reboot a critical system in order to install a patch without impacting the business.
• Prioritize regular patch deployment. If downtime is required, it is better when it is planned, as opposed to an emergency due to a cybersecurity incident. If you don’t have redundancy, planning at least a monthly scheduled downtime (that has the least impact on your organization) should be part of your patch management policy.

Mistake #5: Fear of “Breaking Something”

Even the most well-tested patch deployments can cause problems, particularly in complex environments. Fear of “breaking something” can cause system administrators to delay patching. You can reduce this challenge if you:

• Develop and implement a software patch test plan whenever possible to increase the likelihood of successful deployment.
• Have a strategy for rolling back patches quickly in the event that a patch impacts system functionality.

Mistake #6: Not Monitoring Patch Status

Patches don’t always install properly, leading to data breaches, ransomware attacks, and other consequences. Minimize your risk by:

• Routinely checking your systems’ patch status using automated patch management software.
• Ensuring your team is notified of both successful and failed patch deployments.
• Assigning a point person or team to follow up on failed patch deployments in a timely manner, and regularly auditing this work.

Having a strong patch management policy is a crucial part of your cybersecurity foundation, and it’s one that frequently gets less attention than it deserves due to time and resource issues. Contact us if you need help creating an effective patch management policy or auditing and updating your environment for critical patches—we’re ready to help.