National Checklist Program

FAQ for General Users

1. What is a security checklist?
2. Why use security configuration checklists?
3. What is the Special Publication 800-70?
4. What is the motivation behind the NIST program?
5. What legislation is the NIST program in response to?
6. What technologies is the NIST program targetting?
7. What is the checklist repository and when will it be available?
8. What checklists are available currently?
9. Who creates the security checklists listed by the NIST program?
10. What are the program's operational environments?
11. Should home or enterprise users apply the Specialized Security-Limited Functionality checklists?
12. How do you create and submit a checklist?
13. What process does NIST follow to list the checklists?
14. Who will maintain the checklists?
15. How does this help agencies in meeting FISMA-related requirements?
16. Is there any relationship with the NIAP?
17. What is the checklist program logo?

1. What is a security checklist?
   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:
   
   
   • Configuration files that automatically set various security settings (e.g., executables, security templates that modify settings, scripts)
   • Documentation (e.g., text file) that guides the checklist user to manually configure software
   • Documents that explain the recommended methods to securely install and configure a device
   • Policy documents that set forth guidelines for such things as auditing, authentication security (e.g., passwords), and perimeter security
   
   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.



2. Why use security configuration checklists?
   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:
   
   
   • Providing a baseline level of security to protect against common and dangerous local and remote threats and a consistent approach to securing systems
   • Significantly reducing the time required to research and develop appropriate security configurations for installed IT products
   • Allowing smaller organizations to leverage outside resources to implement recommended practice security configurations
   • Preventing public loss of confidence or embarrassment due to compromise of publicly accessible systems.
   
   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.



3. What is the Special Publication 800-70?
   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.
   
   
4. What is the motivation behind the NIST 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:
   
   
   • To facilitate the development and sharing of security configuration checklists by providing a framework for developers to submit checklists to NIST
   • To assist developers in making checklists that conform to common operational environments and associated baseline levels of security
   • To assist developers and users by providing guidelines for making checklists better documented and more usable
   • To provide a managed process for the review, update, and maintenance of checklists
   • To provide an easy-to-use repository of checklists.
   
   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.



5. What legislation is the NIST program in response to?
   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).
   
   
6. What technologies is the NIST program targetting?
   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.



7. What is the checklist repository and when will it be available?
   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, including the following:
   
   
   • SCAP Checklists: Checklists in this category conform to the Security Content Automation Protocol (SCAP). SCAP enables validated security tools to perform automatic configuration checking using NCP checklists within this category.
   • FDCC Checklists: This category contains OMB Federal Desktop Core Configuration checklists provided using the Security Content Automation Protocol (SCAP) format. These are to be used with SCAP validated tools).
   • Product Category: The checklists are listed by the main product category of the IT product, e.g. firewall, IDS, operating system, web server, etc.
   • Vendor: The checklists are listed by the manufacturer of the IT product.
   • Submitting Organization The name of the organization and authors that produce the checklist.
   
   
8. What checklists are currently available?
   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).
   
   
9. Who creates the security checklists listed by the NIST program?
   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.
   
   
10. What are the program's operational environments?
    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:
    
    
    • Standalone or Small Office/Home Office (SOHO) describes small, informal computer installations that are used for home or business purposes. Standalone encompasses a variety of small-scale environments and devices, ranging from laptops, mobile devices, or home computers, to telecommuting systems, to small businesses and small branch offices of a company.
    • Managed or Enterprise are typically large organizational systems with defined, organized suites of hardware and software configurations, usually consisting of centrally-managed workstations and servers protected from the Internet by firewalls and other network security devices.
    • Custom environments contain systems in which the functionality and degree of security do not fit the other environments. Two typical Custom environments are Specialized Security-Limited Functionality and Legacy:
      • Specialized Security-Limited Functionality: A Specialized Security-Limited Functionality environment contains systems and networks at high risk of attack or data exposure, with security taking precedence over functionality. It assumes systems have limited or specialized (not general purpose workstations or systems) functionality in a highly threatened environment such as an outward facing firewall or public web server or whose data content or mission purpose is of such value that aggressive trade-offs in favor of security outweigh the potential negative consequences to other useful system attributes such as legacy applications or interoperability with other systems. Checklists for this environment are not recommended for home users or for large scale general purpose systems. A Specialized Security-Limited Functionality environment could be a subset of another environment.
      • Legacy: A Legacy environment contains older systems or applications that may use older, less-secure communication mechanisms. Other machines operating in a Legacy environment may need less restrictive security settings so that they can communicate with legacy systems and applications. A Legacy environment could be a subset of a Standalone or Managed environment.
    
    
11. Should home users apply the Specialized Security-Limited Functionality checklists?
    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.



12. How do you create and submit a checklist?
    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 NIST checklist repository (http://nvd.nist.gov/ncp.cfm?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.
    
    
13. What process does NIST follow to list the checklists?
    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.
    
    
14. Who will maintain the checklists?
    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.



15. How does this help agencies in meeting FISMA-related requirements?
    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.
    
    
16. Is there any relationship with the NIAP?
    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.
    
    
17. 17. What is the checklist program logo?
    
    
    
    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.