Securing Windows 2000 Server

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 8: Patch Management

Published: November 17, 2004 | Updated : May 31, 2006

Note: Welcome to the TechNet Archive. We've created this Archive area so that we can continue to make available older content that is still of interest to some of our users. This allows us to streamline the content offerings on the site and keep it focused on the newest, most relevant content.

Operating systems and applications are often immensely complex. They can consist of millions of lines of code, written by many different programmers. For these reasons, it is essential that the software works reliably and does not compromise the security or stability of your information technology (IT) environment. To minimize any problems, programs are tested thoroughly before release. However, attackers continually strive to find weaknesses in software, making it impossible to comprehensively anticipate all attacks in the future.

Software companies release patches to resolve weaknesses in code or implementation that become apparent after the release of the product. A patch is a piece of object code that is inserted in an executable program as a temporary fix of a bug.

Increasingly, these problems are security related; as the number of attacks increase, the methods of attackers become more sophisticated, and new malicious code—executable code that either intentionally or unintentionally causes damage to a new work environment—is created to take advantage of security vulnerabilities. However, deploying patches can also be simply related to adding functionality to a product that is desirable.

Security patch management presents a specific challenge to most organizations. After a weakness has been exposed in software, attackers will generally spread information about it quickly throughout their community. Software companies strive to release a security patch to address the vulnerability as soon as possible. But until you deploy the patch, the security that you depend on and expect may be severely compromised.

Whether your company has thousands of computers or just a few, managing all available patches, determining which are relevant to your environment, and evaluating how much testing you can afford to do before deploying them can be a difficult and time consuming task. After applying the latest service pack available for Microsoft® Windows® 2000 (Service Pack 3) on all of the Contoso computers, we examined each server to see what hotfixes were available and installed those as well. We found that all of the servers required the same handful of patches, but that there were a few additional ones specifically for Internet Information Service (IIS) that we only installed on the Web servers.

This chapter is designed to help you keep your Windows 2000–based servers secure, but the processes described here can also be applied to your patch management processes for all software updates. You should contact specific manufacturers for details on how they deploy updates to their software.

On This Page

Terminology
Patch Management in Your Organization
Patch Management Process
Summary

Terminology

In this guide, the terms patch, service pack, and hotfix are used interchangeably to mean changes to software after its release. The process for deploying them is the same in each case. However, each term has the following more specific definitions.

Service Packs

Service packs keep the product current, correct known problems, and may also extend the functionality of your computer network. They are conveniently packaged for easy downloading and include tools, drivers, and updates, including enhancements developed after the product is released.

Service packs are product specific, so there are separate service packs for each product. However, the same service pack will generally be used for different versions of the same product. For example, the same service pack is used to update Windows 2000 Server and Windows 2000 Professional.

Service packs are also cumulative—each new service pack contains all of the fixes in previous service packs, as well as any new fixes and system modifications that have been recommended since. You do not need to install a previous service pack before you install the latest one. Service packs may also contain a limited number of customer requested design changes or features, and because they are broadly distributed, they are tested heavily.

Hotfixes or QFEs

Quick Fix Engineering (QFE ) is a team within Microsoft that produces hotfixes—code patches for products. Most of these teams now refer to themselves as Sustained Engineering teams. Hotfixes or QFEs are provided to individual customers when they experience critical problems for which no feasible workaround is available. Occasionally you will see technical documentation refer to hotfixes as QFEs.

Hotfixes do not undergo extensive regression testing and are very issue specific—you should apply one only if you experience the exact issue that it addresses and are using the current software version with the latest service pack.

Groups of hotfixes are periodically incorporated into service packs, at which time they undergo more rigorous testing and are made available to all customers.

Security Patches

Security patches are designed to eliminate security vulnerabilities. Attackers wanting to break into computers can exploit these vulnerabilities. These patches are analogous to hotfixes but are deemed mandatory, if the circumstances match, and need to be deployed quickly.

Many security patches are for client-side (often browser) issues. They may or may not be relevant to a server installation. You need to obtain the client patch to update your current client base and the admin patch to update the client build area on your server.

Patch Management in Your Organization

Exactly how you implement patch management will depend a great deal on the size and complexity of your organization. However, it is vital that you understand the importance of patch management and how it fits into the overall risk management strategy for your company.

For example, if you decide that risk must be minimized at all costs, you could follow a strategy of shutting down all production computers every time a new vulnerability appears in your software. You may then choose to not start the computers again until extensive testing has been done on the security patch and it has been deployed throughout your organization. This approach is a very time consuming and expensive process and will be completely impractical for many organizations.

