Security WatchThe Security Configuration Wizard

John Morello

This column includes prerelease information about Windows Server "Longhorn" that is subject to change.

Securing servers efficiently and consistently is a challenge for many IT organizations, particularly those with large numbers of machines dispersed over numerous geographic and organizational boundaries. While hardening a single server can be a relatively straightforward task for a skilled administrator, hardening tens, hundreds, or

even thousands of servers is a far different proposition. Over the years, many organizations have come up with their own internal checklists or standards for server security or incorporated such guidance provided by Microsoft, the National Institute of Standards and Technology, or other external parties. Though this documentation can be tremendously valuable, documentation alone isn’t enough to enable organizations to really put these best practices into action on their networks. Thus, many have opted to either stay with default installation settings or to invest significant time and effort to create their own scripts or policies for hardening systems.

With the advent of the Security Con­figuration Wizard (SCW) in Win­dows Server® 2003 Service Pack 1 (SP1), Microsoft now provides a straightforward and supported method for hardening servers and reducing their attack surface based on the roles they perform. By combining the benefits of the SCW with the centralized deployment and management capabilities of Group Policy, the SCW can be scaled to the largest IT enterprises. In this month’s column, I’ll provide an overview of how IT organizations can use the SCW and Group Policy to manage their servers in a more secure and consistent manner, while lowering deployment and operational costs.

What is the SCW?

The SCW is an optional component, installed through the Add/Re­move Windows® Components control panel, available on all members of the Windows Server 2003 SP1 family, including Windows Server 2003 R2. An administrator would start by running the SCW against a target server to identify the roles that server fulfills. The SCW then assists the administrator in creating a security policy that hardens the machine using a least-privilege scheme. In other words, the SCW helps to ensure that only those services, application capabilities, and ports required for the roles to function are available; anything not specifically needed by the roles the server holds will be disabled. This approach helps to reduce the attack surface of the target server. If you run services that are not required for the role the server performs, you increase the net risk to the server without any gain in capability or functionality. Disabling these services lowers the risk and may also improve server performance.

While Microsoft made many security advances with Windows Server 2003, greatly reducing its overall attack surface compared to previous versions of Windows Server, it is not built on the same highly componentized core that Windows Vista™ and the forthcoming version of Windows Server code-named "Longhorn" are. Thus, on a default installation of Windows Ser­ver 2003, there can be services enabled and running that are not needed for all server role configurations. For example, the Print Spooler service is enabled by default but is not required for a machine that’s only acting as a database server.

Making Role-Based Security a Reality

Over the past several years, Micro­soft has released a wealth of security-focused documentation that helps administrators understand what services are required in different server roles and provides pre-built templates for well known roles like Web servers. However, guidelines like those in the Windows Server 2003 Security Guide can be challenging to implement in large environments, particularly when the applications used in those environments are often more complex than basic IIS or SQL Server installations. Further complicating the matter are myriad third-party applications that enterprises employ, many of which have dependencies on multiple server roles and whose application and service requirements are not always well defined.

SCW addresses these issues by encapsulating all the dependency knowledge and best practices contained in the guides into an administrator- driven wizard. For example, if an administrator is deploying a new line-of-business (LOB) application that requires both SQL Server™ and IIS, he no longer needs to invest significant time combing through the security guide and developing his own list of custom dependencies. Instead, he can install the application on the server and launch the SCW. The SCW will detect what services are currently running, and present the administrator with a list of roles to choose for the server. Depending on his selection, SCW will generate a policy that will disable all services not required by the dependency matrix for the roles. SCW will also provide options for hardening the registry, blocking unneeded network communications, and applying an effective audit policy. After running SCW, the administrator can save the SCW policy as an XML file and apply it to any other servers running the same LOB application.

