Update Management Process

Updated : June 1, 2007

On This Page

In This Module
Objectives
Applies To
How To Use This Module
Overview
Inventory Existing Computing Assets
Assess Security Threats and Vulnerabilities
Determine the Best Source for Information About Software Updates
Assess the Existing Software Distribution Infrastructure
Assess Operational Effectiveness
Summary
Handover to Identify Phase

In This Module

This module describes the first phase—Assess—of the four-phase update management process. The Assess phase is concerned with auditing the software in your production environment, evaluating potential security threats and vulnerabilities, and assessing your update management infrastructure.

The purpose of this module is to describe the principles of the Assess phase of the update management process, and to introduce the types of tasks that will enable you to carry out assessment using Microsoft Windows Server Update Services (WSUS) and Microsoft System Center Configuration Manager 2007 (SCCM).

Note: As previously mentioned in the Introduction Module, the next release of SMS, entitled System Center Configuration Manager 2007 is now available. 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 needed to determine:

• What you have in your production environment.

• What security threats and vulnerabilities you might face.

• How and when your organization is prepared to respond to new software updates.

Without an ongoing assessment process, you will not know what computing assets you have, how you can protect them, and how you can ensure that your software distribution architecture is able to support update management.

Objectives

Use this module to:

• Inventory existing computing assets.

• Assess security threats and vulnerabilities.

• Determine the best source for information about new software updates.

• Assess the existing software distribution infrastructure.

• Assess operational effectiveness.

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 Assess phase of the four-phase update management process. It describes the basic tasks required to carry out assessment using Microsoft Windows Server Update Services (WSUS) and Microsoft Systems Management Server (SMS).

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 Assess phase is the first major phase in the update management process shown in Figure 1.

Figure 1 The update management process

Ideally, it is an ongoing process that you should follow to ensure that you always know what computing assets you have, how you can protect them, and how you can ensure that your software distribution architecture is able to support update management.

The remainder of this section will focus on the key requirements for ongoing assessment. Those requirements are:

• Inventory existing computing assets.

• Assess security threats and vulnerabilities.

• Determine the best source for information about new software updates.

• Assess the existing software distribution infrastructure.

• Assess operational effectiveness.

Inventory Existing Computing Assets

From an update-management automation perspective, there are two types of inventory targets. Systems that are managed, using a management tool such as Microsoft Windows Server Update Services (WSUS), or Systems Management Server (SMS), are categorized as managed infrastructure. Those that do not have a working SMS agent, a working Automatic Updates client (for use with WSUS), or that have been purposefully excluded from management automation, are considered unmanaged infrastructure. Unmanaged infrastructure may include such systems as:

• Security systems, external and DMZ hosts, and known systems in specific environments such as test and development.

• Stand-alone computers.

Unmanaged assets still need to be addressed by update management. You must check these systems to ensure that the latest software updates have been installed. Manual checks, or the use of Microsoft Update, might be the most effective way to deploy software updates into such systems.

Identifying the update management requirements of stand-alone computers, or computers that are not members of a domain under your control can be challenging. Without local administrative rights to these unmanaged clients, you may find it very difficult to collect system information beyond computer name and Internet Protocol (IP) address. However, this basic information can serve as the basis for identifying unmanaged clients in your environment.

Note: For systems based on Microsoft Windows, Microsoft Baseline Security Analyzer (MBSA) will report the names and IP addresses of computers that it cannot scan because the user account that initiates the scan does not have administrative rights to the target computers.

What Information Must Be Collected?

Effective update management requires accurate and current knowledge of what hardware and software has been deployed in the production environment. Without this information, you will not be able to determine which computers in your environment require a software update. It is also important to determine the manner in which client computers are connected to the network. If some connect through slow or unreliable links or use remote access, such as dial-up facilities, the method of distributing and installing a software update will differ from the method used for computers that are connected to a fast, reliable network.

The following sections outline the information that must be retrieved from computers deployed in the production environment in order to perform effective update management.

Identifying Hardware Types and Versions

