Security Patch Management

When security patches are released, expect them to be reverse engineered. Expect an exploit of the vulnerability to become available, if it isn’t already. That is, “is exploit code publicly available?” is not an important question. Act as if it is available.

“Is this vulnerability wormable?” is not an important question, either.  Worms were dramatic and news worthy, but worms are rare. It makes very little sense to develop a worm; there’s no money in it. Unauthorized access to information, information gathering makes money. Worms make news, worms get addressed.

You want to know if your mission critical systems are in jeopardy. Can your data be stolen or corrupted? Where is your data? What would be required to reach it? Check the Open Source Vulnerability Database for additional information about the vulnerabilities being mitigated and their potential risks. Any software vulnerability should be addressed quickly.

Plan for the spikes that your support team will go through. For example, you may not know how many patches Microsoft will release on the second Tuesday of the month  but you know that patches will be released. Identify your mission critical applications. Assign a patch testing team for each mission critical application. Each patch testing team needs their own test script. On patch Tuesday, have each team install the patches and go through their test scripts to determine application impact. Set a deadline for a response; perhaps Friday of that week. Require a response, no compatibility issue found or compatibility issue exists. Follow your change control process.

For non-Microsoft patches, the notification process is less straightforward. Subscribe to the Secunia notifications to and any specific vendors you require. Encourage your vendors to adopt an announcement cycle. Don’t accept “when required” or “as needed” as responses. While they are caught by surprise when vulnerabilities are found, that unpredictability can be managed for their customers in all but the most troublesome of vulnerabilities.

Review your exposure, there’s some exposure but mitigation could be more expensive. Patch installation should never be your only mitigation measure, but it is always an important one.

Proposed tools:

VMware Update Manager to patch ESX, VM Operating Systems, and many applications. VMware Update Manager takes a snapshot of the system before the patch is applied, providing you with a roll back mechanism.

A virtual host is as secure as its least secure guest environment. Do not think that patching the host environment replaces patching of guest environments.

Linux tools: Cfengine, bcfg2, Puppet, Spacewalk for Fedora and CentOS; Red Hat Satellite Server for Red Hat Enterprise Linux.

Microsoft WSUS or Microsoft SCCM for Windows environments, but you’ll still need to address the non-Microsoft applications (such as Sun Java and the Adobe products). SCCM can be used to update any Windows application, with sufficient effort. Bigfix may be more appropriate.

It is best to not rely upon reports from your deployment tool to evaluate your patch deployment status. You are measuring how effective your deployment is. Don’t rely upon the deployment tool to tell you how well it has done its job. If it missed a target environment for deployment, expect it to miss it for evaluation as well.