Keep Your Business Safe with Effective Patch Management

Keeping Your Business
SAFE from Attack:
Patch
Management
By Jeff Fellinge

i

Contents
Chapter 1 Introduction to Patch Management . . . . . . . . . . . . . . . . . . . . . 1
Building the Foundation: Processes, Software, and Training . . . . . . . . . . . . . . . 2
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Create a Patch Management Triage and Deployment Team . . . . . . . . . . . . . . . . . 2
Determine SLAs for Different Levels of Patches . . . . . . . . . . . . . . . . . . . . . . . . . 5
Ensure that the Appropriate Groups Test and Sign Off on a Patch . . . . . . . . . . . . 5
Subscribe to Patch and Security Advisories and Bulletins . . . . . . . . . . . . . . . . . . . 6
Review All New Security Bulletins with the Team to
Assess Risk and Triage Deployment . . . . . . . . . . . . . . . . . . . . . ............ 8
Weigh Deploying Updates vs. Exploit Mitigation Efforts . . . . . . . ............ 9
Choosing Software to Deploy Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Windows Automatic Updates . . . . . . . . . . . . . . . . . . . . ....... . . . . . . . . . . . 10
Microsoft Software Update Services and Windows Update Services . . . . . . . . . . . 11
Microsoft SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... . . . . . . . . . . . 12
Beyond Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... . . . . . . . . . . . 13
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
The Full Rally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ii

Contents
Chapter 2 Microsoft Update Bulletin and Communications . . . . . . . . . . . . 17
Spreading the Word Quickly: Microsoft Email Notifications . . . . . . . . . . . . . . . 18
Soliciting Help from Your Peers: Microsoft Newsgroups . . . . . . . . . . . . . . . . . . 19
Microsoft Security Bulletin Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Security Bulletin Titles . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Bulletin Summaries . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Learning More Details about the Update .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Frequency of Patch Releases . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Interactive Education: Webcasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Processing All the Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

iii

Contents
Chapter 3 The Dry Run: Setting Up a Lab to Test Patches and
Updates and Using Microsoft Baseline Security Analyzer to
Scan for Missing Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
The Test Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Creating Your Lab: Using Virtual Machines vs. Dedicated Hardware . . . . . . . . . . . . . 39
Configuring Forests, Domains, and DCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Patch Deployment Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Living Dangerously: Using Production as Your Test Lab . . . . . . . . . . . . . . . . . . . . . . 41
The Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Verifying Installation and Scanning for Missing Patches with MBSA . . . . . . . . . 43
MBSA Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
MBSA Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Start Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
MBSA Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
MBSA as HFNetChk Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
MBSA Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The Timeline from Test to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iv

Contents
Chapter 4 Microsoft Patching Technologies . . . . . . . . . . . . . . . . . . . . . . . 52
Decoding a Software Patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Discovering the Installer Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
How the Patch Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Microsoft’s Most Common Patch Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Update.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 60
Hotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 65
Ohotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 66
Normal Updates and Administrative Updates . . . . . .. . . . . . . . . . . . . . . . . . . . 67
Normal Updates . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 67
Administrative Updates . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 68
Integrating Office Patches into the Install Sources . . .. . . . . . . . . . . . . . . . . . . . 70
Obtaining Ohotfix.exe . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 71
Dahotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 71
Off the Beaten Track: Older and Unique Update Engines . . . . . . . . . . . . . . . . . . . . 71
Vgxupdate.exe . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 71
Iexpress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 72
Installing Mutliple Hotfixes with Qchain Technology . . . . . . . . . . . . . . . . . . . . 72
Installer Wrap-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

v

Contents
Chapter 5 Individual Solutions: Windows Update and Office Update . . . . 74
Solutions for Individual Computers:
Using Automatic Updates to Scan and Install Patches . . . . . . . . . . . . . . . . . . . . 74
Configuring Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Option 1: Automatically Download and Install Security Updates . . . . . . . . . . . . . 77
Option 2: Automatically Download but Prompt to Install the Security Updates . . . 78
Option 3: Notify Only When New Updates are Available . . . . . . . . . . . . . . . . . . 78
Option 4: Disable Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Behind the Scenes: Automatic Updates Registry Settings . . . . . . . . . . . . . . . . . . 79
Phoning Home: Automatic Updates Routinely Checks with Microsoft . . . . . . . . . . . . 80
Using Automatic Updates to Download Updates from Microsoft . . . . . . . . . . . . . . . 81
Installing the Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
The Windows Update Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
The Office Update Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Using the Office Update Inventory Tool to Scan for Missing Office Updates . . . 91
Using an Administrative Point to Deploy Office Updates . . . . . . . . . . . . . . . . . . 92
Keeping Up to Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

vi

Contents
Chapter 6 Corporate Solutions: Microsoft SUS and WSUS . . . . . . . . . . . . 95
Centrally Managed Passive Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuring Automatic Updates Clients with Group Policy . . . . . . . . . . . . . . . . . . . 97
Exploring the Windows Update GPO Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Deploying Service Packs with SUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
SUS Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Configuring SUS Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
WSUS Revealed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Exploring the New WSUS Interface . . . . . .......... ..... . . . . . . . . . . . . . . . . 103
Approving Updates with WSUS . . . . . . . .......... ..... . . . . . . . . . . . . . . . . 105
Support for Computer Groups . . . . . . . . .......... ..... . . . . . . . . . . . . . . . . 105
What if I don’t see my computer in the list to choose from? . . . . . . . . . . . . . . . . 106
Approving Updates with WSUS . . . . . . . .......... ..... . . . . . . . . . . . . . . . . 107
Reports Added in WSUS . . . . . . . . . . . . .......... ..... . . . . . . . . . . . . . . . . 110
Configuring WSUS Global Options . . . . . .......... ..... . . . . . . . . . . . . . . . . 113
Corporate Solutions Reviewed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

vii

Contents
Chapter 7 Enterprise Solutions: SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . 115
Preparing Your Environment for SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Setting Up AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Installing SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Configuring a Base SMS Installation . . . . . . . . . . . . . . . . . . . . . . ...... .. . . . . . 118
Specify the Management Point . . . . . . . . . . . . . . . . . . . . . . . ...... .. . . . . . 118
Enable Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... .. . . . . . 118
Prepare the Deployment of the SMS Client Software . . . . . . . . ...... .. . . . . . 119
Decrease Polling Intervals and Increase Polling Frequency for Testing . . . . . . 120
Enable Client Push Installation . . . . . . . . . . . . . . . . . . . . . ...... .. . . . . . 120
Specify the Account to Use for Software Distribution . . . . . ...... .. . . . . . 120
Client Discovery and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Review Newly Discovered Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Troubleshooting Missing or Unassigned Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Other Methods for Installing the SMS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Checking the SMS Client on the Client Computer . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using SMS for Software Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Installing the Office Update Inventory Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Installing the Security Update Inventory Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 125
SMS Vernacular: Programs, Packages, Advertisements, and Collections . . . . . . 126
Creating Your Package of Updates: Working with the
Distribute Software Updates Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Advertise Your Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
SMS 2003 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Manually Refreshing the Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Patch Management with SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

1

Chapter 1:

