Don’t trust Microsoft? You're not alone. But if you don't trust the company, why would you depend on it to provide all your Windows security guidelines? A better approach might be to go to a completely independent source.
Who can you go to and how much will the information cost? Obviously, TechRepublic is a fine place to start, but you can also get free advice from the U.S. government.
The National Institute of Standards and Technology (NIST), the federal agency formerly known as The Bureau of Standards, has released a 163-page installation and security best practices document for Windows 2000. It should be required reading for all Win2K power users and sys admins. Although written for government users, the document contains little or no government-specific information, so it can provide all Win2K administrators with a good summary of the current understanding of how to secure this operating system.
The report, "System Administration Guidance for Windows 2000 Professional," is a draft document and therefore incomplete, but what’s missing is mostly the index. The report is already valuable and will be more useful after the comment period is over (March 1, 2002).
The overview of security components in this guide includes:
- Smart cards
- P2P and L2TP
- Encryption file system (EFS)
The NIST guidelines also include two security templates that can extend the default Microsoft Hiscwk.inf template and the Win2k_pro.inf template available from the National Security Agency (NSA). NIST's NIST2kws.inf is designed for stand-alone installations of Windows 2000 Pro; NIST2kdm.inf is for Win2K Pro domain installations. You can freely modify these templates to meet the needs of your organization.
Appendix C of the NIST guidelines includes a list of tools used to configure, manage, and monitor the Win2K Pro security settings. Some are included with Win2K and sources are listed for the others.
The document covers both stand-alone Win2K Pro and domain member configurations. Despite the title, which makes this appear to be a Win2K-only guide, the report includes a considerable amount of information on XP in Appendix D. This is reasonable since XP is based on the Win2K kernel.
The most significant difference between XP and Win2K, as addressed in this document, is the addition of “bridge” functionality in which an XP machine can function as a network bridge between two network interfaces, such as a standard Ethernet adapter and a WiFi (802.11b) adapter. Unfortunately, although this may be a serious security concern, the NIST document merely says that the document’s authors do not yet know what security implications this new bridge capability could pose.
The report also addresses a key change in the EFS. Under Win2K, EFS allows file access to only a single user; in XP, multiple users are granted access to encrypted files. In one way, however, encryption is considerably stronger in XP: By default, it doesn’t include a recovery agent that allows an administrator to recover files if an employee leaves or a password is lost.
Here are some of the additional recommendations included in the guide:
- Use the Security Configuration Analysis snap-in and the Local Security Policy tool to import, analyze, modify, configure, and export the security settings.
- Use the GPO to automate the deployment of security settings to domain member systems.
- Use the Secedit.exe tool in a script file to apply security settings to the Windows 2000 systems.
- Apply the NIST template to configure the Security Options.
This NIST document isn’t the first or only Win2K security guide that the federal government has made available to the public. The NSA has created several security guides. These guides contain so much information on Win2K, the NSA offers a 9.2-MB zipped archive file containing all of them. You can also download the individual documents.
The NSA guides are specifically written for the U.S. military but may prove useful reading for all Win2K system administrators. As with the NIST documents, you will also find a number of downloadable .Inf security configuration templates.
The NSA also publishes security guides for Windows NT, Cisco routers, and e-mail. Particularly useful for a wide range of readers is last summer’s e-mail security guide, which includes a set of security countermeasures that many companies will want to implement.
For instance, countermeasure 5 describes how to coax Windows to display full file extensions such as ILOVEYOU.TXT.VBS. Since this requires extensive registry editing to be completely effective, the accompanying chart is helpful. Some of the other countermeasures are pretty basic, including using antivirus software and applying Microsoft patches as they are released.
The guide offers a number of specific recommendations regarding the protection of the registry, including detailed instructions on altering settings to prevent remote access to the registry. Other recommendations are pretty sophisticated, such as securing additional Base Named Objects, which blocks malicious code from gaining local administrator access via a Dynamic Link Library, and securing system directories by changing access to \Winnt\system32 and \Winnt\system so that authenticated users have only read permission.
Although none of these documents appear to have any startling new information for experienced security personnel, I see several ways you could make use of them.
First, they all provide good introductions to various security concerns, covering all the basics with links to Microsoft documents. When new staff members join your IT group, you can send them to these documents for a fast introduction to Win2K security basics. You can also provide the documents to your help desk and maybe even some power users.
Second, you can use these documents to make sure that you have all your bases covered. Obviously, if the NIST and NSA feel that these are the best practices for securing Win2K, e-mail, NT, and Cisco routers in government agencies, meeting or going beyond these recommendations should give you some cover in the event of a catastrophe in your office.
Third, these guides include configuration templates that you can use as is or modify to meet your needs. This alone should prove a big time-saver if you actually use them or a good reference if you compare them to what you've already created.
These government documents are not copyrighted, nor are the configuration files provided with some of them. The agencies request that you acknowledge the source if you use the documents or files, and they disavow any responsibility if you apply them incorrectly or if they contain errors.