Patch management is a time-consuming task that affects all desktop administrators. While it is exciting that vendors...
are identifying and fixing security vulnerabilities, an increasing number of patches across all operating systems and applications can make the patch management process chaotic.
Check out the following seven steps for structuring patch management.
The key to patch management is to be informed constantly about the latest security patches. But how do you know if a new patch is available from a vendor?
Staying up to date on third-party vendor patches requires a little more work. While some vendors have an email alert service, others require you to regularly browse their websites.
Here is a list of vendor websites to start with:
- Research In Motion's BlackBerry
- Real Networks
- Red Hat (Receive alerts by RSS and email.)
Before you can patch your systems, you need to know what types they are and the applications they're running.
Make sure to consider the following machines:
- Domain joined systems
- Nondomain joined systems
- Frequently disconnected systems (such as laptops)
- Online virtual systems
- Offline virtual systems
After identifying your systems, determine which systems and applications are vulnerable and need patches. This can be done by examining registry keys, file versions and running services. Microsoft Update and Windows Server Update Services (WSUS) use a combination of these techniques to perform patch assessments. If evaluating third-party software, you may need a third-party patch management tool or to write your own scripts.
There are two types of patch assessment engines: agent and agentless. When determining which engine to use, consider the following:
Agents: Great for assessing frequently disconnected systems like laptops. The agent can be "set and forgotten," meaning it'll keep operating without much hassle. On the other hand, you may not wish to install an agent process on some of your systems.
Agentless: Remote patch scanning doesn't require agent installation and is great at identifying overlooked systems -- like that unmanaged, unpatched Internet Information Services server sitting under your desk!
After identifying the patches that need to be deployed and the systems they need to be deployed to, prioritize the installation of each patch.
A companywide patch task force is a good place to start. Include members from a variety of departments, including power users, network admins, auditors and the IT staff. Discuss each security bulletin and patch, and determine how critical a patch is the organization. You should review the vendor-provided severity rating, but remember to modify this for your business. For example, Microsoft rates denial-of-service attacks as "low severity." However, your business may require 100% availability. Therefore, you may rate patches that address denial-of-service attacks as "critical."
Determine which patches should be installed on which machine and in what order. Critical patches may be selected for installation within three business days, whereas moderate- or low-severity patches may be installed quarterly.
The next step is to obtain the patches from the vendor websites.
This used to be a simple task, but it has become much more difficult in the past few years. Today, multiple patches may exist for one vulnerability, including patches for different versions of an application, different operating systems and different platforms (x86 vs. x64). Make sure to download all necessary versions of each patch and label accordingly.
In addition, verify that the patches are from legitimate websites and are fully downloaded. Since many vendors digitally sign their patches, simply right-click and view the properties of the patches, and look for the "Digital Signatures" tab. If this exists, the patch has been fully downloaded and is signed, so there's less of a chance that it is a Trojan horse.
In addition, make sure to place the downloaded patches in a secure, central location. You don't want your patch repository hacked and replaced with the very pieces of malware that you're trying to protect your systems against.
After you've done your planning and downloaded the patches, it's time to get them installed.
First, determine the installation switches for each patch. Patches for one operating system may use different command-line switches than patches for another OS, and switches for application patches may be entirely different from those used by OS patches. And third-party patches may use an entirely different set of switches.
Review the vendor documentation to understand the installation commands, but remember that the documentation may not always be up to date or correct. You can always execute the patch binary from command line and try "/?" or "/help" to display a list of available installation switches.
One of the trickiest parts about patch deployments is determining how to handle any required system reboots. If multiple patches are being deployed at once, you may wish to use "no reboot" install commands so that they don't reboot the system. Once all of the patches are deployed, schedule a system reboot for an appropriate time.
Patch deployments can be a time-consuming and tricky process, but there are many patch management applications that can help. PatchManagement.org includes a link to many popular patch management products.
You should then verify that all of the patches were properly installed.
Even though a patch was executed on a system, a variety of factors may have prevented a successful patch installation. Perform another patch assessment to ensure that the proper files and registry keys were written to each system.
And don't rely on registry keys alone to verify proper patch installation. Registry keys are a point-in-time indicator and don't reflect the current state of the files on the system.
Deployment of a patch is only half the battle. Reporting to management on the current patch state of the enterprise is equally important. Patch reporting may also be required for regulatory compliance and reporting depending on your industry.
Create status reports that show which machines are missing specified patches according to the severity you've assigned. In addition, a strong patch-reporting system should include audit trails that show which patches were installed to which systems at what time and who installed each patch.
Managing the patch process for an organization can be a daunting task, but the above steps can help provide some structure to this otherwise unwieldy process.
For additional patch management tips, subscribe to the PatchManagement.org mailing list or check out the white paper, "Essentials of Patch Management Policy and Practice."
ABOUT THE AUTHOR:
Eric Schultze is an independent security consultant who most recently designed Microsoft patch management solutions at Shavlik Technologies. Prior to Shavlik, Schultze worked at Microsoft, where he helped manage the security bulletin and patch-release process. Schultze likes to forget that he used to work as an internal auditor on Wall Street.