First, what is patch management? Patch management is simply the process of acquiring, testing, and installing patches (and possibly other upgrades) for software applications. And it is the simplest, most effective thing you and your organization can do to minimize your risk profile, especially when it comes to cyber attacks.

That said, many organizations have little to no patch management strategy in place, leaving themselves vulnerable to attack. Others do patch management, but they do it manually. Depending on the number of endpoints, this could easily mean a whole team of people running around and trying to stay on top of patch releases and their effects on machines.

We’ve automated patch management for enough clients that we’ve seen both extremes, and we get why those extremes happen. Making patch management part of your IT strategy (and cyber security plan) is a great idea, but there is an interlocking set of challenges when it comes to time, scale, testing, and uptime/business continuity.

Why Is Patch Management Important?

The importance of patch management cannot be overstated.

Software patches are a fact of life in any software environment: They are necessary not only to fix bugs post-release, but also to close security gaps and exploits that are discovered. In fact, most patches today are more about security than functionality.

Now consider, for a moment, just how many patches are needed in an enterprise environment. Operating systems and typical desktop apps will need patching, of course. But so will servers, routers, firewalls, and other pieces of network infrastructure, as well as websites and website apps. Laptops and mobile devices, too, need consistent patching. Very quickly, the number of patches required on a consistent basis becomes unmanageably huge.

Installing a patch requires a process, too, to guarantee success. It is not unheard-of for a faulty patch to prevent a critical application from functioning. When this happens to a single end-consumer, it’s frustrating. Now imagine it happening to, say, your entire finance department. Those kinds of scenarios make testing and deploying patches a critically important part of patch management as well.

The Biggest Challenge in Patch Management

Ask a room full of IT experts “Who here has mastered patch management?” and you are more likely to see people rolling their eyes than raising their hands. This is because patches can be a source of grief for system admins.

An admin’s biggest fear when installing a patch is that the patch will be installed, the server or workstation will be restarted, and then…. Nothing. The machine either won’t come back up, or will have issues when it does. This will mean further testing, and so further downtime—and more end-user frustration.

Nobody likes it when IT comes to “fix” or “improve” a machine, only to have it stop working. That fear is the #1 reason folks don’t upgrade to begin with.

Now we can see the dilemma this presents. On the one hand, patching is important for fixing vulnerabilities and keeping all machines current and set to a standard configuration. On the other hand, the fear of downtime and “bricked” machines keeps organizations from deploying updates.

Which is too bad, because most attacks exploit old, unpatched vulnerabilities that have been known for years. The attacks work, because organizations are not staying on top of those patches.

Why Automate Patch Management?

A colleague of ours compared patch management to wearing a hard hat at a construction site: It’s not comfortable, fun, or sexy. In fact, it can seem inconvenient. And it doesn’t even contribute to the building getting built. But you do it every time on the off-chance that something really bad happens.

Patch management can be the same way. In an enterprise context, it’s already a time-consuming process. (We once did work for a client where 20 different individuals had full-time patch management responsibilities!) Add in the need for regression testing in a timely manner while keeping service up for users, and it makes patch management a daunting proposition.

Chances are it isn’t the best use of your IT staff’s time, either. Though important, the actual process of installing and testing patches is rather routine and mundane. It’s risk mitigation, but all that time spent on it prevents people from working on strategy or innovative initiatives.

There is good news: Patch management itself does not vary much from industry to industry, or environment to environment. Once you know the best practices and have refined the process, it can be automated and deployed easily.

For example, here at Model we’ve developed a standard cycle for deploying and testing patches in any environment:

• We start with a “smoke test,” installing the patch on low-priority servers or endpoints so we can see the patch in action, provide feedback and/or mitigation, and so on.
• We then deploy on a pilot group of actual users for 1-3 weeks (depending on your risk tolerance vs. patch testing policies). This group will cross-cut different teams and departments. That way, we can see the new patch function in many different cases during actual use.
• If all looks good, we then help construct an automated roll-out, watching for problems along the way.

The Patch Management cycle, courtesy of Wikipedia

In many cases, if the needed business rules are defined and ready to put into place, our automated patch solution can be deployed in about an hour, with patch deployments themselves taking no more than a week.

The best part: By automating the process, your staff no longer has to manually babysit the patch management process, freeing them to do other, more strategic and profitable things. Business continuity can be maximized even while vulnerabilities are addressed.

Of course, we don’t want to reveal everything that goes on with our automated process. IP and all that. But, if you have further questions, please reach out and I would be happy to discuss.