Introduction to Patch Management
Due to the rapid proliferation of nefarious worms, with names such as MS Blaster, Nimda, and Code
Red, applying Microsoft Security Updates is becoming a staple of any business connected to the
Internet or outside world. However, hackers and crackers will continue to exploit computer software
and your company will always need information security protection from zero-day exploits. However,
a majority of the fast-spreading, heavy-hitting worms leveraged and exploited weaknesses in software
that were previously identified and fixed weeks—in some cases months—earlier. Target damage
aside, the proliferation of these worms affects the Internet by clogging routers and Internet gateways.
In all, these worms have sent a loud-and-clear wakeup call to IT departments everywhere to get
serious about patch management.
To reduce the shellshock of frequent patch releases, Microsoft continues to introduce software
and processes to help triage and deploy their Security Updates. Microsoft formalized the Security
Updates release cycle to occur on the second Tuesday of every month. All Security Updates are
ranked in severity and classified by products. They also include detailed descriptions of the exploit
and list mitigating factors. Microsoft also released several patch deployment software products in addi-
tion to the flood of new third-party patch management software products. These software products
exist to help test and deploy all the patches. Most patch management software supports Microsoft
products and some extends to third-party software as well.
However, the process of deploying the patches is only the tip of the iceberg. A successful and
comprehensive patch management program combines well-defined processes, effective software, and
training into a strategic program for assessing, triaging, obtaining, testing, and deploying software
patches. Patching software is not a new phenomenon: software updates are a frequent and regular
occurrence and historically patches improved performance, stability, or even added new program fea-
tures. But of late, the proliferation of Internet worms and viruses have put the spotlight on patch
management vis-à-vis Microsoft Security Updates. The rapid assessment and successful deployment of
these Security Updates causes the most anxiety in IT shops throughout the world. These shops must
balance the potential threats to unpatched systems, project priority, time necessary to identify and
assess security vulnerabilities, and the testing and deployment of patches with the potential business
impact of patch installation (e.g., reboot downtime, unsuccessful patch deployment).
This book describes attributes of a successful patch management program and explains
Microsoft’s update technologies and security update communications network. Your internal processes
coupled with Microsoft’s evolving update distribution program will define your patch management
program. Partially due to the recent attention drawn to the Security Updates, Microsoft continues to
improve its security update communications. The latest bulletins describe the updates in sufficient
detail to help most organizations identify and triage patches relevant to their environment.
This text will also outline how to assemble a patch testing program that calls on the expertise of
resources across your enterprise to minimize adverse effects that a patch might have on your net-
work’s business-critical systems and applications. You’ll learn how to set up a patch testing program

Brought to you by Microsoft and Windows IT Pro eBooks

2 Keeping Your Business Safe from Attack: Patch Management

that provides an important safety net for your production servers. The later chapters will examine the
Microsoft patch mechanisms and Microsoft’s update distribution software: Windows Update, Windows
Update Server, and Systems Management Server (SMS) 2003.

Building the Foundation: Processes, Software, and Training
Let’s look at what constitutes a solid patch management program. The details vary by organization
but traits common to all successful programs include:
• Identifying the processes to assess, test, deploy, and audit the patch installation
• Selecting effective patch testing and distribution software for your organization, then using this
software to deploy the updates
• Training to ensure that everyone is capable and ready to test and deploy patches when the time
comes
• Gaining support from executive management that includes sponsorship and setting overall goals
for patch management

Processes
The patch management process defines the strategy and tactics encompassing your patching program
and includes activities ranging from the selection and deployment of patch management software, to
creating a Patch Management Triage and Deployment Team, to rolling out the individual patches.
Customize each of these elements for your particular organizational needs. Smaller organizations
might not have a formal process but will benefit from a structured approach nonetheless. Be sure to
include in your process early planning topics such as researching, purchasing, and deploying the
patch delivery software for each of your organization’s locations, including branch offices and remote
users. Consider these elements when defining your patch management processes:
• Create a Patch Management Triage and Deployment Team.
• Subscribe to Microsoft and non-Microsoft patch and security advisories and bulletins.
• Review all new security bulletins with the team to assess risk and triage deployment of new
patches or evaluate workarounds.
• Weigh deploying updates versus exploit mitigation efforts for different patches, environments, or
targets.
• Determine service level agreements (SLAs) for different patch levels, such as internal versus pro-
duction or workstation versus server.
• Devise and document testing procedures to ensure that the appropriate groups test and sign off
on a patch before it’s released to production. When feasible, consider a burn in period in which the
patch is tested in a live yet limited environment.

Create a Patch Management Triage and Deployment Team
Effective emergency response or disaster recovery teams drill repeatedly so that when the time comes
they are prepared to handle the event. This training is no different from an Information Security alert
team tasked with investigating unknown events or attacks. Adopting the effective strategies of these
emergency response teams is becoming more important for your patch deployment team. Critical
patch deployments increasingly require fast action—especially when an exploit is in the wild.
In many organizations, the patch deployment team consists of systems administrators or engi-
neers who have primary responsibilities beyond patching systems. Since the burst of the dot-com


Chapter 1 Introduction to Patch Management 3

bubble in 2000, most IT spending budgets have shrunk and resources have thinned considerably. In
many companies, the IT staff is being asked to do more with less help, which unfortunately can
mean that nonrevenue or maintenance activities might be unintentionally (or purposely) reprioritized.
To help ensure that patching is not an afterthought at your company, consider forming a Patch
Management Triage and Deployment Team that includes representatives from each of the disciplines
or functional areas of your organizations: Microsoft SQL Server, Microsoft Exchange Server, Active
Directory, file and print, Web, custom and proprietary applications, etc. By involving subject matter
experts from each of these disciplines, you make certain that when patching time comes you can rely
on each expert to test and deploy the patches to their systems. Especially in large organizations,
involving these folks early on helps with team building so that when a patching crisis arises response
team members already know one another, which implicitly improves communication. Include Busi-
ness Decision Makers (BDMs) and representative customers who can help assess system risk toler-
ance. The BDMs can work with the technical teams to schedule and test patches for specific
business-critical systems. Customers of these systems can provide valuable insight into usage patterns
for scheduling server reboots and downtime or into when workarounds would be beneficial until a
patch can be applied. For large enterprises, your Patch Management Triage and Deployment Team
might include multiple BDMs.
Even during times when you are not deploying patches, schedule regular weekly meetings with
the team members to discuss current or upcoming patches, deployment systems, triage strategies, or
general training. Schedule these reoccurring, standing meetings out into the future so that they are on
key participants’ calendars. Then when a patch needs a quick assessment, testing, and deployment,
the right people already have the time reserved.
Consider establishing different states of alert for your Patch Management Triage and Deployment
Team. Under normal circumstances when no patches need deployment, use the meetings to discuss or
review your patch deployment technologies. Discuss upcoming projects that might tie up key patching
resources, such as testing labs or deployment personnel. These meetings are also an ideal time to train
your team in the process of deploying patches when necessary. Also consider developing two patch
management processes, one for regular patch releases (e.g., a worm is in the wild) and one for emer-
gency patch deployment (e.g., a worm is inside your company’s network boundaries).
Of course when patches must be deployed, the primary role of the team comes into direct play.
In general, the second Tuesday of every month is the day that Microsoft releases the majority of its
patches for the month. Microsoft typically announces the patches by noon PST, so Tuesday after-
noons are good times to meet and be ready when Microsoft releases a new batch of updates. Note
that critical patches for exploits in the wild can be released outside of this timeframe at Microsoft’s
discretion. For this reason, subscribing to Microsoft’s free Security Update notification service is a
good idea. The next section describes this service in more detail.
Upon notification of new Security Updates, rally the Patch Management Triage and Deployment
Team and begin your patch management process. Assess the patches and triage their applicability
and exploit risk to your environment. Figure 1-1 shows a sample process.
For example, you will likely handle an Internet Explorer (IE) patch differently than a core Win-
dows OS patch such as a Local Security Authority Subsystem (LSASS) security update. The IE patch’s
focus might be on deployment to employee workstation computers whereas the OS patch might
need immediate rollout to any Internet connected computers and possibly others depending on the
specific exploit attack vector.



Figure 1-1
Reviewing the patch management process

Security
Bulletin
Released

Automated
Bulletin
Notifies
Team

Implement
Identified
Bulletin Applies
Team Reviews Workarounds
to Immediately
Security Until Testing
At-Risk Systems
Bulletin Is Complete