Understanding whether a computer is a portable computer (mobile client), desktop computer, or server will help administrators to determine how a particular software update needs to be installed. If you are updating a server, for example, you may need to observe outage windows (specific times at which changes and computer restarts are permitted) or ensure that the server is backed up before you deploy the software update.

SMS allows you to create collections that contain servers that can be updated in a specific outage window, which ensures that software updates are not installed during normal business operations. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Identifying Operating System Types and Versions

Administrators must be aware of all operating system (OS) types and versions that have been deployed into the production environment. MBSA will report on missing security updates and service packs and will identify vulnerabilities for installations of the Microsoft Windows Server 2003, Windows Vista, Windows XP, Windows 2000, and Windows NT 4.0 operating systems. It will also report on whether the computer configuration adheres to common security best practices (such as strong passwords).

Identifying Applications and Middleware

As with the operating system and service pack version, administrators must be aware of all deployed software applications and versions.

If you deploy WSUS, you must use MBSA 2.0.1 to identify missing security updates. MBSA will also identify misconfigured security settings for some applications (for example, Microsoft Office, Internet Information Services (IIS), Internet Explorer, and Microsoft SQL Server). For more detailed information on using WSUS in the Assess phase, see Windows Server Update Services (WSUS) Technical Library.

If you use SMS 2003, the Hardware Inventory Client Agent can be used to collect information about all installed applications, service packs, and software updates that have registered in the Windows Add/Remove Programs program. The SMS 2003 Software Inventory Client Agent can be used to obtain details of every executable (.exe) file installed, which includes all applications, even those that do not register in Add/Remove Programs. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Determining Roles

It is essential to determine the role of a computer because administrators require this information in order to evaluate the impact of restarting the computer once a software update has been deployed. For example:

• If the computer is a server running a business-critical application, you might have to reschedule the installation of a software update during periods when it will have minimal impact on your business. It also may be necessary to make arrangements for business continuity, for example, so that users can continue to make use of the application while the server is being restarted.

• If the computer is a domain controller holding one or more of the operations master roles also known as flexible single master operations (FSMOs), you will have to move these roles to other domain controllers in the domain while the computer is being updated. You should restore the roles back to the original computer when it restarts successfully.

If you use SMS 2003, the Hardware Inventory Client Agent can report on the services running on a particular computer. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Note: As previously mentioned in the Introduction Module, 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.

Understanding Connectivity

Understanding the layout of your network infrastructure, its capabilities, security level, link speed, and link availability is important for effective updating. Software updates can vary in size, and knowing the constraints of your network infrastructure can potentially reduce any delays in distributing software updates. It can also dictate the manner in which the software update will be deployed to particular client computers.

SMS Network Discovery can provide information on the network topology and the devices connected to the network. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Identifying Installed and Missing Software Updates

Identifying which software updates have or have not been installed on computers is essential. If you use WSUS, you must use MBSA to determine which software updates are needed on servers and workstations in your organization, as WSUS does not include any specific auditing tools. However, MBSA cannot detect the presence or absence of software updates for all operating systems and software applications. For a full list of those it can detect, see Microsoft Knowledge Base article 895660 titled "Microsoft Baseline Security Analyzer (MBSA) 2.0 is available" at https://support.microsoft.com/kb/895660. If your organization requires comprehensive auditing of hardware and software, the ability to update installed applications such as SQL Server 2000, and the ability to deploy software updates that are not related to security, you should consider deploying SMS to support update management. For more detailed information on using WSUS in the Assess phase, see Windows Server Update Services (WSUS) Technical Library.

If you use SMS 2003, you can use the Security Updates Inventory Tool and the Inventory Tool for Microsoft Updates (part of Software Update Management) to extend SMS hardware inventory to report on the software updates that must be installed on a set of clients. SMS 2003 clients compare what has been installed against the list of available software updates contained in the latest software update catalog (Mssecure.cab) downloaded from the Microsoft Update Web site. Although this tool will not report on missing service packs, you can use SMS hardware and software inventory client agents to discover the currently installed service pack. SMS 2003 also includes the Microsoft Office Inventory Tool for Updates, part of Software Update Management. This extends the SMS hardware inventory so that it reports on required Microsoft Office software updates. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Conducting Inventory/Audit

