Patching Windows with SUS

Everyone remembers the Code Red worm that invaded the Internet last summer. The worm exploited a hole in Microsoft Index Server, a component of most Microsoft IIS installations. Although this worm and its offspring—Code Red v2 and Code Red II—carried a relatively benign payload, they caused tremendous damage in terms of system downtime as administrators scurried to isolate networks and patch systems. This worm's extremely rapid infection rate of more than 350,000 hosts in less than 14 hours was eye-opening.

Ironically, Microsoft patched the vulnerability exploited by this worm a full month before the outbreak. Two months later, the Nimda virus broke out with similar fury, and containment response was much more effective. But once again, well before the outbreak, Microsoft had already released an update that fixed a hole through which this worm burrowed.

No similar large-scale outbreaks occurred for a long time in the aftermath of these wake-up calls (excepting email-based viruses such as Klez and Bugbear). Administrators seemed to increasingly understand the need to regularly patch their systems against known security vulnerabilities. Then, on January 25, 2003, the Slammer worm tore through the Internet, exploiting a Microsoft SQL Server 2000 vulnerability that had been patched 6 months earlier, in July 2002. Again, we were lucky that the payload didn't damage infected servers. However, the Slammer worm created an extremely effective denial of service (DoS) attack that in some regions brought the Internet to its knees with cripplingly slow Web site response times and even caused some ATM machines to fail.

