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.

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.

NIST, with sponsorship from the Cybersecurity & Infrastructure Security Agency (CISA), has produced Special Publication 800-70 Rev 4: National Checklist Program for IT Products – Guidelines 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:

• 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.

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.

For specific information on creating and submitting a new or existing checklist, 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 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.