The Guiding Lights
Harden your computers' defenses with the tips in these Microsoft studies.
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
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.
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:
- Create a new installation of Windows Server 2003 SP1, or use an image of
an existing server.
- Install the SCW component through the Control Panel, Add/Remove Programs
and Add/Remove Windows Components.
- Join the computer to the domain.
- 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.
- Launch the SCW GUI, select Create new policy and point it to the reference
computer you just created.
- Ensure that the server roles, client features, administrative options and
services needed for this server's role are detected and are appropriate for
- 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.
- 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
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
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.
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:
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.