Windows Insider

The Guiding Lights

Harden your computers' defenses with the tips in these Microsoft studies.

• By Greg Shields
• 04/01/2006

Security pundits love to talk up the need to harden your computer systems. As anyone who has attempted to set up IPSec or SMB Signing between every host in a LAN can tell you, though, there's a tradeoff between a highly secure network and one that you can actually use. As systems administrators, we're told by magazine articles, management and Microsoft itself that security is of critical importance. It's our job to protect the network from the viruses, Trojans and worms of the big, bad world. There is plenty of documentation that tells us how to harden your network. The hard part is learning exactly what we should secure.

Triple Crown
To fill the gap, Microsoft commissioned a team of industry security experts. Late last year, the team ran a comprehensive review of all known Group Policies, Registry modifications, auditing policies and domain security configurations. They filtered out those unrelated to security, and developed what amounts to Microsoft's recommendations for your network's precise security configuration.

Dubbed the "Windows Server 2003 Security Guide," the "Windows XP Security Guide," and the "Threats and Countermeasures Guide," these three massive documents break the hardening process down into individual steps and describe how you can leverage Group Policy and the Security Configuration Wizard to do the work.

What sets these guides apart is how the team reviewed each security setting. As anyone who has applied security knows, the Windows Server System includes hundreds of settings that are potential security points. The hard part is determining which ones make sense for your particular environment.

Security Info from the Experts There are many more security guides than those listed in this article, including those for small businesses, Exchange and MOM. To find all the security guides, search the Microsoft Web site for "security guide." The authors, who use the wordy moniker Microsoft Solutions for Security and Compliance Team, also maintain a blog with more useful security information. Check it out at: http://blogs.technet.com/secguide

The "Threats and Countermeasures Guide" does just that. Instead of blindly recommending a series of potentially unnecessary or hazardous configurations, the guide explains the vulnerability associated with each setting, the countermeasure used to fix that vulnerability, and the potential impact -- or possible harm to your network operations -- of enabling that setting. This makes justifying your security plan to management quite a bit easier. Concerned about what a particular setting might break? Just look it up.

Going a step further, all recommended security updates are grouped in three categories based on the types of workstations in your network and your need for nominal or super-strong security. For the highest level of security, called Specialized Security – Limited Functionality, you're warned in advance that this level of security will prevent many applications from even running.

By combining the "reasons why" in the security guides with the "reasons why not" of the "Threats and Countermeasures Guide," you come away with a holistic understanding of what you need to secure and why.

Learn the Security Configuration Wizard
Here's an example of how useful these guides can be in the real world. The "Windows Server 2003 Security Guide" uses the SCW as its primary mechanism for configuring server security policy. There is a series of .INF security template files included with the guide that can help you apply the recommended configuration. You could import these .INF files directly into Group Policy the old way -- using the Group Policy Management Console -- but the guide uses the SCW to help you better visualize the changes the templates will make to your system.

If you've never used the SCW, follow the steps below to import one of the guide's security template .INF files into the SCW:

1. Create a new installation of Windows Server 2003 SP1, or use an image of an existing server.
2. Install the SCW component through the Control Panel, Add/Remove Programs and Add/Remove Windows Components.
3. Join the computer to the domain.
4. Install and configure the mandatory applications installed on all your servers. Examples include management and backup agents, anti-virus and anti-spyware utilities. If you want to establish a baseline against a particular server role, include that role's applications as well.
5. Launch the SCW GUI, select Create new policy and point it to the reference computer you just created.
6. Ensure that the server roles, client features, administrative options and services needed for this server's role are detected and are appropriate for your environment.
7. Ensure the Skip this section checkbox is unchecked for the Network Security, Registry Settings and Audit Policy sections. The .INF file supplied with the guide will add these policy settings.
8. When prompted, include the appropriate security template .INF file from the guide and save the policy .XML file with an appropriate name.

When this process is complete, you have a choice: You can either apply the SCW's policy .XML file directly to the machine using the SCW's GUI or command-line interface, or convert the .XML file to a Group Policy. Each of these options has benefits and drawbacks:

• If you use the SCW to apply the policy file to your reference machine, you can still roll back the last applied policy -- including changes made by the security template .INF file -- and revert your server to its previous configuration. This new feature is handy while testing the policies you want to implement, but difficult to manage if you're applying policies across multiple servers.
• If you convert your policy file to a Group Policy, applying the policy to multiple servers will be easier. Just apply the newly created Group Policy to the appropriate OU and you're done. However, when you do this, you lose the ability to easily roll back that policy due to the Group Policy "Registry tattooing" problem. Registry values set by the policy will remain, even after the policy is deleted. It essentially "tattoos" the Registry until explicitly removed.

During the testing and evaluation process, it's probably a good idea to use the SCW to apply and roll back policies until you're comfortable with your security settings. Once you're ready for prime time, only then should you convert them into Group Policies.

[Click on image for larger view.]

Figure 1. The SCW includes a command-line interface for applying and rolling back policy files. A sample rollback is shown.

There are two items to note with the SCW, the first of which feels like a glaring omission:

First, you can use the command scwcmd analyze /p: to analyze a system and generate a comparison report of the system's security configuration against the policy. However, on two separate test systems, when using scwcmd view /x: to view the comparison report, there appeared to be missing information in the viewer. None of the analyzed Registry keys from the imported .INF file appeared in the view, even though they existed in the comparison report itself.

The SCW -- Learn More Want to know more about the Security Configuration Wizard? Check out a blogcast of Greg Shields discussing it at Redmond magazine's TechMentor conference: http://techmentorevents.com/samples

When asked about this missing information, Patrick Coleman, Program Manager for the Security Configuration Wizard responded, "Although the SCW supports analysis of .INF security policy settings as an adjunct to SCW policies, the best practice is to use the Security Configuration and Analysis MMC snap-in for this analysis scenario."

Seems like a great feature enhancement to me.

Second, the SCW is useful for applying Microsoft security policy to Microsoft products. If you're running applications on your servers that don't come from Microsoft, however, the SCW usually can't recognize those applications or appropriately apply security. We'll look at how to extend the SCW to enable it to identify non-Microsoft server roles and secure them appropriately in a future column.

Security vs. Usability
Always remember that hardening your servers is a delicate balancing act of securing them and keeping them useable. It's your responsibility to enable only the most appropriate security policies.

For example, it's entirely possible -- and actually recommended in the guide -- to configure software restrictions on your network for default Disallowed. This means that no executables can run on your network unless you specifically permit them.

Sounds pretty secure, but if a user needs to run a new application, they need to find you first to approve it. While this ensures a secure network, it comes at the high cost of impeding the normal workflow. Plus you would never get to go on vacation! Keep your life simple. Practice safe -- and sane -- securing.