Test Patch
Installation in
Lab

Needs
More Testing

Patch Team
Resolve Patch
No No
Approves
Deployment
Deployment
Issues

Yes

Install Patch
on Affected
Systems

Audit Server
for Successful
Installation

Verify Server
Operation
Post
Installation

The exploit attack vector is the mechanism an attacker uses to compromise a vulnerable system. For
example, an IE exploit attack vector might be a visit to a Web site containing malicious code. This
means that a user must actively visit an infected site. Depending on your organizations IE security



policy this may or may not be a critical patch to deploy to your end users. Contrast this to the vul-
nerability of a primary security DLL such as LSASS. This DLL is used by many externally accessible
components and depending on the vulnerability, can be exploitable from an unsolicited external con-
nection attempt via Secure Sockets Layer (SSL), remote procedure call (RPC), or other LSASS-enabled
protocol. To exploit this vulnerability, an external attacker might only need network access to a vul-
nerable server. If an SSL-protected Web site exposes this vulnerability, then that company’s Internet
connected Web site might be at risk. The exploit attack vector might be anyone on the Internet estab-
lishing an SSL connection to your Web site. Worms that spread from one vulnerable server to another
frequently use this type of exploit attack vector. These malicious software programs exploit an
unpatched vulnerability, infect the computer, then launch new attacks from the compromised com-
puter. Code Red, Sasser, and MS Blaster are all examples of worms that spread by exploiting vulnera-
bilities that had official patches available months earlier.
The Patch Management Triage and Deployment Team must consider all these factors when deter-
mining when and how quickly patches need testing and deployment. Later this chapter explains how
mitigating factors can help buy your company time to conduct adequate testing of new patches.
However, even with these mitigations, patching has no substitute. The time between disclosure of a
vulnerability and the availability of an automated exploit shrinks every year—from more than 300
days a couple of years ago to only 17 days for the recent Sasser exploit. Chapter 3 describes tech-
niques and processes for testing the patches and updates.

Determine SLAs for Different Levels of Patches
Let’s face it, patching disrupts normal business operations and, unless your IT department is over-
staffed, you will have to make concessions to other projects to accommodate your patch deploy-
ments. To acknowledge your patching activities alongside other business projects, create a policy that
specifies patching SLAs that both the businesses and technical leadership approve.
Include in these SLAs definitions of different levels and types of patches (e.g., internal versus pro-
duction, workstation versus server), define their priority, and set an expectation for when specific
computers will be patched after the release of a new alert. A very basic SLA might assert that all
patches deemed critical by Microsoft will be deployed within 48 hours and all other patches will be
deployed within 2 weeks. Of course you will want to customize this to your environment and tailor it
to suite your needs. A well-defined SLA will not only help ensure that patches get deployed shortly
after release but they also help clear any roadblocks in securing resources to assist with the patch
deployments. Plus by defining your SLAs up front, your business management will probably be more
tolerant of a delayed business project milestone due to a patch deployment exercise.

Ensure that the Appropriate Groups Test and Sign Off on a Patch
You need to devise and document testing procedures for the patches. These procedures are to
ensure that the appropriate groups test and sign off on a patch before released to production. You
also need to consider a burn in period when feasible.
All too often—especially in the heat of battle—patches are deployed without adequate testing.
Many times, administrators assume that it will work and more-or-less hope that the computer will suc-
cessfully restart. Although for the most part this is true due to Microsoft’s rigorous testing, a couple of
patches have had serious problems. For example, the MS04-011 patch released in 2004 caused some
combinations of hardware to stop responding. Although infrequent, a patch might dramatically



change how software behaves between a patched and unpatched system. An example of this was
SQL Server Service Pack 3 (SP3), which implemented additional security settings that affected cus-
tomer’s custom application code in some circumstances.
By involving many cross-functional groups in your Patch Management Triage and Deployment
Team you will have the right people on hand to perform this testing. They will be the experts who
deploy the patches to their systems, then test or watch the system over a period of time to look for
any anomalous behavior.
You might be able to gain flexibility for deploying your patches if you can deploy patches in
stages to certain groups of servers. For example if you manage a Web farm of multiple Web servers,
even after testing in a lab, consider deploying the patch to one Web server and watching it for a few
days. This burn in period tests the patch in a live environment, and if no apparent problems appear,
then after some time you can deploy the patch to the remaining servers with more confidence. How-
ever with a progressive type of rollout, waiting a few days can be the difference between deploying
before a worm and being infected by a worm.
Chapter 3 delves into the detail aspects of testing that help create a solid testing program. Make
sure to include testing in your process and training.

Subscribe to Patch and Security Advisories and Bulletins
The proliferation of worms that exploit known software vulnerabilities has spawned several patch and
security advisory Web sites and bulletins. The primary Security Updates Web site for Windows is the
Microsoft Security Bulletin Web site at http://www.microsoft.com/security/bulletins, which Figure 1-2
shows.

Figure 1-2
Viewing Microsoft’s searchable Security Updates Web site

Bookmark this page, then subscribe to the bulletin notification service to ensure notification
when Microsoft releases new Security Update bulletins. Also, if you subscribe to a specialized support



program like Premier Support, ask your Technical Account Manager (TAM) to add you to any notifi-
cations they send out.
Unfortunately, for now, Microsoft Office uses Office Update, which is a separate update service
than Windows Update. For information about patching Office applications visit the Office Update
Web site at http://office.microsoft.com/officeupdate. This Web site also can scan your computer for
missing Office updates, as Figure 1-3 shows.

Figure 1-3
Scanning the Microsoft Office Update Web site for missing updates

Subscribe to the Microsoft newsletter Inside Office—Product Updates Alert at http://www.microsoft.com/
office/using/newsletter.asp to get notified when Microsoft releases a product update including the
latest security and performance improvements.
In addition to Microsoft, bookmark other security sites and subscribe to other patch-centric ser-
vices to keep abreast of newly discovered vulnerabilities and subsequent software updates. Every day
these distribution lists send a deluge of information, but keep these messages for at least 30 days.
When patch day comes, or if you suspect you have been attacked, you will appreciate the built-up
library of technical articles and correspondence.
Don’t overlook the Usenet groups, which provide huge and largely unmoderated discussions
about most everything including patching. Subscribe to the Microsoft patch and security newsgroups
at http://www.microsoft.com/technet/community/newsgroups/security. To search other newsgroups
for vulnerabilities, use your own provider or a public provider such as Google Groups at
http://groups.google.com.



Other good third-party notification services for exploits, vulnerabilities, patches, and other security
updates include the SecurityFocus Bugtraq at http://www.securityfocus.com/subscribe?listname=1,
Mitre’s Common Vulnerabilities and Exposures at http://www.cve.mitre.org, the Carnegie Mellon Uni-
versity CERT at http://www.cert.org, the United States Computer Emergency Readiness Team (US-
CERT) at http://www.us-cert.gov, and the SANS Internet Storm Center at http://isc.sans.org among
others. Even most antivirus vendors provide links and descriptive information outlining new attacks,
vulnerabilities and include links to vendor patches or mitigating steps. For example, check out
Symantec at http://www.sarc.com and TrendMicro at http://www.antivirus.com for detailed informa-
tion about new viruses and worms and how to prevent them.
Proactive and comprehensive access to new vulnerability and exploit information is essential to
making appropriate triage decisions surrounding patching vulnerabilities in your organization. Chapter
2 delves into the contents of Microsoft Security Bulletin Updates in much more detail.

