In-Depth
Q&A: Manage Security Patches
Learn tips for handling patch management and hiding objects.
For This Solution: Windows Server 2003, Windows 2000 Server or Professional, Windows XP Professional, Microsoft Security Update Services, Microsoft Baseline Security Analyzer
Q: The recent flurry of security threats against various Microsoft products has us scrambling to try to keep our servers and workstations up-to-date. Do you have any recommendations on how we can facilitate this process? It seems a bit overwhelming.
—Nancy, Tampa Bay, Fla.
A: Danielle: You're right Nancy; patch management is a lot of work. In fact, it forces us to rethink our deployment strategies because when we receive a critical warning of a security flaw and an accompanying patch, we pretty well have to deploy it right away. Just look at the MSBlaster worm. That worm came out a little more than a month after the Microsoft warning and security patch release. It is easy to understand why people were caught by this worm. Before the storm of security patches and associated threats we've seen recently, Nelson and I advocated a four-month schedule for service pack and hot-fix update deployment within most networks. This gave you a lot of time to collect, test, and aggregate the patches you needed to deploy. Of course, we also provided our customers with an emergency deployment process that could be used when the circumstances were dire enough. But what we're seeing now is that the emergency mode is becoming the norm, whereas the standard schedule is sometimes being dropped altogether.
There is no doubt: Security patches are a fact of life in any computing environment. You can limit their impact if your operating systems are designed properly and your servers run only the required services to support their role, but you still need to be prepared for emergencies. The first thing you need to do is be informed. Microsoft offers e-mail notification for security bulletins (see Resources). You should also subscribe to third-party security newsletters because they sometimes know about vulnerabilities before Microsoft does. Two excellent sources for this type of information are the SANS Institute and the CERT Coordination Center (CERT/CC). Not only will these bulletins help you know when patches are critical, but the third-party bulletins will also cover non-Microsoft technologies.
Now that you're informed, you'll need to do two more things to control patch distribution in your network. Of course, you could acquire one of the many excellent commercial patch-management technologies that are on the market, such as those provided by Altiris, Shavlik Technologies, ManageSoft, or Ecora, to name a few. But if you don't want or can't afford a commercial product, you can use two free utilities from Microsoft: the Microsoft Baseline Security Analyzer (MBSA) and Software Update Services (SUS). Both are available from Microsoft's downloads Web site. The first one scans systems for security failures and proper security patches, and the second deploys security patches to operating systems. Unfortunately, though MBSA works with a whole variety of products such as the operating system, Internet Explorer, Office, and SQL Server, SUS only works with operating systems. Microsoft is currently working on consolidating its patch-management technologies and delivery process. A new version of the Windows Installer service is in the works (version 3.0) as well as a new structure for all patches, including standardized naming, documentation, testing, and deployment strategies. Meanwhile, you'll still need to work with both SUS and MBSA. I'll let Nelson tell you how.
Nelson: Thanks Danielle. The first thing you need to do, Nancy, is know your systems. Fortunately, MBSA does a great job of this and it is easy to use. One important note: you'll need MBSA version 1.1.1 or later to scan servers running Windows Server 2003. MBSA is also easy to install because it is a Windows Installer file. You'll need administrative rights to the system on which you install it. This can be your own workstation so long as you have network access to all the systems you want to scan. MBSA can be used to scan a single system or a complete network. It will even scan network segments based on IP address ranges. You can use MBSA to scan a single computer, to scan multiple computers, or to review scan reports. In addition, MBSA gets an updated scan database from the Microsoft Web site every time it runs.
To scan a system do the following:
- Launch MBSA (Start Menu | All Programs | Microsoft Baseline Security Analyzer).
- Select Scan a computer.
- Use either the computer name or its IP address (or address range) and select the options you want to use in the scan. Click Start scan (see Figure 1).
- View the report in the MBSA details pane when the scan is complete. The report is automatically saved with the domain name, computer name, and date in the \%UserProfile%\Security Scans folder directly under Documents and Settings.
Make sure you store these reports very carefully because they detail sensitive information about your systems and you don't want them to get into the wrong hands. You should also run this scan at least once a month on all your systems. Okay, now you know what's on, or rather what's not on, your systems, and which security patches are required. The next thing you need to do is deploy them. But before you can deploy any security patch onto your network, you must make sure you test them on your systems. These tests have to be thorough enough to ensure you don't have to roll them back as soon as they are deployed. You're not a hero when you just finished rolling out patches and you find out nothing works anymore. Fortunately, SUS is designed to let you test patches in a laboratory environment before deploying them to your live network.
Basically, you use SUS to replace Windows Update and assign an internal source for all your systems to receive patches. This means that for SUS to work properly, you need to install it in an environment where you can deploy it initially to the test machines, run these through a battery of tests, and then when you're sure everything is okay, authorize the patches for deployment in the production environment. To make sure your production machines receive the updates from your internal authorization server, you'll also need to assign the proper Group Policy settings to each system.
Use the test lab to approve updates:
- Launch the SUS Console on the test server by going to http://servername/SUSAdmin where servername is the DNS name of your SUS test server.
- Click Approve Updates to review available updates. Sort the updates based on Status. Check the ones that apply to your environment.
- Click the Approve button to apply each of the updates you checked. Wait until they are applied on your test machines, and reboot them if required.
- Verify the proper operation of the test systems after application. If there is a problem, remove the updates one by one until the problem is corrected to identify the faulty update. Retry the remaining updates. Make note of the updates to approve.
- Move to your Production SUS Server and approve the appropriate updates for distribution to your production systems.
Once an update has been approved in the SUS server, it will install automatically on all targeted systems if you have set your group policy objects (GPOs) appropriately. The required GPO settings are located in Computer Configuration | Administrative Templates | Windows Components | Windows Update and include the following:
- Configure Automatic Updates: In a corporate environment, you should use setting number four to download and install updates according to a fixed schedule.
- Specify intranet Microsoft update service location: Name the server from which updates will be downloaded; use the server's full DNS name.
- No auto-restart for scheduled Automatic Updates installations: Use this setting if you want to stop servers or workstations from restarting after update installation. It might be preferable to use a different procedure to restart servers especially.
The GPO you use for this should apply to all PCs and all servers. You should use two different GPOs for each (one for servers and another one for PCs). Now, when you use the SUS server to validate the security fixes and updates you need in your corporate environment, they will deploy automatically to your systems. Make sure you document all the changes you apply to both servers and workstations.
Danielle: You can also automate several of these processes through Visual Basic scripts. Several scripts related to hot-fix and service-pack administration are available on the Microsoft TechNet Script Center. Notably, you'll find two that are really useful: Enumerate Installed Hot Fixes and Identify the Latest Installed Service Pack. Along with the MBSA, these scripts can help you keep your network up-to-date. Hopefully, you'll find these recommendations make patch management easier to manage.
Q: During your presentation at the Directory Expert's Conference in Ottawa, Canada, you mentioned a practice to hide objects, including domain local and universal groups and objects with special permissions. Do you have any overview or actual process steps on how this can be accomplished? I have some real-world needs for such a solution. Any help you could pass along would be much appreciated!
—Adam, Anaheim, Calif.
A: Nelson: This one's mine because I was the one presenting. The answer to your question is fairly simple, Adam—simple to say, but not so simple to implement. Danielle and I recommend the use of a special organizational unit (OU) in each domain to hide highly sensitive objects in the directory. As you know, by default any user can search the directory to locate information such as the name of administrative accounts, the name of administrative groups, the name of service accounts with higher privileges, and all sorts of sensitive information. To protect your network, you should create a special OU to store this type of information along with other objects that users don't really need to access. For example, in terms of groups, users only need access to global groups because they are the only ones that should contain user accounts. Other groups, both universal and domain local, should only include global groups. Therefore, users don't need to view the latter group types because they are of no use to them.
Danielle and I recommend including service accounts, administrative accounts, administrative groups, universal groups, domain local groups, and operational accounts within this OU (or OU structure). Then, you modify the default access control lists for this OU to apply Deny List Contents to a global group that includes all generic users (see Figure 2). To apply this property, you must click on Advanced under the Security tab of the OU's properties. To view the Security tab, you must have checked Advanced Features in the View menu of the Active Directory Users and Computers console. You will get a warning from AD when you assign a Deny permission.
This is the tricky part. You can't assign this right to a default group such as Domain Users or Authenticated Users because these groups include everyone in your network by default. If you do this, you'll end up denying your own right to list or view the contents of the OU. Therefore you need to create a new global group that will include only nonadministrative or operational users, and you need to make sure that each new account joins this group. The best way to do this is to create a template account that is a member of your generic user group and make sure operators who create accounts always use this template. If your forest uses multiple production domains, this strategy should be repeated in each domain. And, if you use this strategy, you should also generate reports from each domain to make sure there are no errors and each normal user is contained within your generic user group.