An audit helps an organization to understand and gain an accurate record of its production environment prior to determining baselines using the tools previously identified. You should also add the results of the audit up to this point to your organization's central repository for tracking information about your production environment. This will act as a dual reference point, ensuring the audit is not only correct, but also that you have updated your repository. You should note any differences between the audit result and the repository record and pass that information to your problem management team for investigation. Problem management team members should attempt to determine the point of failure in the recording of the information and develop a workaround if necessary, to prevent similar instances in the future.

Because accurate and up-to-date information about what is present in the environment is essential for update management, administrators need to check that an audit has been done before they can begin to use WSUS or SMS to deploy software updates into the production environment.

If you use WSUS you will need to use MBSA to identify the installed applications, as well as the security updates that are missing to make those applications secure. For more detailed information on using WSUS in the Assess phase, see Windows Server Update Services (WSUS) Technical Library.

If you use SMS 2003, the first step in checking for audit success is to confirm that the Microsoft Office Inventory Tool for Updates and Security Updates Inventory Tool have run successfully. This is done by checking the status messages to see if there have been any failures. You should then check the status of hardware and software inventory on each SMS client by creating a Web report that lists SMS client computers on which the hardware and software inventory client agents have failed to install, or those on which they have failed to run during a specified time period. For more detailed information on using SMS in the Assess phase, see Technical Library for Systems Management Server 2003.

Analyzing Inventory Data for Completeness

Once the audit has been carried out, administrators need to check the results for completeness and ensure that all managed computers have reported up-to-date information. The following activities should be performed:

• The audit results should be compared with a prior audit, and an increase or decrease in computers detected noted. A significant shift in the counts as compared to prior audits may indicate a gap in completeness.

• The audit results should also be compared against computer objects (computer accounts) in Microsoft Active Directory directory service domains. As long as stale accounts are cleaned up, this will be as useful as comparing against name resolution services.

• Systems in active use will register and use the name resolution services-Windows Internet Name Service (WINS) and Domain Name System (DNS)-in your environment. Scripts that cross-reference against active infrastructure such as these services may give a comprehensive view of how complete the inventory for update management is. Ensure that scavenging or cleanup of stale records is enabled on your name resolution servers to obtain more accurate results.

If analysis discovers a discrepancy in the information returned, you should investigate further to determine the cause and take steps to ensure that systems missed by the audit are included in the next audit run.

Baselining Your Environment

A baseline is a set of documented configurations of a product or system that is established at a specific point in time. Baselines establish a standard that systems of the same class and category must match. Effective IT operations use baselines as a trusted point from which systems are built and deployed. Typically, the configuration defined by a baseline is stringently tested and vendor-certified.

An application or software baseline provides the information required to rebuild a system to a desired state. It might be necessary to establish baselines for different software applications, hardware vendors, or types of computers.

Baselining requires that you perform and maintain an accurate inventory of the computers and services in your environment. Keep in mind the following points when establishing baselines for your environment:

• Infrastructure that falls below the baseline must be addressed through problem management. You should bring all the computers that have been identified as below the baseline up to compliance. These computers may have had issues with distribution, schedules, or permissions, or may require special care through exception handling.

• Infrastructures that exceed the baseline are not necessarily at an advantage. Computers exceeding their class baseline should be checked to determine if unauthorized changes have occurred. In some cases, it may be necessary to return a system to a trusted level or it may be appropriate to control it through a change freeze. Systems that exceed an approved baseline contain application versions or software updates that have not been tested for interoperability and formally approved by IT Operations and IT Security.

• Some systems may have special circumstances that make them exempt from the baseline of their class. For example, an older workstation running a legacy payroll application that connects to a processing agency by means of a modem may require an operating system level far below the established baseline. It may not be appropriate to upgrade this system to the latest baseline since this could prevent the legacy application from running.

Assess Security Threats and Vulnerabilities