Review All New Security Bulletins with the Team to Assess Risk and Triage Deployment
Now that you have assembled the team and meet regularly, define your process of reviewing new
Security Bulletins to assess risk and triage the deployment of new patches. The triage process is
important because large companies cannot immediately deploy all patches all the time. You will need
to make tradeoff decisions as to when patches will be deployed and how the patching effort will be
prioritized with the other work your business conducts.
Although a small company might be able to patch everything right away when a new update is
released, a large company hosting complex or mission- and business-critical applications generally
does not have this luxury. Updates need testing and deployment in a systematic fashion that reduces
the chance that a patch will adversely affect an important system. You never want the cure to be
worse than the illness! To intelligently assess new Security Bulletins and their effect on your systems,
you must triage each patch. An example of a triage process follows:
• Rank the patch’s applicability to your environment.
• Assess the risk if you do not deploy the patch. Generally, you calculate risk as the probability of
an event multiplied by the damage that the event could cause. In terms of a patch, the risk might
be the chance that someone could compromise the system multiplied by the effect of the break
in. Let’s use the LSASS DLL as an example again. The risk for this vulnerability is very high
because it is easy for an attacker to access the vulnerability through an SSL Web site. And the
damage is high because the attacker could take full control of the computer system. High proba-
bility times high potential damage equals high risk.
• Assess the damage if someone exploiting the vulnerability that the patch addresses attacks you.
• Assess the patches based on target platform. Microsoft Security Bulletins specify the target of a
patch, such as Windows, SQL Server, IE, or Office.
• Determine whether you can make any mitigating efforts in the short-term to shoreup your
defenses while patch testing occurs.

At the end of this triage assessment, set your sights on determining the criticality and priority for
deploying each patch to specific computers in your environment. For example, priority patches likely
include immediately exploitable attack vectors such as employees using a vulnerable version of IE to
surf infected pages or attackers attempting to infiltrate an unprotected Web server.



Most corporations protect their Internet connections with perimeter firewalls that inspect and
permit inbound and outbound network traffic based on ACLs. The use of a perimeter firewall will
help mitigate many exploit attack vectors. For example, the RPC exploit required a computer listening
on TCP port 135. Most corporate perimeter firewalls ordinarily block this port. Consideration of these
mitigating factors when triaging new patches is important, but don’t assume that you are always pro-
tected. Most firewalls will not protect you from worms or viruses that are distributed through email
messages unless those firewalls have built-in antivirus scanning or intrusion prevention capabilities.
When considering your firewall protection, keep the following scenario in mind. Your remote
users routinely breech your perimeter firewall by transporting their work laptop from inside your pro-
tected LAN to their home, which might be directly connected to the Internet using a DSL or cable
connection. Perhaps they are running a base version of SQL Server and Microsoft IIS on their work
laptop. They disconnect from the corporate LAN and connect their home computer by plugging
directly into their cable modem. Worms that attack IIS and SQL Server (e.g., Nimda, Code Red, SQL
Slammer) still plague the Internet and developer’s computers run a high probability of being infected.
After infection they might either establish a VPN tunnel back into the company or physically carry
and connect their laptop onto the company LAN. When reconnected to the LAN and inside the
perimeter firewall, infected computers can propagate the worms to other internal systems.
This scenario might affect your triage decision regarding when to deploy a patch to your internal
systems. This scenario also provides a good example for implementing system-startup-based and
time-based patch management scanning software that routinely checks that patch management status
of any system on your LAN. Systems not patched are updated or else quarantined from the network.
This practice ensures that even after an initial wave of patch updates, computers brought onto the
network later will be patched.

Weigh Deploying Updates vs. Exploit Mitigation Efforts
The triage team also needs to review and recommend mitigating factors for patches, environments,
and targets. In the Security Update Bulletins for each patch, Microsoft lists several common mitigating
factors specific to that vulnerability. In addition to these, it is important for your triage team to consider
factors relevant to your environment. For example, in the IE exploit attack vector described earlier,
mitigating factors might be to install a client-based IPSec or perimeter firewall ACL that prohibits out-
bound Web requests to specific sites. The mitigating action does not necessarily solve the problem
but it might buy you time so that patches can be appropriately tested and deployed.

Choosing Software to Deploy Patches
Fundamentally, patching a computer consists of downloading the appropriate software update and
executing it on a target computer. Historically, Microsoft product teams introduced distinct patch man-
agement technologies. This means that Windows OS updates are very different from Office updates
and your patch deployment tools might support one better than the other. (Microsoft is addressing this
concern and promises to one day combine all product updates into a common delivery mechanism.)
When configured properly, Automatic Update will check for updates automatically. However, the
manual process for deploying patches usually consists of logging onto computers and either visiting
Windows Update or manually downloading and installing the appropriate patches. This process is
sometimes complicated because Microsoft might release multiple (sometimes three or four) update
files per security update depending on the version of software installed. For example, an IE patch



might be released as separate files for IE 5.0, IE 5.5, IE 6.0, etc. This slows the manual process
because in a mixed environment you must download each of these versions, then choose the correct
patch to run for each computer system you manage. This patch version disparity alone is a com-
pelling reason to purchase and use an effective patch management tool.
A good patch management tool not only scans a computer for the missing patch, but will also
discern the proper version needed, download it, and install it. For example, you can use several tools
to scan a set of computers running different software versions, then simply instruct the patch installa-
tion software to deploy patch MS04-xx. This system ensures the correction version of MS04 is deployed
despite the platform. The patch management tool scans the targets, determines the patches necessary,
downloads the patches from Microsoft, then installs the correct version on the appropriate systems.
Some third-party patch management tools repackage the Microsoft patches into a different format that
lets them add features, such as support for multiple (non-Microsoft) software vendors and additional
installation functionality. Later this chapter discusses some of the features to watch for when selecting
patch management software.

Windows Automatic Updates
Microsoft offers several patch management software packages aimed at different audiences. Small
office/home office (SOHO) and individual computer users without a network infrastructure can con-
figure the Windows XP Automatic Updates feature which regularly polls the Microsoft Web site for
newly available patches. The Automatic Updates client software identifies the correct patch required
for each individual computer and when new patches are available a system tray icon pops up, as
Figure 1-4 shows, and notifies the user.

Figure 1-4
Receiving notification that new updates are ready to be installed



From the Automatic Updates dialog box, the user can review the updates, select updates to
install, and automatically install the patch at a specified time, which Figure 1-5 shows.

Figure 1-5
Reviewing and selecting which updates to install

Windows Automatic Update covers patches for a variety of Microsoft products including: Win-
dows, Office, Crystal Reports Web Viewer, Exchange Server, Internet Security and Acceleration Server
(ISA Server), MSN Messenger, Virtual PC for Mac, BizTalk Server, Content Management Server (CMS),
FrontPage Server Extensions, IIS, SQL Server, and more.
Chapter 2 describes in detail the Microsoft communications. The chapter also contains links to the
patches so that you can download them and manually install them on your computer systems.

Microsoft Software Update Services and Windows Update Services
Microsoft also created Software Update Services (SUS) and the soon-to-be-released Windows Update
Services (WUS) to provide large companies more control over patch deployment to end user com-
puters. SUS leverages the same client as the previously mentioned Windows Update. This client is
included in Windows 2000 SP2 and later and Windows XP SP1 and later releases. But systems using
Windows 2000 SP1 or earlier or Windows XP (without SP1 or SP2) need a separate Automatic Update
client.
SUS lets you centrally manage the automatic update settings of your end user computers and also
lets you deploy your patches from a centralized SUS server in your network. A systems administrator
can approve all updates on SUS server and those approved will be sent to the clients. This practice
saves WAN bandwidth because not every end user computer needs to repeatedly download the same
patches from Microsoft. Instead the SUS server downloads the patches from Microsoft, as Figure 1-6
shows, then each end user’s computer downloads the patches from that SUS Server.



Figure 1-6
Downloading updates from a centralized SUS server

