Designing a Security Update Infrastructure

---

There is much more to updating the security of your infrastructure than just applying new patches. In addition to applying security-related patches, you should make configuration changes as new information and attacks are known or as new services or applications are installed. In this section, we will show you the different tools that you can use to solve your security update woes as well as the benefits and drawbacks of each potential solution.

To create a security update infrastructure, you obviously must be able to determine what needs to be updated and how it will be accomplished. Unfortunately, as far as security updates go, there is no panacea; no single solution solves all of the problems that plague your network infrastructure. It is for this reason that there are several methods for updating the security of computers that, when used in concert, can help you achieve a complete security update infrastructure.

Table 9.2 lists the different methods of updating in a Windows network, including the operating system that the method supports, and whether or not it supports software patches or configuration changes or both.

Table 9.2: Security Update Methods

Method	Operating Systems	Supports
Microsoft Windows Update	Windows 98 and higher	Software patches
Software Update Services (SUS)	Windows 2000 and higher	Software patches
SMS with SUS feature pack	Windows 98 and NT 4 and higher	Software patches and configuration changes
Security Configuration And Analysis	Windows 2000 and higher	configuration
Group Policy	Windows 2000 and higher	Software patches and configuration changes

Each method listed in Table 9.2 is explained in the following list:

Microsoft Windows Update The Microsoft Windows Update website (located at http://v4.windowsupdate.microsoft.com/en/default.asp) is a wonderful utility for individual computers and small businesses to allow the users to update their own systems. It doesn’t support modifying the configuration of any of the software on the running machine. It also does not provide specific information as to how the patch that is being applied will affect other applications on the computer.

Microsoft Software Update Services (SUS) Microsoft Software Update Services (SUS) gives an administrator the ability to deploy critical and security-related updates and services packs to servers running Windows 2000 or Windows Server 2003 and clients running Windows 2000 and XP Professional. The updates can be synchronized from the Microsoft Windows Update website and saved to a SUS server where an administrator can test the update to see if it is compatible with the configuration and applications that are currently running in the network environment. When the administrator determines that there are no conflicts, they will approve the updates to be distributed by the SUS server. The client computers, running the Automatic Updates component, will download the approved updates from the SUS server and apply them.

Microsoft Systems Management Server 2003 (SMS 2003) Microsoft Systems Management Server 2003 is a comprehensive change management and configuration solution. It is capable of deploying applications, managing security and software patches, managing assets, and more to clients ranging from Windows NT 4 and Windows 98 up to current computers running Windows XP and Windows Server 2003. Unlike SUS, SMS 2003 is not free and requires a SQL Server database for its datastore.

Security Configuration And Analysis As you learned in Chapter 8, the Security Configuration And Analysis MMC snap-in is used to evaluate the configuration of systems and optionally apply a template to adjust the configuration of the target computer based on the settings defined in the template. It cannot be used to install software patches, only for configuration. It is also not a great solution alone to deploy the configuration changes across the network. It can create templates that are deployed by means of Group Policy for multiple computers.

Group Policy Group Policy, in the context of software updates and security configuration, can be used to install patches and, when used with administrative templates, can deploy broad-based configuration settings. It requires that Microsoft Active Directory services be configured for the network and that all target computers will be Active Directory clients. It also requires that a specific policy be defined for each update as it comes out.

When you must decide which security update method to apply, you should consider how many client computers need to be updated. The Microsoft Windows Update site is useful when only a small number of computer systems require updating because it typically requires an interaction with the Web interface. With supported client computers, however, Windows Update can be configured to automatically download and apply updates. But there is no check to see how it will affect other installed applications or services.

A Microsoft Software Update Services (SUS) server can update a relatively small number of client computers as well as several hundred. Configuring SUS hierarchy, which is covered later in this chapter, will allow for the update of even more client computers.

Microsoft SMS 2003 can be used to update a practically limitless number of client computers. It is usually reserved for the larger enterprise organizations because it is expensive and requires its own administrative staff to configure, deploy, and manage its own infrastructure.

In most cases, a configuration made up of both SUS and Group Policy will solve all of the issues that need to be addressed, from scalability to client support.

Note

You can evaluate the differences between Windows Update, SUS, and SMS 2003 at www.microsoft.com/windowsserversystem/sus/suschoosing.mspx.

In the following sections you will learn some of the factors that will be considered when designing your SUS infrastructure. In addition you will find out how to use the Microsoft Baseline Security Analyzer (MBSA) utility to identify those computers that are not at the appropriate patch level.

Design a Software Update Services infrastructure

SUS is a customized solution for medium-sized organizations that follows the lead of the Microsoft Windows Update website to provide software updates and security patches to computers. The purpose of SUS is to distribute critical updates to computers in your organization with as little difficulty as possible.

SUS offers the following benefits:

Behind the corporate firewall The SUS server located behind the corporate firewall, which allows you to define a single point inside your organization that will synchronize with the Microsoft Windows Update site whenever new updates are made available for Windows 2000, Windows Server 2003, or Windows XP.

Administrator-approved updates The administrator can now test the updates from the public Microsoft Windows Update site prior to deploying them to the computers within their organization. The administrator can also determine the schedule upon which the updates will be delivered to the target computers. There can be several servers within a network running the SUS, and in that event, the administrator can, through Group Policy or Registry modifications, configure the target computers with the SUS server that they will use.

Administrator-configured synchronization with the Windows Update site The administrator can design SUS infrastructure that is made up of several servers running the SUS. In addition, the administrator can define one of the SUS servers to download the updates from the Microsoft Windows Update site and make the new patches and fixes available to the other servers within the SUS infrastructure. This minimizes the Internet bandwidth required because only a single server must retrieve patches from the Windows Update site.

Staged deployment for test to production Your administrative team can configure in a test environment a server that will publish updates to client computers within the test environment first. If there are no compatibility or other problems with the deployment of the security update, you can publish the updates to the rest of your organization by approving the other SUS servers, those configured for the production computers, to deliver the update to the production computers.

SUS notification e-mail list The administrator can subscribe to a Microsoft-maintained e-mail distribution list that will send notification when a patch is added or updated to the Microsoft database.

There are two parts to the SUS solution:

• The server (or servers) that is running SUS and downloads updates from the Microsoft Windows Update servers or from other internal SUS servers.

• The Automatic Updates client that downloads the updates from either the Microsoft Windows Update site or a SUS server in your network. Before applying the updates, SUS will check the digital signature to make sure that it bears Microsoft’s signature. If the update package is not signed, it will not be applied.

Now that you’ve learned the concepts of SUS you will now learn how to configure the settings of the SUS servers in your organization.

Configuring SUS Servers

SUS runs on Windows 2000 Server, Service Pack 2 or higher, and on the Windows Server 2003 family of operating systems. SUS must be installed on an NTFS partition and the system partition of the server must also be on an NTFS volume.

Note

SUS Service Pack 1 can be installed on domain controllers, unlike SUS 1.

You can download the installer for SUS by navigating to http://go.microsoft.com/fwlink/?LinkId=6930.

Once you install SUS, you configure and administer it using the web application that is installed on the SUS server in the SUSAdmin virtual directory, as you can see in Figure 9.13.

Figure 9.13: Software Update Services administrative website

If you decide that you do not want to use the default website on the server, you must either disable or delete it. SUS will always install into the default website if the website exists on the server. In addition, should you decide that you would like the website that hosts the SUSAdmin application to use a different port, you could change that setting from the Default Web Site Properties dialog box in the Internet Information Services (IIS) Manager MMC snap-in, as you can see in Figure 9.14.

Figure 9.14: The Default Web Site Properties dialog box

It is by using this administrative website that you will configure the SUS service to meet your specific needs. You configure the service to automatically download new patches and updates on a defined schedule, or you can specify that it will update them only when you, the administrator, manually initiate the synchronization process. Figure 9.15 shows the Synchronize Server administration page. You should make sure that new patches and updates are synchronized regularly, ideally every day. Each SUS server can handle updating about 15,000 client computers; you should add additional SUS servers as needed. You can still make sure that only one of the SUS servers in your hierarchy retrieves the updates from Microsoft and then configure the other SUS servers to download the updates from the SUS server that receives the updates directly from Microsoft.

Figure 9.15: The Synchronize Server page

Once the updates are downloaded, you will be able to choose which updates to approve and distribute from the Approve Updates page. Figure 9.16 shows the Approve Updates page from the SUSAdmin web application.

Figure 9.16: SUSAdmin Approve Updates page

You should consider having a different SUS hierarchy that will be responsible for each group of computers based on how updates are going to be approved. In this case, you may have two types of workstations that you need to have patched: normal desktops and mission-critical desktops. You could configure the normal desktops to use one SUS server in which most patches are approved rapidly by its administrator and the mission-critical desktops to use a separate SUS server that requires more meticulous and rigorous testing before a patch can be approved for the mission critical workstations.

When you have decided that an update will be delivered to the SUS clients, you select it from the Approve Updates page and click the Approve button.

Configuring SUS Clients

Now that you have installed and configured your SUS server(s) to download and maintain the updates that are being released from Microsoft on a regular basis, you will need to configure the computers in your organization to look to their respective SUS server, if you have more than one, to retrieve and apply the updates.

In the following sections, we will look at the different techniques that you can use to configure a computer to use your SUS infrastructure.

Using Group Policy Objects to Configure SUS Clients

The recommended method of configuring SUS clients is to use Active Directory’s Group Policy. As is the case with any other configuration options being set in a GPO, Group Policy allows an administrator to configure a policy once and have it be applied consistently throughout the directory.

To define a GPO to configure the SUS client, first navigate to the appropriate section of the GPO:

1. Launch the Group Policy Object Editor (GPEDIT.msc).

2. Expand Computer Configuration Administrative Templates Windows Components.

3. Select Windows Update. (If you do not have the Windows Update section under the Windows Components container, right-click Administrative Templates and select Add/Remove Templates and add wuau.adm.)

There are four settings for the Windows Update policies that can be configured and set:

Configure Automatic Updates This setting allows you to define the behavior of the automatic updates. Once this setting is enabled, you must choose the method of automatic updating as seen in Figure 9.17:

• Notify For Download And Notify For Install The user of the computer is prompted to both download and install the updates.

• Auto Download And Notify For Install The update is automatically downloaded from the Update server and the user of the machine is prompted to apply the update.

• Auto Download And Schedule The Install The update is automatically downloaded from the Update server and automatically installed based on the schedule defined in this setting. If this option is selected, the scheduled install day and scheduled install time will apply.

Figure 9.17: The Configure Automatic Updates Properties dialog box

Specify Intranet Microsoft Update Service Location This setting, once enabled, gives you the opportunity to specify the address of your SUS server so the client can download the updates from it. To use this setting, you must define the server from which the Automatic Updates client will detect and download updates as well as the server to which updated workstations upload statistics. As seen in Figure 9.18 both values can point to the same intranet server.

Figure 9.18: Specify Intranet Microsoft Update Service Location

Reschedule Automatic Updates Scheduled Installations This setting specifies the amount of time that the Automatic Updates service will wait after the computer starts up before beginning a scheduled installation that it had previously missed (typically because the computer was powered off when the schedule dictated installation should occur).

No Auto-Restart For Scheduled Automatic Updates Installations If enabled, this option prevents the computer from automatically restarting itself after an update is installed. The update will not be complete until the interactive user of the computer manually restarts the computer.

Manually Configuring SUS Clients

In addition to using a GPO, you can configure the settings manually on the client using any one of the following techniques:

• Use the Local Security Policy on each workstation. The steps are identical to when configuring a GPO, but this is applied only to the computer that you configure it on.

• Use the Automatic Updates tab of the System Properties Control Panel applet, as seen in Figure 9.19.

  
  Figure 9.19: The Automatic Updates tab

• Manually modify the Registry on each client.

As you can see, the only realistic option is to use a GPO when there is a moderate quantity of client computers involved. You will want to make sure that your OU structure is designed in such a way that software updates and patches can be deployed with a minimum of administrative effort.

In the Designing a Patch Management Solution” Design Scenario, you will evaluate the provided scenario and decide the best way to design a patch management solution from the possible answers.

Design Scenario: Designing a Patch Management Solution

You are the security architect of Kellum Enterprises, a worldwide bicycle manufacturing company. You currently support over 25,000 computers that are made up of Windows NT, Windows 2000, and Windows Server 2003 operating systems. Your network is divided into four major sites: North America, South America, Asia, and Europe. Each site is connected to the Internet, and they connect to each other using VPN connections. You need to design a patch management solution for this enterprise that can handle all of the clients and doesn’t put any unnecessary burden on any one server. Administrators for each site will approve the patches to be deployed to computers in their site. There are approximately 6,500 computers in each site.

1. Question: How should you configure a security patch management solution? (Choose the best answer.)

   A. Install a single SUS server in the North America site to retrieve the updates from the Microsoft Windows Update site. Install secondary SUS servers in each of the other sites and configure them to retrieve the updates from the North America SUS server. Create a GPO for each site that configures the clients to use the SUS server in the same site.

   B. Install a SUS server in each site and configure it to retrieve the updates from the Windows Update site. Create a GPO for each site that configures the clients to use the SUS server in the same site.

   C. Install a SUS server in the North America and the Europe sites to retrieve the updates from the Microsoft Windows Update site. Install secondary SUS servers in South America and Asia. The South America SUS server will retrieve its updates from the North America SUS server; the Asia SUS server will retrieve its updates from the Europe SUS server. Create an OU for each site and create a GPO for each one that identifies the appropriate SUS server for clients in the OU to use.

   D. Create a single GPO that configures the client computers to retrieve the updates directly from the Microsoft Windows Update Internet site. Link the GPO to the domain.

   Answer: B

   Because the administrator at each site needs the ability to approve its patches and fixes, each site should have a primary SUS server. Option A is incorrect because it puts an undue burden, when compared to answer B, on the North America SUS server; it would have to distribute the updates to the other sites. It also would prohibit patches that North America doesn’t approve from being downloaded to other SUS servers. Option C is incorrect because it creates new OUs for the sites, which is unnecessary because GPOs can be linked to a site. In addition, an undue burden is placed on the North America and Europe SUS servers by making Asia and South America download the updates from them. Also, the South America and Asia SUS servers would be able to download only the approved updates from North America and Europe, respectively. Option D is incorrect because it doesn’t allow for each site’s administrator to approve the patches that will be applied.

Identifying Computers That Are Not at the Current Patch Level

Now that you have designed an infrastructure that supports the process updating the computers in your organization, you will want to define a technique to verify that it is working. In other words, you will need to audit the patches of the machines on your network to make sure that the correct patches are applied. Microsoft has created a utility to accomplish this task: Microsoft Baseline Security Analyzer (MBSA).

MBSA is used for two different tasks: analyzing the configuration of a computer and generating a report of the security vulnerabilities and determining if there are patches that are available for the operating system or services on a machine that have not been applied.

You can use MBSA to analyze a single computer, a range of addresses, or an entire Windows domain. The current version of the MBSA utility (version 1.2) can analyze the following operating systems and services:

• Windows NT SP4, 2000, XP, and Server 2003

• Internet Information Services (IIS) 4–6

• Microsoft SQL Server 7.0 and 2000

• Internet Explorer 5.01 and higher

• Office 2000 and higher

The MBSA utility can be configured to compare the target computer with the patches that have been approved by a SUS server.

Note

SUS version 1 does not currently support Microsoft SQL Server or Office applications.

You can use the MBSA user interactive interface when you want to manually analyze a computer or group of computers. Figure 9.20 shows an example of the interactive MBSA utility.

Figure 9.20: MBSA manual scan interface

In order to truly exploit the power of the MBSA on an enterprise scale, you will use it in scripts that include the command-line version of the MBSA utility. You can evaluate all of the commandline options by executing mbsacli /? from the MBSA installation directory. It can be scheduled to scan a group of computers and store the report to be viewed at a later time. For example, the following command line will scan a domain named myDomain.com, store the results in the c:\results\scanresult.txt file, and use the SUS server London for a list of approved updates:

 Mbsacli /d myDomain.com /f "c:\results\scanresult.txt" /SUS      "http://London" 

Once the scan has completed, you should evaluate the contents of the scanresult.txt file, which would be similar to the following:

 Computer Name, IP Address, Assessment, Report Name  ----------------------------------------------------- NWTRADERS\LONDON, 192.168.247.8, Severe Risk, NWTRADERS - LONDON    (2-20-2004 11-19 AM) 

There would be an entry for each computer in the domain. You would use this information and evaluate the details of each computer using the report viewer in the MBSA GUI client. Figure 9.21 shows what a completed MBSA security report might look like.

Figure 9.21: MBSA security report

Using this information, you would either apply the appropriate patches to the specified computers or begin troubleshooting to find out why they weren’t applied in the first place. As with any good solution, you must verify it over time to make sure that it continues to work. No patch management solution is complete without a patch auditing solution to verify that the patches are being applied.

In the “Auditing Your Security Patch Solution” Design Scenario, you will determine the best way to determine whether or not a critical patch has been applied.

Design Scenario: Auditing Your Security Patch Solution

You are using a combination of SMS 2003 and SUS to patch all of the appropriate applications to the current level. You have several Windows, IIS, and SQL Server servers that must be updated with the latest updates available, and you must constantly verify the patch level.

1. Question: How would you configure MBSA to audit the patches that are being applied to these servers? What resource should they use to determine which patches are available? Answer: You should use a script to automate the MBS ACLI command-line utility and specify that it should get the update information from the Internet instead of from the SUS server. SUS doesn’t support SQL Server patches in its current ver sion.

---