Deployment

Once you have determined which patches need to be applied, and which systems they need to be applied to, the next step is to deploy those patches to the affected systems. In recent years a number of commercial solutions have emerged to provide both an automated discovery and deployment capability. Before deployment can be planned, it is important to ensure that patches have been adequately tested in a preproduction environment.

Patch Testing

Installing new security patches introduces a new risk to mission-critical systems. Oversights or the introduction of new bugs into a patch can lead to unexpected downtime and result in significant financial losses. As a result of this risk, some organizations delay the installation of security patches as long as possible until it is absolutely necessary. Even worse , others defer the installation of a patch indefinitely, preferring to risk infection rather than to incur downtime.

In order to mitigate the risks associated with installing new patches, testing should be performed on nonproduction systems in order to ensure that no adverse side effects will result. In a perfect world, test systems would exist for all production systems to facilitate the full parallel testing of patches prior to their deployment. In reality, however, few organizations could justify such a deployment. Such a configuration may be chosen for mission-critical systems, where an unexpected failure from a buggy patch will result in a substantial business impact. The criticality of these systems must be weighed in order to determine where this may be appropriate.

When deploying a test network, the applications should match the production environment as closely as possible. In some cases, where a dedicated test system is not available, a redundant or failover production system may be used instead prior to deployment on the primary production systems. In either case, the testing of patches on mission-critical production systems is strongly advised.

Scheduling

Like traditional software deployment, the installation of patches must be scheduled accordingly . Many organizations have, for example, developed procedures around Microsoft's "patch Tuesday," in reference to the second Tuesday of each month on which Microsoft releases their monthly patch updates. As such, resources can be allocated in advance to prepare for testing, planning, and deployment.

Scheduled patches from major vendors like this provide consistency in an otherwise chaotic environment of unexpected patch releases. Other vendors should take heed. Unfortunately, scheduling patch releases like this is not always an option when vendors are faced with emergency patches to protect customers from severe, high-urgency threats.

In order to schedule patch installation appropriately, organizations must look at a number of operational areas to determine the best time at which to schedule deployment. Ultimately, these factors must be based around the business requirements of the organization and the availability requirements of the organization's IT infrastructure. Also, the criticality of particular patches must be taken into account in order to prioritize individual patches when faced with multiple possibilities. This prioritization should be combined with an organization's asset database and the criticality of individual assets to be protected.

Ultimately, organizations should have measures in place for the deployment of both scheduled and nonscheduled patch releases, and for critical and noncritical patches.

Patch Distribution

The final step involved in the vulnerability and patch management process is the actual act of rolling the patch out across your organization. For many, this is the single most costly and resource- intensive effort. As a result of the pain involved in accomplishing this, a number of commercial patch deployment solutions have surfaced. In addition, vendors have increasingly suggested that patch installation become an automated activity, relying on internal operating system capabilities in order to keep a given system up to date (Windows Update, for example).

Microsoft Windows

For the Microsoft Windows environment, organizations have a number of options that can be used to deploy patches. These include options provided directly from Microsoft, as well as third-party vendors. Microsoft offers two solutions that can be used to maintain patches on individual computers, as well as across your organization. Since these solutions are provided free of charge, it is certainly the most attractive for those with limited budgets .

The most transparent solution available is the integrated Windows Update functionality. Included standard with all current Windows releases, Windows Update provides an automated mechanism that can be used to keep systems up to date. Windows Update currently supports Windows 98, Windows Millennium Edition, Windows 2000, Windows XP, and Windows Server 2003. Unfortunately. Windows Update is useful only for keeping individual computers up to date and not effective for the management of patches across an organization, especially where patch deployment must be carefully calculated to avoid impacting critical IT systems.

From an enterprise perspective, Microsoft's current solution is offered in the form of their Software Update Service (SUS). SUS is a version of Windows Update designed for organizations that want to approve each software update before installing them. SUS allows administrators to quickly and easily deploy Windows- related security updates and critical updates to any computer running Windows 2000, Windows XP Professional, or Windows Server 2003 systems. SUS includes the following capabilities:

Software updates can be approved on each SUS server, enabling testing in a separate environment as well as phased deployments across an enterprise.
SUS clients , which are the same as the Windows Update component described earlier, can be configured to download software updates from the SUS server (saving bandwidth on shared Internet connections), or directly from Windows Update.
Software updates can also be copied onto a CD-ROM from an SUS server connected to the Internet, and then transferred to an SUS server in a protected network with no Internet access.

Future versions of Software Update Service, to be known as Windows Update Services, will continue to expand on their core functionality and simplify patch deployment for Microsoft Windowsbased networks.

Virtual Patching

Virtual patching, sometimes also called vulnerability shielding, involves the protection of information systems by blocking any attempt to exploit a vulnerability, rather than patching the core vulnerability itself. Virtual patching can serve as a short-term workaround to avoid the deployment of the patch itself, but it should be treated as just thata short- term workaround.

Virtual patching can be performed at several different levels, and can also involve several different actions. Both network-based and host-based intrusion prevention systems commonly tout virtual patching as a function of their products. Virtual patching can consist of the following capabilities offered by these products:

Preventing the exploitation of network-based vulnerabilities at the perimeter by blocking the associated attacks.
Preventing the exploitation of a vulnerability on a host system by blocking the attack on each particular endpoint.
The implementation of automated workarounds, such as disabling of specific vulnerable operating system components until a patch is installed.