Patch Management 101

 Author: Jeremy Taylor, JTaylor@jackhenry.com 

Patch Management has become a dirty word in the IT industry. That’s mostly because keeping systems updated with the latest patches and security fixes can be a daunting chore. And then when you feel like you finally have a handle on it, here comes an auditor who says otherwise. I’d like to take a look at what some of the common deployment structures look like and what you can do to avoid the dreaded “failed audit.”

First let’s focus on the basics. What does it take for a patch to be deployed to an end point? First a security risk must be identified. This is usually discovered by software and operating system manufacturers like Adobe or Microsoft. Once the risk has been identified, manufacturers will work to develop a small installation package to fix or “patch” the issue. Those packages are then published on the manufacturers’ web sites and made available to the masses. At that point, it is up to you to obtain those packages and install them onto your systems.

There are many methods for deployment available at this point. You can manually install the patches on each device yourself, purchase software to manage the process for you, or outsource the project to a third party who can manage the deployment process from their systems. Each of these methods has its pros and cons, but they all serve the same end goal, which is to patch the machine, fixing the vulnerability. It’s important to understand the differences in these methods and where each falls a little short so you can be prepared to fill in the gaps and ensure your system is up to date when auditors come knocking.

Let’s start with the first method, manual deployment. This provides the ability to be extremely granular with each end point and ensure all updates from all packages are maintained. The downfall, of course, is that the time it takes to manage even a small organization in this way can be astronomical, making this a rather impractical option.

The second option of managing the process in-house is to purchase and maintain software that will automate the chore of patch management. This provides a central management platform and prevents the need to visit each machine individually. The downside here is the cost and knowledge needed to maintain this system on your own. Plus, if you aren’t performing your own testing, it’s very possible that a bad patch will slip through the cracks and could wreak havoc on your network.

The third option is outsourcing the entire process to a third party. This way they can be responsible for the patch testing, deployment, and remediation of issues that arise. The downside to this process, however, is that they will not be as intimately familiar with your environment as you are and thus don’t normally have the same time to spend scrutinizing your network. Ensuring that you keep the lines of communication open with your patching vendor can help to alleviate these types of concerns. One example of this would be to give your provider ample time to help you prepare for an upcoming audit and notifying them when changes occur on your network, such as adding new machines or decommissioning old ones.

In order to keep your network as up to date as possible, you should ensure the endpoints being patched are constantly available to receive patches or they could easily fall behind. Policies should be put in place to ensure machines are left on at night. Many patches require reboots which are best performed at night while no one is using the system. A lack of reboots can cause other patches in the queue to fall behind, resulting in machines that are vulnerable.

Finally, it’s important to be diligent with your reporting. Whether you invest in your own product or outsource the task to a third party, you should be able to parse through a number of reports that detail exactly what is happening in your environment in regards to patch management. Good reports should include things like patches deployed, patches outstanding, common patches missing, a general overview, and system downtime detected. Some reports may also specify when new machines are detected and when others drop off. Reports can be the best way to ensure the patch process is performing as expected and help to highlight areas of your network that may require more effort.