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:
- Windows Vista Security Guide:
- Windows XP Security Baseline:
- Windows Server 2003 Security Baseline:
- Windows 2000 Security Hardening Guide:
If you experience issues or have comments after you implement the Microsoft Security Guides, you can provide feedback by sending an email message to
secwish@microsoft.com.
Security configuration guidance for the Windows operating system, for Internet Explorer, and for the Office productivity suite is provided in Microsoft Security Compliance Manager:
http://technet.microsoft.com/en-us/library/cc677002.aspx.
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:
811834 Cannot visit SSL sites after you enable FIPS compliant cryptography
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.