Running SCW thus provides three powerful advantages over traditional, more manual approaches to securing Windows Server. First, it greatly reduces (if not eliminates) the need for an administrator to constantly consult product documentation to determine the services and settings required for a given workload. This knowledge is built into SCW, and the question-driven interface makes it easy for the administrator to supply needed details. Next, the SCW consolidates guidance for a number of areas, including service hardening, reducing network attack surface, hardening of LDAP and SMB services, and locking down IIS. Previously, performing these configuration tasks required separate utilities, each with its own interface and approach. Finally, because the SCW outputs its settings into an XML policy file, it can be used in "create once, apply many" scenarios. Whether you’re deploying 1 or 100 servers to support a particular LOB application, the same SCW policy can easily be applied to all of them. This makes security settings more consistent and lowers operational costs. It also makes rolling back SCW policies simple.

SCW Components

For all its capabilities and benefits, the SCW is actually a fairly simple tool that consists of three primary parts: the wizard interface, the command-line interface, and the Security Configuration Database (SCD). Administrators in small or medium enterprises may only need to interact with the wizard interface. In larger or more complex environments, administrators can use the command-line interface to assist in automating SCW tasks such as transforming an SCW policy into a Group Policy Object (GPO). Typically, only advanced administrators who wish to create their own custom SCW roles will modify the SCD.

The wizard interface, shown in Figure 1, allows administrators to create, edit, apply, and roll back security settings to a target server. It presents choices to administrators in a consistent work flow that first examines services and settings, then network connectivity, then security audit policies, and finally IIS settings.

Figure 1** SCW interface **(Click the image for a larger view)

The SCW command-line interface provides three basic functions. It allows administrators to analyze and configure multiple servers (either local or remote), and to roll back policies. It can be used to automatically convert an XML-based SCW policy into a GPO that can be natively used in standard GPO management tools like the Group Policy Management Console. Finally, the SCW command-line tool shown in Figure 2 is used to register any new Security Configuration Database extensions.

Figure 2** SCW command-line tool **(Click the image for a larger view)

The SCD is simply a collection of XML files that detail the particular services and settings required for each SCW role. These files are located in %win­dir%\security\msscw\kbs. By default, the SCW ships with a number of core Windows Server roles, as well as 12 predefined application roles including: BizTalk®, Commerce Ser­ver, Exchange Server, Host Inte­gration Server, Internet Security and Ac­cel­er­ation Server, Microsoft Ident­ity Inte­gra­tion Server, Microsoft Oper­a­tions Man­ager, Small Business Server, Share­Point® Portal Server, SharePoint Team Ser­vices, SQL Server, and Systems Man­agement Server. Each role has its own XML file (see Figure 3). Any time a new role definition is created, its corresponding XML file will be placed into this directory. The files are standard XML and can be read in any text viewer or other application that supports XML (see Figure 4).

Figure 3** Predefined roles **(Click the image for a larger view)

Figure 4** Role configuration file **(Click the image for a larger view)

Combining the SCW and Group Policy

By itself, the SCW is a great tool, but its true power isn’t fully revealed until it’s combined with Group Policy. Since the release of Windows® 2000, Micro­soft recommendations for securing Windows servers have been focused on using Group Policy to provide consistent, persistent, centrally managed policy application. By grouping servers into Organizational Units (OUs) based on their roles, administrators are able to deploy standard security configurations throughout the enterprise rather than at the individual machine level. By building upon the standard Group Policy accumulation and application logic, organizations can design a tiered server role hierarchy where a handful of master policies can secure hundreds or thousands of individual servers. When unique server roles demand variation from the master policies, smaller role-focused delta policies can be created more "closely" in the OU hierarchy to the servers themselves. This allows small changes to be made to enable role-specific functionality without having to duplicate the master policy in its entirety, an approach that gives large enterprises the benefits of a centrally managed policy along with the flexibility to adapt to specific applications when required.

