Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Maintenance Strategies for Patch Management

Patch management should be a part of your organization's formal change control process but should have its own set of rules and processes. Patch management should be defined separately because it is much more time-dependent than most change requirements. A new software upgrade often has some flexibility in its implementation plan. However, an announced vulnerability is often followed by an attack that uses it. The timeframe allowed for the application of security patches is the time between the patch availability and the attack. However, no one knows when an attack will occur, and the timeframe is getting increasingly shorter. Patch management should include processes to update all servers, devices, and applications on your network; however, the tools described here are native Windows tools that can be used to update Windows Server 2003.

Patch Management Process

Many products and software processes can be used to update Windows Server 2003 with security patches. However, the process of patch management is not just patch application. The process of patch management can be split into three steps:

Monitor

The first step is gaining knowledge by monitoring security sites and lists. Sign up for Microsoft security bulletins at Chapter 18.

Evaluate

Whether or not you should make a change or apply a patch is based on a number of factors, including your organization's policy on security maintenance. In general, the decision of whether and when is based on evaluating the following issues:

Does the security issue apply to your systems? For example, a change that should be made to Windows 2000 systems is of no concern if Windows 2000 computers are not part of your network. Nor is change for Microsoft Office of interest to you if your only responsibilities are Windows Server 2003 servers, unless these servers in some way are responsible for the security of desktops that run Microsoft Office, such as if Group Policybased Microsoft Office administrative templates are used to assist in the lockdown of Office applications, and the modification is related to those administrative templates. Any reported Windows Server 2003 operating system vulnerabilities and applicable patches or configuration changes, however, must be evaluated.

Will the recommended change or patch cause other problems? The change, for example, may recommend disabling a specific service. However, you may rely on that service for critical operations. There is also no guarantee that a patch will not cause a new problem or issue. Although patches are thoroughly tested, it would be impossible to guarantee that no conflict or possible problem will result from the application of the patch. To determine if a patch is safe for use across all servers, test them on servers configured in the same manner.

How immediate is the need for the patch? In most cases, the announcement of vulnerability is based on research into the possibility of an exploit, not the existence of attacks in the wild. This means that although there is a need to respond, there is time to evaluate, test, and make the change as part of a regularly scheduled change process, instead of a knee-jerk reaction. In addition, many recommended changes or patches will be rated and a distinction made between a critical patch that needs to be made quickly and a patch or change that has less immediacy.

Zero-Day Attacks

A zero-day attack is one in which the attack code is used to attack systems either before or on the same day that the vulnerability is announced. A patch may or may not be ready. Therefore, there is no time to test a patch. The risk of possible patch issues must be weighed against the risk of a successful attack. The risk may be mitigated by other security practices.

What additional protective measures or workarounds can be put into place? In many cases, firewalls can protect systems from an external attack. This does not mean that the recommended change or patch should not be applied; instead, it means that the other protection can buy time while the change is appropriately researched.

In addition to these considerations, if it is decided that the patch should be applied, before you apply it in a production environment, test its application and function on test computers configured similarly to your production systems.

Act

Patches and changes always will need to be made before any action is required, although you should determine how the changes will be made and put into place in any necessary infrastructure. Several possible methods exist for each type of change in:

Direct application to a single machine by running the executable provided

Using Windows Update site

Using Automatic Updates

Using Software Update Services

Using Systems Management Server (SMS) to apply the patch

Patching Processes

Part of your security maintenance plan should be the establishment of policy and procedures for applying patches.

Directly Applying Patches

You can directly apply a single patch to a single machine or create your own scripts for applying multiple patches. In most cases, applying a single patch is accomplished by double-clicking the patch executable. Patches can be obtained by visiting the Windows Update site or by visiting the Microsoft Download Center. To obtain a patch from the download center, follow these steps:

Using the Windows Update Site

