Update Management Process

Article
06/29/2009

Updated : June 1, 2007

In This Module

This module describes the second phase—Identify—of the four-phase update management process. The Identify phase is concerned with the reliable discovery of new software updates, whether new updates are relevant to your production environment, and whether an update represents a normal or emergency change.

The purpose of this module is to describe the principles of the Identify phase of the update management process, and to introduce the types of tasks that will enable you to carry out identification using Microsoft Windows Server Update Service (WSUS) and Microsoft Systems Management Server (SMS).

Note: Beta 2 of the next release of SMS, entitled System Center Configuration Manager 2007, is now available for download at https://www.microsoft.com/technet/sms/2007/evaluate/download.mspx. With major investments in simplicity, configuration, deployment and security, Configuration Manager 2007 dramatically simplifies system deployment, task automation, compliance management, and policy based security management allowing for increased business agility.

After reading this module you will be able to plan the tasks required to:

Discover new software updates.
Determine whether new updates are required in your environment.
Determine whether an update requires standard or emergency update deployment.

Without an identification process, you will not know what software updates are available, what updates you require, how to obtain virus-free, checked and tested updates, and whether an update needs to be deployed rapidly or as part of a planned scheduled rollout.

Objectives

Use this module to:

Discover new software updates.
Determine whether software updates are relevant.
Obtain safe and reliable software update source files.
Categorize the software update as a normal change or an emergency.

Applies To

This module applies to the following products and technologies:

All Microsoft products and technologies

How To Use This Module

This module describes the Identify phase of the four-phase update management process. It describes the basic tasks required to carry out identification using Microsoft Windows Server Update Service (WSUS) and Microsoft Systems Management Server (SMS). Detailed instructions are provided in the WSUS and SMS Technical Libraries listed below.

To gain the most from this module:

Read the Introduction portion of the “Update Management Process" module. This will give you an overview of all phases in the four-phase update management process and provides an introduction to the tools available to support update management in Microsoft Windows operating system environments.
Use the WSUS and SMS Technical Libraries for more detailed reference materials. These libraries are located at:
- Windows Server Update Services (WSUS) Technical Library
- Technical Library for Systems Management Server 2003

Overview

The Identify phase is the second phase in the update management process shown in Figure 1.

Figure 1 The update management process

Figure 1 The update management process

The goal for the Identify phase is to:

Discover new software updates in a reliable way.
Determine whether software updates are relevant to your production environment.
Obtain software update source files and confirm that they are safe and will install successfully.
Determine whether the software update should be considered a normal change or an emergency, and submit a request for change (RFC) to deploy it. Submitting an RFC is the trigger for the next update management phase, which is Evaluate and Plan.

The remainder of this module describes those goals in more detail. It also addresses how you can meet these goals more quickly if you are dealing with an emergency.

Discover a New Software Update

Identification of a software update starts with discovering it in a safe and reliable way. Discovery has two main components:

How you are notified of a new software update
How you know you can trust the source and the notification

How You Are Notified of a New Software Update

Discovering a new software update starts with notification. Notification should be supplied either through subscription to a reliable source that provides scanning and reporting activities, or by some other reliable notification mechanism. The most commonly used notification mechanisms are:

E-mail notifications.
Vulnerability scanning tools.
The WSUS Server Administration page.
The SMS Software Update Management feature.

E-Mail Notifications

Notification by e-mail is the most common form of update notification. One option for e-mail notification is to subscribe to the Microsoft Security Notification Service at https://www.microsoft.com/technet/security/bulletin/notify.mspx. For interim product releases, or software updates, you will normally receive an e-mail message informing you that new software updates are available on the Microsoft Web site.

An example of an e-mail message notifying administrators of new security updates is shown in Figure 2.

Figure 2 Example e-mail message notifying administrators of new software updates

How You Know You Can Trust the Source and the Notification

It is important to handle e-mail notifications carefully. The following guidelines are designed to help you to validate each notification and ensure it is the latest security bulletin information available:

