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.
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.
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 1.
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.