The real challenge to this approach is in making it a reality. For large organizations with many different applications and server roles, creating the right set of policies is difficult and time consuming—or it was before the SCW. By using the SCW to generate policies and then attaching those policies to the right OU, you can greatly decrease the time it takes to deploy directory-hosted, role-based security, both for existing workloads and any you may adopt later on. To better illustrate how an organization might make this work, let’s walk through a large enterprise implementation of SCW and role-based GPOs.

SCW in the Enterprise

For this example, I’ll use the fictional Contoso network. Contoso has a large, complex, and geographically dispersed IT enterprise. Hoping to reduce its operational costs and increase the security of its servers, Contoso follows Microsoft guidance for creating a role-based OU hierarchy that separates and organizes servers based on workload. To create the policies to attach to these OUs, Contoso uses the SCW.

Because the SCW is not installed by default, Contoso needs to specifically enable the SCW component in its unattended installation image. To do so, it adds a new line, SCW=On, to the [Components] section of Unattend.txt. Thereafter, all new systems built with this image will have the SCW component installed during setup. Note that simply configuring SCW to be installed does not apply any policies to machines as they’re being built.

To apply a default policy during the setup process, Contoso edits the [Com­mands] section of the cmdlines.txt file in the image to call scwcmd with the following options:

scwcmd configure /p:ContosoBaselinePolicy.xml 

Both the text file and the XML file must be in the $OEM$ directory of the image. Why would Contoso apply a baseline policy at build time rather than simply relying on the one attached to the top-level OU in the directory? By applying a policy at build time, Contoso is able to ensure a consistent baseline regardless of whether a machine is joined to Active Directory®. For example, if a server is built for testing purposes, applying the baseline policy during the build process ensures that it at least follows the organization’s standard security policy, even if it’s never joined to the production Active Directory. If the server is later joined to Active Directory, the Group Policy application and precedence algorithm will override the local settings with those from the Domain or OU level (remember that the order of precedence for policy application is Local, Site, Domain, OU).

Once the SCW has been installed, Contoso can begin creating its baseline policy. The baseline policy should be the one deployed at the top level of the role-based security OU hierarchy and will typically be the most restrictive policy in the hierarchy. The idea is to have as secure a default as possible, then to open up only those services and ports for individual workloads as required by those server roles. To that end, the baseline policy should be created by taking a plain, newly built server and adding the standard Contoso stack of management tools and utilities, then running SCW against it. For example, after the basic Windows installation is complete, Contoso installs (either manually or through the cmdlines.txt file) its standard antivirus, back­up, management, and monitoring tools on the server. Because each of these tools likely creates its own Windows services, having them on the server prior to creating the baseline policy allows SCW to be aware of them during the service-lockdown phase.

Once the server is built, Contoso runs the SCW against it. The SCW can be run either locally or remotely, and whoever is running it must be a member of the local administrators group on the machine. If SCW is being run remotely, it provides an option to specify the user account to run under on the remote host; if it’s being run locally, you can use runas.exe to accomplish the same thing. The first task SCW undertakes is to evaluate those services running on the local machine and to display which roles are currently installed (see Figure 5).

Figure 5** Select and view server roles **(Click the image for a larger view)

No roles should be selected on Con­toso’s baseline server since the machine is designed to be in a highly restricted state. After the roles the server performs are selected, the next step is to identify the required client features in order to enable functionality such as Automatic updates, Active Directory, or the FTP client. For most organizations, accepting the SCW default (as illustrated in Figure 6) provides important functionality (such as the ability to join a domain), while prohibiting less critical features (like the FTP client).

Figure 6** Installed features **(Click the image for a larger view)

The SCW then continues, letting you choose which specific administrative tools and non-default services to allow. Those non-default services options are why you should run the SCW after installing the standard Contoso server management stack. When the antivirus, backup, and related applications are installed, SCW will then be able to have knowledge of these services and therefore include them in its resulting policy settings.