Throughout the patch management process, you will need to evaluate the risks against the costs of deploying the appropriate countermeasures. After a security vulnerability has been disclosed, there may be a short period before a patch is released. You will need to evaluate the increased risk caused by the vulnerability and determine measures to take prior to testing and deploying a patch.

These measures may include disabling services, taking computers offline, or restricting access to internal users or other groups as necessary. When a patch is released, you need to determine the risk of deploying it immediately against the cost of keeping services down or unprotected while you test and make sure that the patch does not negatively affect the computer. If you decide to test, you need to determine how much testing you can afford to do before the risks of not deploying outweigh those of deploying.

Note   Your organization should implement a change management process. Microsoft Operations Framework (MOF) includes a change management process that can serve as this foundation process for your organization. For details on MOF, see the "More Information" section at the end of this chapter.

Assessing Your Current Environment

Often, patches are applied inconsistently throughout an organization, and there is no documentation on why, when, and where they have been deployed. Before you can manage the security of your environment properly, you must know in detail its current state. At a minimum for patch management purposes, you must know:

• What computers are in your environment, including:

  • Operating systems and their versions.

  • Patch levels in use (service pack versions, hotfixes, and other modifications).

  • Function.

  • Applications in use throughout your environment.

  • Contact information on the individuals or groups responsible for maintaining each computer.

• What assets are present in your environment and their relative value.

• What are the known threats, and the processes you have for identifying new ones or changes in threat level.

• What are the known vulnerabilities, and the processes you have for identifying new ones or changes in vulnerability level.

• What countermeasures have been deployed in your environment.

It is highly recommended that you keep this information available to all those involved in your patch management process and ensure that it is kept up to date.

After you know your assets, vulnerabilities, threats, and how your environment is configured, you can determine and prioritize which of the threats and vulnerabilities are going to be of concern to your company.

Software Update Service

In many environments, it can be beneficial to have specialized computers from which you perform many of the steps of the patch management process. These computers provide specialized locations for storing security tools, patches, hotfixes, service packs, and documentation. You can use these computers as a place to perform patch analysis, retrieval, and deployment. In this guide, such computers are referred to as a Software Update Service (SUS).

You should ensure that your security update systems are on one or more dedicated computers that can be tightly controlled and secured, as these computers will be used for deploying and maintaining security patches for all computers in your environment.

Security update systems do not generally need to be high powered servers, as the load on them will typically be very light. However, high availability is very important, as these computers will form the basis of keeping your environment up to date with the latest patches.

To properly deploy a security update system, the computer will need direct or indirect Internet access to download the latest patch information from trusted sources, as well as access to each computer that it is responsible for keeping current.

Examples and sample scripts that should be run from the SUS are provided later in this chapter.

Note   MOF discusses update systems as part of the Release Management process.

Communication

If your company is small, then only one person may need to be put in charge of keeping patches up to date, testing and installing them, and reading the various log files that they generate. However, in larger environments there will generally be several people in charge of different aspects of security patch management.

It is very important that all those involved in patch management communicate effectively. Good communications will help ensure that decisions are made without duplicating effort, and that no steps of the process are missed.

Patch Management and Change Management

Patch management is really just a subset of change management. If you already have a change management procedure in your organization, you will not have to create an entirely new process for patch management. This chapter provides information specific to the patch management process that can be used to greatly improve your existing change management process.

A good change control procedure has an identified owner, a path for customer input, an audit trail to account for all changes, a clear announcement and review period, testing procedures, and a well understood rollback plan.

Microsoft Security Tool Kits

The Microsoft Security Tool Kits can be useful when it comes to obtaining the service packs and hotfixes needed to keep your servers current. The toolkits contain important security information, current service packs, critical security patches for Microsoft® Windows NT® version 4.0, Windows 2000, Internet Information Services (IIS), and Microsoft® Internet Explorer. They also include the Windows Update notification tool. This tool ties back to the Windows Update site to ensure that all the latest patches are installed on your computers. Two Security Tool Kits are available from TechNet. The first is Microsoft Security Tool Kit: Securing an Existing Windows 2000 System, at www.microsoft.com/technet/Security/tools/w2kexist.mspx. The second is Microsoft Security Tool Kit: Securing an Existing Windows NT 4.0 System, at www.microsoft.com/technet/Security/tools/nt4exist.mspx.

Patch Management Process

The patch management process is represented in the following flowchart.