After you install SUS inside your corporate network boundaries, it polls the Windows Update
server on the Internet for new updates, downloads them, and makes them available for deployment
in your corporate environment.
Your central SUS server can also feed other SUS servers located in branch offices, for example for
remote deployment to reduce network traffic. Additionally, SUS provides centralized configuration by
means of a Group Policy Object (GPO). Configure when and how to download and deploy patches,
then assign that GPO to your computers in specified GPO containers such as sites, domains, or OUs.
Chapter 6 will cover more details about SUS and the newer WUS.

Microsoft SMS 2003
Microsoft created SMS to help enterprise-size organizations manage a large number of end-user com-
puters. SMS 2003 integrates the patch management features released for SMS 2.0 Feature Pack 1. SMS
2003 provides a much higher degree of targeting and more robust reporting than SUS. For example,
you can specify to deploy patches based on machine attributes (e.g., laptops versus desktops) and
you also have a fine degree of control over patch deployment. In addition, you can set up a patch
deployment package that lets the user choose the most convenient time to install patches within a



3-day window after patch deployment. Chapter 7 explores some of the SMS 2003 features sur-
rounding patch management.

Beyond Microsoft
The software involved in a patch management solution generally scans target systems for missing
patches, then deploys patches on those computers. Various software applications add features and
functionality to help this process.
Many patch management applications let you create several groups that contain desktops or
servers, such as IIS servers, database servers, infrastructure servers. Look for products that ease the
process of populating to these groups. For example, can they read Active Directory (AD) to get group
or structure information such as domains, sites, or organizational units (OUs)? Can they create groups
based on IP address or other characteristics (e.g., software installed) of the target systems? Look for
the ability to quickly customize and save patch group memberships. Using predefined groups will
save you time during subsequent scanning and deployment procedures.
The patch scanning features vary by product. The most accurate (but frequently slowest) scan-
ning methodologies involve comparing the registry and specific file versions (including size or date)
of a target computer with the desired values stored in a patch database. The patch management tool
flags a computer when any of the values do not match.
The scan and deployment features also vary by product so be sure to put several products to the
test. Some products let you deploy patches immediately following a scan and some let you schedule
both the scan and deployment. For example, you can scan anytime to check compliance, then
deploy later during specific change windows or at night. Some patch management tools retain a his-
tory of scans for auditing purposes or in case a rescan is necessary. Many Microsoft updates require a
reboot when installed and different patch management tools let you specify when and how the
reboot should occur. Some products use QChain, the Microsoft utility that keeps track of changed
files, to minimize multiple reboots through a succession of patch updates. Also check whether the
products support Microsoft update rollback features. Not all patches support this feature, but you
might find it useful for your patch management software to support patch uninstallation also.
Patching Office products may require the Office installation files. If you want to deploy Office
patches, make sure the patch management tool supports Office deployments and check with the
vendor to determine whether they support updating multiple versions of Office (each needing sepa-
rate source files) with a single scan and deploy action.
Installing patches requires administrator access at some level, so make sure the products you
select will fit into your user privilege model. For example, will your end users need to be local
administrators or does the patch management tool run under a separate privileged account? Some
patch management solutions require that a software agent be installed on every computer, yet other
solutions scan and deploy entirely from one management console. Agents can provide better feed-
back and installation control but also increase the software footprint of the computer, which may be
an important consideration for server deployments. Agents also tend to provide more robust remote
management options and may include basic Quality of Service (QoS) controls, such as bandwidth
throttling and checkpoint restarts.



Training
The final essential element to a solid patch management program is to provide quality, comprehen-
sive training to everyone involved with the patch management program. At first consideration you
might think of training the systems administrators who use the patch management software day to
day. But don’t forget about training management who must buy into your patch management program
and fund the software and resources required to roll out the patches.
Extend your training efforts beyond how to use your patch management software. Include
training for the processes behind your entire patch management strategy and tactics. This includes
developing documentation and holding meetings regarding the elements presented earlier in this
chapter, such as the roles of the various Patch Management Triage and Deployment Team members,
how to interpret Microsoft’s security software update communications, and how to keep your system
inventory current to facilitate patch triage decisions.
When a new exploit ravages the Internet, bring together your patch deployment team and review
the exploit’s attack vector (the method that the exploit used to leverage a particular vulnerability). Dis-
cuss how your patching efforts saved (or could have saved) your organization from this exploit. If
you were a victim of an exploit resulting from an unpatched vulnerability, immediately conduct a
postmortem review. Use this review to play back the steps leading up to the attack. Use the session
to help train others affected by the exploit on the importance of your patching processes. Another
benefit of a postmortem review immediately following an exploit is that everyone is much more
acutely aware of the issues and problems leading up to the exploit and are likely to accept action
items for any corrective actions that lead to process improvements. Even if you were not vulnerable
to a widespread exploit such as a mass-infecting worm, use the publicity of the event to rally your
team to confirm your processes and drill team members with what if scenarios to encourage continual
process improvement.
Develop training materials that document your patch management process. These materials
define the goals of the patch management team and the roles and responsibilities of each team
member. For example, a systems administrator might be the point person for installing the patches on
specific systems but a developer might be responsible for testing the effect of the patches on the
system applications. Clearly document your organization’s entire patch management process: from
system and application inventory, to patch triage activities, to patch testing, to deployment, and even
to follow-up testing. Review with team members their roles in the process and distribute the docu-
ment for reference. You will find that physically documenting the process helps bring auxiliary team
members into your process, which ultimately improves the effectiveness of the entire program.
Training consists of both formal and informal meetings. Formal meetings might include Web-
based seminars from your patch management software vendor or in-house expert. Formal training
might also include dry-run sessions and drills, which keep staff current and skilled on your chosen
patch deployment methodology. Informal training comes in the form of discussion groups or emails
that are sure to circulate when preparing for or during a patch management exercise.
Keep up to date on the version and features of your patch management deployment software.
This industry is still somewhat new and Microsoft will continue to consolidate and improve its patch
update delivery mechanisms. As Microsoft evolves its technologies patch management software ven-
dors will do the same.



Also train Quality Assurance (QA) testers and patch deployment engineers to proficiently use
your tools and testing methodologies to ensure that new patches are thoroughly tested and promptly
and effectively applied.
Even if you are not a software development company, you might be surprised at the QA
resources available to assist with the testing of your patches. Whereas QA testers for software compa-
nies test developer’s code to look for bugs and performance issues, application service providers
(ASPs) use QA staff to test Web sites for proper operation across the target audience of that ASP.
Large organizations in more traditional lines of business (LOB) sometimes employ QA testers to test
new functionality for enterprise software such as large financial applications, customer relationship
management (CRM) systems, point of sale (POS) systems, etc. These people are also commonly
experts with the target systems and you will likely find it valuable to tap their knowledge and famil-
iarity with their systems. Plus they might be able to help put together appropriate tests or review your
triage decisions to ensure that after a patching exercise the target platform remains fully operational.
Chapter 3 describes ideas and attributes for a patch management testing plan. Ensure that the
executors of these testing plans are also familiar with the patching process and methodology. When
integrated into the patch management program your organization’s QA resources will become your
frontline scouts to warn you of any problems that might arise as a result of a particular patch.

The Full Rally
A solid patch management program consists of well-defined processes, effective software, and com-
prehensive training. Consider developing a Patch Management Triage and Deployment Team to regu-
larly meet and review and prioritize upcoming patches and help marshal the deployment process. In
summary, consider these pointers to help set up your patch management program:
• Identify your processes to assess, test, and deploy the updates.
• Create a Patch Management Triage and Deployment Team to help coordinate your patch man-
agement activities.
• Subscribe to Microsoft and non-Microsoft patch and security advisories and bulletins. For central-
ized management, consider subscribing an internal distribution list to the Microsoft Security Bul-
letins newsletter for distribution within your company.
• Review all new Security Bulletins with the team to assess risk and triage deployment of new
patches.
• Weigh deploying updates versus exploit mitigation efforts for different patches, environments, or
targets.
• Determine SLAs for different levels of patches, for example, internal versus production or work-
station versus server.
• Devise and document testing procedures to ensure that the appropriate groups test and sign off
on a patch before released to production. Consider a burn in period when feasible.
• Select patch testing and distribution software effective for your organization and train staff on
how to use this software to deploy the updates.
• Scope and cost will often dictate whether to use Windows Update or an external patch manage-
ment software such as SUS, SMS, or third-party tool to manage the deployment of new updates.
• Drill and train staff not only on the patch management tools but the processes for triaging and
testing new software updates.



