Microsoft Windows NT 4.0 and Windows 98 Threat Mitigation Guide

  • Article
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 6: Patch Management

Published: September 13, 2004 | Updated : March 30, 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.

On This Page

Introduction
Background
Solution Design
Implementation
Summary

Introduction

One of the main ways you can guard against attack is to ensure that your environment is kept up to date with all of the necessary security patches. Patches are required at the server and client levels. This chapter shows you how to ensure that you find out about new patches in a timely manner, implement them quickly and reliably throughout your organization, and monitor to ensure that they are deployed everywhere. It describes the compromises in patch management implementations and concludes with a detailed description of the patch management system at Trey Research.

Background

Patch management is a critical component of information security. When new vulnerabilities are identified in existing code or when new threats emerge, vendors release patches to fix vulnerabilities or add security features. Organizations like Trey Research must be able to quickly identify which computers need which patches, and then deploy the patches as necessary. They must be able to do this in a consistent and repeatable manner, because failing to patch even a few computers means that the overall network is still vulnerable.

Solution Design

Exactly how you implement patch management will depend 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 organization.

For example, if you decide that risk must be minimized at all costs, you could follow a strategy of shutting down all production systems every time a new vulnerability appears in your software. You may then choose not to start the systems again until you have done extensive testing on the security patch and deployed it throughout your organization. This is a very time-consuming and expensive process and would be impractical for most 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 of time before a patch is released. You will need to evaluate the increased risk caused by the vulnerability and determine what must be done prior to testing and deploying a patch.

You may need to disable services, take systems offline, or restrict access to internal users or other groups as necessary. After 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 system. 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 the foundation process for your organization. For details on MOF, see the "More Information" section at the end of this chapter.

Solution Prerequisites

The Trey Research patch management solution must allow the IT department to:

  • Automatically inventory computers to identify which ones have been patched and which ones have not.

  • Quickly perform on-demand inventories to immediately identify computers that are missing specified patches.

  • Automatically perform scheduled scans for patch compliance, generating reports that can be maintained and tracked over time.

  • Install single or multiple patches on selected computers without user intervention, minimizing the number of reboots whenever possible.

Because Trey maintains offices in several locations, each with its own administrative staff, the company needs to adopt a uniform set of tools and processes for patch management. Although this is primarily a process issue (addressed by the solution design described in a subsequent section), there are some technical issues that impact the Trey solution design:

  • The Microsoft® Software Update Service (SUS) installation used by Trey computers that run the Microsoft Windows® XP or Windows 2000 operating system does not support Windows 98 or Microsoft Windows NT® version 4.0. The existence of these older operating systems limits their ability to automatically download new security updates and push them to client computers.

  • Computers running Windows 98 and Windows NT can use the public, Microsoft-hosted Windows Update service to download patches and updates, but there is no way to use system policy settings to restrict the set of updates that users download. In addition, it is not possible to make these clients use an internal SUS or Windows Update Services server.

Solution Architecture

Patch management architectures vary widely among organizations. Some organizations opt for a highly centralized and tightly managed system using as many off-the-shelf tools as possible, while others build customized patch inventory and deployment tools. However, all of these architectures share some common features and requirements. The basic patch management process consists of four phases:

  • Assess the environment to determine which computers exist, how patches can potentially be distributed to them, and what business processes influence how and when patches are applied. To do this, you must look at the current environment and evaluate potential threats (as described in Chapter 2 of this guide). When you complete this evaluation, you will be able to determine the patches that you must deploy to reduce the threats to your environment.

  • Identify which specific computers need which specific patches. This process may be done automatically with a tool like the Microsoft Baseline Security Analyzer or Systems Management Server, manually, or with environment-specific scripts that check patch revisions.

  • Evaluate and plan the patch deployment, including testing the patch, making provisions for rolling back failed patch installations, and deciding which patches are important enough to merit immediate application. In addition, you must identify who will perform the patch testing and deployment.

  • Deploy the patches to systems that need them, verifying that all needed patches were applied and that systems were rebooted when necessary.

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

Assessing the Environment