Figure 8.1  Patch management process

It is worth examining these steps in more detail:

• Analyze. Look at the current environment and potential threats. Determine the patches that you must deploy to reduce the threats to your environment.

• Plan. Determine which patches should be deployed to deter the potential threats and vulnerabilities that you have identified. Identify who will perform testing and deployment and the steps involved.

• Testing. Review the available patches and categorize them for your environment. Test all patches that have been identified to make sure that they will work within your environment without any negative side effects. Understand what the patch does and how it affects your environment. Verify that it performs as planned.

• Deploy. Deploy the right patches to make your environment secure.

• Monitor. Check all computers after deploying patches to make sure that there are no undesired side effects.

• Review. As part of the ongoing process, you need to routinely review new patches that have been released, your environment, and which patches are needed for your organization. If during the review you find that new patches are needed, start again at the first step.

  Important   It is highly recommended that you back up all production computers prior to deploying patches.

Analyze Your Environment for Missing Patches

As an ongoing process, you need to ensure that you are up to date on patches. In some cases, a new patch will be released that you will need to install on all your servers. In others, a new server brought online will need to be patched appropriately. You should continue to analyze all of your servers to ensure that they are completely up to date with all of the latest patches. There are a number of tools that you can use to help you with this task.

Microsoft Baseline Security Analyzer

The Microsoft Baseline Security Analyzer (MBSA) has been designed to scan computers that are running Windows NT 4.0, Windows 2000, Windows XP Professional, and Windows XP Home Edition. The MBSA can be executed from any computer that is running Windows 2000 Professional, Windows 2000 Server, Windows XP Home, or Windows XP Professional.

One particularly important element of operating a secure computer is staying up to date on security patches. It is critical to know which patches have been applied to your computer and, more importantly, which have not. The MBSA tool determines this information by referring to an Extensible Markup Language (XML) database that Microsoft constantly updates. The MBSA uses the popular HFNetChk tool that Microsoft released in August 2001 to achieve this goal.

The XML file contains information about which hotfixes are available for each Microsoft product. This file contains security bulletin name and title and detailed data about product-specific security hotfixes, including files in each hotfix package and their file versions and checksums, registry keys that were applied by the hotfix installation package, information about which patches supersede other patches, related Microsoft Knowledge Base article numbers, and much more.

When you run the MBSA tool for the first time, the tool must obtain a copy of this XML file so that it can find the hotfixes that are available for each product. The XML file is available on the Microsoft Download Center Web site in compressed form (digitally signed .cab file). MBSA downloads the .cab file, verifies the signature, and then decompresses the .cab file to the local computer on which MBSA is running. Note that a .cab file is a compressed file that is similar to a WinZip (.zip) file.

Note   Each time MBSA is run it will attempt to connect to the Internet to download the XML file from Microsoft. If an Internet connection is not available, the tool will look for a local copy of the XML file in the tool installation folder. Each time the file is successfully downloaded during a scan, a local copy will be stored on the computer in the event that subsequent scans fail to connect to the Internet. Otherwise, for computers that never connect to the Internet, users can separately download this file from the Microsoft Download Center site and copy it onto the computers running the tool.

After the .CAB file is decompressed, MBSA scans your computer (or the selected computers) to determine the operating system, service packs, and programs that you are running. MBSA then parses the XML file and identifies security patches that are available for your combination of installed software.

For the MBSA to determine whether a specific patch is installed on a given computer, three items are evaluated: the registry key that is installed by the patch, the file version, and the checksum for each file that is installed by the patch.

In the default configuration, MBSA compares both file details and registry keys from the resulting XML subset to the files and registry details on the computer that is being scanned. If any of the file or registry key details on the computer do not match the information that is stored in the XML file, the associated security patch is identified as not installed and the results are displayed in the security report. The specific Microsoft Knowledge Base article number that relates to the patch is also displayed on the screen.

In general, the MBSA scans for security issues in the Windows operating systems (Windows NT 4.0, Windows 2000, and Windows XP), such as “Guest” account status, file system type, available file shares, members of the Administrators group, and so on. Descriptions of each operating system check are shown in the security reports with instructions on fixing any issues found.

Note   To use MBSA, you must have either local administrator or domain administrator access to the computer being checked for patches.

The tool has a number of command line switches, listed in the following tables. The MBSA-style scan will store results, as was done in MBSA version 1.0, in individual XML files to later be viewed in the MBSA user interface. MBSA-style scans include the full set of available Windows, IIS, Microsoft® SQL Server™, desktop application, and security update checks.

