Previous Section
 < Day Day Up > 
Next Section


Preparing for Patch Management

Before an organization can implement a patch management process, it needs to prepare for it. Although the four-phase model has an Assess phase, with steps that would appear to cover the initial preparation for patch management, the phase is part of an established and running patch management process. Without careful preparation, a patch management solution is extremely likely to fail. Preparing for patch management is a project in itself, with the defined goal of getting the organization to the point where it can enter the Assess phase of the four-phase model. Among the tasks that need to be accomplished during the preparation project are identifying, inventorying, and bringing the IT assets that will fall under the solution to a known configuration, deployment of the patch management infrastructure, and establishment and training of the patch management team.

Identifying, Inventorying, and Configuring IT Assets

Necessary tasks in the project of preparing for patch management are the identification of assets that will fall under the patch management process, inventorying them, and configuring them so that they conform to a secure baseline. Not all the IT assets within an organization might qualify for inclusion in a patch management process. Examples of such systems might be legacy systems due for retirement, servers in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) that need special attention and are patched by hand, development and test systems, and systems leased from a vendor with which there’s a support agreement including upgrade maintenance in place. The goal of identifying and inventorying assets is to quantify the number of systems that the patch management process needs to cover, their physical and logical positions within the enterprise, and their hardware and software profiles. You use this information in two ways: to categorize the systems and to determine what the secure configuration or baseline should be in each category and to design the patch management infrastructure to support the patch management process.

Identifying IT Assets

There are many ways to identify IT assets, which can be divided into two categories: manual and automated. In medium and large organizations, manual identification of assets might be infeasible and an automated approach might be favored. SMS 2003 is able to discover assets using a variety of mechanisms, including searching the Active Directory directory service or performing network- based discovery. The quandary here is that you can’t deploy SMS 2003 to support the patch management solution effectively without the information that’s derived from this task. But with SMS 2003 in place, you can perform this task, and subsequent tasks, more efficiently. One strategy is to deploy a minimal SMS infrastructure that’s used solely to gather this information and which is reconfigured when building out the patch management infrastructure.

Inventorying IT Assets

Once you’ve identified IT assets, you must inventory them. The goal is to determine what the hardware profile of the system is and what software is installed on each. Without this information it won’t be possible to determine which systems need to be brought to a secure baseline configuration. A comprehensive patch management solution will need to cope for variations in hardware and software, but it’s not possible or desirable for most organizations to manage a large number of combinations. Instead, the organization should categorize IT assets—either by function, such as server or desktop, or by hardware or software configuration. You can use SMS 2003 to help with the inventory process. It will accurately report the operating system, configured services, and any programs or updates that registered themselves with Add/Remove Programs on clients. You can use the SMS 2003 Software Inventory Client Agent to scan SMS client systems for all installed executables, which is useful for inventorying those applications that didn’t register themselves. You can examine information about installed applications on any SMS-managed client using the Resource Explorer, which is stored under both Hardware and Software nodes in the Microsoft Management Console (MMC)–based view.

Before you can inventory systems using SMS, the SMS Client must be installed on them. You can do this by pushing the SMS Client software to the systems once they’ve been discovered, either through Active Directory or network-based discovery. Once the patch management infrastructure is built out, clients can be assigned to SMS sites other than the one in which the SMS Client was deployed.

Configuring IT Assets

Once assets have been identified, an inventory has been performed, and each asset has been categorized, you need to configure the assets and bring them to a secure baseline. Each category will have its own configuration and you should be careful when determining what that configuration should be. The secure baseline should address both the hardware and software configuration for IT assets. As a rule of thumb, each system should be configured for the task to which it is applied, with no extraneous hardware or software and with all appropriate updates applied. Once a secure baseline configuration has been identified for a category, all new systems deployed in that category should conform to the baseline. During the patch management process, as updates to software are deployed, the secure baseline configuration will change. This is discussed in detail later in this chapter.