For patch management purposes, your IT staff needs to know at least the following information:

  • What systems are in the environment, including:

    • Operating systems and their versions.

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

    • Functions performed by the systems.

    • Applications in use throughout the environment.

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

  • What assets are present and their relative values.

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

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

  • What countermeasures have been deployed.

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 greatest concern to you.

If you follow the guidance given in Chapter 2, "Applying the Security Risk Management Discipline to the Trey Research Scenario," much of this information will already be available as you plan your patch management deployment. Information about the specific patches in use can be gathered using the steps described in the following sections. Data about applications, assets, risks, and countermeasures can be adapted from the SRMD materials and the recommendations in previous chapters of this guidance.

Identifying Patching Requirements

As an ongoing process, you need to ensure that your computer patches are up to date. In some cases, a new patch will be released that you will need to install on all your servers. In others, a new server that is 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. To efficiently keep the computers in your organization up to date, you need to know what vulnerabilities exist and what protection is already in place. Tools you can use to assist in this process include the Microsoft Baseline Security Analyzer (MBSA), Microsoft Systems Management Server (SMS) version 2.0 and SMS 2003, and the Office Update Inventory tool.

Using the Microsoft Baseline Security Analyzer

Although it is critical to know which patches have been applied to your system, it is more important to know which patches have not been applied. MBSA was designed to scan computers that are running Windows NT 4.0, Windows 2000, Windows XP Professional, and Windows XP Home Edition, and to generate reports about which patches are present and which ones are required.

Note MBSA can be executed from any computer that is running Windows 2000 Professional, Windows 2000 Server, Windows XP Home, or Windows XP Professional. It cannot run on Windows 98 or Windows NT 4.0, and it does not scan computers running Windows 98.

The MBSA tool performs its scan by referring to an Extensible Markup Language (XML) database that Microsoft constantly updates. It also uses the popular “HFNetChk” tool that Microsoft released in August 2001. The XML file contains security bulletin names and titles 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 (KB) article numbers, and much more.

When you run the MBSA tool for the first time, it 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 you run MBSA it attempts 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 are running. MBSA then parses the XML file and identifies security patches that are available for your combination of installed software.

For 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 KB article number that relates to the patch is also displayed on the screen.

In general, the MBSA tool 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, along with instructions about how to fix any issues that are found.

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

The MBSA tool has a number of command line switches that can be used in two modes: MBSA mode and HFNetChk mode. 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 (UI). MBSA-style scans include the full set of available Windows, Internet Information Services (IIS), Microsoft SQL Server™, desktop applications, and security update checks.

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 standalone HFNetChk tool. MBSA 1.1 includes the "/hf" flag that will indicate an HFNetChk scan to the MBSA engine. In addition, in HFNetChk mode, MBSA can scan a list of computers supplied in a text file, and it can check systems to see whether they have all the patches published by a named Software Update Service (SUS) server.

If you are using MBSA to verify your patch status, you should ensure that it is run regularly. In most environments, the best way to do this is to schedule it to run at pre-set intervals.

Note For more information about using the MBSA tool, see the Microsoft Baseline Security Analyzer page on Microsoft TechNet at https://microsoft.com/technet/security/tools/mbsahome.mspx.

Office Update Inventory Tool

With the powerful application programming capabilities built into Microsoft Office, it has become important to pay attention to vulnerabilities within the applications themselves. Many viruses and Trojan horses take advantage of the ability of today’s productivity applications to act upon active content within documents, spreadsheets, and e-mail communications. To help keep Office deployments updated and secure, Microsoft released the Office Update inventory tool. This utility can be executed on computers running the Windows 98 operating system or later and Office 2000 or later. It allows administrators to accurately assess the patch levels of their Office deployments.

The Office Update Inventory Tool is available at https://office.microsoft.com/en-us/assistance/HA011402491033.aspx.

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 do this is to look in the computer's 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 KB article that discusses the hotfix. However, this is not the case for some older hotfixes and for hotfixes for some particular applications.

Other Tools for Determining Hotfix Levels

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

Evaluating and Planning Patch Application

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. Similarly, 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. This will allow you to make an informed decision about 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 describing how to remove the patch or mitigate failures in patch installation.

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 Worldwide Web site at https://microsoft.com/worldwide and then reference your country to then access the Microsoft Security Home page at https://microsoft.com/security/.