Table 8.1  MBSA-Style Command Line Switches

Switch
Selecting computer to scan
<no option>
/c <domainname>\<computername>
/i <xxx.xxx.xxx.xxx>
/r <xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx>
/d <domainname>
Selecting which scan options NOT to perform (can concatenate like /n OS+IIS+Updates)
/n IIS
/n OS
/n Password
/n SQL
/n Updates
Security update scan options
/sus <SUS server>
/s 1
/s 2
/nosum
Specifying output file name template
/o %domain%
Displaying results and details
/e
/l
/ls
/lr <report name>
/ld <report name>
Miscellaneous options
/?
/qp
/qe
/qr

The HFNetChk-style scan will check for missing security updates and will display scan results as text in the command line window, as is done in the stand-alone HFNetChk tool. MBSA 1.1 includes the "/hf" flag that will indicate an HFNetChk scan to the MBSA engine. The HFNetChk switches listed in the following table can be used after the "/hf" flag is specified on the command line.

Note   The MBSA-style scan parameters that are listed in the preceding table cannot be combined with the /hf flag option.

Table 8.2  HFNetChk-Style Command Line Switches

Switch
Selecting computer to scan
-h <hostname>
-fh <filename>
-i <xxx.xxx.xxx.xxx>
-fip <filename>
-r <xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx>
-d <domainname>
-n
Specifying which scan options should/should not be performed or displayed
-sus <SUS filename | SUS server>
-b
-fq <filename>
-s
-nosum
-sum
-z
-history
-v
Specifying output format and file names
-o
-f <filename>
Miscellaneous options
-t
-u <username>
-p <password>
-x
-ver
-trace
-about

If you use MBSA to verify your patch status, you should ensure that it is run regularly. In most environments, the best way to verify your patch status is to schedule MBSA to run at preset intervals.

Note   For more information about using MBSA, see the Microsoft TechNet: Security Tools Web site at www.microsoft.com/technet/security/tools/default.mspx.

Patch Management Script

This guide includes a patch management script, MBSAPatchCheck.cmd, which will check multiple servers for missing patches and record the results to a log file that is saved in a date-based folder. The script uses MBSA to scan servers and another script, movelog.vbs, to move the files into the appropriate folders. Over time these folders make up a history that you can review as part of your analysis and review phases, helping you to keep your environment more secure.

Note   The script included with this guide requires MBSA version 1.1 or later.

After downloading and extracting the scripts included with this guide, you will have the following folder structure for the patch management script.

Table 8.3  Folder Structure for the Patch Management Script

Folder	Description
C:\SecurityOps	This folder is the root folder for all of the files included with this guide.
C:\SecurityOps\PatchMgmt	This folder contains the patch management script, MBSAPatchCheck.cmd, the movelog.vbs script, and the subfolders for the support files and logs. This folder is also where the mssecure.xml file must be placed.
C:\Program Files\Microsoft Baseline Security Analyzer\	This folder is where the MBSA utility must be placed after being downloaded from the Microsoft Web site. See the following procedure for more detailed instructions.
C:\SecurityOps\PatchMgmt\ServerLists	This folder is where you create and keep text files listing groups of servers to be scanned for missing patches.
C:\SecurityOps\PatchMgmt\Logs	This folder is where the log files are created after MBSAPatchCheck.cmd is run. The script creates a subfolder with the current date in which the log file is stored, for example \SecurityOps\PatchMgmt\Logs\2002117.

Important   If you install the files included with this guide on a partition other than drive C, you will need to edit the paths in the MBSAPatchCheck.cmd file to use that partition.

To set up and use the MBSAPatchCheck.cmd script on SUS

1. Run SecurityOps.exe to extract the script files included with this guide to create the folder structure listed in Table 8.3. By default this file is located in C:\SCI\Scripts when you extract the files from the self-extracting executable called SecWin2k.exe.

2. Download the MBSA utility from https://www.microsoft.com/technet/security/tools/mbsahome.mspx and install the tool in the default folder (C:\Program Files\Microsoft Baseline Security Analyzer).

3. If the computer that is running the script is not connected to the Internet, you will also need to download and extract the Mssecure.xml file from https://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab. Mssecure.xml should be placed in the MBSA folder.

4. Create a server list text file in C:\SecurityOps\PatchMgmt\ServerLists. This file is a text file containing the NetBIOS names of the servers that you want to check, separated by carriage returns.