Microsoft has expended considerable energy to launch and publicize its Get Secure, Stay Secure campaign, providing first a security toolkit and more recently a security resource page (http://www.microsoft.com/security/articles/security_resources.asp) that contains up-to-date versions of patch-detection and security-assessment tools. Microsoft also maintains a popular HotFix and Security Bulletin Service Web site (http://www.microsoft.com/technet/security/current.asp) from which administrators and end users can obtain up-to-date warnings and threat assessments.

Thanks to new patch-management systems from Microsoft, patching holes consistently across many machines has become much easier. In particular, small to midsized companies will appreciate the quick and relatively transparent capabilities of Microsoft Software Update Services. SUS regularly and automatically distributes critical OS updates from Microsoft and provides one point from which Windows 2000 Service Pack 2 (SP2) or later clients can fetch applicable updates. (SUS doesn't update service packs, but you can use the built-in Win2K Group Policy software distribution to do so.) Best of all, Microsoft provides SUS as a free download.

Prudent Patching
Effective patch deployment requires that you keep a few key questions in mind. Does the patch apply to your system? Is your system vulnerable to the problem that the patch addresses? Will the patch work with your service pack or application version?

Today's patch-management tools address many of these questions. However, you need to remember that patching a system effectively changes the way your OS or application works. Therefore, you should always test deployment of any new update in a nonproduction test environment before applying it to your production machines. Set up test and production SUS servers to permit a phased rollout of patches to subsets of machines so that you can perform such testing.

To triage new updates and help balance deployment schedules with adequate testing, consider adopting a patch-applicability review board. Decisions that this board makes should help you decide whether to apply a given patch today or during the next regularly scheduled update window.

What's SUS?
SUS provides a centralized method for deploying critical Microsoft updates to Windows XP and Win2K SP2 client computers. SUS leverages the client-update technology from XP's built-in Windows Update and adds improvements—such as centralized configuration, an update-approval process, and inhouse deployment capability—that are beneficial to corporate deployments. When you use inhouse deployment, your company downloads an update once from Microsoft, then your clients download the update from an inhouse location. This feature requires sufficient storage space for all approved critical updates but reduces network load.

SUS is a client/server application. The SUS server component runs on Win2K SP2 or later and requires IIS. You must install Automatic Updates 2.2 or later client software on SUS clients. An SUS-enhanced version of Automatic Updates comes with XP SP1 and Win2K SP3. Alternatively, you can use a standalone installation program—available from Microsoft at http://www.microsoft.com/windows2000/downloads/recommended/susclient/default.asp—to install this version separately on a Win2K SP2 or later machine. Consider using Active Directory's (AD's) IntelliMirror features, or a deployment application such as Microsoft Systems Management Server (SMS), to deploy the service pack or Automatic Updates client.

The deceptively simple SUS concept will probably be popular in the intended market of small to midsized organizations that don't have sophisticated reporting or client-targeting needs. (Larger organizations that require more comprehensive update management should consider Microsoft's newly released SMS 2.0 Software Update Services Feature Pack.) The SUS server maintains a synchronized catalog of Microsoft-obtained updates and pushes these updates to subscribing clients in your organization. The first synchronization takes a while because the SUS server must download all critical updates from the Microsoft Windows Update server, as Figure 1 shows. Subsequent scheduled synchronizations complete much faster because the software downloads only updates that are new since the previous synchronization. You manage the SUS update server through an IIS Web-based interface (by default, http://susserver/susadmin). From this interface, you can review and approve each update intended for the SUS client base.

Configure SUS Clients with Group Policy
The Automatic Updates client on each computer checks regularly with the SUS server for approved and applicable updates, then obtains the updates and installs them according to that client's settings. You can configure client settings such as whether to automatically download and install updates or prompt the end user to approve each update in each client computer's registry; however, most organizations will appreciate the capability to use AD's Group Policy to centrally configure the Automatic Updates client.

On a computer that has SUS-enhanced Automatic Updates installed, go to the Microsoft Management Console (MMC) Group Policy snap-in and expand the Computer Configuration node. Right-click Administrative Templates and click Add/Remove Templates to load the new Windows Update administrative template (%windir%infwuau.adm). Next, expand the Computer Configuration Windows Components node and select Windows Update to display the two new SUS configuration items. Edit the properties of the first item, Configure Automatic Updates, to specify the folder location, notification parameters, and schedules of automatic updates. For example, you can notify your users when updates are ready for installation or you can schedule automatic installations. In the second item, Specify the Intranet Microsoft Update Service Location, define the location of the SUS update server (e.g., http://susserver) and statistics server that you want clients to use. The statistics server collects SUS update report data. You can set both to the same server; however, you might want to configure a separate statistics server to handle reporting from multiple SUS update servers (e.g., for different geographic offices).

SUS Reporting
SUS reporting consists of recording client-update downloads to a standard IIS Web log on your specified SUS servers (by default, these files reside in %systemroot%logfilesw3svcx). Unfortunately, SUS offers no predefined reports or any type of data aggregation or other summary-level reporting to convey your organization's patch compliance. You can, however, troll the logs to determine whether a specific machine has requested a specific patch.

After you configure Group Policy, refresh the policy on a client and verify the SUS settings. Open the Control Panel System applet and select the Automatic Updates tab to review a client's settings. Figure 2 shows a client configuration in which SUS automatically downloads and installs approved patches every Saturday at 4:00 a.m.

To begin deploying updates, you don't need to perform much additional SUS configuration. This simple approach to patch deployment will be welcome news if you've ever manually installed multiple patches. (New Microsoft Internet Explorer—IE—updates typically include three separate patches for IE 6.0, IE 5.5, and IE 5.0, and your installation logic must check the version and push the appropriate update.) SUS transparently handles patch management for you, ensuring that the appropriate clients get the correct version of an approved patch.

Configuring SUS Server Options
You can configure your SUS clients to synchronize their updates (and, optionally, approved items) from another local SUS server or directly from Windows Update servers. Doing so helps you scale SUS and offers a good solution for placing SUS servers in multiple offices. For example, you can configure a master SUS server at corporate headquarters to pull its catalog from Microsoft, then configure child SUS servers at satellite offices that pull their catalogs from the corporate SUS parent. Such a configuration eliminates the need for each SUS server to be connected to the Internet. However, at least one SUS server must have Internet access to communicate with the Windows Update server.

Update Testing and Targeted Distribution
If you want to use SUS to roll updates to a set of test servers before rolling out to a wider production set, you must install multiple SUS update servers. (Alternatively, you can save updates to a local machine and manually install them for testing; however, this solution doesn't use the SUS deployment mechanism.) If you use multiple servers, be cautious when sharing existing IIS servers with SUS because SUS runs IIS Lockdown on installation, which might cause the failure of other Web applications on a shared server.

After you finish configuring your SUS servers, separate your test computers from your production computers by placing them in different AD organizational units (OUs). Configure an OU Group Policy to point the test OU computers to the staging SUS update server and the production OU computers to the production SUS update server.

Service Packs
The current version of SUS doesn't support the deployment of service packs. However, you can use AD's Group Policy and IntelliMirror software-distribution features to install XP or Win2K service packs. You can define Group Policy software installation for computers or users, commonly at an OU level. To deploy a mandatory software update such as a service pack to every machine regardless of who's logged on, you assign the software to the computer, as Figure 3 shows. Group Policy software installation supports Windows Installer (.msi) files, which come with most current service packs and other Microsoft corporate products. To verify or troubleshoot installation at the client, you can review the Application event log for a failed or successful Application Installation message.

Security Cornerstone
Patches and patch-assessment tools aren't designed to provide full protection from viruses, intrusions, and all malicious activity. For the best protection, you should consider deploying a multilayered defense that incorporates competent niche products that address specific threat vectors—for example, antivirus software on every desktop and mail or Internet gateway, an intrusion-detection system, and vulnerability scanners. Without a doubt, you should consider the elimination of known vulnerabilities from your OS and applications a cornerstone of your security foundation.

Keeping your software up-to-date is more important than ever. After you get SUS running, you'll be able to maintain a current and applicable set of patches for all new production machines. Update scanning will occur regularly, and approved patches will automatically flow to machines. This consistent and methodical approach will help ensure that new systems introduced into your production environment months after a flurry of patching will instantly be at the same patch level as their peers.