Categorizing Patches

As each new patch becomes available, you should determine its importance to your environment, which in turn will help you decide how soon you need to deploy the patch 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 6.1: Vulnerability Ratings , as Defined by Microsoft

Computer type

Critical rating

Moderate rating

Low rating

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 systems

Running of 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 and likelihood.

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.

Assessing the Patch

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

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

  2. 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 because it mitigates the risk of a single person missing critical and relevant points when evaluating the update.

  3. Verifying the patch category. After further assessment of the patch, you may need to change its category. This 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 system?

  • 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?

In addition to 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.

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 in order to fix potentially serious problems.

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

The amount of testing that 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. In the Trey Research scenario, each of the server roles still had to function properly after the recommended hotfixes were installed. This was confirmed 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 6.2: Minimum Testing for Patches

Patch type

Testing phases

Critical severity

Assessing the patch

Assessing server operations (Limited)

Moderate severity

Assessing the patch

Installing the patch in a test environment

Assessing server operations (Full)

Checking the uninstall procedure

Low severity

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 due to urgency, you should still continue to complete them in a test lab to find potential problems before they occur on already deployed systems.

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

Installing the Patch

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 to evaluate the benefits and drawbacks of applying the patch.

Testing Server Operations

After the patch is installed, you need to make sure that the server continues to work normally. 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 normally. How much risk you can handle on a particular server that has a particular vulnerability will determine how long you should allow the server to run before concluding that everything is running normally. If there are any problems, you need to make sure they are documented and reported to Microsoft as soon as possible.

Note You can use Microsoft Operations Manager (MOM) to collect Event Log and System Monitor information from Windows NT 4.0 servers.

Testing Application Operations

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

Preparing for Uninstallation

It is possible that, despite testing, you will encounter problems after installing the patch that result in your having to uninstall the patch. It is important, therefore, to test that the uninstallation 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 testing proceeds entirely without incident, it is still possible that there will be challenges as you deploy the patch throughout your organization. You need a plan of action to restore the system to its original state before the patch was deployed.

In some cases, this plan will consist of taking a snapshot backup of a server before the install occurs, so that the server can be restored quickly if problems occur. You should thoroughly test the rollback plan that your organization designs.

Deploying the Patches

If the testing has proceeded without incident, you are ready to deploy the patch across your organization. There are a number of ways to do this, including the following methods and processes:

  • Manual deployment.

  • Automated deployment tools from Microsoft or other vendors.

  • Scripts built in, and customized for, your environment.

Manual Deployment