The Windows Update Site is a reasonable solution for small businesses with a couple of Windows Server 2003 computers. However, these businesses will have to schedule a time when they manually request the updates. The site allows an individual to automatically have a single system evaluated for the need to update and then, with a click of a button, have the updates downloaded and applied. The major advantages of Windows Update are that additional updates and drivers are also identified and that you can select which updates to apply. The disadvantage is that you must manually request the scan, which is a time-consuming operation if more than a couple of servers must be updated. Other drawbacks include the fact that the user must have administrative privileges on the computer, the user must be knowledgeable about his systems to consider which changes should be made, and no local testing is done.

To use Windows Update, follow these steps:

Using Automatic Updates

Automatic Updates can be configured to automatically download and install new updates to Windows Server 2003 from the Microsoft web site or from a local SUS server. Automatic Updates for Windows Server 2003 can be configured directly or managed via Group Policy. In fact, Group Policy can be used to manage Automatic Updates for many Windows systems if they are joined to the domain, including, the following:

Windows Server 2003

Windows XP Professional

Windows 2000 Service Pack 3 and above

Windows 2000 Service Pack 2 and Windows Automatic Update client

Manual Configuration

Manual configuration is via the Automatic Update Property page of the Control Panel System applet, as shown in Figure 16-3. The choices are as follows:

Turn on or turn off automatic updating.

Notify the logged on user when updates are available and notify before installing.

Automatically download updates and notify when they are ready for installation.

Automatically download and install updates according to a selected schedule.

If the last option is selected, updating is totally automatic. You should, however, audit the application of updates. Periodic use of a tool such as Microsoft Security Baseline Analyzer should be used.

Automatic updating of servers, however, may not be a perfect solution. Although most patches do not cause problems, there will be occasional problems that may result in system downtime. This is not a good idea, especially if the servers involved are running mission-critical services or applications. It is always wise to test the addition of any patch on test systems before applying it in a production environment. However, in smaller organizations where test staff and systems do not exist, the risk of downtime due to malware or attacks that may take advantage of unprotected systems is far greater than the risk of downtime due to a problem with a patch.

Group Policy Configuration

The Group Policy Windows Update configuration is located in the Computer Configuration, Administrative Templates, Windows Components, Windows Updates section, as displayed in Figure 16-4.

NOTE: SUS and Windows 2000

If Windows 2000 is used as the host for SUS, the wuau.adm administrative template must be added to the Group Policy to use these settings.

Each section is described in Table 16-1, which is followed by screenshots of each option.

Configuring Automatic Updates is displayed in Figure 16-5, SUS server location in Figure 16-6, updating missed updates in Figure 16-7, and preventing auto-restarts in Figure 16-8.

Using SUS

Software Update Services (SUS) is a free security patch updating system that offers the best features of automatic updating and yet provides the opportunity to select which updates will be applied. Using SUS can also reduce bandwidth requirements for Internet access because only one computer needs to download patches over the Internet. In its simplest form, a single SUS server exists as a locally approved source of official Microsoft operating system security patches that can be used by configured clients for automatic updates. Windows XP, Windows 2000, and Windows Server 2003 computers can be updated. Organizations with complex, large, or geographically dispersed networks can use multiple SUS servers to meet their needs. It is possible to link SUS servers in SUS hierarchies and manually transfer approved updates to a SUS server that exists within an isolated network (a network with no Internet connectivity).

TIP: SUS Only Applies MS Updates

SUS cannot be used to apply configuration changes or to apply software updates that are not provided by Microsoft. All updates are signed. If you attempt to manually add an update to the SUS server, the update will not be applied to clients.

The basic scenario works like this:

Using SUS Hierarchies

SUS hierarchies are collections of SUS servers that are linked together to better serve an organization's update requirements. The root or parent SUS server downloads the security patches from Microsoft. Other SUS servers use this server as their source for updates. Each server can be configured to provide a different set of security patches or can simply provide alternative local locations for obtaining patches. Group Policy can be used to point the computers with accounts in different OUs to different SUS servers, thus distributing the download load. A simple SUS hierarchy is displayed in Figure 16-9.

