As a cybersecurity service provider, we regularly advise customers to “patch early and patch often.” There are many reasons why organizations may not patch systems and devices, though.
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 an injury, or we’re really busy with work, or we don’t want to pay for a gym membership we don’t think we’ll use. The result? We often avoid working out unless we make a conscious effort to 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, one 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 organizations patching?
Why Patch?
Let’s get this out of the way: for most organizations, patching early and often is going to be the best strategy. Not patching systems, especially those directly exposed to the Internet, pose an open threat for cyber attacks.
According to one recent report, only a small number of data breaches stem from successful exploitation of vulnerabilities. The report noted that while this does still happen, it shouldn’t be a major cause for concern as long as your organization has policies and procedures in place for patching and you aren’t being targeted by nation-state cyber attackers.
This is an improvement from just a few years ago, when more than 70 percent of successful cyber attacks were attributed to threat actors exploiting known vulnerabilities that had a patch available. 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.
The 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 might not patch.
Legacy Systems
Most rationales for not patching center around the dreaded “R” word – RISK. It’s true, patching can indeed be risky. Many organizations have at least one outdated system 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 a business application from the 90s that is somehow still in use.
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 organizations with some undesirable consequences to deal with and a significant risk of impacting the rest of the business.
Interrupting Operations
Most patching requires that systems be stopped, patches installed and then rebooted. This means that the services provided by that system are going to experience some downtime. For some organizations, even a small amount of downtime is not an option. This is especially true when dealing with mission critical systems, such as those in public safety, or life-saving systems like 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 (COTS) systems, home-grown applications an organization creates and maintains, and systems where there have been significant modifications, there can be a gargantuan number of things to patch. Additionally, the number of patches available to be installed on each of these systems can be overwhelming. Too often, it can feel like a losing battle.
With so many patches, the issue of timing becomes problematic. Installing all of these patches at once can require extensive planning that can be time-consuming.
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 there are very few results, since it isn’t typically any one person’s job. It can be challenging to find the expertise within an organization to understand all of the variables and set up a patching schedule that works.
Generally, risk analysis should include the following:
- If the patch or update is supposed to add functionality, is that functionality something that the 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 is being patched? 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 the system vulnerable to that particular exploit? Can risk exposure be reduced through some other method? (for example, leveraging another application, closing a firewall port, etc.)
- If something goes wrong, are rollbacks an option? What is the time frame to accomplish that roll back? Are there backups for critical data?
- And finally, is data available to support the business case for patching if there will be downtime or third-party costs associated with it? If not, are there resources to get that information?
Summary
The good news is that organizations don’t have to evaluate these risks alone. Automation and asset management tools are a strong ally in this fight, as are security professionals who can provide best practices for vulnerability management. Additionally, bringing in a third-party company like Motorola Solutions to help the organization create a patch and update schedule that syncs with business operations is never a bad idea. Get into a “workout routine” so that patch management becomes second nature for a healthier operation.
Stop the second-guessing with our Security Patching Services.