Manual hotfix installation is the most common installation method. This method consists of simply running the executable that corresponds to the hotfix on each server. If your organization has many servers, though, this may be impractical. Because Trey Research has a moderate number of servers, and because the company's servers are spread among multiple locations, manual deployment is the current patch deployment method.

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 KB article number that provides more information about the hotfix.

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

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

  • x86 is the processor architecture for which it is designed.

  • en indicates the language in which the hotfix is released (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 Microsoft Internet Explorer.

Hotfixes also support several command line switches that you can use to control the behavior of the hotfix installation process. These switches are listed in the following table:

Table 6.3: 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

Use Quiet mode — no UI

-m

Use Unattended mode

-l

List installed hotfixes

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

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 UI and does not force a restart.

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

QChain is a tool that allows you to string together several Windows NT 4.0 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.

If additional Windows components, such as the Domain Name System (DNS) service, 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.

Scripted Deployment

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 that check the current patch status and then check updates from a centralized server. Your scripts can include QChain to ensure that only a single restart is needed if more than one hotfix is required.

Deployment Monitoring and Reporting

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 afterwards to make sure that nothing was missed.

In addition to 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 without installing the current patches. New servers should always receive the latest build, and your organizational monitoring policy should ensure that this happens.

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

Implementation

The Trey Research patch management solution includes a number of separate components that work together to deliver reliable, robust inventory and delivery services. The first step Trey performed was a comprehensive analysis of the company's existing network and systems. Patches are often applied inconsistently throughout an organization, and there is no documentation on why, when, and where they have been deployed. Trey wanted to build a unified patch management process that they could use to provide repeatable processes for consistently applying patches to the right computers at the right time.

Building Update Staging Servers

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 systems provide specialized locations for storing security tools, patches, hotfixes, service packs, and documentation. You can use these systems as a place to perform patch analysis, retrieval, and deployment. Microsoft Software Update Service (SUS) and Windows Update Services (WUS) are products that perform all these functions for Windows networks. However, SUS could not be used in the Trey environment because Windows 98 and Windows NT 4.0 do not support it, and Trey chose to build its own staging servers for testing and delivering patches. These servers are actually shares hosted on Microsoft Windows Server™ 2003 domain controllers; Trey downloaded the Microsoft Security Tool Kit, placed it on the staging servers, and used the patches contained therein to harden existing computers. In addition, Trey updated its server and workstation build process to include application of patches from the Security Tool Kit when new computers are built.

Trey chose to use its domain controllers as staging servers to ensure that the security update systems are on one or more dedicated computers that can be tightly controlled and secured. Trey made this decision because these systems will be used to deploy and maintain security patches for all systems in their environment.

Although security update systems do not generally need to be high-powered servers (because the load on them will typically be very light), maintaining high availability is very important.

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.

Note   MOF discusses update systems as part of the release management process.

Identifying Missing Patches

An ongoing analysis process is required to ensure that all servers and workstations remain current with all of the latest patches. To efficiently keep the computers on its network up to date, the Trey IT staff used a combination of the tools described previously in this chapter.

Scanning the Base Operating System

MBSA allows the Trey IT staff to regularly scan their Windows NT servers and workstations and catalog the results. At first, the IT director used MBSA to perform a quick baseline scan to identify systems that were missing patches; once those systems were patched, MBSA was scheduled to run regularly on different sets of systems.

To perform a baseline scan using MBSA

  1. Log on to a computer running Windows 2000, Windows XP, or Windows Server 2003 with an account that has administrative privileges for the computer or computers you want to scan.

  2. Open a command prompt.

  3. Launch the command-line version of MBSA with the –b switch, as follows:

    mbsacli.exe /hf –d <yourDomain> -b

    The –b switch runs MBSA in its baseline-scan mode, which will only check for patches identified as baseline by the Microsoft Security Response Center.

  4. Review the text report produced, which lists each system found, whether it was scanned, and information about any missing patches.

To perform a standard scan using MBSA

  1. Log on to a computer running Windows 2000, Windows XP, or Windows Server 2003 with an account that has administrative privileges for the computer or computers you want to scan.

  2. Launch MBSA and click Scan more than one computer.

  3. In the Domain Name field, type the name of the domain that you want to scan.

  4. Click the Start scan button and wait while MBSA enumerates and scans the systems on your network.

  5. Click Pick a security report to view.

  6. Select a computer from the list of security reports, and then double-click the associated computer name.

  7. Review the report.

Note   The "Microsoft Baseline Security Analyzer V1.2" white paper, available at https://microsoft.com/technet/security/tools/mbsawp.mspx, contains a complete description of the scanning modes and vulnerability checks that MBSA performs.

Scanning Office Installations

You can use the Office Update Inventory Tool described previously in this chapter to scan individual workstations for critical Office updates. However, it requires that a client executable be installed and run for each system. Because Trey Research will be migrating to Office 2003 as a part of its IT modernization plan, the company has a mix of Office 2000 and Office XP installations, and administrators have already installed the current service packs as part of normal system maintenance. Trey assessed the risk of a network compromise due to an Office security flaw as relatively low, so it has adopted a strategy that allows users to directly visit the Office Update Web site at https://office.microsoft.com/officeupdate to check for updates. Critical systems, and those belonging to executives, are scanned in one of two ways:

  • Systems running Windows NT, Windows 2000, and Windows XP are scanned using MBSA in local mode, which checks for Office security patches on the local computer only.

  • Systems running Windows 98 are manually scanned using the Office Update Inventory Tool.

Planning for Patch Application

The Trey Research IT director wrote a patch application plan template that is used as the base for the company's monthly patch application plans. Because Microsoft releases security patches on a predictable schedule, having a template allows Trey administrators to follow a standardized process to evaluate, assess, and deploy each set of security patches when Microsoft releases it. Template guidelines include:

  • What services, systems, and applications are considered to be business-critical and which ones are optional or non-essential.

  • How to determine whether a patch applies to a particular system or set of systems.

  • How to determine whether the patch may cause other problems.

  • Instructions for identifying dependencies for each patch.

  • Criteria for deciding whether a vulnerability is sufficiently important to require emergency installation or scheduling of an additional patch deployment.

  • Who must review and approve patch deployment.

  • How to roll back patch installation in the event of a failure.

In addition to developing this template, the Trey IT staff signed up for the Microsoft security notification service, and they regularly review the Microsoft Security Home page at https://microsoft.com/security/.

Categorizing Patches

Trey Research uses the standard Microsoft categorization scheme for patch severity, as shown earlier in Table 6.1. However, the company adds an additional parameter to the categorization: an indication of whether the patch is applicable to its environment. For example, because Trey is not currently using Office 2003, patches for it would receive a rating of “not applicable,” regardless of the severity that Microsoft associates with the vulnerability. Alternatively, because Trey uses Microsoft Data Engine (MSDE) and SQL Server 2000 heavily, all SQL Server patches are rated as “applicable." This approach requires more categorization effort, but it allows Trey to focus their effort on patches that are most pertinent to the company's environment.

Testing the Patches

The lead IT administrator at Trey Research developed a patch test plan that establishes the conditions for testing patches for wide deployment based on their severity, their applicability, and the nature of the systems being patched. Trey chose to adopt the Microsoft recommendations for the level of testing (outlined in Table 6.2) and built a model of its production network for lab use that contains representations of workstations and servers. New patches are first deployed to the test lab to verify that the patches install properly and that they do not break anything critical. If initial testing is successful, patches are deployed according to the criteria in the patch application plan.

After the patch is installed in the test lab, Trey performs a standard set of tests. These tests include adding and removing resources in Microsoft Active Directory® directory service and running a standard set of the company's line-of-business applications. In addition, test pass criteria require checking the Event Log and System Monitor for any unexpected results.

Note   You can use Microsoft Operations Manager (MOM) to collect Event Log and System Monitor information from Windows NT 4.0 servers.

Deploying the Patches

If the testing has proceeded without incident, Trey Research deploys the patches to systems that require it. They use a combination of two methods: manual deployment by administrators or affected users and automated deployment using custom scripts.

Manual Deployment

Manual hotfix installation is the most common installation method. This method consists of simply running the executable corresponding to the hotfix on each server. If your organization has many servers, though, this method may be impractical. Because Trey has a moderate number of servers, and because the company's servers are spread among multiple locations, manual deployment is the standard patch deployment method for servers. To avoid unnecessary downtime, the IT staff installs fixes using the –z switch to prevent reboots until after the last patch is installed; the last step in the installation process is to run Qchain.exe to unify all files installed during the patch operations.

Scripted Deployment

Trey Research built a custom script that uses QChain to install multiple hotfixes and reboot the computer after the last fix is installed. The script is described in KB article 296861, "How to Install Multiple Windows Updates or Hotfixes with Only One Reboot" at https://support.microsoft.com/?kbid=296861. The following script sample shows how Qchain was used:

@echo off
setlocal
set PATHTOFIXES=some path
%PATHTOFIXES%\Q123456_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\Q123321_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\Q123789_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\qchain.exe

Summary

The majority of breaches in IT security come from exploitation of system environments that are not fully up to date with security patches. Good patch management is essential to minimizing the security risks that you face. If you treat patch management seriously you will likely be able to dramatically reduce the costs associated with security breaches. For Trey Research, as in most organizations, patch management is an ongoing process; servers must be kept up to date with security-related hotfixes.

More Information

Third-Party Tools

A number of 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 covered by the tools described previously, and use a graphical user interface (GUI) for administrative tasks. You should evaluate these features and determine whether they are appropriate for your environment. Available third-party tools include:

Download

Get the Microsoft Windows NT 4.0 and Windows 98 Threat Mitigation Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions