Security configuration guidance support

Summary

Microsoft, the Center for Internet Security (CIS), the National Security Agency (NSA), the Defense Information Systems Agency (DISA), and the National Institute of Standards and Technology (NIST) have published "security configuration guidance" for Microsoft Windows.

The high security levels that are specified in some of these guides may significantly restrict functionality of a system. Therefore, you should perform significant testing before you deploy these recommendations. We recommend that you take additional precautions when you do the following:

Enable System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

Disable Automatic Update service or Background Intelligent Transfer Service (BITS)

Disable NetLogon service

Enable NoNameReleaseOnDemand

Microsoft strongly supports industry efforts to provide security guidance for deployments in high security areas. However, you must thoroughly test the guidance in the target environment. If you need additional security settings beyond the default settings, we highly recommend that you see the Microsoft-issued guides. These guides can serve as a starting point for your organization's requirements. For support or for questions about third-party guides, contact the organization that issued the guidance.

Introduction

Over the past several years, a number of organizations, including Microsoft, the Center for Internet Security (CIS), the National Security Agency (NSA), the Defense Information Systems Agency (DISA), and the National Institute of Standards and Technology (NIST), have published "security configuration guidance" for Windows. As with any security guidance, the additional security that is required frequently has an adverse effect on usability.

Several of these guides, including the guides from Microsoft, from CIS, and from NIST, contain multiple levels of security settings. These guides may include levels designed for the following:

Interoperability with older operating systems

Enterprise environments

Enhanced security that provides limited functionality

Note This level is frequently known as the Specialized Security – Limited Functionality level or the High Security level.

The High Security, or Specialized Security – Limited Functionality, level is designed specifically for very hostile environments under significant risk of attack. This level guards information of the highest possible value, such as information that is required by some government systems. The High Security level of most of this public guidance is inappropriate for most systems that are running Windows. We recommend that you do not use the High Security level on general-purpose workstations. We recommend that you use the High Security level only on systems where compromise would cause the loss of life, the loss of very valuable information, or the loss of lots of money.

Several groups worked with Microsoft to produce these security guides. In many cases, these guides all address similar threats. However, each guide differs slightly because of legal requirements, local policy, and functional requirements. Because of this, the settings may vary from one set of recommendations to the next. The "Organizations that produce publicly available security guidance" section contains a summary of each security guide.

More Information

Organizations that produce publicly available security guidance

Microsoft Corporation

Microsoft provides guidance for how to help secure our own operating systems. We have developed the following three levels of security settings:

Enterprise Client (EC)

Stand-Alone (SA)

Specialized Security – Limited Functionality (SSLF)

We thoroughly tested this guidance for use in many customer scenarios. The guidance is appropriate for any organization that wishes to help secure its Windows-based computers.

We fully support our guides because of the extensive testing that we have conducted in our application compatibility laboratories on those guides. Visit the following Microsoft websites to download our guides:

The Center for Internet Security

CIS has developed benchmarks to provide information that helps organizations make informed decisions about certain available security choices. CIS has provided three levels of security benchmarks:

Legacy

Enterprise

High Security

If you experience issues or have comments after you implement the CIS benchmark settings, contact CIS by sending an email message to win2k-feedback@cisecurity.org.

Note CIS's guidance has changed since we originally published this article (November 3, 2004). CIS's current guidance resembles the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the "Microsoft Corporation" section earlier in this article.

The National Institute of Standards and Technology

NIST is responsible for creating security guidance for the United States Federal Government. NIST has created four levels of security guidance that are used by the United States Federal Agencies, private organizations, and public organizations:

SoHo

Legacy

Enterprise

Specialized Security – Limited Functionality

If you experience issues or have comments after you implement the NIST security templates, contact NIST by sending an email message to itsec@nist.gov.

Note NIST's guidance has changed since we originally published this article (November 3, 2004). NIST's current guidance resembles the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the "Microsoft Corporation" section earlier in this article.

The Defense Information Systems Agency

DISA creates guidance specifically for use in the United States Department of Defense (DOD). United States DOD users who experience issues or have comments after they implement the DISA configuration guidance can provide feedback by sending an email message to fso_spt@ritchie.disa.mil.

Note DISA's guidance has changed since we originally published this article (November 3, 2004). DISA's current guidance is similar or identical to the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the "Microsoft Corporation" section earlier in this article.

The National Security Agency (NSA)

NSA has produced guidance to help secure high-risk computers in the United States Department of Defense (DOD). NSA has developed a single level of guidance that corresponds approximately with the High Security level that is produced by other organizations.

If you experience issues or have comments after you implement the NSA Security Guides for Windows XP, you can provide feedback by sending an email message to XPGuides@nsa.gov. To provide feedback on the Windows 2000 guides, send an email message to w2kguides@nsa.gov.

Note NSA's guidance has changed since we originally published this article (November 3, 2004). NSA's current guidance is similar or identical to the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the "Microsoft Corporation" section earlier in this article.

Security guidance issues

As mentioned earlier in this article, the high security levels that are described in some of these guides were designed to significantly restrict the functionality of a system. Because of this restriction, you should thoroughly test a system before you deploy these recommendations.

Note The security guidance that is provided for the SoHo, Legacy, or Enterprise levels has not been reported to severely affect system functionality. This Knowledge Base article is primarily focused on the guidance that is associated with the highest security level.

We strongly support industry efforts to provide security guidance for deployments in high security areas. We continue to work with security standards groups to develop useful hardening guidance that is fully tested. Security guidelines from third parties are always issued with strong warnings to fully test the guidelines in target high-security environments. However, these warnings are not always heeded. Make sure that you thoroughly test all security configurations in your target environment. Security settings that differ from those that we recommend may invalidate the application-compatibility testing that is performed as part of the operating system testing process. Additionally, we and third parties specifically discourage applying the draft guidance in a live production environment instead of in a test environment.

The high levels of these security guides include several settings that you should carefully evaluate before you implement them. Although these settings may provide additional security benefits, the settings may have an adverse effect on the usability of the system.

File system and registry access control list modifications

Windows XP and later versions of Windows have significantly tightened permissions throughout the system. Therefore, extensive changes to default permissions should not be necessary.

Additional discretionary access control list (DACL) changes may invalidate all or most of the application compatibility testing that is performed by Microsoft. Frequently, changes such as these have not undergone the thorough testing that Microsoft has performed on other settings. Support cases and field experience have shown that DACL edits change the fundamental behavior of the operating system, frequently in unintended ways. These changes affect application compatibility and stability and reduce functionality, with regard to both performance and capability.

Because of these changes, we do not recommend that you modify file system DACLs on files that are included with the operating system on production systems. We recommend that you evaluate any additional ACL changes against a known threat to understand any potential advantages that the changes may lend to a specific configuration. For these reasons, our guides make only very minimal DACL changes and only to Windows 2000. For Windows 2000, several minor changes are required. These changes are described in the Windows 2000 Security Hardening Guide.

Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs DACL changes, or you apply the system defaults, you cannot roll back the original DACLs.

Changes to the DACL in the %SystemDrive% folder may cause the following scenarios:

The Recycle Bin no longer functions as designed, and files cannot be recovered.

A reduction of security that lets a non-administrator view the contents of the administrator’s Recycle Bin.

The failure of user profiles to function as expected.

A reduction of security that provides interactive users with read access to some or to all user profiles on the system.

Performance problems when many DACL edits are loaded into a Group Policy object that includes long logon times or repeated restarts of the target system.

Performance problems, including system slowdowns, every 16 hours or so as Group Policy settings are reapplied.

Application compatibility problems or application crashes.

To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, you cannot currently roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting the hard disk drive and by reinstalling the operating system.

For example, modifications to registry DACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the DACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can guarantee only that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

Microsoft network client: Digitally sign communications (always)

When you enable this setting, clients must sign Server Message Block (SMB) traffic when they contact servers that do not require SMB signing. This makes clients less vulnerable to session hijacking attacks. It provides significant value, but without enabling a similar change on the server to enable Microsoft network server: Digitally sign communications (always) or Microsoft network client: Digitally sign communications (if client agrees), the client will be unable to communicate successfully with the server.

Network security: Do not store LAN Manager hash value on next password change

When you enable this setting, the LAN Manager (LM) hash value for a new password will not be stored when the password is changed. The LM hash is relatively weak and prone to attack compared with the cryptographically stronger Microsoft Windows NT hash. Although this setting provides extensive additional security to a system by preventing many common password-cracking utilities, the setting can prevent some applications from starting or running correctly.

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

When you enable this setting, Internet Information Services (IIS) and Microsoft Internet Explorer use only the Transport Layer Security (TLS) 1.0 protocol. If this setting is enabled on a server that is running IIS, only web browsers that support TLS 1.0 can connect. If this setting is enabled on a web client, the client can connect only to servers that support the TLS 1.0 protocol. This requirement may affect a client’s ability to visit websites that use Secure Sockets Layer (SSL).For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Additionally, when you enable this setting on a server that uses Terminal Services, clients are forced to use the RDP client 5.2 or later versions to connect.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

811833 The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows

Automatic Update service or Background Intelligent Transfer Service (BITS) is disabled

One of the key pillars of the Microsoft security strategy is to make sure that systems are kept current on updates. A key component in this strategy is the Automatic Updates service. Both Windows Update and Software Update services use the Automatic Updates service. The Automatic Updates service relies on the Background Intelligent Transfer Service (BITS). If these services are disabled, the computers will no longer be able to receive updates from Windows Update through Automatic Updates, from Software Update services (SUS), or from some Microsoft Systems Management Server (SMS) installations. These services should be disabled only on systems that have an effective update-distribution system that does not rely on BITS.

NetLogon service is disabled

If you disable the NetLogon service, a workstation no longer functions reliably as a domain member. This setting may be appropriate for some computers that do not participate in domains. However, it should be carefully evaluated before deployment.

NoNameReleaseOnDemand

This setting prevents a server from relinquishing its NetBIOS name if it conflicts with another computer on the network. This setting is a good preventive measure for denial of service attacks against name servers and other very important server roles.

When you enable this setting on a workstation, the workstation refuses to relinquish its NetBIOS name even if the name conflicts with the name of a more important system, such as a domain controller. This scenario can disable important domain functionality. Microsoft strongly supports industry efforts to provide security guidance that is targeted to deployments in high security areas. However, this guidance must be thoroughly tested in the target environment. We highly recommend that system administrators who require additional security settings beyond the default settings use the Microsoft-issued guides as a starting point for their organization's requirements. For support or for questions about third-party guides, contact the organization that issued the guidance.

References

For more information about security settings, see Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP. To download this guide, visit the following Microsoft website:

For more information about the effect of some additional key security settings, click the following article number to view the article in the Microsoft Knowledge Base:

823659 Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments

For more information about the effects of requiring FIPS compliant algorithms, click the following article number to view the article in the Microsoft Knowledge Base:

811833 The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and later versions

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

For information about your hardware manufacturer, visit the following Microsoft website: