Best Practices for SCW

  • Article

Applies To: Windows Server 2003

This topic tells how to get the most out of SCW by using Best Practices.

This topic tells how to get the most out of SCW by using Best Practices.

Identify and target similar servers

SCW helps to reduce the attack surface of servers by creating a security policy that is specifically designed for their specific roles. Administrators can simplify policy authoring and distribution by identifying groups of servers that perform the same or similar tasks. Here are ways you can do this:

  • Author one policy for a group of servers. SCW authors a security policy based on the roles, tasks, and functions performed by a server. Others servers that perform the same, or very similar, functions can be configured with the same security policy. Administrators can use SCW once to author a security policy, save it, and apply it to all servers that perform the job function.

  • Group similar servers in one organizational unit (OU) in Active Directory. The SCW transform operation can apply a security policy to a domain or OU by using Group Policy. To simplify policy distribution, an administrator could group servers that perform similar job functions, and use the same security policy, into a single OU. A new security policy can be distributed quickly and easily to the server OU by using the SCW transform operation.

  • Create policies for similar platforms. For services or ports specific to 64-bit computers, create the policies on a 64-bit computer. Then deploy these policies only to other 64-bit computers (not 32-bit computers) to ensure that the services are properly identified and configured.

  • Model your prototype server after the target servers to be configured at the service level. It is highly recommended that the prototype server from which the security policy will be created matches the target servers to be configured at the service level. The security policy disables any service on the server that is contained in the Security Configuration Database but was not present on the prototype server when the policy was created.

    For example, if the DCOM Server Process Launcher service is listed in the Security Configuration Database, but is not present on the prototype server, the security policy created based on the prototype server will set the DCOM Server Process Launcher state to disabled. When you apply the security policy to other servers, the DCOM Server Process Launcher service will be disabled on those servers. You can configure unnecessary services in SCW (you can disable the service or leave the startup mode of the service unchanged), but only services that are not in the Security Configuration Database, and therefore are not defined in the security policy that you create with SCW.

Test new security policies offline before deployment

The settings configured in the new security policies may cause compatibility issues with applications or services. Therefore, thoroughly test new security policies in a test environment before applying the policies to production servers.

Create one complete security policy

SCW should be used to author a single security policy that contains all desired security settings for a server or a group of servers. This will simplify configuration, rollback, and analysis. For simple configuration and rollback, a single security policy for a computer, or group of computers, is much easier to understand and update than a series of policies. If a security policy defines all the desired settings for a server, a compliance report can be generated by running one scan, which facilitates analysis when using the scwcmd /analyze command. For more information about Scwcmd, see Getting Started with SCW.