Patch management enhancement tools and best practices

For patching server and workstation systems, nothing gets me irritated more than simply being informed that this update needs to be installed on a system. Pick your flavor of irritating package, we all have them. Mine are Java runtime engines, Adobe Flash and Reader, Windows pick of the litter, and SQL Server updates. While it isn’t impossible to maintain and automate updates on systems, administrators are challenged when it is more complicated than just updating everything.

Vendor requirements, test cycles, application dependencies and other factors can make the patch management process more complicated than it may look. What can administrators do about this? The most important first step is to have a collection of automation tools in place. What tool is in use can be part of the problem, however. This is primarily driven around the central assumption that system management software can do more than just determine what needs to be installed and push it out.

There will always be a collection of systems that can take all updates all of the time. Those are relatively straightforward to support and can possibly even be managed outside of a systems management package. Automatic Update configuration locally or through Group Policy as well as individual application configuration may do the trick for the majority of Windows systems. Note: Be sure to check my earlier tip on how to patch Windows Server Core.

Now, many people may just say what more needs to be done than apply all applicable updates? Enter the tightrope dance between facilitating software vendor requirements that may say a certain patch or major service pack is not supported and internal security scans saying that a system is vulnerable to a specific risk.

I recently saw that a new feature for QualysGuard Vulnerability Management appears to do a good job of reporting what updates need to be applied to a collection of systems to address specific issues, rather than install simply because it is not installed. This can reduce the application of unnecessary updates as well as minimize precious downtime. This new feature is called Patch Report, which can identify what systems are in need of which updates based on your own criteria. Patch Report isn’t a deployment mechanism, so it won’t do the work that the systems management packages will need to do.

System management packages such as Altiris, Microsoft System Center, ZENWorks and other packages are still useful to enlist the dirty work of getting patches to a system, but they may frequently lack the ability to get reporting on the vulnerabilities rather than the broad patch inventory.

Patch management can also be made better by providing scripted installations of the updates. With system management software, a package can be created to deploy the specific updates required to address a list of vulnerabilities yet reduce downtime and maintain application support. This would be a little more labor intensive and would require very well defined organization of systems in a tool such as Active Directory.

For very highly controlled environments, updates may not be permitted unless they address only the most critical vulnerabilities. Hopefully this inventory is a small number of systems, but the update process in this case may be best served by doing manual updates from an organized list.