Once you understand what computer systems and data have been deployed in the production environment, you should carry out an ongoing security assessment to determine the steps that should be taken to protect the availability, integrity, and confidentiality of computer systems and data. At a minimum, the security assessment must cover the following:

• Identifying security standards and policies.

• Determining how security policies and standards are to be enforced.

• Analyzing system vulnerabilities.

For more detailed information about performing a security assessment, see the "Security Risk Management Guide" at https://www.microsoft.com/technet/security/topics/complianceandpolicies/secrisk/srsgch01.mspx.

Identifying Security Standards and Policies

An effective security policy should identify the minimum security standards for computers and help to minimize exposure to potential security vulnerabilities. To be effective, an organization's security policy should be reviewed whenever changes are made to IT systems and software in the production environment and include, at a minimum, the following items:

• Installation standards, describing supported installation locations and methods.

• Network and domain standards, indicating how names and Transmission Control Protocol/Internet Protocol (TCP/IP) information is assigned and which domains computers should join.

• Operating system security options and policy settings, including those for reducing open ports based on required services.

• Any standards that describe the use of encrypted file systems.

• Minimum service pack or software update compliance, updated with each security release.

• Antivirus software compliance.

• Application security configuration settings, such as macro file protection and security zones.

• Administrative account standards, such as renaming or disabling accounts and setting up decoy accounts.

• Strong password standards.

A security policy violation suggests a vulnerability that should be eliminated from the environment. The vulnerability could be a computer that lacks various software updates or is not configured correctly, or a user who fails to use strong passwords.

The security policy may provide guidelines for each type of policy-compliance violation; this can then be used to determine the severity of an incidence of a specific vulnerability.

Note: MBSA scans for security updates and common security misconfigurations. It does not scan for conformance with all elements of an organization's security policy.

After you have established and activated a security policy that defines computer security standards, you should apply the strategies presented in the following section to address any discovered violations or vulnerabilities through a series of escalations.

Determining How Security Policies and Standards Are to Be Enforced

Enforcing security policy can be complicated by distributed administration and vulnerable assets that are not centrally managed. Those responsible for administering the asset and resolving the vulnerability may be unknown or hard to find, may be in another department in the organization, or may not have the necessary skills to resolve the vulnerability on their own.

Accordingly, there are several practices that become necessary and helpful when it comes to enforcing security policy:

• Security policies, enforcement timelines, and approaches should have the support of management across the entire organization.

• Techniques and tools for determining ownership and administrative information on an unmanaged computer should be available to specific service desk technicians.

• Service desk technicians should be trained on mitigating each of the vulnerabilities that violate security policy.

• Automated tools and techniques-such as Group Policy-should be used to ensure that computer systems are continually in compliance with corporate security policy and standards.

The nature of a security vulnerability, such as the risk of exploitation and the cost of recovery, should help determine how aggressive the response should be to a system that is not in compliance. If attempts to resolve the vulnerability in the required timeline are unsuccessful, you may choose to employ more aggressive tactics, including:

• Escalating the issue within the violator's organization.

• Disabling the primary account that is used to access the computer.

• Removing the computer from the network by physically disconnecting it or configuring network hardware to automatically remove the device from the network-by disabling ports, for example.

These last two tactics will typically result in a call to the service desk, where the unresolved vulnerability can be discussed and an acceptable resolution determined. Be sure to have executive support for the security policy before escalating security violations and attempting these techniques.

Analyzing System Vulnerabilities

Ongoing scanning and reporting of security issues is crucial for ensuring that potential security vulnerabilities are identified and addressed.

At a minimum, organizations should perform the following actions:

• Perform checks on computers deployed in the production environment, and check the operating system and other installed components, such as Microsoft Internet Information Services (IIS) and Microsoft SQL Server, for configurations that may compromise security. You can use the MBSA to identify many security misconfigurations, but you should also check the Microsoft Security Central Web site for more information on computer hardening and security. That site is located at ttp://www.microsoft.com/security.

• Regularly scan and identify computers that may have been infected by a virus. You can create these reports using the virus tools that your organization has selected.

• Review information returned by network monitoring tools, event logs, and other monitoring tools, and the output of any intrusion detection system to determine whether attacks are being made against computer systems in the production environment.

• Create and maintain operating system images (baselines) that can be applied to a given hardware platform to quickly revert a compromised system to a known good operating system.

• Check that all users and administrators are aware of the steps they need to take in the event of an attack on computer systems in the production environment.

• Maintain a prioritized list of all key information and assets that need to be protected first should an attack occur.

• Verify your router and firewall logs and configurations to ensure they are consistent with your organization's given standards for these devices.

• Review domain controller security policies.

Scanning systems for potential security vulnerabilities should be as automated as possible and performed on a regular basis-daily for most systems. The frequency will depend on the level of automation that is available for each of these areas, the availability and skills of IT security staff in the organization, and the level of commitment to a secure environment.

If you discover that a security vulnerability has been exploited, then you must carry out an emergency response process to minimize the impact.

Determine the Best Source for Information About Software Updates

Once you know what you have deployed in your production environment and have assessed security threats and vulnerabilities, you must determine the best source of information about new software updates. This information will be used in the following phase when you identify new software updates. Sources of information about software updates can be:

• E-mail notifications.

• Web sites.

• Microsoft technical representatives.

Subscribing to the proper notification methods is essential to maintaining and updating your established operating baselines and for implementing an efficient update management process.

The Microsoft Security Response Center (MSRC) investigates issues that are reported directly to Microsoft, as well as issues discussed in certain popular security newsgroups. The security bulletins that Microsoft releases contain summary information outlining vulnerabilities and the products that they affect. The bulletins also include detailed technical information describing vulnerabilities, updates, and workarounds, as well as deployment considerations and download instructions for any available updates.

Security bulletins and related security updates are released monthly on the second calendar Tuesday between 10 A.M. and 11 A.M. Pacific Time, unless Microsoft determines that customers will be better served by releasing a security bulletin at a different time. This policy was established in response to international customer feedback, with the purpose of enabling customers to schedule update management plans.

You can review all security bulletins and other information about Microsoft product security at https://www.microsoft.com/technet/security/default.mspx. All security updates included in the last two service packs for all currently-supported products are available for download from this location.

You can learn about new Microsoft software updates through e-mail messages. The level of detail that you need will depend on the size of your organization and the level of technical information that you desire, as follows:

• For customers who have more extensive knowledge of or interest in the technology behind security updates, Microsoft TechNet offers the Microsoft Security Notification Service. This is a free e-mail notification service geared toward IT professionals. The e-mail messages contain in-depth technical information. For more information, or to sign up to receive the Microsoft Security Notification Service, see https://www.microsoft.com/technet/security/bulletin/notify.mspx.

• Microsoft now offers Microsoft Security Update, a free e-mail alert service that makes it easier for small businesses to stay apprised of the latest security updates. Each time Microsoft releases an update, subscribers receive an e-mail message that explains in non-technical terms why Microsoft has issued the update. The message also lists which products are affected, and provides a link to the full announcement on the Security Central Web site. You can sign up to receive Microsoft Technical Security Notifications at https://profile.microsoft.com/RegSysProfileCenter/subscriptionwizard.aspx?wizid=5a2a311b-5189-4c9b-9f1a-d5e913a26c2e&lcid=1033.

• You can also be notified of new Knowledge Base articles through "Register for the Free TechNet Flash Newsletter" at https://www.microsoft.com/technet/abouttn/subscriptions/flash_register.mspx. These articles will frequently have information about software updates you should deploy to resolve issues in your production environment.

Assess the Existing Software Distribution Infrastructure

Assessing the software distribution infrastructure is another key part of an effective update management process. The assessment should address such questions as:

• Is a software distribution infrastructure in place?

• Can it be used to distribute software updates?

• Does it service all computers in your environment? Is it designed to handle updating of business-critical computers?

• Is your WSUS or SMS infrastructure, Active Directory, and Group Policy implementation properly maintained?

