Patches—everyone hates them, but they are an inescapable
part of the everyday computing world. I hated them and complained about
them when I was a UNIX system administrator some 20 years ago. And I
still hate them now, even though the overall process of obtaining,
testing, and applying them has gotten far better than it was back then.
In
the old days, when your network wasn’t connected to the Internet, when
system administrators were the only people who installed software, and
when users had only a green screen terminal, deciding when to apply a
patch was a fairly straightforward decision. If there was a specific
problem you were having 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 network, and the data stored on
it, at risk.
Applying
patches is only one part of a defense-in-depth strategy to protect your
network, but it’s a critical part. Don’t neglect it.
There are, or should be, four basic phases in the ongoing cycle of
maintaining a well-patched and up-to-date network. The four phases are
-
Assess -
Identify -
Evaluate and plan -
Deploy
Each of these phases is essential to the successful management of
patches on your network. Depending on the size and complexity of your
network, you might combine phases and even bypass them 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.
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 ameliorate 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, hopefully. Whether you build a
big spreadsheet, have a fully relational database, or use a
full-featured tool such as Microsoft Systems Management Server (SMS),
you need to get your software environment audited and documented. One
tool that can help with that auditing is Microsoft Baseline Security
Analyzer (MBSA).
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 NT 4 systems that are no longer supported? Are there Windows 95
or Windows 98 machines on your network? 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? Who is responsible
for identifying, testing, and deploying patches? What resources do they
have 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?
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
There
are many ways to discover patches, but for Microsoft products one of
the best is to sign up for e-mail alerts. If you do this, Microsoft will
send you notifications of security updates before they are actually
released. The sign-up page is at: http://www.microsoft.com/technet/security/bulletin/notify.mspx. You can tailor the notification method and detail level to suit your environment.
Note
The link above provides only alerts 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.
Once you know about a patch, you need to decide whether it’s relevant
to your environment. If all your client machines are running Windows XP
Professional SP2 (and they should be!), a patch that applies only to
Windows 2000 isn’t really relevant to your environment. However, if the
patch is a critical security update for Microsoft Office 2003 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. 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 on
the link in an e-mail to get your patch. Even when you have verified
that the e-mail is really from Microsoft and is a legitimate e-mail, you
shouldn’t click on the links in it. 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 a "phishing" attack—that is,
of 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 e-mail clients today have the ability to force all e-mail 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 to only reading e-mail in plain text, your e-mail
won’t be as pretty, but you’ll give yourself an additional layer of
protection from phishing attacks.
To enable plain text e-mail handling in Outlook 2003, select Options
from the Tools menu. Click the Preferences tab, and then click on 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.
Once
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?
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 98 machines that
aren’t running any critical business applications.
Once you’ve identified the priority of the patch, you need to plan
the actual deployment. Which machines 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 machine going to have the patch deployed as soon as
possible?
The deployment phase of
patch management is in many ways the easiest. 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 the deployment will cause changes in behavior, tell your
users before the
deployment. You will have far fewer support calls if you’ve warned
people that a certain behavior is expected than if you surprise them.
Depending on what the priority of the patch is and how many machines
it affects, you should test your deployment on a subset of the machines
or on your test network. If no problems are reported, you can extend the
deployment to additional users.
The
four phases of patch management are a circle, and when you’ve finished
the last phase—deployment—it’s time to start the first
phase—assessment—all over again. You should, at the very least, verify
that the patch has been successfully deployed to the affected machines.
Update your software map and database so that you know which machines
have had the patch applied. Ensure that any nonpatch countermeasures
have been successfully deployed as well. Verify that the patch hasn’t
caused issues for your end users that were missed during the testing of
the patch.
|
