Security Templates Define and Enforce the Rules

Best practices for configuring, managing, and auditing OS security features

You know that Windows 2000 has a robust security model. However, to ensure legacy compatibility and interoperability, Win2K Setup activates only a few of the available security features. For example, when you install a fresh copy of Win2K or upgrade a legacy platform to Win2K, default security settings don't implement account lockout controls or enable security auditing. You'll also discover that the default settings permit blank and zero-length passwords and set most services to start automatically with the system account. And although Win2K Setup implements access controls on the system root to limit nonadministrator access, the OS grants Everyone Full Control access to the root of all logical drives.

You'll find many compelling reasons to modify the default security settings, especially if you're configuring systems for a secure environment. For example, to ensure application compatibility when you upgrade a Windows NT 4.0 system to Win2K, Win2K by default adds the local Users group to the local Power Users group. Members of the Power Users group can manage and manipulate local user and group accounts and shared resources—tasks you might not want a typical interactive user to perform. Therefore, if you plan to upgrade many NT 4.0 systems to Win2K, you might want to remove the local Users group from the local Power Users group. Similarly, if you're setting up a VPN server that only manages connections, you might want to disable unnecessary services as a deterrent to unauthorized access and to eliminate potential security vulnerabilities. As you learn more about Win2K's default security settings and how they affect a mixed environment, you're guaranteed to discover new areas of vulnerability that require your attention to eliminate intrusion opportunities.

The Security Configuration Tool Set
Win2K includes a group of three security-based utilities, collectively called the Security Configuration Tool Set, that assist you in defining, implementing, and managing security roles for systems. These utilities—Security Templates, Security Configuration and Analysis, and Security Extensions to Group Policy—extend the controls available in NT 4.0 system policies.

Here's the big picture for how you leverage the security tool set. You start by defining enterprise security requirements for a common group of systems, such as end-user workstations, firewalls, or special-purpose servers. Then, you use the Microsoft Management Console (MMC) Security Templates snap-in to create a template that translates your security requirements into OS-specific settings. A security template defines values and behaviors for seven security-related categories—account policies, local policies, event-log controls, restricted groups, system services, the registry, and the file system—that implement the controls you need.

After you define the template, you use the MMC Security Configuration and Analysis snap-in to test the template and assign it to systems that share the same security role. You use the Security Configuration and Analysis snap-in to compare active settings with settings in a template. If you want to implement security templates through Group Policy, you must use the MMC Security Extensions to Group Policy snap-in. You can use the tools individually or together to define, implement, audit, and document corporate standard security settings on all systems in your enterprise.

Security Templates
Security Templates is a standalone MMC snap-in that lets you configure OS security by making selections from a GUI. Templates contain a lot of information, and it takes several seconds for the snap-in to locate and process the built-in templates. Similarly, the first time you expand a template, the snap-in might respond sluggishly; but after the template is loaded, response time improves. In the left pane of the Security Templates snap-in, which Figure 1 shows, you can see the 12 built-in templates that define security settings for generic classes of machines, from a basic workstation to a high-security server.