Figure 16-10 illustrates another use for a SUS hierarchy. In this figure, a parent SUS server downloads patches from Microsoft while two child SUS servers offer updates to either a test network or the production network. The test network SUS server is used to make available patches for the clients on the test network. After the patches are tested, they are approved for download on the production network SUS server. This arrangement allows automatic updating of multiple test clients that match production configuration. Patches can be tested on many different configurations automatically, thus making the testing process more efficient.

Securing the SUS Server

The SUS server should be secured to prevent possible compromise or simple accidental misuse. In addition to keeping the SUS server behind a firewall and hardening it in the normal fashion, three specific operations should be considered.

Limit the number of administrators
Only those administrators who are members of the local SUS server Administrators group can administer SUS. Because the Domain Admins group is a de facto member of the local Administrators group, consider removing it, and in its place, add a custom local group to which you add approved SUS administrators. Don't forget to add the new group to the local Administrators group.

Don't host other web sites on the SUS server
The SUS server is the source of your approved patches, and access to this server should be restricted. When additional web sites are authorized on this server, users will have the right to log on locally, anonymous access may be provided, and the risk of compromise increases.

Use SSL to protect the update process
Using SSL ensures that the server is authenticated. Because clients are configured to use a specific SUS server, if SSL is required, the SUS site cannot be spoofed, and clients will not download updates from a SUS server that cannot provide the proper credentials. Obtain an SSL certificate for and add to the local IIS. Do not require SSL for the web site; instead, require SSL for access to the following directories:

\autoupdate\administration

\autoupdate\dictionaries

\Shared

\Content\EULA

\Content\RTF

Installing and Configuring SUS

SUS is not difficult to install and configure. The software can be downloaded for free from the Windows download site for use on a licensed server. Before installing SUS, check to ensure that the server meets SUS requirements. The requirements are as follows:

A minimum of a Pentium 700 MHz or equivalent.

512 MB RAM.

Network adapter.

NTFS partition of at least 100 MB free space for SUS installation.

Minimum of 6 GB storage for updates.

Microsoft Windows 2000 Server service pack 2 or later or Windows Server 2003. The server can be a member server, a domain controller, or a Windows Small Business Server.

Microsoft Internet Information Services.

Microsoft Internet Explorer 5.5 or later.

TIP: SUS Demo

You can watch a demo of the SUS installation at http://www.microsoft.com/seminar/shared/asp/view.asp?url=/Seminar/en/20030925TNT1_95d1/manifest.xml.

To install SUS, follow these steps:

To configure SUS, follow these steps:

WARNING: Choose the Language for SUS Downloads

Microsoft produces updates in many languages. The default setting for SUS is to download all updates in all languages. To reduce the time it takes to download changes, and to reduce the disk space necessary for updates, download only the languages that you need.

Configure Clients for SUS Automatic Updates

Windows XP Professional and Windows Server 2003 have Automatic Update clients installed as part of the OS, but earlier versions do not. A version of the client for Windows 2000, however, is available for download. SUS service pack 1 requires updates to some original Automatic Update clients. Table 16-2 lists Windows clients that can receive automatic updates via SUS and those that may need an additional update when SUS SP1 is used. If Windows systems have been kept updated with service packs, no download is required.

If Automatic Update clients are up-to-date, configure them to point to SUS. You need the wuau.adm administrative template file. This file is installed in the %systemdrive%\inf folder when Automatic Updates is installed.

In a managed environment, update clients are configured using Group Policy. However, the Local Group Policy object can be used in test or non-Active Directory environments. To use the Local Group Policy object, open it in the Group Policy console. In an Active Directory environment, create and link a GPO to the OU where computer accounts to be updated live:

If Active Directory will not or cannot be used to set update configuration, registry entries can be used. You need to manually create the RegDWORD keys, shown in Table 16-3, at the location HKEY_LOCAL_ MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU.

To set the location of the SUS server, two keys at HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows\WindowsUpdate must be set:

