As detailed earlier, the Microsoft-recommended patch
management process is a four-phase process: Assess, Identify, Evaluate
& Plan, and Deploy. The process is a continuous cycle, reflecting
the reality of operations management. As the result of an alert of
software update, the organization shifts from the Assess phase to the
Identify phase and begins its journey through the process cycle. It’s
important to realize that movement through the phases of the process is
updatespecific. This means that if an organization is in the Evaluate
& Plan phase in response to one update when an alert is received for
another, the organization will move to the Identify phase for the
second update and be in two phases of the process simultaneously. This
can pose both logistical and technical challenges to the organization,
especially if the alerts are somewhat related or dependencies exist in
the updates, and care should be taken.
1. The Assess Phase
The Assess phase is the first phase in the patch
management process. In the Assess phase the organization is concerned
primarily with the ongoing assessment of its production environment
covered by the patch management process and with monitoring for alerts
of software updates. Although many of the steps and tasks in the Assess
phase are similar to the tasks undertaken during preparation for the
implementation of a patch management process, they’re instead focused on
optimizing and improving the existing patch management process.
Inventorying and Discovering Existing Computing Assets
As
part of the operations of any production environment, IT assets will be
added, updated, or retired. This task in the Assess phase is concerned
solely with ensuring that the record of IT assets is accurate. As assets
are added to the production environment, they should be inventoried and
evaluated for inclusion into the patch management process. Assets that
are retired should be removed from the record and from the patch
management process. Existing assets should continuously be inventoried
to ensure that their configuration hasn’t changed without a formal
change management process or the patch management process. You can
automate these tasks somewhat by using SMS 2003’s Active Directory and
network-based discovery techniques, which are especially useful for
discovering unmanaged or rogue systems that were deployed outside a
management process.
Assessing Security Threats and Vulnerabilities
Although the IT assets within an organization
might have the latest software updates applied to them, there might
still be risk from security threats and vulnerabilities introduced by
the addition, configuration, or removal of hardware or software
components. The organization needs to remain vigilant and check for
vulnerability using tools such as the Microsoft Baseline Security
Analyzer (MBSA), available from http://www.microsoft.com/mbsa
and the Software Update Inventory Tools for SMS 2003, which are
described later. When vulnerability is discovered, you need to undertake
a risk analysis to determine the best course of action.
Determining the Best Source for Information About Software Updates
The patch management team needs to remain
informed about new software updates for IT assets under control of the
patch management process. The team can remain informed by subscribing to
e-mail notifications, visiting vendor Web sites, and through regular
contact with representatives of software vendors.
Microsoft’s authoritative Web site for information about security bulletins is http://www.microsoft.com/security, where users can also sign up for e-mail notification of software updates and security bulletins issued by Microsoft.
Assessing the Existing Software Distribution Infrastructure
Although
careful planning and implementation might yield a versatile patch
management infrastructure that meets the needs of the organization at
implementation time, it might not suffice as the organization changes.
The patch management team needs to assess the patch management
infrastructure continuously to ensure that it continues to meet the
organization’s needs. SMS 2003 is an extremely flexible management
solution and can be reconfigured as needed to support the addition,
change in configuration, or removal of categories of IT assets or sites.
If the Assess phase was entered after the
completion of the last phase in the patch management process, the Deploy
phase, the organization should evaluate how successful the deployment
of the software update was. If problems were encountered, the
infrastructure should be examined for problems.
Assessing Operational Effectiveness
Lastly, in the Assess phase the patch
management team needs to validate the entire patch management process.
They need to ask questions such as the following: Does the patch
management team have the necessary resources? Do key security
stakeholders have the necessary training and understanding of the patch
management process? Are formal processes in place for day-to-day
operations that have an impact on security? You can find the Microsoft
Operations Framework Self-Assessment Tool, designed to gauge an
organization’s operational excellence, at http://www.microsoft.com/technet/itsolutions/tandp/opex/moftool.asp.
As with assessing the software distribution
infrastructure for problems after a deployment, the patch management
team should assess the operational effectiveness of the process,
including their own performance. Lessons learned in this assessment
should be applied in order to improve operational excellence for future
software updates.
Leaving the Assess Phase and Moving to the Identify Phase
When the patch management team receives
notification of a software update that affects the production
environment, the patch management process moves into the Identify phase.
2. The Identify Phase
During
the Identify phase of the four-phase patch management process, the
organization is focused on gathering information about the software
update that triggered entry into the Identify phase, whether or not the
update is relevant to the production environment; obtaining the software
update itself; and categorizing the update as either an emergency
update or one that can be dealt with routinely within the time frame set
by the organization for software updates.
Discovering New Software Updates Reliably
When an organization receives an e-mail alert
from Microsoft about a software update, the alert contains links to
Microsoft’s Security & Privacy Web site, found at http://www.microsoft.com/security,
where more detailed information is made available. Organizations might
choose to subscribe to other sources of information about software
updates or receive e-mail messages from account representatives or other
Microsoft employees. Regardless of where the alert came from, the patch
management team needs to verify its authenticity. For alerts detailing
software updates to Microsoft products, the authoritative source of
information is the Microsoft Security & Privacy Web site, which the
team should visit. Of special note, Microsoft never releases software
updates as attachments to e-mail messages. If the team receives an
e-mail message with an attachment purporting to come from Microsoft and
containing a software update, the safest course of action is to delete
the message. Similarly, rather than clicking on links contained in
e-mail messages that appear to take the reader to a Microsoft Web site,
the reader should copy and paste the URL into their browser, as the true
Web site that the user will be taken to can be hidden in the formatting
of the e-mail message.
SMS 2003 Software Updates, when configured,
will automatically poll Microsoft’s Web sites, looking for information
about software updates in the products that it’s aware of. Using the SMS
Administrator Console, you can view just about every applicable
software update for the production environment, along with the number of
systems that are in compliance and those that are not. Figure 1
shows a screen shot of software updates listed in the SMS Administrator
Console.
Determining Whether Software Updates Are Relevant
Benjamin Franklin
wrote, “In this world nothing is certain but death and taxes.” Although
this was written long before software was invented, today he would no
doubt feel compelled to add software updates to the list of certainties
faced in life. The fact is that software releases are made on a
continual basis and can come from a variety of sources, such as
operating systems and application vendors, independent software vendors
(ISVs), original equipment manufacturers (OEMs), and hardware
manufacturers. Not every released software update will necessarily apply
to an organization’s production environment, even when it touches a
software product in use. The patch management team will need to evaluate
and determine whether or not patches are relevant to the production
environment covered by the patch management process. For example, a
software update to a word-processing package that’s deployed within the
organization might apply only to a feature that isn’t installed or used,
or perhaps the risk from not installing the update is considered so low
that it can be safely ignored. A good starting point for evaluating the
relevance of a software update issued by Microsoft is the detailed
bulletin found on Microsoft’s Security & Privacy Web site at http://www.microsoft.com/security.
The bulletin will contain details of the vulnerability addressed by the
update, any mitigating factors that might affect the requirement to
update a system, and any workarounds if available.
Each
software update should be assessed from a risk management perspective,
with the organization making a determination about whether or not the
update should be applied to its affected IT assets. When considering the
risk from not installing an update, the organization must balance it
against the risk from installing the update. Risk from installation
includes incompatibilities with already-installed applications, system
instability, and loss of functionality.
As described earlier, SMS 2003 Software Updates
can be configured to poll Microsoft’s Web sites for details of
available software updates and list them in the SMS Administrator
Console. Only updates that are applicable to the production environment
are listed. An update is deemed to be applicable when one or more SMS
Clients scans itself and determines that the update should be applied
and reports this information to an SMS site server.
Obtaining and Verifying Software Update Source Files
When assessing the relevance of a software
update, it’s often desirable to have the source files for the update at
hand. The patch management team should take care when obtaining software
updates to ensure that they come from legitimate sources only. Every
software update that Microsoft releases is digitally signed, and you can
verify its authenticity by examining the signature. Although you can do
this manually, you can also do it using SMS 2003. When a software
update is identified as relevant to the production environment and
listed under Software Updates in the SMS Administrator Console, it can
be included in a package built by the Distribute Software Updates
Wizard. You can instruct the wizard to download software updates
automatically, and it will check the signature of each as it does so. If
the wizard is unable to download a software update automatically, which
might be the case if different updates exist for different platforms
and configurations or if the patch management team prefers to download
updates by hand, you can verify the software update’s digital signature
through its properties using Microsoft Windows Explorer. Figure 2 shows the dialog box of a software update’s digital signature, accessible through Windows Explorer.
Until
a software update identified in an alert has been successfully
downloaded and verified, the patch management process can’t leave the
Identify phase.
Determining the Nature of the Software Update and Submitting a Request for Change
Every software update released by Microsoft is
assigned a severity rating. The purpose of the ratings is to provide
guidance to administrators and patch management teams about the urgency
with which the update should handled. These ratings, and their meanings,
are listed in Table 1. You can find full details of the ratings used by Microsoft in TechNet at http://www.microsoft.com/technet/security/bulletin/rating.asp.
Table 1. Software update severity ratings
| Rating | Definition |
|---|
| Critical | A vulnerability whose exploitation could allow the propagation of an Internet worm without user action. |
| Important | A
vulnerability whose exploitation could result in compromise of the
confidentiality, integrity, or availability of users’ data or of the
integrity or availability of processing resources. |
| Moderate | Exploitability
is mitigated to a significant degree by factors such as default
configuration, auditing, or difficulty of exploitation. |
| Low | A vulnerability whose exploitation is extremely difficult or whose impact is minimal. |
The
patch management team should take an update’s severity rating into
account when determining its nature. Software updates with a low rating
might be safely ignored until a predefined refresh cycle is begun,
whereas an update rated as critical might need to be deployed as soon as
possible. Mitigating factors should also be taken into consideration
when determining the nature of an update. For example, with sufficient
perimeter defenses and a secure VPN in place, a patch management team
might consider not rushing an update for a newly discovered
vulnerability that a worm is exploiting if the port used by the worm to
propagate itself is blocked at the firewall and not allowed over a VPN
connection.
Other considerations that the patch management
team should examine are the impact of the update on the production
environment. For example, does the update require systems to be
restarted after installation and can it be rolled back if it’s
determined that the update has a negative effect on the production
environment?
Once the patch management team has completed
determining the nature of the software update, it should submit an RFC
to the Change Management Board.
Leaving the Identify Phase and Moving to the Evaluate & Plan Phase
The events that trigger leaving the Identify
phase and the handover to the Evaluate & Plan phase are the
successful acquisition of the software update and the submission of the
RFC.