5. Open a command prompt, change to the C:\SecurityOps\PatchMgmt folder, and start the script using the following command line:

   MBSAPatchCheck.cmd serverlist.txt

   where serverlist.txt is the name of the server list text file.

   Note   If you receive a dialog box asking whether you want to download the mssecure.xml file, click Yes.

6. Change to the C:\SecurityOps\PatchMgmt\Logs folder, open the folder with the current date, and open the file with the same name as the serverlist.txt file.

7. Examine the log file to determine what patches are missing on your servers.

   Note   If the patch management script is run twice in a single day, the log file from the first time the script was run will be overwritten.

Working with Multiple Server Lists

In a large scale network, you will have many different server types. As part of your risk management process, you may determine that you need to monitor some of your servers more often than others for missing patches.

If you use multiple server lists, you can schedule the patch management script to scan different types of servers at different intervals. Multiple server lists are also useful if you have different administrators responsible for different groups of servers. Using multiple lists, you will be able to create separate reports of missing patches for each group of administrators.

As an example, you could create five server list files to provide patch reports to different groups of administrators for the Contoso network shown in the following figure.

Figure 8.2  Server list files for a simple network

In this example, the server list files for each type of server would contain the names of those servers. For example, File&Print.txt simply contains:

• FP01

• FP02

• FP03

The fifth server list file, Servers.txt, contains all of the servers in the environment. The results of this scan could be used by the security team to ensure that each group is keeping their servers up to date with the latest patches.

Scheduling the Patch Management Script

To ensure that MBSAPatchCheck.cmd runs at set intervals, you should consider scheduling the tool to run regularly, either with the task scheduler or the AT command. By using multiple server lists, you could ensure that different servers are checked at different times.

Note   By default, the schedule service is disabled in the Member Server and Domain Controller Baseline policies. You will need to enable the service if you want to schedule the Patch Management Script.

Other Methods for Determining Hotfix Levels

If you do not want or are unable to use the MBSA tool in some parts of your environment, there are other ways that you can determine whether hotfixes have been installed.

The easiest way to determine whether hotfixes have been installed is to look in the registry under the HKLM\Software\Microsoft\Windows Nt\Currentversion\hotfix key. Every new hotfix installed should have a key with a Q name that corresponds to the article in the Microsoft Knowledge Base discussing the hotfix. However, some older hotfixes and hotfixes for some applications do not have such keys.

Other Tools for Determining Hotfix Levels

There are two other free tools from Microsoft that that you can use to gather this information. These tools are:

• Qfecheck.exe /v. This tool informs you of service pack levels and hotfix versions installed on your servers. Qfecheck will also tell you if a patch was not correctly installed in your environment.

• Hotfix.exe -l. This tool displays the number and versions of hotfixes installed on your servers.

Plan

Not every threat or vulnerability poses a significant risk to your environment. As you read notifications of potential new operating system or application vulnerabilities, you should assess whether these vulnerabilities apply to your particular environment.

For example, if the vulnerability applies to the File Transfer Protocol (FTP) service in Windows 2000 and you never enable this service, then the vulnerability does not apply to you. Likewise, if you learn that there is an increased chance of hurricanes this year, but your IT environment is inland, then this threat is minimal.

If you respond to threats and vulnerabilities that do not apply to your environment, you will use up valuable resources and, potentially, adversely affect the stability of your environment with no corresponding benefit.

As new threats and vulnerabilities emerge, you should read any supporting information about them. Staying knowledgeable about threats and vulnerabilities will allow you to make an informed decision on the level of significant risk to your environment and then determine the appropriate response. Your primary alternatives will be to take no action, to disable the service at risk, or to deploy a patch.

Important   When creating the plan for deploying a new patch, you should also create a rollback plan.

To ensure that you stay current on new patches, make sure that you receive regular security bulletins from Microsoft. To sign up to receive the update bulletins, go to the Microsoft Security Web site. For details, see the "More Information" section at the end of this chapter.

Categorizing Patches

As each new patch becomes available, you should determine its importance to your environment. Understanding its importance will help you determine how soon you will need to deploy it and how much testing you can afford.

Microsoft provides ratings for each vulnerability that is the subject of a security bulletin. The rating levels are shown in the following table.

Table 8.4  Vulnerability Ratings as Defined by Microsoft

Computer type	Rating level	Rating level	Rating level
	Critical	Moderate	Low