Immediately delete any e-mail notifications claiming to be from Microsoft that contain any attached software files. Never run or install any executable attached to an e-mail notification.

Note: Microsoft has a policy of never distributing software through e-mail attachments. Please review the Microsoft Policies on Software Distribution at https://www.microsoft.com/technet/security/bulletin/info/swdist.mspx.
Do not click any links directly from inside an e-mail notification. Instead, you should paste any URLs into a browser window to confirm that they direct you to a Microsoft Web site.
Always visit the Microsoft TechNet Security Center Web site at https://www.microsoft.com/technet/security/default.mspx to read the authoritative details of a security bulletin. Alternatively, if you do not expect to have Internet access when receiving bulletins, familiarize yourself with Pretty Good Privacy (PGP) encryption tools and use one to verify the authenticity of the PGP signature included on each security bulletin.
You can download the Microsoft Security Response Center (MSRC) Security Bulletin key from: https://www.microsoft.com/technet/security/bulletin/pgp.mspx
Microsoft digitally signs all e-mail notifications related to security updates when it sends these notifications to customers. More information about how to verify the digital signature is available at https://www.microsoft.com/technet/security/bulletin/notify.mspx

Note: There are several e-mail hoaxes that claim to be notifications from Microsoft. When you receive a Microsoft Security bulletin, confirm it and all hyperlinks to software updates by visiting the Security Bulletin Search Tool Web site at https://www.microsoft.com/technet/security/current.aspx. For more information about these types of hoaxes, see "Recognize and avoid fraudulent e-mail to Microsoft customers" at https://www.microsoft.com/technet/security/bulletin/info/patch_hoax.mspx

If you use WSUS, you can sign up for the update-alert service, which informs you of new updates through an e-mail message. To identify these updates you must force synchronization between the WSUS server and the public Windows Update server whenever you receive the update notification e-mail. You use the Synchronize Now option in the WSUS Server Administration Page to do this. For more detailed information on using WSUS in the Identify phase, read the module, see Windows Server Update Services (WSUS) Technical Library.

If you use SMS, each time you receive a new e-mail notification you must determine whether SMS 2003 will be able to detect that the update is applicable to systems in your production environment:

If the update is for software that is not supported or detectable by Microsoft Baseline Security Analyzer (MBSA), you will need to use the SMS 2003 Hardware Inventory and Software Inventory Client Agents to determine which computers need the software update.
If the update can be detected by MBSA, you can use the software update management tools in SMS 2003 to identify the computers requiring the update.
If the update is for a Microsoft Office application, and the update is in the list of updates supplied by the Microsoft Office Inventory Tool for Updates, you can use the software update management tools to identify the computers requiring the update.

For more information about using SMS in the Identify phase, see Technical Library for Systems Management Server 2003.

Vulnerability Scanning Tools

As mentioned earlier in this module, administrators can use MBSA along with WSUS to scan for missing and installed security updates on local and remote computers and to determine whether the computer is exposed to common security vulnerabilities such as a blank administrator password. For more detailed information on using WSUS in the Identify phase, see Windows Server Update Services (WSUS) Technical Library.

You can also use components of the Software Update Management feature in SMS 2003 to scan for, and report on, missing and applied software updates across your environment. For more information on SMS, see Technical Library for Systems Management Server 2003.

Determine Whether Software Updates Are Relevant

A large number of software updates are regularly released into the information technology (IT) operations community. These come from a variety of sources and have been created for many reasons, including addressing problems that could lead to security breaches. All software updates must be checked thoroughly for their relevance to the IT infrastructure of your organization. The screening process outlined in this section should remove the majority of irrelevant software updates, but it is likely there will still be more that you can discount.

Each software update received should be checked for relevance. When a notification contains information about more than one software update, each update needs to be checked individually for its relevance to the organization.

The first step in checking for relevance is determining whether the software update is designed to address the operating system or applications in your production environment.

Once you have determined that the software update applies to something in your production environment, the next question is whether the application or system that the update applies to exhibits the vulnerability the software update is designed to address. For example, a software update might be designed for all Windows Server operating systems running Microsoft Internet Information Services (IIS) with Active Server Pages (ASP) enabled.

While your environment might contain several Windows Server operating systems, the security update is not relevant if your organization does not have ASP enabled on any IIS servers.

Not every security update that applies to something in your environment will be relevant. Although it is important to be aware of, and have a good understanding of, existing security updates, you should only deploy security updates that have relevance to your environment. This will minimize the effort that is required to keep your environment up-to-date and secure.

Although the information in a software update might be classified as irrelevant, it is important to note that it exists by passing the information to personnel in problem management. If it later becomes relevant and is required, the organization will have access to this information at the original source.

There are several screening methods that you can use to determine the applicability of a software update to your IT infrastructure:

Reading security bulletins and Microsoft Knowledge Base (KB) articles.
Reviewing the individual software updates.
Using the SMS Administrator console.
Using SMS built-in reports.

Reading Security Bulletins and KB Articles

Information in security bulletins on the Microsoft Web site is arranged into sections that help you to determine how critical the described vulnerabilities are to your environment. Although you should review all information in a security bulletin, pay close attention to the sections shown in Table 1 when you first examine a security bulletin.

Table 1: Security Bulletins - Key Information

Section	Description
Summary	Immediately review the Summary section of a security bulletin. The Maximum Severity Rating, Impact of Vulnerability, Affected Software, and Recommendation items contain information that will assist you with determining how susceptible your environment is to the vulnerability.
Vulnerability Details	The Vulnerability Details section provides an in-depth technical description of the vulnerabilities. This section also outlines the mitigating factors and the severity of the vulnerability for all affected products.
Workarounds	The Workarounds section includes information on the workarounds that Microsoft has tested in order to help mitigate the threat until you have updated your environment. You must read this section as part of your risk assessment.
Frequently Asked Questions	The Frequently Asked Questions section provides answers to commonly asked questions specific to that vulnerability or fix. This is a good place to start after reading the Summary section.
Security Update Information	This section lists items like Prerequisites, platform-specific Installation Information, Deployment Information, Restart Information, Removal Information, File Information (including file names, size, versions, target folder), and Update Verification steps.
Knowledge Base article	Refer to the KB article identified in the title of a security bulletin. Additional information on the vulnerabilities and any updates prescribed by the security bulletin is provided in the KB article. The number in parentheses to the right of a security bulletin's title indicates the security bulletin's corresponding KB article. Use this number to search for the article on the Microsoft support Web site at https://www.support.microsoft.com/.

For more information on the security bulletin release process, see the "Revamping the Security Bulletin Release" white paper at https://www.microsoft.com/technet/security/bulletin/revsbwp.mspx.

The information gathered in the initial notification and the further information discovered by reading the security bulletin and associated KB article will help you to decide whether the software update has relevance to your organization.

The brief descriptions in the Summary section of a security bulletin should enable you to make a quick assessment of the potential impact the vulnerability might have on your environment without having to closely review the entire contents of a bulletin.

The Summary highlights the type of exploit, provides a list of the affected software, and recommends the proper course of action. After reviewing the Summary, you should be able to determine whether you must perform an immediate in-depth review of the remaining sections of the security bulletin.

Using high-level relevancy checks, you should be able to isolate the computers in your environment likely to be affected by the vulnerability.

In addition to the items described in Table 1, the Microsoft Security Response Center (MSRC) has implemented the Maximum Severity Rating System to assist you with quickly determining how important an update is to your organization. These ratings are based on the potential impact of the vulnerability and are intended to inform you of the urgency of any required actions.

Determining the relevance of technology-specific software updates can pose significant challenges in any environment. Technologies such as the Microsoft Data Engine (MSDE) or IIS, which can be installed on clients or servers, can make it difficult to determine if a software update is relevant to any specific subset of computers in your environment. This emphasizes the importance of maintaining as accurate an inventory of your environment as possible.

Reviewing Individual Software Updates