Until a system is brought to the secure baseline for the category within which it’s placed, it can’t be included in the patch management process. As with identifying and inventorying IT assets, you can use SMS 2003 to bring systems to a secure baseline configuration in preparation for a patch management process. Of concern to most organizations is ensuring that the software updates necessary to bring a system to a secure baseline configuration are applied. Automating this process with SMS 2003 is discussed in detail later in the chapter in the section entitled “Authorizing and Distributing Software Updates.”

Building the SMS 2003 Patch Management Infrastructure

Building out a patch management infrastructure can be a daunting task. A poorly designed infrastructure can have a serious impact on the performance of the patch management process and might result in updates not being applied to systems in a timely fashion. With SMS 2003, organizations have the ability to reconfigure and optimize their patch management infrastructure once it’s deployed, but this shouldn’t be relied upon in place of a good initial design and implementation. The goal of the implementation should be to build an infrastructure that you can rely on to distribute software updates to systems in a timely fashion. As discussed earlier, you should use the information gathered during the identification and inventorying of IT assets to design the patch management infrastructure. When planning the SMS site hierarchy, take into consideration the categories of assets that will be in each site. For example, SMS sites are comprised of IPv4 subnets and network design best practices recommend placing servers on different subnets from workstations, so it might make sense to create SMS sites designed to achieve the different patch management needs of each category of system on each subnet. An example of an SMS infrastructure that has several sites, each for a specific category of IT asset, is shown in Figure 13.4.

Click To expand
Figure 13.4: An SMS 2003 infrastructure designed to support patch management.

Another consideration to keep in mind is how critical each category of system is. Sites with line-of-business systems, such as servers and workstations that are required for the organization to function, should be placed higher up in the SMS site hierarchy. To guarantee that critical updates can be distributed to them as soon as required, intersite links to these sites from the SMS central site shouldn’t be configured with bandwidth restrictions. Sites containing noncritical systems can be placed further down in the hierarchy and the intersite links bandwidth restricted as needed. Where a site has multiple categories of assets with a large number of systems in each, it might be desirable to deploy multiple SMS site servers in the site and assign one or more categories to each in order to balance the load against patch management requirements.

Establishing and Training the Patch Management Team

When preparing for patch management, you need to make an effort to establish the patch management team. The patch management team will be responsible for monitoring for alerts of updates to software. When an alert is received, the team needs to assess the impact on the production environment protected by the patch management process. If, as a consequence of an alert, a software update or configuration change needs to be applied to part of or to the entire production environment, the patch management team will be responsible for building, testing, and deploying the update or change.

The makeup of the patch management team will vary from organization to organization and will depend on many factors, including the organization’s size, the number of categories of IT assets, the number of systems, and the complexity of the production environment. In larger organizations many people might fulfill a role, while in smaller organizations team members might hold more than one role. The MOF team model white paper, available from http:// www.microsoft.com/technet/itsolutions/tandp/opex/mofrl/mofeo.asp, is a useful reference and provides guidance when building operations teams for organizations of all sizes.

The patch management team will need to undergo training on the patch management process and on how to use the patch management infrastructure and associated tools. This training should be tailored to the production environment protected by the patch management process.

Entering the Assess Phase

Once the patch management infrastructure is in place and the organization’s IT assets have been brought up to the secure baseline configuration, the organization can enter the patch management process. In larger organizations and in those with a complex production environment, it might not be feasible or possible to bring all systems to secure baseline configurations before beginning the patch management process. In these cases the organization might consider rolling systems into the process as they’re configured. One of the challenges of rolling in systems over time is that the secure baseline configuration might change in response to an alert of software update before a system is configured, causing the organization to expend considerable resources in updating the baseline before the systems are actually configured—in some cases many times. Several strategies exist for rolling systems into the patch management process, including subnet-by-subnet, category-by-category, site-by-site, and during hardware or software refresh periods. When planning for patch management, the organization needs to consider what strategy it will adopt to roll in systems if it’s not possible to bring all systems to a secure baseline before beginning the patch management process.



Previous Section
 < Day Day Up > 
Next Section