Internet servers	Web site defacement, denial-of-service (DoS), or full control.	Difficult to exploit, unusual configuration, or transient effect.	Limited impact such as disclosure of scripts.
Internal servers	Elevation of privilege, data disclosure, or modification. Auditing difficult.	Auditable data disclosure, modification, or DoS.	Untargeted or fragmentary data theft or modification, limited DoS.
Client computers	Run arbitrary code without user action; remote escalation of privilege.	Local escalation of privilege, untargeted data disclosure or DoS, use action exploitation.	Limited or fragmentary data theft or modification, hostile Web site attacks.

The rating system categorizes vulnerabilities, according to their potential impact if the vulnerability is exploited and the likelihood of that happening.

You can use this rating system as a guide for categorizing patches. However, the Microsoft rating system is just an overall estimate of potential impact in the context of millions of customers worldwide; the severity ratings are based on past experience and subjective judgment. For these reasons, they may not be accurate predictors of impact for your environment. Ultimately, you will need to categorize patches based on your own environment.

Testing the Patches

As with any software, patches may not work perfectly in every environment. Ideally, you should thoroughly test any patches that you are going to install in your environment. However, many security patches need to be installed quickly to fix potentially serious problems.

In many cases, you will find your testing procedure is a compromise between the need to solve a security issue and the need to ensure that your patch is stable in your environment.

How much testing is appropriate will depend on how you have categorized the patch. Using the Microsoft categorizations, the following table shows the minimum level of testing that you should perform for each patch type. For the Contoso scenario, we wanted to be sure that each of the server roles still functioned properly after the recommended hotfixes were installed. We did so by verifying that various client computers could still connect to the network services running on each server role and performing other basic test procedures to confirm that everything was still working as expected.

Table 8.5  Minimum Testing for Patches

Patch type	Testing phases
Critical severity patches	Assessing the patch Assessing server operations (Limited)
Moderate severity patches	Assessing the patch Installing the patch in a test environment Assessing server operations (Full) Checking the uninstall procedure
Low severity patches	Assessing the patch Installing the patch in a test environment Assessing server operations (Full) Assessing application operations Checking the uninstall procedure

As part of your risk management procedure, you will need to determine how thoroughly to perform each step. If you skip some phases because of urgency, you should still continue to complete them in a test lab to find potential problems before they occur on already deployed computers.

All testing should occur on servers that resemble your production servers as closely as possible.

Assessing the Patch

At a minimum, your patch assessment should consist of the following steps:

• Identifying the patch owner. For all patches, you should have an identified owner who is responsible for the evaluation of the patch.

• Reviewing all documentation. Before applying any service pack, hotfix, or security patch, all relevant documentation should be read and peer reviewed. The peer review process is critical as it mitigates the risk of a single person missing critical and relevant points when evaluating the update.

• Verifying the patch category. After further assessment of the patch, you may need to change its category. If you do, it will affect other aspects of your testing.

As you read the documentation, look for answers to the following questions:

• Is the update relevant, and will it resolve an outstanding issue?

• Will adopting the update cause other problems resulting in a compromise of the production computer?

• Are there dependencies relating to the update? (For example, do certain features need to be enabled or disabled for the update to be effective?)

• Do you need to perform any actions prior to deploying the update?

As well as examining the documentation released with the updates, you should search the Microsoft support Web site for any additional post-release information on the update. TechNet also provides security bulletins in a searchable (by product name and service pack) database on its Web site. These materials supply critical information that must be referenced.

Installing

You should make sure that the patch installs correctly, understand whether the patch requires a restart, know how much space it takes up (including an uninstall folder), understand what options are available to you, and so on. You also should read any supporting documentation for additional information evaluate the pros and cons of applying the patch.

Server Operations

After the patch is installed, you need to make sure that the server continues to work properly. It is also a good idea to monitor the Event Log and System Monitor for any unexpected results.

Test all of the server functions and make sure that everything operates as it should. How much risk you can handle on the particular server, for the particular vulnerability, will determine how long you should allow the server to run before determining whether everything is running properly. If there are any problems, you need to make sure that they are documented and they should be reported to Microsoft as soon as possible.

Note   You can use Microsoft Operations Manager (MOM) to collect Event Log and System Monitor information.

Application Operations

As part of your testing procedure, it is important to test the patch with any applications that coexist on the servers and make sure that you identify any issues with dependencies. After installing the patch, you should check that all applications continue to work as before.

Uninstall

It is possible that despite your testing, after installing the patch you will run into problems that result in your needing to uninstall the patch. It is important, therefore, to test that the uninstall works. After uninstalling, you should check that the server continues to run as expected and continue to watch the Event Log and System Monitor counters.

