15.3 Operating System Updates

     

When Microsoft ships an operating system, it does its best to find and remove all security vulnerabilities. In a perfect world, that would mean that the operating system was perfect from a security standpoint. In our imperfect world, however, operating systems are large and complex. As we know, complexity is the enemy of security. This means that the complexity of these large operating systems provides plenty of opportunities for security vulnerabilities to crop up.

Security vulnerabilities are discovered every day both by vendors and by customers who purchased the products. Microsoft, like virtually all other hardware and software vendors , continuously refines its products based on the discovery of these vulnerabilities. When a particularly critical vulnerability is discovered , Microsoft quickly writes and releases a software patch to address the issue.

Microsoft almost never writes patches to address configuration issues. This may seem obvious, but many administrators believe that any improper configuration is a bug. The extensive documentation available for Microsoft products, including this book, help you determine the proper configuration to implement. If you implement it incorrectly or without a proper plan in place, you may create your own security vulnerability. Because this isn't improper behavior of the software, Microsoft doesn't patch it.

The quicker you apply a patch to your systems, the quicker you become resistant to attacks that exploit that particular vulnerability. This doesn't mean that you should watch the TechNet web site all day and immediately apply every security patch to every computer in your enterprise. Nor does it mean that you should apply patches only when Microsoft sends email specifically indicating that you have a product with a known vulnerability. The proper patch management strategy for your environment lies somewhere in between.

Patch management is essential to ensure the ongoing security of all components in your network. This book focuses specifically on Windows Server 2003, but the same consideration should be given to other software and hardware that can be updated. Some software, such as virus scanners and software firewalls, should be regularly updated to ensure they provide defense against the latest attack vectors. Routers, hardware firewalls, and other intermediate network devices also have software or firmware that should be regularly updated to ensure they remain resistant to known attacks and patch known vulnerabilities.

Optimally you will plan a software update strategy before you deploy the computers in your enterprise. Realistically, however, this isn't usually the case. Computer systems are deployed with little or no regard for regular software maintenance. We often have to take systems that have various levels of software updates and bring them all to a single version of software. This section addresses the various strategies you can use to determine the software patches installed and the ways you can ensure patches are installed on necessary computers.

The remainder of this chapter will cover updating only operating systems, focusing on Windows Server 2003 and Windows XP Professional in a corporate environment. Most of these strategies can be extended to other software packages and Windows operating systems. As you develop your policy and procedures, you can simply extend the information provided here to encompass your specific environment.

All computer systems are not equal. Some may be critical to your business, while others could be removed with little notice. Because you cannot apply patches to all computers simultaneously , you must determine an order and priority for your patch application activities. Some basic rules apply to your decisions regarding patch application, including the following:

Some systems are more exposed to attacks than others

Web-based attacks that exploit a flaw in IIS, for example, would be most dangerous to computers that have direct exposure to the Internet. When a patch is available for a computer that publicly exposes the functionality that the patch addresses, it should be given a high priority. The patch should be applied to all computers as appropriate, but the more immediate need is to patch those computers most likely to be attacked .

Critical business systems should be patched quickly

While your product support web site may not be essential to your continued business operation, your central database server may be critical, and its loss would mean the demise of the company. When an update strategy and procedure is created, you should keep this in mind and assign priorities according to business need.

Defense- in-depth helps reduce the need to apply patches immediately

If you have internal firewalls and desktop-based virus scanners, your computers may be reasonably resistant to new attacks. This could give you enough time to test the patch and ensure its compatibility with your environment before deploying it. If your computers are completely undefended inside the corporate network, any exposure to an attack could be catastrophic until a patch is deployed to the entire company. Unfortunately, it is common for worms and viruses to "jump" firewalls through a variety of means, such as portable laptops and computers with modems.

A recent Internet worm called Code Red that attacked IIS was highly successful. A little-known fact about this worm is that there was a patch available for months before the worm became widespread. Vigilant network administrators who had patched their IIS-based web servers quickly thwarted the worm. Those who did not have an update strategy, on the other hand, were susceptible to this attack. They had to repair the damage done in addition to patching all servers to ensure the worm did not continue to spread.

15.3.1 Windows Update

