1. Why Patching Is Important
In the old days, when your network wasn’t connected to the
Internet, system administrators were the only people who installed
software, and users had only a green screen terminal, deciding when to
apply a patch was a fairly straightforward decision. If you were
having a specific problem and you wanted a bit of overtime on the
weekend, you came in and applied a patch. If no one was complaining
and you didn’t want to work on the weekend, you threw the tape
(patches always came on tapes in those days) in the drawer and waited
until you had to come in on the weekend for some other maintenance, or
users started complaining about a problem that seemed related. Or you
simply never got around to it at all.
Even in the more recent past it was possible to have a more
considered and gradual approach to applying patches. When a
vulnerability was identified, it often took months before there was
any real risk to your network.
Today that approach simply won’t work, as Code Red, Nimda,
Slammer, and others have all too clearly demonstrated. Within hours or
(at most) days of the release of a critical security update, there
will almost certainly be sample exploit code posted on the Internet,
telling anyone and everyone how to exploit the vulnerability. If you
ignore critical security updates, you place your entire SBS
network—and the data stored on it—at risk.
Applying software updates is only one part of a defense-in-depth
strategy to protect your network, but it’s a critical part. Don’t
neglect it.
2. The Patching Cycle
There are (or there should be) four basic phases in the ongoing
cycle of maintaining a well-patched, up-to-date network:
Assess
Identify
Evaluate and plan
Deploy
Each of these phases is essential to the successful management
of updates on your network. And in a typical well-run enterprise
network, each of these phases is quite formal and carefully
delineated.
Given the relative simplicity of SBS networks, and the more
realistic IT budgets and resources we have, you’re going to have to
combine and simplify the overall process a bit, and you’ll probably
even bypass phases on occasion. However, it’s good to have an
understanding of the phases and to think through the steps involved in
each one, even if you’re combining them. In the following sections,
we’ll cover each of the phases of the full patching cycle, and then
provide an “SBS Version” subsection that provides a realistic
description of the phase for an SBS network. Obviously, there is no
single SBS version—the resources and requirements of an SBS network of
50 users are a good deal different from those of 5 users.
2.1. Assess
The assess phase of patch management is
all about understanding what your environment is, where and how it
is vulnerable and can be attacked, and what resources and procedures
are in place to reduce those vulnerabilities.
When a patch is released, you can’t make an informed decision
about whether you need to install that patch unless you first know
what software is present in your environment and what your critical
business assets are that absolutely, positively must be protected.
So the first step to an overall patch management process is to
figure out what software you’re running in your environment. All of
it, we hope. Whether you build a spreadsheet, have a Microsoft
Office Access database, or just a keep it all in a chart in
Microsoft Office Word, you need to get your software environment
audited and documented.
Identify your critical business assets. Is there confidential
data that you couldn’t function without? Are there critical systems
that must be available at all times? Are there individuals whose
productivity is mission-critical? All of these are business assets
that you should factor into your overall patch management
strategy.
The next part of the assessment phase is to understand what
security threats and vulnerabilities you currently have. Do you have
legacy Windows systems that are no longer supported? Are there
non-Windows systems that aren’t being fully monitored and updated
automatically?
Are you running old versions of software programs that can’t
be easily updated or replaced? Do you have public-facing web servers
that are not behind your firewall? What are your security policies
and how are they enforced? These and many, many more questions need
to be asked—and answered.
Finally, you need to assess your patching infrastructure and
resources. How do you deploy software and patches now? Who is
responsible for identifying, testing, and deploying patches? What
resources are available to help with that? How rapidly can you
respond to a critical vulnerability that affects your systems? What
steps can you take to improve your response time?
2.1.1. SBS Version
If all that seems a bit much, it’s really just a lot of
somewhat formal words to say that you need to know what software
is running on your network and how it is updated. It’s also good
to have a record of what kinds of patches have caused trouble for
you in the past—when you see new patches that affect these areas,
you’ll probably want to do some additional testing before you send
the patch out.
2.2. Identify
The identify phase is about finding out
what software updates or patches are available, and how critical it
is that they be deployed in your environment. You need to take the
following actions:
There are many ways to discover patches, but for Microsoft
products one of the best ways is to sign up for email alerts. If you
do this, Microsoft will send you notifications of security updates
before they are actually released.
Note:
This link provides alerts only for security-related
patches.
Whatever method you use to discover patches, it’s important
that you have a way to trust the source of the patch information.
All Microsoft security update alerts are signed with a publicly
available PGP key, for example. And it shouldn’t be necessary to say
this, but just in case: Microsoft will never send a security update
as an attachment to an email! Never.
Warning:
IMPORTANT Wait, maybe you
missed that. Again, for emphasis: Microsoft will never
send a security update as an attachment to an email!
Never.
Once you know about a patch, you need to decide whether it’s
relevant to your environment. If all your client computers are
running Windows 7 (and they should be!), a patch that applies only
to Windows XP isn’t really relevant to your environment. However, if
the patch is a critical security update for Microsoft Office 2010
and you run that in your environment, you’ll need to apply
it.
When you determine that a patch is relevant to your
environment, you need to obtain the patch from a known and trusted
source. For a Microsoft patch, this generally means downloading it
directly from Microsoft. With SBS, this means letting WSUS download
the patch by synchronizing, but we’ll get to the gory details of
WSUS later. Find the relevant Knowledge Base article for the patch,
and then cut and paste the link to the download page directly into
your browser. Do not click the link in an email to get your patch.
Even when you have verified that the email is really from Microsoft
and is a legitimate email, you shouldn’t click the links. Get into
the habit of always using cut and paste. When you use cut and paste
to put a link into your browser, you greatly reduce the likelihood
of a phishing attack—being unknowingly redirected to a site that
looks exactly like the site you expected to go to, but is actually a
site designed to steal information from you or download unwanted
spyware onto your computer.
Note:
Most email clients today have the ability to force all email
to display as plain text. This is a good thing, because it
prevents unscrupulous people from hiding the real destination of a
link. The giveaway for detecting a bogus link will usually be that
it’s a link to an IP address, not the actual DNS domain name, or
if it is a DNS name, it’s not exactly the one you think it is. If
you make the change and read your email only in plain text, your
email won’t be as pretty, but you’ll be a lot safer.
To enable plain-text email handling in Outlook 2003, select
Options from the Tools menu. Click the Preferences tab, and then
click E-Mail Options. Select the Read All Standard Mail In Plain
Text and Read All Digitally Signed Mail In Plain Text check boxes.
Click OK and restart Outlook.
To enable plain-text email handling in Outlook 2010, click
on the File tab in the Ribbon and then select Options. Click Trust
Center, and then click Trust Center Settings to open the Trust
Center dialog box. Click E-mail Security, and then select the Read
All Standard Mail In Plain Text and Read All Digitally Signed Mail
In Plain Text check boxes. Click OK and then OK again. You might
need to restart Outlook for the changes to take
effect.
After you’ve downloaded the patch and read the associated
Knowledge Base article, you are in a position to determine just how
critical the patch is in your environment. Is this a patch that
needs to be deployed immediately, with limited testing—or even with
no testing? Or are there ameliorating factors that allow the patch
to be deployed as part of a regular patching schedule after full
testing?
2.2.1. SBS Version
Again, if that seemed a bit much, you’re probably right. But
it’s actually what we had to go through before the R2 version of
SBS 2003 if we didn’t have some method—usually third-party—to
automatically download and identify patches for our environment.
With the R2 release of SBS 2003, we were able to let WSUS take
care of the downloads and the initial analysis. SBS 2011 extends
that to fully support WSUS version 3, but you’ll still want to do
some thinking before you let it fire off an automatic update to
every client in the network.
2.3. Evaluate and Plan
The evaluate and plan phase of patch
management flows naturally out of the identify phase, and in many
ways is an extension of it. In this phase, you determine how to
respond to the software update you’ve downloaded. Is it critical, or
even necessary? How should it be deployed? And to whom? Should
interim countermeasures be employed that will minimize your exposure
to the vulnerability? What priority does the patch have?
The initial determination of need, suitability, and priority
is made during the identify phase, but in the evaluate and plan
phase, you should take a closer look at the patch. What priority is
the patch? If it affects a critical business asset and there’s no
easy or appropriate countermeasure except the patch, it will have a
higher priority for testing and deployment than if there’s a simple
countermeasure that you can implement until the patch can be
deployed. If it targets critical business assets, it’s going to have
a higher priority than if the only computers that are affected are
several old Windows 2000 computers that aren’t running any critical
business applications. (But you got rid of those old Windows 2000
computers, right?)
After you’ve identified the priority of the patch, you
need to plan the actual deployment. Which computers
need to have the patch deployed to them? Are there any constraints
or issues that interfere with the deployment? Who needs to be
notified, and what steps need to be taken so that the deployment
minimizes the disruption to the environment? If this is an emergency
release, will it go through a staged deployment, or is every
affected computer going to have the patch deployed as soon as
possible?
2.3.1. SBS Version
In any SBS network larger than a few clients, you should
have a couple of clients that are designated canaries. In all but
emergency-patch situations, these computers will have the new
patches deployed to them first. If they survive the patch without
major issues, you can OK the deployment onto the rest of your
clients.
Unfortunately, WSUS—as included with SBS 2011—doesn’t
support having a special group of client computers that are
treated differently from other clients. The workaround we’ve found
is to have one (or two) users who go directly to Microsoft Update
every Patch Tuesday and update their computers. This gets the
update onto their computers quicker than any other method and
allows some testing time before any automatic deployment can
happen. If you go this route, choose a user who has a fairly
typical computer and, most important, who is willing to take on
this role. Also, make sure that you carefully review the “Caveats”
section of the Security Bulletin. This section details known
issues and interactions that you should be aware of.
2.4. Deploy
The deployment phase of patch management
is in many ways the easiest phase. You’ve done all your preparatory
work; now all you need to do is the actual deployment.
First and foremost, communicate. Let everyone who will be
affected know that you will be deploying a patch, and what application or area of the
operating system it affects. If you know that the deployment will
cause changes in behavior, tell your users before the deployment.
You’ll have far fewer support calls if you’ve warned people that a
certain behavior is expected than if you surprise them.
2.4.1. SBS Version
With SBS, we have WSUS to do the deployment and track its
progress. If your canary user has survived, you should proceed
with the deployment. But the same rule applies as for a really
large enterprise—communicate. If users have open files and SBS
automatically deploys an update that requires a reboot, they could
potentially lose work. Sending a reminder email to your users on
Patch Tuesday is a good idea.
2.5. Repeat
After you’ve deployed a patch, the process starts over again.
It really is a continuous process—or it should be. At a minimum,
verify that the patch has been successfully deployed to the affected
computers. Update your software map and database so that you know
which computers have had the patch applied. Because our assumption
is that every patch is on every computer, we only keep track of the
exceptions. When a patch cycle is complete, we make a note of any issues,
confirm that deployment has been successful, and get ready for the
next round.