• Train QA testers to use the same patch management tools and processes as your production
teams to ensure consistent testing between labs and production.

Microsoft offers and supports low-cost patch deployment tools and tools that scale for very large
enterprises. If Microsoft does not have a solution that fits your organization, consider one of the many
new third-party patch management and deployment software packages that have hit the market.
Chapter 2 will examine the Microsoft Update Bulletin and communications. Microsoft uses these
primary information delivery mechanisms to inform its customers about newly available patches.


17

Chapter 2:

Microsoft Update Bulletin
and Communications
A software update fundamentally changes the way that the OS or application code works and in
some cases these internal patches can affect the outward operation or behavior of your systems.
Additionally, the vulnerabilities that some software updates address might not apply directly (or at all)
to every one of your servers and workstations because of their function or location. For these reasons
it’s crucial that you and your Patch Management Triage and Deployment Team understand exactly the
scope of the update, including what vulnerabilities the patch addresses and what existing software
components it updates and affects. This fundamental data will help you triage when and where to
deploy the update. For example, you might want to deploy a Windows Media security fix to
employee workstations before applying the fix to Web farm servers because of the greater potential
harm to the workstations. Of course each of these decisions must be made individually for your
organization and on a per-computer or class-of-computer basis.
To help answer your questions about software updates, Microsoft continues to improve their
security update communication tools. Microsoft uses email and the Microsoft Security Web site at
http://www.microsoft.com/security as the primary vehicles for communicating new software updates
but also supports Usenet newsgroups, chats, and Webcasts to get the word out about new updates.
The email messages proactively notify you of all new updates. These notifications describe the
update, the vulnerability it corrects, the level of severity or urgency, and contains links to other
information including the Microsoft Security Bulletin Web site.
The Microsoft Security Bulletin Web site contains detailed information on all Microsoft software
updates. Microsoft identifies each update with a unique, sequential label (e.g., MS04-XXX means it is
the XXXth Microsoft Security Update in 2004) and includes summary information about the update as
well as technical details and FAQs about the update including alternate methods for mitigating the
vulnerability. Not all updates will have workarounds applicable to your environment for mitigating
the vulnerability without deploying the patches, but the bulletins explain the steps to implement any
workarounds.
Microsoft security newsgroups and chats also include a discussion board question and answer
forum where end users of Microsoft systems can post questions and other users (often Microsoft
employees or other experts) can respond with answers. Bearing in mind that the information
presented in these forums is subjective and unofficial, they are a terrific place to learn about other
people’s experiences with a particular update. Microsoft also offers live and archived Webcasts
highlighting information about security bulletins.



Spreading the Word Quickly: Microsoft Email Notifications
Microsoft primarily uses email messages to alert customers of new security updates. Anyone can
subscribe to the Microsoft Security notifications. Additionally if you are a member of an enhanced
support program such as Microsoft Premier Support, your technical account manager (TAM) might
supplement these email messages with additional information or early warning of updates specifically
relevant to your company. (If you are a Premier Support subscriber, talk with your TAM about
options available to you.)
Microsoft sends out email notifications as a part of their newsletter subscription service and they
write multiple security-related newsletters that target different audiences. When starting out, you might
find value in subscribing to all the newsletters to get a sense of the content, tone, and audience until
you find several that best fit your needs. Even if you are a small- to medium-sized business you
might benefit from the additional information provided in the Microsoft Security Newsletter for Home
Users. This newsletter is aimed at less technical users but often includes additional information that
might, if forwarded to employees, be useful in helping them secure their home systems (which in
turn will likely improve security for your business, especially when mobile users connect remotely).
Signing up for Microsoft security updates is easy. Navigate your Web browser to the Microsoft
Subscription Center at https://profile.microsoft.com/RegSysSubscriptionCnt—you must have a
Microsoft Passport—and sign up for any of the available newsletters that interest you. The security
update related newsletters offered in mid-2004 included:
• Microsoft Security Newsletter
• Microsoft Security Newsletter for Home Users
• Microsoft Security Notification Service
• Microsoft Security Notification Service: Comprehensive Version
• Microsoft Security Update

Each of these newsletters targets a specific audience with specific information. You can click links
to sample newsletters for each. Table 2-1 lists the security-related newsletters and provides a short
summary of each newsletter as described on the Microsoft Web site.


Chapter 2 Microsoft Update Bulletin and Communications 19

Table 2-1 Microsoft Security Software Update Newsletters
Newsletter Title Description from the Microsoft Subscription Web Site
Microsoft Security This monthly newsletter is the authoritative information source for understanding the
Newsletter Microsoft security strategy and priorities. Written for IT professionals, developers, and
business managers, it provides links to the latest security bulletins, FAQs, prescriptive
guidance, community resources, events, and more.
Microsoft Security This bimonthly newsletter offers easy-to-follow security tips, FAQs, expert advice, and
Newsletter for Home Users other resources that help you enjoy a private and secure computing experience.
Microsoft Security Microsoft’s monthly Security Notification Service provides links to security-related
Notification Service software updates. The goal of this service is to provide accurate information you can use
to protect your computers and systems from malicious attacks. These bulletins are written
for IT professionals and contain in-depth technical information.
Microsoft Security The Comprehensive Updates version serves as an incremental supplement to Microsoft’s
Notification Service: Security Notification Service. It provides timely notification of any minor changes to
Comprehensive Version previously released Microsoft Security Bulletins. These notifications are written for IT
professionals and contain in-depth technical information.
Microsoft Security Update Geared toward home users and small businesses, these monthly alerts notify you when
Microsoft releases an important security bulletin or virus alert and explain, in non-
technical terms, when you might need to take action to guard against a circulating threat.

Soliciting Help from Your Peers: Microsoft Newsgroups
Let’s say you have received the email notification and visited the Microsoft Security Bulletin Web site
but you still crave information about how others are responding and handling a new security update.
Or maybe you simply have a question that you want to ask a community of users like yourself.
To help gather more information about a patch, you can peruse the official Microsoft Security
newsgroups or the Internet Usenet for a broad source of supplemental information. The newsgroups
consist of a threaded conversation forum in which a community of users ask questions and respond
directly with answers to other users’ postings. In many large newsgroups Microsoft Most Valuable
Professionals (MVPs), who are Microsoft-designated experts on a particular product or solution, or
other experts will chime in with recommendations or clarifications to the myriad of postings.
Realize that the forum is unmoderated and the information is not official Microsoft (e.g.,
something a user recommends might be a best practice and recommended for your environment,
at times the information might be incorrect). But when you need a quick response from a field
of peers, the newsgroups are a great place to get information. After a few days of assessing the
newsgroups, you will more easily recognize the quality information from the bad information.
You can use your Web browser or a newsreader client to access the newsgroups. To visit the
Microsoft security-related newsgroups, navigate to http://www.microsoft.com/technet/community
/newsgroups/security/default.mspx and select the newsgroup security topic that interests you. From
this Web page you can click one of two links depending on whether you are using a Web browser
or newsreader client to access the forum. The Web browser offers fairly sophisticated browser
controls, which Figure 2-1 shows, which are fine for casual browsing or searching. You will find
that using Outlook Express or another third-party newsgroup reader is much better for frequent
newsgroup usage.



Figure 2-1
Viewing the Microsoft newsgroup discussions in Windows Update General

The Microsoft Security newsgroup topics include:
• Security General
• Security HfNetChk
• Security Microsoft Baseline Security Analyzer (MBSA)
• Security Toolkit
• Security Virus

The Microsoft Products and Technologies newsgroups cover:
• Access Security
• Internet Information Services (IIS) Security
• Microsoft SQL Server Security
• Windows 2000 Security
• Windows SDK: Security API
• Windows XP Security and Administration

If for some reason, Microsoft does not list a Windows Update newsgroup on this security page,
you can obtain a broader list of newsgroups (including Windows Update newsgroups) from the
Microsoft Communities newsgroups Web site at http://communities2.microsoft.com/communities
/newsgroups/en-us/default.aspx. From the left pane of this Web page you can select the language,



product, and newsgroup that interest you. For example, for a patch management problem first
expand your language of choice, next look for Windows Update, then click Windows Update
General to visit the content of the Windows Update newsgroups.
For faster access and a richer UI than a Web browser provides, use Outlook Express or a
third-party newsreader client to subscribe to the Microsoft software update-related newsgroups. You
can specify to connect to any of the Microsoft newsgroups by configuring your newsreader to
connect to the Network News Transfer Protocol (NNTP) server msnews.microsoft.com. Download a
list of all available newsgroups, search them, select those that interest you, and subscribe to them, as
Figure 2-2 shows. Another benefit of a newsreader is that you can subscribe to a newsgroup and the
newsreader will download new messages for you. This tool makes it easy to check regularly for new
information or follow particular threads or responses to your postings.

Figure 2-2
Displaying the newsgroups with subscriptions



Msnews.microsoft.com hosts around 10 Windows Update centric newsgroups in different
languages. The English software update centric newsgroups include:
• Microsoft.public.officeupdate
• Microsoft.public.softwareupdatesvcs
• Microsoft.public.win2000.windows_update
• Microsoft.public.win98.internet.windows_update
• Microsoft.public.windowsceupdate
• Microsoft.public.windowsupdate

The popularity of the newsgroups ebbs and flows, so sometimes the content can be quite sparse.
At publication time for this eBook, the microsoft.public.windowsupdate newsgroup contained the
most messages. If you are looking for an answer to a specific question about a Microsoft software
update, this particular newsgroup is an excellent place to start searching.
The Microsoft newsgroups are not the only newsgroups discussing Microsoft Software Updates.
When you need to quickly search the entire Usenet (all public newsgroups on the Internet), try using
Google Groups available at http://groups.google.com. This Web-based search engine returns a very
fast search with a threaded conversation of newsgroups containing your search criteria.
You can use Google Groups to search a specific newsgroup too. For example, to search only
the Microsoft.public.windowsupdate for all postings containing the words Service Pack 2, enter the
following search syntax in the Google Groups search field:

service pack 2 group:microsoft.public.windowsupdate

Click the Advanced Groups Search for even more options.

Microsoft Security Bulletin Web Site
So far this chapter has explained how Microsoft uses email messages to proactively let customers
know about new security update releases and it has explored how newsgroups let peers interact to
answer questions about updates. However, the most detailed source of information on Microsoft
security updates is the Microsoft Security Bulletin Web site. This site contains the official Microsoft
communication about specific software updates. These Web pages of information contain detailed
information about every security update that Microsoft releases. Microsoft lists these bulletins in
multiple formats.
To scan for security updates by product and date, which Figure 2-3 shows, navigate to
http://www.microsoft.com/security/bulletins/default.mspx.



Figure 2-3
Scanning security updates by product and date

This page sorts the updates by product and month. Drill down on any month to get more details
on the bulletin, as Figure 2-4 shows.



Figure 2-4
Drilling down to the Windows security updates for July 2004

Alternatively, the Microsoft Bulletin Search Web page provides a more useful view and more
direct route to the bulletins. On this page you can view all updates in chronological order, search by
product or technology, or filter by severity rating. The Microsoft Security Bulletin Search, which
Figure 2-5 shows, is available at http://www.microsoft.com/technet/security/current.aspx.



Figure 2-5
Displaying the Microsoft Security Bulletin Search Web site

From this page, select a specific update to drill down to the full bulletin description, which
Figure 2-6 shows. The Security Bulletin Search page contains specific information about the bulletin in
a consistent format that your Patch Management Triage and Deployment Team can use to make
triage decisions.



Figure 2-6
Viewing the full description of a bulletin

The upper section of each bulletin includes the issue date, the version, and any update dates
when applicable. A Summary section lists
• Who should read this document
• Impact of Vulnerability
• Maximum Severity Rating
• Recommendation
• Security Update Replacement
• Caveats
• Version Requirements for Dependent Components for this Update
• Tested Software and Security Update Download Locations
• Affected Software



The following four sections contain the crux of the bulletin:
• Executive Summary
• FAQ
• Vulnerability Details
• Security Update Information

Ancillary information about the update is described in
• Acknowledgements
• Obtaining Other Security Updates
• Support
• Security Resources
• Software Update Services
• Systems Management Server
• Disclaimer
• Revisions

The following sections of this chapter describe these items in more detail.

Security Bulletin Titles
Microsoft suffixes the title of each bulletin with the Microsoft Knowledge Base number. As Figure 2-5
shows, the heading of bulletin MS04-026 is:

Microsoft Security Bulletin MS04-026
Vulnerability in Exchange Server 5.5 Outlook Web Access Could Allow Cross-Site Scripting and
Spoofing Attacks (842436)

You will notice that Microsoft categorizes its security updates by a number similar to MSYY-XXX
(e.g., MS04-025). The YY is the year and the XXX is the number of the bulletin. So in the case of
MS04-026, it is the 26th bulletin of 2004. Some bulletins also list an update number, such as 842436.
The update number corresponds to the Knowledge Base article ID number.
So by looking at the earlier name, you can deduce that this is the 26th security bulletin of 2004
and the title is Vulnerability in Exchange Server 5.5 Outlook Web Access Could Allow Cross-Site
Scripting and Spoofing Attacks. The corresponding Knowledge Base article is 842436.
The name is important because it is the first piece of information that can help you triage the
update. Generally the update title begins with one of the following:
• Vulnerabiltiy in…
• Security Update for…
• Cumulative Security Update for…

The phrase Vulnerabiltity in means that Microsoft found vulnerability in one of its products or
technologies and this security update fixes this vulnerability. (You must still read the details to assess
the vulnerability and the Microsoft response.)



Examples of recent Vulnerability in titled updates include:
• Vulnerability in HTML Help Could Allow Code Execution (840315)
• Vulnerability in Task Scheduler Could Allow Code Execution (841873)
• Vulnerability in POSIX Could Allow Code Execution (841872)
• Vulnerability in Utility Manager Could Allow Code Execution (842526)

A bulletin with a title prefixed with Security Update for might contain fixes to multiple
vulnerabilities. For example, the security bulletin MS04-011 lists 14 vulnerabilities addressed in a
single update:
• LSASS Vulnerability - CAN-2003-0533
• LDAP Vulnerability - CAN-2003-0663
• PCT Vulnerability - CAN-2003-0719
• Winlogon Vulnerability - CAN-2003-0806
• Metafile Vulnerability - CAN-2003-0906
• Help and Support Center Vulnerability - CAN-2003-0907
• Utility Manager Vulnerability - CAN-2003-0908
• Windows Management Vulnerability - CAN-2003-0909
• Local Descriptor Table Vulnerability - CAN-2003-0910
• H.323 Vulnerability - CAN-2004-0117
• Virtual DOS Machine Vulnerability - CAN-2004-0118
• Negotiate SSP Vulnerability - CAN-2004-0119
• SSL Vulnerability - CAN-2004-0120
• ASN.1 “Double Free” Vulnerability - CAN-2004-0123