If you use WSUS, you should configure a single WSUS parent server to automatically download software updates from the Microsoft public Windows Update servers. These updates should occur on a daily basis using a preconfigured synchronization schedule. Once the updates have been approved, the updates become immediately available to all WSUS clients. The download should be configured so that it occurs at network quiet times. More detailed information on using WSUS in the Assess phase is given at Windows Server Update Services (WSUS) Technical Library.

If you use SMS, note that the site servers should be located where there is a large client population or where there is a requirement to manage or control network bandwidth. In some locations, you may need two SMS site servers; one to support workstation clients and another to support business-critical computers.

More Information

For more detailed information on WSUS in the Assess phase, see Windows Server Update Services (WSUS) Technical Library.

For more detailed information on using SMS and SMS 2003 in the Assess phase, see Technical Library for Systems Management Server 2003.

Assess Operational Effectiveness

Effective IT operational processes are perhaps the most important dependency for effective update management. Microsoft Operations Framework (MOF), based on the IT Infrastructure Library (ITIL), details 20 service management functions (SMFs). For more information on those SMFs that have direct impact on update management, including Change Management, Configuration Management, and Release Management, see the TechNet guidance, "Microsoft Solutions for Management on TechNet," at https://www.microsoft.com/technet/itsolutions/cits/mo/default.mspx.

There are several questions to ask when you assess your operational effectiveness in the context of these SMFs:

• Are there enough skilled people to perform update management?

• Are people aware that update management is necessary?

• Do those responsible understand security settings, common computer vulnerabilities, software distribution techniques, remote administration, and the update management process?

• Are there standard operational processes in place, or are day-to-day operations largely unstated and imprecise?

• Do processes exist for change management and release management, even informal ones? Securing an environment from attack should not be left to chance or as required operations.

• Is there an emergency process for deploying software updates?

• Are processes continuously evaluated and tested?

Update management is one of many areas of IT operations. Organizations spend a considerable percentage of their IT budgets on operations, because achieving operational excellence reduces expenditure while improving mission-critical service reliability, availability, supportability, and manageability.

An operations assessment enables an operations staff to realize tangible benefits to existing or proposed operations, regardless of the size of the enterprise or its maturity level.

For a quick self-assessment of your organization's operational excellence, see the MOF Self-Assessment Tool at https://www.microsoft.com/technet/itsolutions/cits/mo/mof/moftool.mspx.

Administration Model

An organization should also review the current administration model of its IT environment and determine how well this supports update management. Here are some of the issues that you need to consider:

• How large is the infrastructure compared to the number of staff? What is the administrator-to-system ratio?

• What is the current support model: centralized, decentralized, or shared?

• What are the hours of operation for support staff? Are there sufficient change windows allotted for maintenance and administration?

• Are roles clearly defined and communicated to team members?

• Are service management processes formalized and being followed?

• Are there sufficient tools for individuals to effectively execute their roles?

Skill Sets

The following questions may help to determine the appropriate skill sets required for effective update management execution.

• Do individuals have sufficient experience in handling the size and complexity of the infrastructure?

• Were personnel trained correctly and with relevant technologies?

• Are individuals working together synergistically as a team?

• Do individuals have the appropriate experience or training to understand key operational disciplines and methodologies?

• Do individuals have skills in scripting?

• Do individuals understand user and system permissions and contexts?

• Do individuals understand software update structures and dependencies?

Summary

These are the key points to remember from the Assess phase of the update management process:

• You must determine the threats to, and vulnerabilities of, your production environment.

• You should understand what your business-critical assets are.

• You should understand what you have deployed in your production environment and what is classed as managed (by management tools) and what is not.

• You should ensure that your software distribution tools are configured, maintained, and able to support normal and emergency update management.

• You should ensure that your personnel have assigned roles and responsibilities and that they know how to respond in an emergency-that is, how to deal with the software update and how to mitigate its impact.

Handover to Identify Phase

The trigger for handover to the Identify phase of the update management process is notification that a new software update exists. For more information about the Identify phase, see the module, "Update Management Phase 2 - Identify."