Each software update in a notification requires a detailed and in-depth review. This review should include all associated documentation, including that sent with the software update and supporting information that might be found, for example, on the Microsoft TechNet Web site.

Once you receive an e-mail message identifying applicable software updates, you must make someone responsible for investigating them. This team member should then take ownership of the software update. The reviewer needs to read the relevant KB article and understand what is fixed by the software update.

The software update may be specific to particular scenarios or configurations. The reviewer should check whether the scenario/configuration deployed in production matches that covered by the KB article.

There are also questions to ask in terms of software update dependencies:

Are there dependencies relating to the update? For example, do certain features need to be enabled or disabled for the update to be effective?
Does the software update require a certain service pack to be installed? Is the software update superseded by a service pack or another software update and does it makes sense to wait for a newer version?

Identifying the above dependencies is critical because it will have a direct impact on your release and deployment planning for the software update. Document which service pack (SP) the software update will appear in and whether a different version of the software update is required, depending upon the active service pack. (It is important to know this in case compliance problems occur as users upgrade from one service pack to another.)

You can use the scan results and reports generated by the SMS 2003 Software Update Management features to view the specific and applicable information regarding a software update. If you use WSUS, this documentation can be accessed from the WSUS Server Administration Page. For more information about WSUS and SMS, see Windows Server Update Services (WSUS) Technical Library and Technical Library for Systems Management Server 2003.

Obtain and Verify Software Update Source Files

Once a software update has been identified and its relevance established, you must obtain the software update source files and confirm that they are safe and will install successfully. The verification process will either authenticate security updates or highlight updates that are not security-validated. In the latter case, when an invalid notification is received, information about the notification should be sent to those responsible for the subscription process and to the security team for further investigation. For example, if a notification comes from a normally reliable source of information, but the specific notification has errors on validation, this might raise security concerns about the quality of the notifications from this particular source. The source should be investigated and any issues resolved.

At a minimum, your software update verification should consist of the following steps:

Identifying and verifying the software update.
Reviewing all accompanying documentation:
- Reviewing software update files.
- Identifying software update size.
- Identifying software update dependencies:
- Identifying any pre-updating or post-updating actions needed.
- Verifying that software update install procedures exist.
- Verifying that software update uninstall procedures exist.
Ensuring that the software update is safe.

Identifying and Verifying the Software Update

Microsoft notifies administrators of new software updates through e-mail messages, but it never includes (or attaches) software files to these messages. The following are key Microsoft practices with regards to notification and verifying Microsoft as the software update owner:

Microsoft will occasionally send an e-mail message to customers to inform them that upgrades and software updates are available. However, the message will provide links to the download sites only. The software itself will never be attached. These links will always lead to either the Microsoft Web site or the Microsoft File Transfer Protocol (FTP) site, never to a third-party site. Some malicious e-mail messages might contain Internet links in which the link is not the same as the text shown in an HTML-formatted e-mail message. It is important to ensure that somebody is responsible for checking the Universal Resource Locator (URL) of the Web site visited.
In addition to links provided in e-mail notifications, Microsoft makes software updates available on the Internet. The files can be accessed from https://www.microsoft.com, through the FTP site at ftp://ftp.microsoft.com, or via the Microsoft Update Web site at https://windowsupdate.microsoft.com.
The software update files may also be provided on physical media such as CD- ROMs and floppy disks.
Microsoft always uses Authenticode technology to digitally sign its products and allow administrators to ensure that the files have not been tampered with, as shown in Figure 3.

Figure 3 Authenticode digital signature

More information about Microsoft policies on software distribution is available at https://www.microsoft.com/technet/security/bulletin/info/swdist.mspx.

Reviewing All Accompanying Documentation

Before applying any software update, you should read and peer review all relevant documentation. The peer-review process is crucial as it mitigates the risk of a single person missing critical and relevant points when evaluating the update. As you read the documentation, look for answers to the following questions:

Will adopting the update cause other problems, resulting in a compromise of the production system?
Do you need to perform any actions prior to deploying the update?
Do you need to perform any actions after deploying the updates?
Are there workarounds or mitigation steps available while you update your environment?
Are software update install procedures available?
Are software update uninstall procedures available?
What is the software update file size? File size will impact your overall release process and plan-for example, how you handle mobile users.