Built-in templates define five security roles: basic, secure, highly secure, compatible, and optional component file security. (The Web-exclusive sidebar "The Purpose of Built-in Templates," http://www.secadministrator.com, InstantDoc ID 23081, briefly explains the built-in templates.) Win2K stores the text versions of built-in templates in the default location %windir%securitytemplates. This directory contains one file with an .inf extension for each template. To avoid rights problems with legacy applications, all built-in templates make the local Users group a member of the local Power Users group.

The built-in templates define generic security roles for systems. The last one or two letters of each built-in security template describe the role to which the template applies: wk or ws represents a workstation, sv represents a server, and dc represents a domain controller (DC). Workstation templates are less restrictive than server templates, and server templates have fewer controls than DC templates. As with any template, anticipating the many ways an enterprise might need to configure and control workstations and servers is difficult. You can use a built-in security template in your enterprise if the settings meet your security needs. You can also use a built-in template as a baseline to define a custom template that implements more rigorous controls. To customize a template, you can make a copy of an existing template, rename it during the copy operation, and add policies and controls that implement your site-specific security requirements. (For an example of a custom security template, see the Web-exclusive sidebar "Building a Custom Security Template," InstantDoc ID 23082.)

Each security template contains a key for seven security categories. (Figure 1 shows the keys for the Setup Security template.) If you've previously examined or modified the Local Security policy on a Win2K system, many of these entries will look familiar. Expand any key in the left pane to display the available controls and their current settings in the right pane.

A side benefit of security templates is that they permanently document a system's security configuration. When implementing security controls, you often make changes on different days over a long period of time, and it's difficult (if not impossible) to reconstruct the whole picture on demand. However, if you define all the modifications in a template, you can reference the template to answer questions about specific settings. With a template, you can recreate the same configuration at will on any system with just a few mouse clicks.

For example, when you upgrade a Windows 9x system to Win2K, the upgraded system has all the default settings of a new Win2K system. However, when you upgrade an NT 4.0 system to a Win2K DC, setup doesn't change the NT security settings or system root ACLs. If you want the Win2K DC you upgraded from NT to have the same settings as a new Win2K DC, apply the basicdc template. If you want your upgraded Win2K DC to conform to the more restrictive settings of a secure DC, you must also apply the securedc template. The securedc template adds to but doesn't include controls in the basicdc template. In other words, built-in templates are incremental, not all-inclusive. (For more information about incremental templates, see the Web-exclusive sidebar "How Incremental Templates Work," InstantDoc ID 23083.)

Security Configuration and Analysis
The Security Configuration and Analysis snap-in configures and analyzes the local system by using a security template as a guide. The analysis effectively audits the local system against settings defined in a template, while the configuration component applies the template settings to the local system. If you plan to assign security templates to systems through Group Policy (e.g., to a group of systems or all systems in a domain or an organizational unit—OU), you need the Security Extensions to Group Policy snap-in.

Secedit.exe is the command-line interface for the Security Configuration and Analysis tool. Secedit has five commands—Analyze, Configure, Export, RefreshPolicy, and Validate—that help you define, apply, and audit security settings. The command-line interface is handy if you need to perform only one task, such as analyze a system, export a database to its companion .inf file, or refresh the Local Security Policy from local or Group Policy Object (GPO) settings. If you manually edit a template .inf file, you can use Secedit's Validate command to syntactically verify the contents of the .inf file before you use the template with the Security Configuration and Analysis snap-in.

All configuration and analysis tasks operate with a database built from a security template. The first time you start the Security Configuration and Analysis snap-in, the right pane contains instructions for opening an existing database or creating a new database. The first time you use a template, the snap-in creates and permanently saves the database. Because the tool creates a permanent copy of the database with an .sdb extension during database creation, you need to create the database only once. (For ease of use, I recommend that you give each database the same name as the template and that you store all the databases in the same directory.) After you create the database, right-click the Security Configuration and Analysis snap-in to display the tasks you can perform with the active template.

The Analysis Task: Auditing a System
You can use the Security Configuration and Analysis snap-in's Analyze Computer Now option to compare (i.e., audit) the current system configuration with settings in a template. With an audit, you can analyze a system to confirm the configuration or identify discrepancies. If the current settings don't match the template, either you missed a definition or someone has the (potentially undesirable) ability to modify security settings. In either case, an audit helps you identify and close loopholes.

During Win2K installation, the Setup utility uses the Setup Security .inf template to implement Win2K's default security settings. You can use the setup template to compare the system's current configuration with settings that the original installation implements. To compare configurations, right-click the Security Configuration and Analysis snap-in, select Open database, then type

Setup Security

in the File name text box. In the Import Template dialog box, which Figure 2 shows, select setup security .inf, then click Open to create the database. The next time you need the Setup Security database, it will appear in the database directory list as setup security.sdb.

To start the audit, right-click the Security Configuration and Analysis snap-in, select Analyze Computer Now, then either accept the default log-file name or enter an alternate path. The log duplicates most of the GUI results in a text file and, as such, is a permanent record of the audit. I recommend that you direct the log file to the same directory in which you store templates and databases. (By default, the Security Configuration and Analysis snap-in creates the log file in My Documents.)

You'll see a progress screen as the audit proceeds through the seven categories. When the analysis is finished, the Security Configuration and Analysis snap-in displays the results in each of the keys that appear below the snap-in. Expand each key to examine the detailed results of the audit. In the right pane of the console, you'll see three columns. The first column displays the policy name, the second column displays the template setting, and the third column displays the system's current setting, as Figure 3 shows. Whenever a discrepancy occurs between the template setting and the system setting, a red circle with an x appears over the policy item name. In Figure 3, the Setup Security template doesn't activate security logging, but the system is currently configured to audit several categories of security events.

The Configuration Task: Activating a Security Template
Using a template to configure a system is as easy as performing an audit. For example, let's say that you want to reset a system to installation defaults so that you have a known starting point for testing a custom template. If you have a different template loaded in the Security Configuration and Analysis snap-in, you need to create or open the Setup Security database I referred to in the previous section.

After the database is loaded, right-click the Security Configuration and Analysis snap-in, then select Configure Computer Now. The same progress screen the snap-in displays when it's auditing a system will appear. Because the Security Configuration and Analysis snap-in is implementing changes, configuring a system takes slightly longer than analyzing one with the same template. When the Security Configuration and Analysis snap-in finishes configuring the system, the system's security settings duplicate settings from the original installation.

When you configure a system, the Security Configuration and Analysis snap-in doesn't display the results after a configure task like it does after an analysis. To check a specific setting or verify settings or policies, use the same template to analyze the system a second time, then look at the results of the analysis report. (You can also examine the log file that the Configure task creates, but looking at the GUI version of the Analysis report is much easier.)

A word of caution about configuring a system with the built-in templates: You might expect that the Securews template contains all the policies from the Basicwk template, but such isn't the case. Each built-in template implements a specific set of nonoverlapping policies and controls. To bring a system into compliance with the Securews template, you first apply the Basicwk template, then apply the Securews template. Similarly, to configure a highly secure workstation, apply the Basicwk, Securews, and Hisecws templates in that order.

Configuring with Multiple Templates
You can expedite using multiple templates to configure a system by creating a composite database of all the templates that you need to implement necessary security controls. The Security Configuration and Analysis snap-in can import multiple templates into the same database, which produces a database that reflects the combined settings of all the templates. (For more information about using multiple templates, see the Web-exclusive sidebar "How Incremental Templates Work.")

When you import multiple templates into the same database, the Security Configuration and Analysis snap-in doesn't track or inform you about the templates you load, which means it's easy to become confused about what you've imported. So, be methodical when you perform these tasks. Also, the Security Configuration and Analysis snap-in doesn't support unloading a template, so you can't revert a database to a previous state. If you import the wrong template, you need to delete the database and start over. When you're satisfied with the results, you can save the cumulative database in its own security template. To save the database, right-click the Security Configuration and Analysis snap-in, select Export, then enter a template name. After you export the database, the new template appears in the Security Templates snap-in.

When you create a new database that combines multiple templates (as opposed to opening an existing database), you must name the database before you select and import a template. Be sure to give the cumulative database a name that reflects the composite contents (i.e., don't name it for the first template you load).

The Security Configuration and Analysis snap-in also routinely reports that it can't open a database you've previously created—either because the database is corrupt or because the snap-in encountered an unknown error when it tried to load the file. When this problem occurs, you can recreate the database from your carefully documented notes or restore the database from a backup copy. One other annoyance is that the Security Configuration and Analysis snap-in doesn't support renaming or deleting a database. You must perform these operations from Windows Explorer or at a command prompt.

Room for Improvement
After experimenting with the Security Configuration Tool Set, I've identified several features that would make these utilities more convenient. But first I want to discuss one obvious security problem. The .inf files, databases, and log files that these tools create contain system-configuration data such as registry settings and values and file-system access controls. To protect this sensitive information, I recommend that you restrict access to these files to administrators and security personnel. Although one directory that contains all the template files, databases, and log files is important for usability reasons, having one directory also lets you monitor and restrict access to sensitive OS security configuration information (e.g., through ACLs and directory-access auditing). Here's a list of tool-set shortcomings that you should be aware of:

Making Enterprise Security Easier
Despite its shortcomings, you can employ the Security Configuration Tool Set to define, implement, audit, and enforce corporate security standards on workstations and servers throughout your enterprise. The Security Templates snap-in helps you define several levels of workstation and server security-specific configurations once. With the Security Configuration and Analysis snap-in, you can interactively configure a system with the template that corresponds to its function. You can also interactively audit a system to determine whether the security settings conform to the security role you previously defined. I didn't explain how you define file-system or registry ACLs or how you can include registry entries in a template. Fortunately, the applicable online Help is fairly straightforward. If you're responsible for defining, configuring, and enforcing Win2K security, you've learned most of what you need to know to get the job done.