The code CAN-200X-XXXX that follows the name of the vulnerabilities means it is a candidate for
inclusion into the Common Vulnerabilities and Exposures (CVE) dictionary managed by the MITRE
Corporation and funded by the US Department of Homeland Security. (For more information about
CVE, visit the Web site at http://www.cve.mitre.org/about.)
Fixes to each of these vulnerabilities are wrapped up into one update: MS04-011. When
Microsoft bundles many fixes into a single update such as this one, you might think it’s easier to
deploy because you need to run only one update. But be careful because if you have a problem or
incompatibility with any one of these fixes, you might not be able to install the update and must
forego protection from the remaining vulnerabilities. For this reason it’s very important to read the
details of each of these bulletins to understand which components will be patched, then assess how
the patches might affect your systems or applications.
If an update’s title begins with Cumulative Security Update for it generally means that this update
supersedes (and rolls up) all previous updates for that particular product or technology. For example,
Microsoft released cumulative updates for the following products on these respective dates:
• Internet Explorer (IE) on July 30, 2004
• Outlook Express on July 13, 2004
• Microsoft remote procedure call (RPC) and Distributed Com (DCOM) on April 13, 2004

So when installing a base OS, you should be able to install the July 30, 2004 cumulative update
for IE to make it current as of July for all previously identified IE vulnerabilities.



The title also contains the Knowledge Base number associated with the security bulletin. You
can navigate to the Microsoft Help and Support Web site at http://support.microsoft.com and search
for the Knowledge Base article number, as Figure 2-7 shows, to get a link to any Knowledge Base
articles referencing the security bulletin. In many cases this Knowledge Base article is simply a link
back to the Security Bulletin Web site for that bulletin but sometimes other Knowledge Base articles
might be available that describe related technical concerns in reference to the security bulletin.

Figure 2-7
Using a Knowledge Base article number to search for articles

In addition to the title, every bulletin has an issue date and version number. The issue date is
generally the second Tuesday of every month but you can spot special (usually critical) updates by
dates that break this schedule. For example, MS04-025 was a cumulative update for IE released on
July 30, 2004. Microsoft deemed it important not to delay this update to the August 10, 2004 (the
second Tuesday in August) release and released it outside of the normal schedule. The version
number reflects the release version of the bulletin. Most bulletins are 1.0 but Microsoft might
increment them as new information develops. At the bottom of every security bulletin is a Revisions
section that describes the history of the revisions.



Bulletin Summaries
Each bulletin includes a Summary section, which Figure 2-6 shows. The Summary consists of a
synopsis of the security update suitable for initial reconnaissance and quick triage. Essentially, the
Summary informs you whether or not you are an immediate candidate for the update.
The first bit of triage information is listed in the first line of the Summary, titled Who should read
this document. Microsoft lists the audience that the update likely affects, for example: Customers who
use Microsoft Windows or Systems Administrators who have servers running Microsoft Exchange Server
5.5 Outlook Web Access.
Microsoft also lists the Impact of the Vulnerability and the Maximum Severity Rating. The
Impact of Vulnerability section describes what could happen if someone successfully leveraged the
vulnerability. One of the more severe consequences is Remote Code Execution. Other effects might
be Local Elevation of Privilege, Denial of Service, or Information Disclosure.
The Maximum Severity Rating is the Microsoft ranking of the security bulletin in level of
importance from Critical, Important, Moderate, to Low. Numerous factors go into determining the
Maximum Severity Rating of a bulletin. If a bulletin includes fixes to multiple vulnerabilities, then
the severity rating for the entire bulletin is set to the highest individual ranking of an included
vulnerability. Microsoft also provides a short Recommendation, such as Customers should consider
applying the security update, or Customers should consider applying this security update at the earliest
opportunity, or Customers should apply this update immediately.
Microsoft lists the Security Update Replacement that this bulletin’s update replaces (and
supersedes), which can be useful in collecting background information about the patch or remem-
bering a past test plan used for a previous patch deployment. In addition to the recommendation,
Microsoft lists any caveats associated with the update. Caveats are nuances or particularities that
customers should consider when assessing or deploying the patch. For example, MS04-026 lists the
following caveat, which is useful when considering how to deploy and test the patch:

Customers who have customized any of the Active Server Pages (ASP) pages that are listed in
the File Information section in this document should back up those files before they apply this
update because those ASPs will be overwritten when the update is applied. Any customizations
would then have to be reapplied to the new ASP pages.

New patches for complex software such as the OS can touch many different files across different
OS components. Microsoft documents the Version Requirements for Dependent Components for this
update to help you determine any necessary upgrades to software that you must perform before
applying the security update.
Microsoft also lists the Tested Software and Security Update Download Locations for the affected
software, unaffected software, and affected components. This section contains the links to download
the individual updates from Microsoft. After reviewing a few security bulletins, you’ll quickly see
the benefit of using a comprehensive patch management tool. For example, the Security Bulletin
MS04-024 references 10 downloads for the same security update—each one designed and compiled
for a specific platform (e.g., from Microsoft Windows Workstation 4.0 Service Pack—SP—6a through
Windows Server 2003 64-Bit edition). A high quality patch management tool will scan and detect the
platform version of each of your systems and download only the specific updates that apply.
Compare this with the arduous process of downloading up to 10 different platform-based updates



(for just one security update), saving them into specific locations, and manually running the proper
update for each different platform. Yuck! Use these testing and versioning notes to help you triage
the update and determine whether the update applies to your specific servers in your environment or
whether other software needs to be updated before the update is applied.

Learning More Details about the Update
The General Information section of the security bulletin update includes four sections:
• Executive Summary
• FAQ
• Vulnerability Details
• Security Update Information

Each of these sections includes comprehensive information about the update and in most cases
includes links to other sources of information about the vulnerability or update.
The Executive Summary, which Figure 2-8 shows, presents a short description of the update and
the vulnerability it addresses.

Figure 2-8
Viewing the Executive Summary of a security bulletin

It differs from the Summary in that it pulls together all the Summary elements into one narrative
and includes more details. For example, after reading the Executive Summary you should have
enough basic information to determine whether the update is applicable to your environment and
whether you concur with the Microsoft recommendation and severity rating.
A single Microsoft security update can include fixes to multiple vulnerabilities and the Executive
Summary will include the individual Severity Ratings and Vulnerability Identifiers for each of the



vulnerabilities as well as available links to third-party information about the vulnerability. For
example, the update commonly includes CVE identifiers that describe where you can find more
information about the vulnerability from the Web site at http://www.cve.mitre.org/cve/.
Sometimes the technical details surrounding an update can be complex and to keep the
Executive Summary lean, Microsoft often provides more details about the update as Frequently Asked
Questions (FAQ) related to this security update, as Figure 2-9 shows.

Figure 2-9
Displaying the FAQ for a security bulletin

This section’s length and content varies greatly by update. It is a great resource for determining
an update’s applicability and can also answer questions you might have surrounding triaging or
deploying the update. Whereas the Executive Summary aims to succinctly describe the update and
vulnerability, the FAQ section can be much more lengthy and can address a variety of ancillary
questions surrounding the update.
Microsoft also provides a section in the security bulletin that describes the Vulnerability Details,
which Figure 2-10 shows, and delves into the specifics of each vulnerability in the update.


Keep Your Business Safe with Effective Patch Management

Keep Your Business Safe with Effective Patch Management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie Keep Your Business Safe with Effective Patch Management

Ähnlich wie Keep Your Business Safe with Effective Patch Management (20)

Mehr von gopi1985

Mehr von gopi1985 (16)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Keep Your Business Safe with Effective Patch Management