Patch Management

Patch Management

August 26th, 2008
By James Voorhees

Many of the security risks that you and your organization face can be reduced if you patch your systems regularly. This can be expensive and time-consuming. It can also be difficult, as each operating system, each application can require its own set of patches. The more complex your IT environment, the more complex patch management becomes.

Yet the costs of not patching can be higher. If a system becomes infected, employees who rely on it will unable to do their work. Customers who use it will be unable to get the information they seek or buy the goods or services you offer. That will affect the organization's reputation. Even worse things can happen. Your intellectual property can be stolen. You can be sued for not exercising due diligence in protecting your resources. In addition, there are the costs in time and money of cleaning up after an infection. These, too, can be high.

Patching should be a regular part of conducting business. Indeed, patch management should be as standard a process as billing and payment. Like billing and payment, the procedures should be written out and followed scrupulously. Also like billing and payment, the people needed to carry out the procedures must have their roles and responsibilities clearly defined.

To manage patching adequately, you need to know what needs patching. An organization just establishing a program needs to identify the systems that need to be patched. If an organization already has a patching procedure,, the list of such systems needs to be updated regularly. The list should be prioritized according to the value of the systems to the organization and the risk that they will be compromised.

How to patch critical systems can be a contentious question. These systems often need patching most, but get patched least because of the costs of taking them offline and the risks that a patch will interfere with their operation. Testing can help minimize those risks. The costs of taking the system offline can be reduced by patching only during off-hours—at 3:00 on a Sunday morning, for example. These costs are also one argument for using redundant systems, so that one system can remain live while the other is patched.

Once you know what needs to be patched, you can find out what patches are needed. Most vendors have established ways to notify their customers when patches come out. Some vendors, like Microsoft and Oracle, issue patches on a regular schedule. You should also be aware of patches issued out-of-cycle, to combat an urgent threat. Web sites and mailing lists that publish information about updates and vulnerabilities that will require patches can also be consulted. These include Bugtraq, SecurityFocus, and patchmanagement.org.

Once you know what to patch, you can determine how to do it. There are essentially three steps to doing this: getting the patch, testing it, and deploying it.

Getting a patch and installing it on a single system can be done manually, and most vendors have tools that make this easy. Microsoft's Windows Update is one example. Sun has smpatch for Solaris, RedHat has up2date, and Debian/Ubuntu Linux has the apt application. This can be practical for small organizations or for small numbers of a particular application.

For larger numbers of systems, however, patch management needs to be centralized. Microsoft has WSUS and SMS Server to help patch its own products.[1] If the network includes other systems, however a third party product may be needed. Vendors that provide these include Ecora, PatchQuest, and ManageSoft.

These products will help download and deploy patches. Testing requires its own tools and procedures. How much testing is done varies widely by the resources available in an organization and the criticality of the system.[2] For some, it is enough that a system successfully reboots; for others, extensive test scripts run in a test environment are essential.

Once the tests have shown that the risk of applying a patch is minimal, it can be deployed and installed using the tools and procedures established for that. Those procedures should include proper notification of those affected before the patch is applied and proper documentation of the change after it has been installed. They should also include a procedure for backing out of a patch in case something goes wrong. Lastly, it is good practice to verify that patches were installed, particularly when a large number of systems are affected.[3] That can be done as part of a regular vulnerability assessment program.

1. Microsoft, "Update Management Process"
http://www.microsoft.com/technet/security/guidance/patchmanagement/secmod193.mspx

2. Jason Chan, "Essentials of Patch Management Policy and Practice,"
http://www.patchmanagement.org/pmessentials.asp.

3.BITS Financial Services Roundtable, "Patch Management Best Practices for IT Practitioners
http://www.bitsinfo.org/downloads/Publications%20Page/bitspatchmgmt2004.pdf