Since the Windows 9x days, Microsoft has provided Windows Update (http://windowsupdate.microsoft.com), a web-based service that integrates with Windows to provide operating system updates and new features. You've probably used Windows Update yourself to download and install updates. Windows XP Professional and later versions of Windows even include Automatic Updates, a feature that can periodically check Windows Update for new updates, download them in the background, and apply them for you.

Windows Update is primarily intended for individual users and doesn't always make sense in an enterprise. Imagine, for example, that you configure thousands of client computers to automatically download and apply updates. Each time an update is available, each client computer will independently download a copy, which is an inefficient use of your company's Internet connection. Additionally, you won't have any opportunity to test and approve the updates before they are deployed to your client computers.

Microsoft Software Update Services provides a kind of "corporate edition" of Windows Update and is a more efficient and controllable means of managing security updates within your organization.

15.3.2 Microsoft Software Update Services

Software Update Services (SUS, pronounced suss) is a free download from the Windows web site (www.microsoft.com/windows). SUS consists of two components: a server and a client. The server component can run on Windows 2000 Server or Windows Server 2003; the client component is included in Windows 2000 Service Pack 3 and Windows XP Service Pack 1.

By the time you read this, SUS may be called Windows Update Services (WUS, pronounced wuss, no pun intended).

The SUS client is also available as a standalone download. However, the easiest way to deploy and configure it is to simply deploy the appropriate service pack to your client computers. You'll also receive the other benefits of the service pack, including bug fixes and security updates.

Once installed and configured, your SUS server will automatically download new updates from Windows Update. You'll be able to test and approve these updates, which will then be made available to computers running the SUS client. SUS handles only updates marked by Microsoft as critical, which includes all security updates. New features and other noncritical updates aren't handled by SUS, although client computers can still use Windows Update to obtain these updates.

The SUS client software is also referred to as Automatic Update. Windows XP Professional ships with Automatic Update but isn't compatible with SUS. Windows XP Service Pack 1 and Windows 2000 Service Pack 3 include a new version of Automatic Update that is SUS compatible.

15.3.2.1 Installing and configuring SUS server

To install SUS server, simply launch the Microsoft installer (MSI) file containing the software. As part of the installation, you'll specify a location where SUS will store its updates, as shown in Figure 15-8. This location should contain sufficient space for a large number of updates. Keep in mind that SUS server can download all available critical updates for all Microsoft operating systems, Internet Explorer, and other products.

Figure 15-8. Installing SUS and configuring the location for storage of updates

After installing SUS, you can connect to the SUS administrative interface by using a web browser. Simply point the browser to http://server/SUSAdmin , replacing server with the name of the computer running SUS server.

You can require the use of SSL on the /SUSAdmin directory in IIS. In that case, the URL is https ://server/SUSAdmin .

You may need to configure one or more of SUS server's options, as shown in Figure 15-9. These options control SUS' use of proxy servers, allowing SUS to operate within your network.

Figure 15-9. SUS configuration options

Your first administrative step should be to configure a synchronization schedule as shown in Figure 15-10. This schedule allows SUS to automatically download new critical updates from Microsoft's servers (or from another SUS server in your organization). A weekly schedule is usually sufficient.

You can also manually trigger synchronization whenever you like, although a scheduled synchronization ensures that your SUS server always has the latest updates. Remember that SUS won't actually deploy these updates to clients until you've approved them, so there's no danger in having the latest updates on the SUS server.

Figure 15-10. SUS update schedule configuration

After synchronization completes, you can use the Monitor Server tab of the SUS admin page to view the number of available updates, as shown in Figure 15-11. SUS categorizes updates by product, including versions of IE and Windows.

Figure 15-11. The SUS Monitor window that shows available updates

However, just because updates are available doesn't mean your client computers will receive them. First, you must approve the updates, giving you the opportunity to test them for compatibility in your environment. As shown in Figure 15-12, you can review the available updates and indicate which ones you approve for deployment to your clients. When client computers contact the SUS server, they will receive all approved, applicable updates for their operating system and other installed products (such as IE).

Figure 15-12. Approving updates in SUS

Notice that the update approval list indicates which updates will require a client computer restart after installation. You can centrally configure the SUS client software's restart behavior to avoid disrupting your users; I'll cover that in the next section.

15.3.2.2 Configuring SUS clients

Once you have installed one or more SUS servers on your network, you'll need to configure the SUS client software on your client computers. Although you can manually configure the software on a per-client basis, it's far more efficient to use Group Policy to centrally configure all your client computers at once. First, determine the right place to apply a Group Policy Object (GPO).

For example, if you want all domain computers to use a centralized SUS server, you might apply an appropriately configured GPO to the domain. However, it's more likely that you'll deploy a SUS server for each major site within your organization. Doing so will allow clients to retrieve their updates locally, rather than using WAN bandwidth. In that case, it would make the most sense to configure a GPO and link it to Active Directory sites, creating a consistent, location-aware configuration for SUS.

Configuring SUS couldn't be easier: Simply open the Group Policy Editor. Under Computer Configuration, open Administrative Templates, then Windows Update. As shown in Figure 15-13, four policy settings control the SUS client software.

Figure 15-13. SUS client policy configuration

Configure Automatic Updates

This policy setting activates the SUS client software and configures its primary behavior. You can configure client computers to automatically download and apply updates, to notify their users prior to downloading or installation, or to automatically download and notify prior to installation. The best choice is usually full automation, ensuring that users don't prevent the installation of important updates. You can also select the day of the week and time that available updates should be installed. For example, if users typically leave their computers on in the evenings, you might schedule installation for every night at 10 p.m., when users won't be impacted should a restart be required.

Specify intranet Microsoft update service location

This is where you provide the URL of the SUS server that clients should use, which should be the URL of the SUS server that you've set up on your corporate network.

Reschedule Automatic Updates scheduled installations

You can specify how long the client software should wait after system startup to begin installing updates that were missed. For example, if a user turns off his system in the middle of an update installation, the SUS client will not attempt to install the update again until the next scheduled time. By configuring this option, you can have SUS retry five minutes after the system restarts.

No auto-restart for scheduled Automatic Updates installations

This policy allows you to prevent SUS from automatically restarting a client computer after installing updates that require a restart. When this policy is enabled, SUS will complete the update installation the next time the computer is restarted, rather than restarting it automatically.

Remember that these policies apply only to computers running Windows XP SP 1, Windows 2000 SP 3, or Windows Server 2003.

15.3.3 Using MBSA to Determine Current Security Status

The Microsoft Baseline Security Analyzer (MBSA) is a tool used to verify the current state of security patches and settings on a computer. It is a direct result of customer feedback that there was no centralized tool to determine the security state of a computer.

MBSA has two goals for most Microsoft Windows operating systems and applications, including Windows Server 2003 and Windows XP:

• Identify common security misconfigurations such as a blank administrator password or excessive users in the Administrators group

• Identify missing security patches

MBSA has both a graphical interface and a command-line interface. This allows you to tailor your use of MBSA to the needs of your environment. For example, the command-line version of MBSA can be scripted or run as a regularly scheduled batch process. However, for ad hoc usage of MBSA, you may prefer the graphical interface. It provides a simple way to configure and launch the tool as well as view the report and take corrective action.

Among its numerous customer-driven features that make it a powerful and useful tool, MBSA can:

Scan multiple computers

This can be done by selecting a domain name to scan or a range of IP addresses. Figure 15-14 shows the configuration range options.

Target specific security areas of concern

This is also shown in Figure 15-14. This feature allows you to target specific MBSA checks. This saves time by scanning only the areas you feel are vulnerable or must verify.

Integrate with SUS

MBSA can check the patch level of a targeted computer based on its own data or based on the patches loaded on your internal SUS computer. This is also shown in Figure 15-14 as the administrator has selected Woodgrove-sus.

Provide detailed reporting

When MBSA is done with its scan, it displays the results of the scan as shown in Figure 15-15. All scans and their results are shown, and the areas of security concern are highlighted. You can get more information on the exact criteria used for the scan, as well as the recommended corrective action, from this report. Furthermore, the reports are stored in XML so you can parse them with any XML-savvy program to create charts , analyze trends, or predict future statistics.

Figure 15-14. The Microsoft Baseline Security Analyzer targeting computers in a specific IP address range

Figure 15-15. MBSA report display: large, colorful icons help you quickly identify problem areas

Using MBSA should not be part of your daily routine. An appropriately planned and implemented update strategy, as described earlier in this chapter, should eliminate your daily need for tools such as MBSA. It should be used in limited situations such as:

• When a new widespread virus or worm appears that takes advantage of a known security flaw. At that time, you should use MBSA to ensure that your most vulnerable computers are protected with the appropriate patches. This allows you to spot-check those vulnerable servers. Although your update strategy should have already protected those servers, there's no harm in double-checking.

• As a periodic audit tool to ensure your patch update strategy is working. You will be reviewing Audit Logs of these updates anyway, but MBSA allows you to periodically choose a critical server and examine it for security vulnerabilities.

Any problems that MBSA exposes should not be fixed manually unless there is a time-critical need, such as protecting against a spreading attack. Rather, you should address discovered vulnerabilities by locating the cause of the problem such as a misconfigured update server or violation of a security policy. Locating the root cause of the problem ensures that the problem will not reappear later due to some fundamental flaw or loophole in your security strategy.

MBSA as an Attacker's Tool

You may say to yourself, when first reading about MBSA, "Wow! This is a great tool that can help me identify vulnerabilities." As you begin to read more reports and discover more vulnerabilities and misconfigurations in your environment, however, you may develop a different attitude. You may, as many people do, think that this tool is a little too aware of your misconfigurations. It seems to find so many problems.

You may also realize that you're not the only person who's downloaded MBSA. And that Microsoft doesn't require any type of "good deed oath" to download it. An attacker could use it to footprint your network and get the same information. She could then launch an attack based on a vulnerability from an MBSA report.

While this is true, it's a little shortsighted. Literally hundreds of existing attacker tools are available on the Internet right now. Many of them are redundant with MBSA and many are legitimate tools used by security professionals for penetration testing. An attacker could easily get the same information using a different, non-Microsoft tool.

So don't blame Microsoft for telling anyone who cares to listen about your vulnerabilities. Just fix them!

MBSA can be downloaded from http://www.microsoft.com/technet/security/tools/tools/MBSAHome.mspx. Details on exactly what vulnerabilities MBSA scans for and how it determines patch levels are included in the Baseline Security Analyzer white paper located at http://www.microsoft.com/technet/security/tools/tools/mbsawp.mspx.