Creating a Rollback Plan

Even if your testing proceeds entirely without incident, it is still possible that there will be problems as you deploy the patch throughout your organization. You need a plan of action to restore the computer to its original state before the patch was deployed.

In some cases, this plan consists of taking a snapshot backup of a server before the install occurs, so that if there are problems the server can be restored very quickly. Whatever rollback plan your organization comes up with should be thoroughly tested.

Deploying the Patches

Assuming the testing proceeds smoothly, you should be ready to deploy the patch across your organization. There are a number of ways to deploy patches, including the following methods and processes:

• Manual deployment

• Group Policy

• Scripts

Manual

Manual hotfix installation is the most common installation method for most organizations. This approach consists of simply running the executable corresponding to the hotfix on each server. If your organization has many servers, though, this approach may be an impractical option.

The name of most hotfixes will tell you important information about the fix. For example, a typical name for a hotfix is Q292435_W2K_SP3_x86_en.EXE.

In this case:

• Q292435 is the Microsoft Knowledge Base article number where you can find out more information about the hotfix.

• W2K is the product it is intended for (Microsoft Windows 2000).

• SP3 is the Service Pack that it will be included in.

• x86 is the processor architecture that it is meant for.

• en is the language that the hotfix is released in (English in this case).

Note   Hotfixes that have a file name of QXXXXXX.exe and do not have W2K_SP3_x86 appended to the file name are specific to applications such as Internet Explorer.

Hotfixes also support several command line switches that can be used to control the behavior of the hotfix installation process.

Table 8.6  Switches for Hotfix Executables

Switch	Description
-y	Perform uninstall
-f	Force applications to close at shutdown
-n	Do not create an uninstall directory
-z	Do not restart when update completes
-q	Quiet mode—no user interface (UI)
-m	Unattended mode
-l	List installed hotfixes

Note   Application specific hotfixes with file names of QXXXXXX.exe typically do not support all of the listed switches.

If you script the installation of multiple hotfixes, you will want to use the -q and -z switches so that the hotfix is installed without a user interface and does not force a restart.

Typically, when you install multiple hotfixes you need to restart the computer between each one. The computer needs to be restarted because any files that are locked, or in use, cannot be replaced, so they are placed in a queue to be replaced after the computer restarts.

QChain is a tool that allows you to string together several hotfixes with only a single restart, instead of restarting between each install. To use QChain, run the hotfix installer with the -z switch to instruct the installer not to restart after the installation. Then run QChain.exe and restart the computer.

Note QChain is available on TechNet. For more details, see the "More Information" section at the end of this chapter.

If additional components, such as DNS, are added after applying a service pack and patches, it is necessary to reapply the service pack and patches to ensure that the new component is properly patched.

Group Policy

Windows 2000 natively supports software distribution using Group Policy. Patches do not typically come in the form of a Windows Installer package. However, you can use such an executable in conjunction with a .zap file.

Applications that do not use Windows Installer packages must use a .zap file to describe their existing setup program. A .zap file is a text file (similar to an .ini file) that provides information about how to install a program, the application properties, and the entry points that the application should install.

A .zap file can only be assigned to a user, which means that after you set up Group Policy to distribute the hotfix, you still need to log on to the computer with the user account to which the .zap file was assigned.

Note   For more information about creating a .zap file and assigning it using Group Policy, see the Microsoft Knowledge Base article 231747, "HOW TO: Publish non-MSI Programs with .zap Files," at https://support.microsoft.com/default.aspx?scid=231747.

Scripts

You may want to create your own scripts using the Microsoft® Visual Basic® Scripting Edition (VBScript) language or batch files to roll out patches. These scripts could be in the form of logon or startup scripts, which check to see the current patch status and then check updates from a centralized server.

Your scripts can include QChain, to ensure that if more than one hotfix is required, only a single restart is needed.

Monitoring

After you have installed the patches into your production environment, you need to continue to monitor your servers. Make sure that you watch the Event Log and System Monitor counters for problems. If you see any other errors on the computers for the next couple of weeks, you should test to make sure that they are not related to the patch that you deployed. Also, if you implemented a patch without thorough lab testing because it was time-critical, you should continue testing the patch in a lab environment afterward to make sure that nothing was missed.

As well as monitoring existing servers, it is very important that you monitor the environment as a whole to ensure that new servers are not brought onto the network and left without installing the current patches on them. There should always be a latest build available for new servers to receive. The monitoring policy for your organization should ensure this availability.

Reviewing

