Patch management is a little like taking out the trash or
cleaning the toilets: It’s not fun, but it has to be done. Most of the network
administrators I know seem to approach it in one of three ways:

  • Avoidance:
    they put it off as long as possible and then rush through it as quickly as
    they can.
  • Automation:
    they turn on Windows Update’s automatic update feature on all the
    machines, “set it and forget it” (which is really just another
    form of avoidance) and pray that they won’t encounter any incompatibilities.
  • Overkill:
    they set up an elaborate patch management program that involves personally
    trying out every patch in a test bed environment on an exact replica of
    every one of their production servers and then using expensive and complex
    deployment servers to apply the patches, after running complete and
    comprehensive vulnerability scans on each system to document exactly which
    patches are missing — in essence, making patch management a full-time job.

Whether your network is a small business workgroup or a multi-domain
enterprise, keeping the systems on your network properly updated is absolutely
essential. New operating system and application vulnerabilities are being
discovered every day, and as soon as a vulnerability
is made public, someone, somewhere will find a way to exploit it.

Avoidance isn’t the answer

Avoidance isn’t the answer, but it’s most common among
administrators of small networks — the ones that are least likely to have
adequate fault tolerance measures and other security solutions in place and
thus stand to lose the most — at least, as a percentage of their revenues — if
their systems are hit.

To be effective, your patch management plan must be timely
and continuous. Unfortunately, as with any type of preventative maintenance, it’s
easy to put it off because you’re always busy taking care of more immediate
problems. That means some type of automation is almost inevitable.

Windows Update: better than nothing

Relying on Windows Update is better than avoiding the issue
altogether, but it’s still not the idea solution. If there are only 10
computers on your network, you may be able to ensure that each system is
properly configured and getting all its updates regularly, but that strategy
doesn’t scale very well. You also must remember that the automatic update
feature only delivers updates deemed to be “high priority”. And what
if your network is running Windows NT or Windows 98 machines? Those versions
don’t support automatic updates (although they can be updated via the Windows
Update Web site).

Windows Update is an excellent solution for keeping consumer
computers up to date, and it will work in a small workgroup environment where
users are responsible for their own machines. But as the network grows, you
need more centralized control.

One thing you can do, in an Active Directory environment, is
configure Group Policy to administer the Automatic Update settings on computers
in the domain. This at least keeps you from having to physically visit each
computer to configure or verify its settings. You can also use the Group Policy
setting (found in Computer Configuration\Administrative Templates\Windows
Components\Windows Update) to schedule the day and time for installations. You
might also want to enable the Group Policy setting to Remove Access to Use All
Windows Update Features in the User Configuration node (User
Configuration\Administrative Templates\Windows Components\Windows Update) so
that even users who are local administrators won’t be able to install updates
manually. Automatic Updates will still run and install updates as scheduled.

By default, the updates will be downloaded from the public
Windows Update site. However, you can gain more control over the update process
by specifying that the updates be downloaded from an intranet update service.

Centralized software deployment

In a large organization, you are likely to have proprietary
applications that may cause conflicts with some updates. That can create a
nightmare if you don’t have more control over which updates get installed to
which machines.

There are several ways to centrally deploy updates in a
Windows domain. You can use Group Policy’s Software Installation functionality
to deploy and install service packs and some updates. Note that you’ll need to
obtain or create .msi packages for the software that
you install this way.

Group Policy Software Installation gives you a way to deploy
software to multiple machines from a centralized location, but it doesn’t
provide a way to get the updates in the first place. What you need is a way to
combine the automatic download aspect of Windows Update’s Automatic Update and
the administrative control of GP Software Installation. That’s what you get
with Microsoft’s Software Update Service or SUS (soon to be replaced by a new
version called Windows Server Update Service or WSUS).

NOTE: The release
candidate of WSUS had been made available. In its beta form, WSUS was called
Windows Update Services or WUS. The final release is expected sometime in the
second quarter of 2005.

With SUS and WSUS, you set up your own internal update
server on the network (running on a Windows 2000 or 2003 server). That server
downloads updates from Microsoft, then your network
clients download the updates from the SUS/WSUS server. As the administrator,
you have control over which updates are approved for installation on the client
machines. You can choose whether to download all the updates and store them
locally on the SUS/WSUS machine or they can be pulled directly from the
Microsoft public server when they’re approved for installation.

WSUS is designed with added scalability in mind. In addition
to updating Windows operating systems (as SUS does), it can update other
Microsoft products such as Office, SQL Server, and Exchange. Update support for
other products will be added, without any requirement for you to upgrade WSUS.

Another important scalability feature is that you can
install WSUS on Windows Small Business Server (SBS) 2003, so if you are using
SBS instead of the regular Windows server products, you can still use it.

WSUS also scales up well, as you add testing requirements
for patches. You can mark patches as Not Approved until you’ve tested them, or
you can mark them as Declined to remove them from your updates list (although
you can still get them back if necessary). WSUS can detect what updates are
needed, but it will also work in conjunction with more comprehensive third
party vulnerability scanners that detect patch status.

 Finally, WSUS’s scalability is enhanced by the fact that it’s free.
As long as you have licenses for the Windows server(s) on
which your WSUS server(s) run, and CALs for
the clients that connect to it, there’s no extra charge for the WSUS software
or the update service.