The URL of the SUS server should be entered in the key WUServer.

The URL of the SUS statistic server should be entered in the key WUStatusServer.

Preparing and Using an Offline SUS

An offline SUS server is a SUS server with no connection to the Internet. This SUS server does not require IIS and is configured to use updates provided by a content management server. This server can be used to provide update access to clients on a network that is not connected to the Internet. To configure such a server, follow these steps:

WUSAn Improved SUS

A new version of SUS called Windows Update Services (WUS) will soon be available. It offers more functionality and the ability to provide patches for more Microsoft applications.

Changes to Client Patch Management Strategies with Windows XP SP2

Although this book is about Windows Server 2003, many of its features work best with Windows XP, and changes announced and released for Windows XP in SP2 will probably be available in SP1 for Windows Server 2003. Patch management via SUS is enhanced with Windows XP SP2, although many features cannot be used until the release of WUS. The following new features are part of Windows XP SP2:

Windows updates for drivers and other applications are supported.

A new option, Install updates and shutdown option to the Shut Down Windows and Turn off Computer dialog box, makes it easier to deploy updates with less inconvenience for users.

Improvements to Background Intelligent Transfer Service (BITS), which is used during patch download, means improved bandwidth efficiency. BITS can be configured to download updates during a specific time, which means they can be scheduled for periods of lower network use. BITS can be configured to use only a portion of the available bandwidth and only the part of a file that has changed. BITS can recover from network failures.

Additional scheduling options are available, such as administrator notification and the receipt of previously declined and hidden updates.

Updates to the Automatic Updates components can be done automatically.

Updating rules provide better filtering of updates, such as preventing the download of an update meant for a different version of the OS.

These new update configurations are represented by new registry key changes and updates to Group Policy. For a complete list of registry keys and values for these settings, see the document "Changes to Functionality in Microsoft Windows XP Service Pack 2" at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2maint.mspx. There are four changes configurable by using Group Policy: three new policies under the Windows Components\Windows Update folder, and one in the Network\Background Intelligent Transfer Service node. The new Windows Updates policies are listed in Figure 16-17. Registry keys and Group Policy settings are only applicable for Windows XP SP2 computers.

Do not display "Install Updates and Shut Down" option in Shut Down Windows dialog box determines if this new options appears when the Shut Down box is displayed. When this option is enabled, the new shut down option is not displayed; if disabled or not configured, the option is displayed.

Do not adjust default option to "Install Updates and Shut Down" in Shut Down Windows dialog box controls what shut down option is the default. If this option is enabled, the user's last shut down choice is the default; if disabled, the Install Updates and Shut Down option is the default.

Enable client-side targeting determines the update group assigned to the client. If enabled, the update group can be included, as shown in Figure 16-18. The client update group is only used if the WUS is installed and configured to use update groups. Update groups enable targeting of clients for specific updates.

The Maximum network bandwidth that BITS uses policy enables configuration of bandwidth management, as shown in Figure 16-19.

Using SMS

SMS 2003 adds and improves upon the patch management features made available for SMS 2.0 in the Software Update Services Features Pack. The feature pack added security patch management capability to the Microsoft Systems Management Server 2.0 server. Security patch management is integrated with SMS inventory and software distribution and provides automated deployment of Microsoft Office and operating system software updates and is integrated with SUS. Administrators must still test and approve patches. The Microsoft Baseline Security Analyzer (MBSA) can also be distributed via SMS, as can the client for patch downloads. The command-line version of MSBA is used by the client to do a patch inventory (using the list approved by SMS administrators) and provide that information to SMS. The SMS client can be used to download and install the appropriate patches. Only authorized updates will be applied. The status of updates, including successful and failed updates, is also reported. The advantage of using SMS for patch management is that SMS provides patch inventory information. This information allows the administrator to see which computers need which patches, but it also allows him or her to discover problems. If patches are not being installed, the inventory will still show unpatched systems, even though the patches have been approved.