You will find information in the security bulletin, under the sections described earlier in Table 1, which will help you to find answers to these questions.

Ensuring That the Software Update Is Safe

To prevent virus infection or malicious code from affecting your IT infrastructure, you should look at any files related to a software update in an isolated (quarantined) environment. This quarantine should be imposed on all software and documentation. There should be strict controls in place in the quarantined environment and, to ensure this, the quarantine process should be carried out by a group of specialists in the organization.

On rare occasions, software updates will only require you to make registry or configuration file changes or adjust application settings, but most software updates will involve downloading files. Always quarantine the files that you download by isolating them from your production network while you examine them for viruses and confirm their digital authenticity.

If you use WSUS, each update is signed; a hash is computed and sent with the metadata (metadata that describes what an update is useful for). When an update is downloaded, WSUS checks the digital signature and hash. If the update has been tampered with, it is not installed. To get more detailed information on using WSUS in the Identify phase, see Windows Server Update Services (WSUS) Technical Library.

Note: The Microsoft Download Center, Microsoft Update, and SMS 2003 with Software Update Management features provide only authentic, Microsoft software updates. If you receive a Microsoft software update through any other means, be sure to confirm its validity and digital signature.

Verifying the Software Update Install Procedures

The following are some guidelines for verifying the software update install procedures:

Follow the instructions given in the Knowledge Base articles and security bulletin accompanying a software update to verify that it installs correctly.
Determine whether the software update requires a restart. If it requires a restart, you will have to take into account special considerations during the planning and deployment phases for mission-critical servers, core infrastructure servers, and servers running line-of-business (LOB) applications. To get more information on these issues, read the module, "Update Management Phase 3 - Evaluate and Plan."
Assess how much disk space the software update requires (including an Uninstall folder).
Check whether the update provides configuration options that are available to you during the install.
Read any supporting documentation for additional information about installing a software update.

Despite your testing, you may run into problems after installing the software update that require you to uninstall it. It is important, therefore, to test that the uninstall procedure 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.

Some of the updates released by Microsoft provide an uninstall path, whereas others do not. You will have to determine which software updates can be uninstalled by reviewing the technical details in the security bulletin under the Security Update Information section.

Decide Nature of Software Update and Submit RFC

Now that you have identified the software update, determined its relevance to your organization, obtained software update source files, and confirmed that they are safe and will install successfully, the next step is to submit a request for change (RFC) to start the evaluation and planning phase of the software update.

The change request submitted must address the following information:

What is the change?
What vulnerability is the change in response to?
What services will be impacted by the change?
Is a software update already being deployed for that service?
Does the software update require a restart to complete the installation?
Can the software update be uninstalled?
What, if any, countermeasures can you implement to give you more time to test and deploy the software update?
What are the recommended test strategies for this change?
What is the suggested priority of the RFC?
What is the impact (category) of the change?

If a software update addresses a critical security issue or system instability, the priority of the RFC should be marked as "emergency" An emergency RFC should be created only when the deployment of a software update or the implementation of security countermeasures such as closing network ports must be performed as a matter of urgency.

Summary

The following are the key points to remember from the Identify phase:

You must ensure that you are notified of all new software updates.
You should confirm that the software update notification comes from an authorized source.
You should check that the software update is relevant to systems in your production environment.
You must obtain the software update source files and confirm that they are virus free.
You must check that the software update installs successfully.
You must decide whether the software update is an emergency and submit an RFC to deploy it into production.

Handover to the Evaluate and Plan Phase

You have completed the requirements of the Identify phase and are ready to proceed to the Evaluate and Plan phase when:

You have verified that you have a relevant software update that is safe to deploy.
You have submitted a request for change (RFC), which is the trigger for the Evaluate and Plan phase.

For more information about the Evaluation and Plan Phase, read the module, "Update Management Phase 3 - Evaluate and Plan."