A security configuration checklist (sometimes referred to as a lockdown guide, hardening guide, or benchmark configuration) is essentially a document that contains instructions or procedures for configuring an IT product to a baseline level of security. Checklists can be developed not only by IT vendors, but also by consortia, academia, and industry, Federal agencies and other governmental organizations, and others in the public and private sectors. A checklist might include any of the following:
Not all instructions in a security configuration checklist need to be for security settings. Checklists can also include administrative practices for an IT product that go hand-in-hand with improvements to the product's security. Often, successful attacks on systems are the direct result of poor administrative practices such as not changing default passwords or failure to apply new patches.
There are many threats to users' computers, ranging from remotely launched network service exploits to malicious code spread through e-mails, malicious web sites, and file downloads. Vulnerabilities in IT products are discovered on an almost daily basis, and many ready-to-use exploits are widely available on the Internet. Because IT products are often intended for a wide variety of audiences, restrictive security controls are usually not enabled by default, so many IT products are immediately vulnerable out-of-the-box. It is a complicated, arduous, and time-consuming task for even experienced system administrators to identify a reasonable set of security settings for many IT products.
While the solutions to IT security are complex, one basic yet effective tool is the security configuration checklist. To facilitate the development of security configuration checklists and to meet the requirements of the Cyber Security Act, NIST has developed a program to (a) provide vendors and other groups with guidance for developing standardized, high-quality checklists to secure IT products, (b) establish a formal framework for the submission of checklists to NIST, and (c) assist users by making available a checklist repository.
Some of the benefits that organizations and individuals can achieve by using checklists are as follows:
While the use of security configuration checklists can greatly improve overall levels of security in organizations, no checklist can permit a system or a product to become 100% secure. However, use of checklists that emphasize hardening of systems against flaws or bugs inherent in software will typically result in greater levels of product security and protection from future threats.
NIST, with sponsorship from the Department of Homeland Security (DHS), has produced Special Publication 800-70: Security Configuration Checklists Program for IT Products - Guidance for Checklist Users and Developers to facilitate the development and dissemination of security configuration checklists so that organizations and individual users can better secure their IT products.
This publication is intended for users and developers of IT product security configuration checklists. For checklist users, this document gives an overview of the NIST Checklist Program, explains how to retrieve checklists from NIST's repository, and provides general information about threat models and baseline technical security policies for associated operational environments. For checklist developers, the document sets forth the policies, procedures, and general requirements for participation in the NIST Checklist Program.
Many organizations have created various checklists; however, these checklists may vary widely in terms of quality and usability, and may have become outdated as software updates and upgrades have been released. Because there is no central checklist repository, they can be difficult to find. They may not be well documented with the result being that one checklist may differ significantly from another in terms of the level of security provided. It may be difficult to determine if the checklist is current, or how the checklist should be implemented. While many existing checklists are of high quality and quite usable , the majority of checklists aren't accessible or directly usable by most audiences. Consequently, the goals of the NIST program are:
NIST's program also serves to assist vendors in the process of making their checklists available to users out-of-the-box. In such cases, it will still be advisable for product users to consult the NIST checklist repository for updates to pre-installed checklists.
The Cyber Security Research and Development Act of 2002 (Public Law 107-305) tasks NIST to develop, and revise as necessary, a checklist setting forth settings and option selections that minimize the security risks associated with each computer hardware or software system that is, or is likely to become widely used within the Federal Government. In addition, the Common Configuration Working Group Report of the Technical Standards and Common Criteria Task Force, formed at the Department of Homeland Security's first National Cyber Security Summit in 2003, recommended government promotion of the use of a NIST central repository for IT security configuration checklists. In response, this document has been developed by NIST in furtherance of its statutory responsibilities under the Cyber Security Act as well as the Federal Information Security Management Act (FISMA) of 2002 (Public Law 107-347).
The key IT product technology areas include: operating systems, database systems, web servers, e-mail servers, firewalls, routers, intrusion detection systems, file private Networks, biometric devices, smart cards, mobile devices (e.g., PDAs), multi-purpose devices, telecommunication switching devices, and web browsers.
The NIST checklist repository contains checklists that have been developed and screened to meet the requirements of the program. Users will be able to browse the checklist descriptions to locate and retrieve a particular checklist using a variety of different fields.
NIST has produced checklists for Microsoft Windows 2000 and XP Professional, available at http://csrc.nist.gov/itsec. NIST is currently working with other checklist-producing organizations and IT product vendors to include their checklists in the planned NIST repository, including those available from the Defense Information Systems Agency (DISA), the National Security Agency (NSA) and the Center for Internet Security (CIS).
Ideally, product vendors will create checklists as they release new products. The vendor is often in the best position to create the checklists, however in some cases 3rd-party checklists could be submitted, such as from recognized security groups, state governments, and corporations. The Microsoft Windows XP templates included with the NIST Windows XP System Administration Guidance Special Publication represents an example of consensus settings by a 3rd-party working group. NIST's program will also work in conjunction with other agencies and IT prodcut vendors to develop and disseminate security configuration checklists for IT products.
The NIST program identifies several broad and specialized operational environments, any one of which should be common to most audiences. By identifying and describing these environments, developers can better target their checklists to the general security baselines associated with the environments. End-users can better select the checklists that are most appropriate for their operating environments. The operational environments are as follows:
Almost never. The Specialized Security-Limited Functionality checklists generally reduce the functionality of products and are recommended only for specialized environments. Home users or users that require maximum functionality of a product will find that Specialized Security-Limited Functionality checklists will cause applications to break. For example, applying a Specialized Security-Limited Functionality checklist to a desktop operating system would likely cause installed applications such as home productivity software and games to cease working.
For specific information on creating and submitting a new or existing checkling, see the FAQ for vendors and checklist developers.
The NIST Checklist Program provides a lifecycle process and guidance for developing checklists in a consistent fashion. For checklist developers, steps include the initial development of the checklist, checklist testing, documenting the checklist according to the guidelines of the program, and submitting a checklist package to NIST. NIST then screens the checklist according to program requirements prior to a public review of the checklist, which typically lasts 30 to 60 days. After the public review period and any subsequent issue resolution, it will be listed on the NISTchecklist repository with a detailed description. NIST will periodically ask checklist developers to review their checklists and provide updates as necessary. NIST will retire or archive checklists as they become outdated or incorrect.
After the checklist information is submitted to NIST, NIST will screen the checklist for adherence to the development criteria and format. After addressing any issues with the checklist submitter, NIST will post the checklist for public review. Issues raised during the review will be addressed by the producer. After all issues are addressed satisfactorily, the checklist or checklist description will be posted on the NIST checklist repository.
Checklist submitters will be responsible for maintaining their associated checklists when new versions of the products appear. When the final checklist is listed, NIST will set a periodic review schedule with the developer. Typically, the timeframe for the review will be one year; however, it could be sooner depending on certain factors such as the discovery of new vulnerabilities. If the developer decides to update the checklist, NIST will announce that the checklist is in the process of being updated. If the checklist contains major changes, it will be accepted as if it were a new submission; it must undergo the same reviews as a new submission.
FISMA (section 3544(b)(2)(D)(iii)) requires each agency to determine minimally acceptable system configuration requirements and ensure compliance with them. Accordingly, Federal agencies, as well as vendors of products for the Federal government, are encouraged to acquire or develop and share such checklists using the NIST repository. The development and sharing of these checklists can greatly reduce what would otherwise be a reinvention of the wheel for IT products that are widely used in the Federal government, e.g., common operating systems and office applications.
The National Information Assurance Partnership (NIAP) is independent of the IT security checklists program. NIAP includes a formal testing program requiring vendors to submit their products to validated testing laboratories. The checklist program has less overhead and expense for vendors, however ever it does not contain the same formal testing benefits as with NIAP.
Checklist producers, e.g., vendors, will be able to use a checklist program logo on product literature or websites to show participation in the NIST program and ownership of a checklist on the repository. To use the logo, the producer must provide checklist-related assistance. The logo does not convey NIST endorsement of the checklist or IT product.
Please send comments if your questions were not answered here.