Security Patch Management

A standardized patch management process reduces the incremental costs of patch deployment. You can afford to deploy patches with hard-to-quantify risks when your patch management process is well-designed.

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 exploit code 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, worms make no money.

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.

Pre-patch announcement tasks:

1. Identify your mission critical applications.
2. Assign a patch testing team to each mission critical application.
3. Each patch testing team needs their own compatibility test script.

Patch announcement tasks. On patch Tuesday:

1. Have each patch testing team install the patches on test environments and go through their test scripts to determine application impact. Set a deadline for a response; perhaps Friday of that week. Require a pass/fail response, either “no compatibility issue found” or “compatibility issue exists.”
2. When all patch testing teams report “no compatibility issue found,” follow your change control process.

Your change control process includes:

• Identify affected systems.
• Is a restart required?
• What is the roll-off, recovery or uninstall plan?
• What is the time frame for this change, and has this time frame been communicated to affected parties? (Identify any schedule conflicts.)

SearchMidmarketSecurity.com has a series of articles by Felicia Nicastro describing the security patch process:

Step by Step: Best practices for security patch testing and management

1. Introduction
2. How to prepare for security patch testing
3. Security patch testing and deployment phase
4. Security patch validation and verification

I prefer to begin testing before scheduling the deployment. You want to know that this mitigation measure is not detrimental to mission critical applications before committing to it as a mitigation measure. Testing in a test environment should be part of the patch evaluation.

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.

There is a reluctance to deploy patches. Fight that reluctance. The view may be “our testing wasn’t rigorous enough.” Then improve the test scripts. The view may be “it ain’t broke.” That’s simply denial, the belief that because no one has actively complained it doesn’t need attention. It is broke, it needs fixing, get on it.

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. Secunia (and its Corporate Software Inspector (CSI) software) offers patching of third-party applications through WSUS.

Network equipment, too. Cisco Router Assessment Tool (RAT) or nipper.

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.