Why patching is still a problem -- and how to fix it

Many obstacles stand in the way of perfect patching. Getting around them may be easier than you think

Why patching is still a problem -- and how to fix it

Despite warnings from people like me, unpatched software is the top reason computers get exploited.

People aren't too dumb or lazy to install patches. They want to do the right thing. But patching can be difficult for a multitude of reasons, and those roadblocks explain why patching is performed so poorly in most organizations. Let's walk through those reasons.

Too many patches

The sheer number of software vulnerabilities and related patches is second to only the number of unique malware programs released each day. According to the Microsoft Security Intelligence Report, 5,000 to 6,000 new vulnerabilities surface each year. That works out to an average of 15 per day.

An individual operating system or application may have hundreds of new vulnerabilities each year, each of which needs to be patched. Moreover, almost every program has a different frequency and patching method. Many have autoupdate mechanisms, but administrators and users often disable or ignore autoupdate routines to avoid service interruptions or other unintended consequences. Manual patching requires vigilance and discipline.

Folk wisdom says that patching habits can be divided into quarters: 25 percent of people patch within the first week; 25 percent patch within the first month; 25 percent patch after the first month, and 25 percent never apply the patch. The longer the wait, the greater the increased risk.

Legacy vulnerabilities

We still have machines whose vulnerabilities should have been patched back in the 1990s. Sad but true: Most of my friends decline to patch until an update request gives them no choice. I figure there are a ton of mom-and-pop shops with servers or systems installed by a capable contractor -- who has never been invited back.

In the corporate world, you have hugely popular programs, like Java, which if patched would break too many critical applications. Instead of fixing or mitigating the application issues, companies simply don’t patch. Hackers love this.

Some things can’t be patched

Every appliance you buy comes with an operating system, application software, and possibly scripts, often all of it customized open source code. Unfortunately, vendors typically try to hide what's being used and often fail to patch in a timely way -- or at all. In 20 years of reviewing security appliances, I've seen only one that lacked a critical vulnerability. The very devices you’re using to help protect your systems are among the most vulnerable.

You literally can’t patch most appliances. The vendor can, but they often don’t. Most of those patches certainly aren’t timely. Even if you find out what software and applications are running on your appliance and you can identify missing patches, you never can apply the patches yourself. Most likely you'd break your support contract.

Hundreds of millions of smartphones and other mobile devices have essentially the same problem. Some devices get frequent updates from the originating vendors; others force you to wait until a downstream vendor or wireless provider graces you with a patch update. It can be years between patches, and the problem is getting worse.

Patches often interrupt operations

Most patches mean either stopping and restarting the affected software -- or a complete reboot. Show me a server that hasn’t been rebooted in years and I’ll show you a very vulnerable server.

Some small percentage of patches cause real operational issues. The percentage of people impacted is usually minuscule, but as long as it’s nonzero, we have a trust problem. People worry that applying any patch -- even a critical, needed one -- can bring down their system. On top of that, many patches are huge, often into the gigabytes. Patching a large number of systems all at once can overwhelm a network.

Toward a better patching solution

With all these problems, how can we do it better?

First, focus on applications most likely to be exploited. Not all patches are equal. Not all critical vulnerabilities are equal. Yes, there may be 5,000 to 6,000 new vulnerabilities each year, but perhaps a 100 of these are widely exploited. Plus, a handful of applications (Java, Adobe Acrobat, Flash, Internet Explorer) account for almost all risk.

Figure out which applications are exploited the most among your critical assets, and patch them first and best. You’ll get a lot more bang for the buck than if you tried to patch everything.

Incentivize patch management teams properly. Most patch management teams are measured either on how well they patch Microsoft Windows and Microsoft applications or on the total number of patches (by percentage) applied across the organization. If they patch a high percentage of everything, patching is deemed to be going well. This is the wrong type of incentive.

Patch management teams should be rewarded based upon how well they patch the most exploited programs. This is the quickest way to lower vulnerability risks in any environment. Pound for pound, perfectly patching a handful of applications is the most effective use of resources to prevent breaches.

But remember: Patch management teams must be given rightful authority. You can’t tell them they are required to apply patches, then tell them this and this and this are hands-off -- especially if “this” is a highly exploited program, such as Java.

Instead of the hands-off approach, force programmers and vendors to enable patches to be applied without blowing up existing arrangements. When patch updates mess with systems, it’s almost always because programmers did things they didn’t need to do or were told they shouldn’t do.

Any program you can’t update with a vendor-recommended patch has been coded incorrectly. Hold vendors and programmers accountable.

Pick software and devices that can easily be updated. Avoid products that can't be software-updated. Pick platforms and devices with a healthy respect for computer security, including patching. Before you buy an item, find out how it gets patched and how often patches are distributed. You want patches to arrive quickly after critical vulnerabilities are discovered.

Improve patch education. Make sure everyone using a system under your control understands the importance of patching. They need to know that unpatched software is a prime attack vector. Teach them how systems are patched -- and how to recognize the malicious fake patches they need to avoid.

Patching is a terribly weak link in most computer security defenses, but it doesn’t have to be. With a few tweaks and some focus, patch management could easily become a strength.

Copyright © 2016 IDG Communications, Inc.

Get the best of CSO ... delivered. Sign up for our FREE email newsletters!