Is your patch programme up to scratch?
Windows 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 programme 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 centralised 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.
Centralised software deployment
In a large organisation, 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 centralised 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 licences 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.