We Don’t Need No Stinking Patches: Why Organizations Don’t Patch

by Ryan Clancy on August 7, 2019

As a cyber security vendor, we regularly advise our readers and clients to “patch early and patch often,” but there are many reasons why organizations don’t patch.

First off, let’s just say that patching is a bit like working out. We all know we should exercise regularly. The reality though, is that it can be time consuming, and there are often more pressing things that take our attention. Or maybe we have a nagging injury, or we’re short on cash, or we don’t want to pay for a gym membership we don’t think we’ll use. So we often avoid working out unless we make it a part of our daily routine, or the doctor gives us a dire warning about our health that motivates us to get moving.

Okay, you might say, I can see the similarities. But with so much attention in the media and in the security industry on data breaches and vulnerabilities, why aren’t people patching?

Why Patch?

Let’s get this out of the way: for a large majority of companies, patching early and often is going to be the best strategy. Not patching systems, especially those exposed to the Internet – and what isn’t these days – is the equivalent of running with scissors. It’s only a matter of time before something messy happens and someone gets hurt.

According to the 2019 Verizon Data Breach Investigation Report (DBIR), most data breaches considered in the study involved methods other than exploiting known vulnerabilities. This is an improvement from just a few years ago, when the 2015 DBIR showed more than 70 percent of successful cyberattacks exploited known vulnerabilities where there was an available patch. Yet a look at some of the biggest data breaches of the 21st century shows that known vulnerabilities played a role in many of them.

Sponsorships Available

The 2017 Equifax data breach is a perfect example of what can happen to an unpatched system. This data breach left the personal information of nearly 150 million Americans open to compromise and has already cost Equifax at least $1.4 billion. Despite these high-profile cases and many others, many organizations still shy away from patching their systems and applications. Let’s examine a few reasons why organizations don’t patch.

Infamous Legacy Systems

Most rationales for not patching center around the dreaded “R” word – RISK. It’s true, patching can indeed by risky. You’d be surprised how many companies have at least one ancient system lurking in their environment. Perhaps there’s an old server that runs some accounting scripts, a system that has to run Windows XP due to limitations with the application, or you’re still nursing along a business application from the 90s. Some IT professionals view these systems with affection, as though a Lifetime Television movie will be made about their relationship. Others view legacy systems with total disdain.

For most of these systems, the IT team has created a delicate balance in keeping the lights green and these systems fully operational. The risk is that installing a patch would break other dependent systems and applications. In some cases, installing a patch could even void a warranty on equipment. This could leave you with some messy consequences to deal with and significant risk of impacting the rest of the business.

Interrupting Operations

Most patching requires that systems are stopped, the patches installed, and then rebooted. This means that the services provided by that system are going to experience some downtime. For some businesses, even a small amount of downtime is considered unacceptable. This is especially true when you’re dealing with mission critical systems, such as those in banking, or even life-saving systems, such as those in healthcare.

Besides the downtime required to install a patch, patches can cause unintentional or secondary issues with applications and operating systems, which gets back to the comment we made earlier about risk. Whether it’s true or not, the IT operations team can report that systems “run slower” after patches have been installed and systems rebooted. The data is fairly mixed in supporting these claims, yet as anyone who has worked in IT knows, user perception can be reality.

Too Many Patches to Manage

Between commercial off the shelf systems, home-grown applications that your organization creates and maintains, and systems where you’ve made significant modifications, the amount of systems to be patched can be gargantuan. Additionally, the number of patches available to be installed on each of these systems can be overwhelming for an organization. Too often, it can feel like a losing battle.

With so many patches, the issue of update timing becomes problematic. Installing all of these patches at once would put a “doors opening early on Black Friday” level of pressure on your network and team.

It’s Patch Time

Ultimately, a risk-based approach to patching is the best choice for most companies as part of an effective security program. But try doing a search to hire a “patch manager,” and you’re going to come up with very few results, since it isn’t typically any one person’s job. It can be challenging to find the expertise within your organization to understand all of the variables and set up a patching schedule that works.

Generally, your risk analysis should include the following:

If the patch or update is supposed to add functionality, is that functionality something that your business actually needs?
What exactly does the patch fix? Is it a security update or a non-security update? Does it involve software updates or hardware updates?
What type of system are you patching? Is this a critical, customer-facing system? Does it contain sensitive data?
If the patch is a security update, what issue is it addressing? Where does this fit in terms of prioritization for patching? Is this a short-term fix? Is your system vulnerable to that particular exploit? Can you reduce your risk exposure through some other method? (for example, leveraging an application you already own, closing a firewall port, etc.)
If something goes wrong, are you able to roll back the patch? What is the time frame to accomplish that roll back? Do you have backups for critical data?
And finally, do you have the data you need to support the business case for patching if there will be downtime or third-party costs associated with it? If not, do you have the resources you need to get that information?

Summary

Know that you don’t have evaluate these risks by yourself. Automation and asset management tools are a strong ally in this fight, as are security professionals who can help guide you on best practices for vulnerability management. Additionally, bringing in a third-party company to help you get your organization started with a patch and update schedule that syncs with your business operations is never a bad idea. We can help you get you into a “workout routine” so that exercise – I mean patch management – becomes second nature and you have a healthier operation.