The last question in the service hardening section asks how to handle unspecified services. These are services that may be encountered on other computers on which the SCW policy is applied, even though they’re not running on the machine on which the policy was originally created. For example, if the baseline policy is applied to a new server with some new third-party application, any services installed by that application are handled according to the choice the administrator makes here. SCW allows the administrator to either not change the startup mode of the service or to disable it. Disabled is the more secure option, but it should be used with care since any services that are not explicitly allowed to run will be prevented from running. For this reason, this option is most suitable for high-security, well-managed environments. For other parts of an organization, choosing not to change the startup mode is recommended. Thus, in the Contoso example, that’s the option chosen. Before completing the service hardening portion of its tasks, SCW presents the administrator with a report on which services will be altered.

After completing service hardening, the SCW provides options for limiting inbound network access. As with the list of services required for a given role, the list of ports required for a given workload is included in the SCW’s XML database.

Administrators can configure additional ports as needed and also make per-service port rules, as shown in Figure 7. For the Contoso baseline server, only the most basic services, such as Remote Desktop, should be allowed. All other exceptions will be configured in the role-based policies lower in the OU hierarchy.

Figure 7** View and allow ports **(Click the image for a larger view)

The SCW then allows the administrator to select registry options such as signing file and print traffic. Again, in the baseline configuration, choosing the most secure defaults is recommended as a best practice.

The next set of choices involves the system audit policy. On most systems, selecting the Audit successful activities option is best; auditing all activities is more processor-intensive and generates a significant amount of data in the audit log. When an attack is suspected or more detailed analysis needed, failure auditing can be enabled on the specific machine.

Finally, SCW will present the administrator with options for hardening IIS. These options are similar to those available in the IIS Lockdown tool and are now integrated directly into the SCW policy.

After all the steps are completed, SCW prompts the administrator to save the XML file. The saved file must then be converted into a format that is understood natively by Group Policy. Scwcmd.exe is used to transform the saved XML file into a GPO. Here’s the command to enter:

scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy 

This policy is automatically created in Active Directory and can be attached to the top of the Contoso role-based hardening OU hierarchy.

Once this policy is applied to the top level of the hierarchy, any machines added to the OU hierarchy will inherit its settings. When a machine is added that requires modifications to this policy (such as an IIS server that requires the W3SVC service to be running), Contoso administrators will rerun the SCW for that new server role, transform this new policy into a GPO, and attach that GPO to a new sub-OU containing the server(s). Because the GPO closest to the server will take precedence, the end result will be that all of the baseline settings will be in place, except those that require modification to enable the desired role functionality for that OU (see Figure 8).

Figure 8** Policy application at Contoso **(Click the image for a larger view)

The real power of this approach becomes clear in larger organizations or when many servers are being deployed. Once the initial SCW policy is created and attached to an OU, subsequent servers simply need to be added to that OU and they automatically inherit the proper security policy. Thus, once the initial set of policies is created and added to Active Directory, deploying new servers or replacing existing ones becomes a simple and fast process.

Looking Ahead

In the next release of Windows Server "Longhorn," Micro­soft has greatly componentized the operating system, resulting in a streamlined and limited attack surface out of the box. Rather than focusing on locking down the minimal default installation, administrators will instead use the Server Manager tool to add those roles and workloads required on each server. Server Manager works much like the SCW in that it has an internal database of dependencies that allows the installer to add only those pieces of functionality required to provide the desired role service. Moreover, centrally managed role-based security using Group Policy as discussed in this article is further enhanced by the greatly expanded set of GPO-controlled features. In short, Windows Server "Long­horn" takes the SCW concept to the next level with increased flexibility and an even stronger security posture right out of the box.

SCW Resources

The following Web pages will help you get started using SCW:

• Security Configuration Wizard Documentation
• Security Configuration Wizard for Windows Server 2003
• Windows Server "Longhorn"

John Morello graduated from LSU and has been with Microsoft for six years in a variety of roles. As a Senior Consultant, he designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He’s currently a Senior Program Manager in the Windows Server group working on security and remote access technologies.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.