Patching a large enterprise full of server and client systems has become something of an administrative nightmare in most IT shops because of the importance of staying on top of security patches that Microsoft releases on a not-infrequent basis. Although Microsoft makes every effort to release patches in a timely manner, sometimes attackers themselves use security bulletins that inform them of a vulnerability to gain the ability to exploit it. With this awareness, an attacker can scan for companies whose machines have not been patched against the vulnerability, often severely damaging their systems. As the security specialist in your organization, you should have as part of your overall strategy a plan to analyze and quickly deploy the security patches that Microsoft releases.
To include new features and more functionality in newer versions of an OS, programmers have to write more lines of code. More lines of code mean more room for security holes, which leads to more patch releases. Not only do you need antivirus software to protect your system against malicious programs, you also need to worry about security patches so that hackers don t take advantage of a security hole. This was the case with the Blaster worm, which recently exploited the RPC/DCOM service and caused servers that didn t have the proper security patches to constantly reboot themselves, thus disrupting productivity by creating an unstable environment.
To help organizations and security specialists with this huge burden of securing networks against security vulnerabilities, Microsoft has made available a free product known as Software Update Service, or SUS. SUS essentially works as an internally controlled Windows Update site that allows you to analyze and approve security patches and then apply them to your networked computers in a consistent manner.
When deploying SUS, it s important to be aware of not only its capabilities but also its limitations. SUS certainly isn t a one- size -fits-all solution, and you should be certain that SUS will meet your needs before you deploy it.
SUS allows you to control which patches are visible to your users and automates the download and installation process so that no user intervention is required. Another important feature that is often overlooked is its ability to optimize bandwidth, especially for a large organization. Rather than having 5,000 clients each download a 3MB update (that s 15 gigabytes of information being pushed down your expensive Internet connection), you will be able to host the update locally and have clients download their information over an internal LAN connection.
In short, SUS allows you to maintain what is effectively an internal Windows Update Web site, where your SUS server contacts the actual Windows Update Web site and downloads updates that an administrator can review and approve for deployment. SUS has many advantages over Windows Update, the most obvious of which is that with SUS, you can control and approve the patches that are installed, as shown in Figure 4.5. As hard as Microsoft tries to build a software update package that will not break anything, sometimes patches that are not tested can damage a specific environment, rendering your computers unusable rather than tightening security on them.
However, SUS is far from a panacea, and it s important to remember its limitations. SUS only allows you to deploy critical updates and service packs that you download from Microsoft. You cannot deploy other Windows Update files, including software updates and updated device drivers, using SUS. Nor can you create your own .EXE or .MSI files and have SUS deploy them for you; anything that SUS deploys needs to be a critical update downloaded directly from Microsoft.
If you are working in an environment that supports many down-level or legacy clients, it s absolutely key to remember that SUS will only deploy patches for modern Microsoft operating systems, a definition that extends to the following:
Windows 2000 Professional
Windows 2000 Server, all versions
Windows XP Home
Windows XP Professional
Windows Server 2003, all versions
If you are still supporting Windows NT or 9 x clients, you will not be able to deploy patches for these operating systems using SUS. On the server side, you can t automate the installation of updates for back-end applications such as SQL or Exchange Server. Finally, there s no good way to push installations to your clients, since SUS is designed to operate in the background with no user intervention. So, if there is a newly released patch that you need to install on your client workstations right away, SUS doesn t offer an intuitive way to force an update for your clients.
When your environment is spread over geographically distant sites or remote offices, you need to accommodate these sites with SUS as well. You can configure secondary SUS servers for your remote offices that poll the main SUS server, download the updates from it, and in turn make them available to their local users. With SUS, you have the ability to configure these child SUS servers to synchronize with the main server on a time interval of your choosing, as shown in Figure 4.6. Whenever possible, you should configure this schedule so that this polling takes place during off-peak hours when network traffic is low so that SUS doesn t hog bandwidth, especially over expensive WAN links. This is especially important when you are dealing with remote sites that are connected using slower links, such as 56K ISDN lines; you want to ensure that the synchronization occurs after hours, when users have left for the day. Otherwise your SUS design might actually create a DoS for these remote users, since they won t have the bandwidth that they need to do their jobs. However, if your WAN topology can handle the traffic (if your sites are connected via multiple T1 lines, for example), you can configure synchronization to occur as soon as one hour after the master SUS server has downloaded its patches.
Group Policy is another great way you can deploy software in general and patches and updates in particular. Using GPOs, you can even customize who gets which updates and can thereby exert more granular control over the software distribution process, allowing you to prioritize updates based on importance. (As we discussed in the last section, this is something that SUS will not allow you to do.)
For example, let s say that a security patch has just been released that addresses a particularly dangerous security vulnerability in IIS. Instead of simply approving the patch and making it available for everyone via SUS and then crossing your fingers until it s deployed, you can create a GPO to forcibly update the OU, site, or domain that contains all your IIS Web servers. Especially if you have grouped your Web servers into a single discrete container such as an OU, this is quite an efficient way to deliver an update, since only the machines that need the update are the ones that receive it, and they receive the critical update as soon as Group Policy refreshes. This creates an even greater advantage over SUS if you have remote offices and child SUS servers to contend with. In this scenario, you would first need to wait until the child SUS server in the Web servers site synchronizes with the master server before that patch is even available to them. Using Group Policy, you are pushing the package to all the necessary servers regardless of geographic location.
|Test Day Tip|| |
Software installations in Group Policy can be applied to either computer or user configurations. Software packages applied to Computer Configurations are installed on computer startup. Packages applied to user configurations are installed at user logon.
Let s explore another situation; let s say that a critical security patch has been released for an application in use across your network. Before approving the update in SUS, you find during testing that the update interferes with a development application that is used by your Web programmers. If your Web programmers are separated into their own OU, you can use the Block Inheritance setting within Group Policy to push this patch out to everyone except the Development OU. Even if the development users aren t separated into a single OU, you can still use access control lists (ACLs) to prevent the harmful patch from being deployed to their computers. But again, you have the option of pushing a software package in this manner only when you use Group Policy, as shown in Figure 4.7. SUS does not offer this level of fine control.
|Test Day Tip|| |
Remember that a user needs Read and Apply Group Policy permissions to a GPO to be able to have that GPO applied to that user. You can alter the ACL on a GPO to control which users or groups will and will not have a GPO applied to them.
Now that you have configured your preferred method of pushing security patches to workstations and servers, how do you audit to make sure that your strategy is actually working? You ll need to perform some kind of audit to ensure that your machines are receiving the patches that they should receive and to identify machines on your network that do not possess the most up-to-date patch information. This audit is necessary because you never know when a machine may be experiencing some issues whereby it is not getting the updates and is therefore susceptible to attack. Many tools are available to help you scan your network and generate reports of the current security patch level on machines. Microsoft offers several tools to assist with this task, including:
Microsoft Baseline Security Analyzer (MBSA) This is a free utility that provides you with the ability to scan your domain or subnet periodically to check whether computers have failed to install patches or updates. MBSA can also report on a computer s compliance with some security best practices, such as strong password requirements. It can also check a computer to make sure that it is not open to any known security vulnerabilities (see Figure 4.8). What MBSA does not offer, however, is the ability to deploy the missing or failed patches. Once MBSA finds the vulnerability, you ll need to go back to SUS or GPO to redeploy the patches or else deploy them manually.
Microsoft System Management Server (SMS) This is an enterprisewide management utility for which the scope exceeds hardware and software inventories. However, if SMS is deployed in your organization, it can be used for the purposes of generating reports on the software that is installed on the server. SMS has recently added a SUS plug-in that further extends its functionality in this area.
A number of third-party tools and applications can also address this issue. Here are some of the more popular ones:
HP OpenView: www.openview.hp.com OpenView is infamous for its enterprisewide management capabilities. It operates at the same level as SMS and should be implemented as part of a larger management strategy, not just for patch management.
NetIQ Security Manager: www.netiq.com Security Manager by NetIQ offers a product designed for patch management. Everything from analysis and reporting to deployment of patches is included.
Gravity Storm Software Service Pack Manager 2000: www.securitybastion.com This product, like NetIQ, also offers a well-rounded method of gathering information about current computer patch levels and can even poll the corresponding Microsoft article if you are unsure what the missing or failed patch does. This product also offers the ability to deploy the missing patches and offers scheduling so that deployments do not adversely affect network traffic.
Figure 4.8: Microsoft Baseline Security Analyzer
|Test Day Tip|| |
You will not need to be familiar with specific third-party utilities for the 70-298 exam. However, you should be familiar with the abilities and limitations of the free and built-in Microsoft utilities so that you can recognize a scenario in which a third-party utility might be appropriate.