You can only be sure that any process is working properly if you review it. As you complete the patch management process for each patch, you should review to ensure that each one was deployed correctly, and that all procedures ran correctly. This review will help to ensure that your patch management process continues to function as it should. As you review the process, you should continue to analyze the environment for additional changes. If any occur, you will need to start the patch management process again.

Other Tools

By following the recommendations outlined so far in this chapter, you are well on your way to managing patches effectively within your organization. However, there are a number of additional tools that you can use to further automate the process of patch management.

Microsoft Systems Management Server

If you have Microsoft® Systems Management Server (SMS) deployed in your organization, you can use it to help you with many of the phases discussed earlier in this chapter.

The Microsoft Security Tool Kit contains an SMS import utility that can be used to automate the distribution and installation of recommended IIS security fixes. SMS can help you determine which computers need the security fixes, and then deploy them.

The software deployment features of SMS can be used to roll out patches in your environment to all computers that have the SMS client. If you create a software package for the patch, you can force an upgrade to all or any collection of computers in your environment. One of the main advantages of this flexibility is that you can monitor which computers have the patch installed. However, in most cases you will need an SMS administrator or someone with knowledge of creating SMS packages to correctly roll out these types of upgrades.

Third-Party Tools

The following third-party tools are available to help with patch management. These tools offer some features not currently available with the free tools from Microsoft, such as the ability to deploy fixes and have the status reported back, create computer groupings with similar update needs, support other products not supported by the tools described earlier, and have graphical user interface (GUI) command areas for administrative tasks. You should evaluate these features and determine whether they are needed within your environment.

Shavlik Hfnetchkpro

This tool is built on HFNetChk technology. It has a GUI option that the command line version does not which allows you to keep a scan history.

www.shavlik.com

Bindview Security Advisor

The Bindview tool has a GUI to help simplify the process of checking for noncompliant computers. It also has an update service that lets you know when new patches have been released.

www.bindview.com/

Altiris Software’s Security Expressions

This tool allows administrators to implement security lock down policies on Windows- and UNIX-based computers. It also has the capability to check for hotfixes and automatically download and install them if needed.

https://www.altiris.com/Products/SecurityExpressions.aspx

Summary

Most IT security breaches come from the exploitation of environments that are not fully up to date with security patches. Good patch management is essential to minimizing the security risks that you face. Take patch management seriously and you are likely to dramatically reduce the costs associated with security breaches. For the Contoso scenario, we recognized that patch management is an ongoing process and we made sure that the servers remained up-to-date with security-related hotfixes throughout the project.

More Information

For more information about MBSA, see the Microsoft Baseline Security Analyzer Web site at www.microsoft.com/technet/security/tools/mbsahome.mspx and the "Microsoft Baseline Security Analyzer V1.2" white paper at www.microsoft.com/technet/Security/tools/mbsawp.mspx.

For more information about troubleshooting catalog file downloads, download the "How to troubleshoot catalog file downloads for the Microsoft Baseline Security Analyzer 1.2" article at https://download.microsoft.com/download/xml
/security/1.0/nt5/en-us/mssecure.cab.

For more information about how to create a .zap file for use with Group Policy, see the "HOW TO: Publish non-MSI Programs with .zap Files" article at https://support.microsoft.com/default.aspx?scid=231747.

For more information about Qfecheck.exe, see the "Qfecheck.exe Verifies the Installation of Windows 2000 and Windows XP Hotfixes" article at https://support.microsoft.com/default.aspx?scid=282784.

For more information about Hotfix.exe, see the "How to install and remove hotfixes with Hotfix.exe" article at https://support.microsoft.com/default.aspx?scid=184305.

For more information about Qchain and to download the executable for it, see the "The correct file is not installed when you chain multiple hotfixes" article at https://support.microsoft.com/kb/815062.

For more information about the Microsoft Security Rating system, see the Microsoft Security Response Center Security Bulletin Severity Rating System (Revised, November 2002) page at www.microsoft.com/technet/Security/bulletin/rating.mspx.

To sign up to receive monthly security bulletins from the Security Bulletin Advance Notification program, see the TechNet Security Center at www.microsoft.com/technet/Security/default.mspx.

For more information about the Microsoft Security Tool Kit, see the Security Tools Web site at www.microsoft.com/technet/security
/tools/default.mspx.

For more information about MOF, see the Microsoft Operations Framework Web site at www.microsoft.com/technet/itsolutions
/cits/mo/mof/default.mspx.

Download

Get the Securing Windows 2000 Server

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions