Security Configuration Checklists
For IT Products Program

Checklist Description

Version 2.0

Organization

IT Product & Version

Checklist Name & Version

Date

Please complete the following information and return this document to:
checklists@nist.gov.  

Field Name	Description	Example Data	
Checklist Name	The name of the checklist.		
Checklist ID	Uniquely identifies the checklist in the NCP repository.  This will be generated during the NCP submission process and assigned to the checklist.	Will be populated by NIST.	
Version	The version or release number of the checklist.		
Review Status	The status of the checklist within the internal NCP review process. A status of "Final" signifies that NCP has reviewed the checklist and has accepted it for publication within the program.  Possible status options are:  Candidate, Final, Archived, or Under Review.	Will be populated by NIST.	
Entry Date	States the date when the checklist record was first listed in the NCP repository, in the format MM/DD/YYYY.	Will be populated by NIST.	
Publication Date
	States the date when the actual checklist document was published, in the format MM/DD/YYYY.		
Last Modified Date	States the date when the checklist record was last revised within the NCP repository, in the format MM/DD/YYYY.	Will be populated by NIST.	
Product Category	The main product category of the IT product (e.g., firewall, IDS, operating system, web server).		
Target Product(s)	The set of specific IT systems or applications that the checklist provides guidance for.		
CPE Name	The CPE representation of a specific Target Product.		
Checklist Role	The primary use or function of the IT product as described by the checklist (e.g., client desktop host, web server, bastion host, network border protection, intrusion detection).		
Tier	The checklist tier (Tier I, II, III, or IV).
•	Tier I checklists are prose-based, such as narrative descriptions of how a person can manually alter a product’s configuration.
•	Tier II checklists document their recommended security settings in a machine-readable but non-standard format, such as a proprietary format or a product-specific configuration script.  These checklists may include some elements of SCAP (for example, they may contain CCE identifiers), but do not meet the Tier III requirements.
•	Tier III checklists use SCAP to document their recommended security settings in machine-readable standardized SCAP formats that meet the definition of “SCAP Expressed” specified in NIST SP 800-126 [29]. Tier III checklists can be processed by SCAP-validated tools, which are products that have been validated by an accredited independent testing laboratory as conforming to applicable SCAP specifications and requirements.  
•	Tier IV checklists include all properties of Tier III checklists. Additionally, Tier IV checklists are considered production-ready and have been validated by NIST or a NIST-recognized authoritative entity to ensure, to the maximum extent possible, interoperability with SCAP-validated products. Tier IV checklists also demonstrate the ability to map low-level security settings (for example, standardized identifiers for individual security configuration issues) to high-level security requirements as represented in various security frameworks (e.g., SP 800-53 controls for FISMA), and the mappings have been vetted with the appropriate authority.		
SCAP Expressed	Checklists that are designed to be processed by SCAP-validated products.  For more details regarding the definition of SCAP Expressed, see NIST SP 800-126 [29].		
XCCDF Expressed	Whether the checklist is expressed in XCCDF (yes or no). If yes, the checklist is expressed in XCCDF and validates against the published version of the XCCDF schema. The checklist also validates against the NIST-provided XCCDF reference implementation.		
CCE Expressed	Whether the checklist has valid CCEs (yes or no). If yes, each configuration setting has an associated CCE.		
CPE Expressed	Whether the checklist has valid CPEs (yes or no). If yes, the checklist expresses its applicability to systems using CPE.		
CVE Expressed	Whether the checklist has valid CVEs (yes or no). If yes, each software flaw and patch has an associated CVE or CVEs.		
CVSS Expressed	Whether the checklist has valid CVSSs (yes or no). If yes, each CVE identifier has an associated CVSS base score.		
OVAL Expressed	Whether the checklist is expressed in OVAL (yes or no). If yes, each OVAL definition must validate according to the OVAL reference implementation.		
Checklist Summary	Summarizes the purpose of the checklist and its settings.		
Known Issues	Summarizes issues that may arise after application of the checklist to help users pinpoint any functional and operational problems caused by the checklist.		
Target Audience	The intended audience that should be able to install, test, and use the checklist, including suggested minimum skills and knowledge required to correctly use the checklist.		
Target Operational Environment	The IT product’s operational environment, such as Standalone, Managed, or Custom (with description, such as Specialized Security-Limited Functionality, Legacy, or Federal Desktop Core Configuration).		
Checklist Installation Tools	Describes the functional tools required to use the checklist to configure the system, if they are not included with the checklist.		
Rollback Capability	Whether the changes in product configuration made by applying the checklist can be rolled back and, if so, how to roll back the changes.		
Testing Information	Platforms on which the checklist was tested. Can include any additional testing-related information such as summary of testing procedures used. Should specify any operational testing performed in production or mirrored production environments.		
FIPS 140-2 Compliance	Whether the product can operate in a FIPS 140-2 validated mode (yes or no).		
FIPS 140-2 Compliance Verification	Whether the checklist enumerates the required settings which must be configured on a product for the product to be FIPS 140-2 compliant.  		
Regulatory Compliance	Whether the checklist is consistent with various regulations (e.g., Health information Portability and Accountability Act [HIPAA], Gramm-Leach-Bliley Act [GLBA], FISMA [such as mappings to NIST SP 800-53 controls], ISO 27001, Sarbanes-Oxley, Department of Defense [DoD] 8500).		
Comments, Warnings, Miscellaneous	Any additional information that the checklist developer wishes to convey to users.		
Disclaimer	Legal notice pertaining to the checklist.	
	
Product Support	Vendor will accept support calls from users who have applied this checklist on their IT product; warranty for the IT product has not been affected. Required for usage of NCP logo if the submitter is the product vendor. If the submitter is not the product vendor, the submitter should describe any agreement that they may have with the product vendor.		
Authority 	The organization responsible for producing the original security configuration guidance represented by the checklist. Authorities are ranked according to their “Authority Type.” Within the NCP website, authorities are grouped with their authority types through the syntax of Authority Type: Authority. 
If it is not clear which checklists(s) should be analyzed, users from Federal civilian agencies should first search for checklists produced by authorities of type “Governmental Authority.” If “Governmental Authority” produced checklists exist, the user should search for NIST-produced checklists, which are tailored for civilian agency use. If no NIST-produced checklist is available, then agency-produced checklists from the Defense Information Systems Agency (DISA) or the National Security Agency (NSA) should be used. If no “Governmental Authority” checklists exist, the user should search for checklists produced by authorities of type “Software Vendor.” If none of these checklists exist, the user should search for checklists produced by authorities of type “Third Party.” 		
Author 	The organization responsible for creating the checklist in its current format. In most cases an organization will represent both the author and authority of a checklist, but this is not always true. For example, if an organization produces validated SCAP content for NIST SP 800-68, the organization that created the SCAP content will be listed as the Author, but NIST will remain the Authority. 		
Authority Type 	Type of organization that lends its authority to the checklist. The three types are Governmental Authority, Software Vendor, and Third Party (e.g., security organizations). 		
Point of Contact 	An email address where questions, comments, suggestions, and problem reports can be sent in reference to the checklist. The point of contact should be an email address that the checklist developer monitors for checklist problem reports. 		
Sponsor 	States the name of the IT product manufacturer organization and individuals who sponsor the submitted checklist if it is submitted by a third-party entity. 		
Licensing 	States the license agreement (e.g., the checklist is copyrighted, open source, General Public License [GPL], free software, shareware). 		
SCAP Content 	A link to the machine-readable content representing the configuration guidance. This guidance is expressed using SCAP. 	 	
Supporting Resource 	A link to any supporting information, or content, relating to the guidance. This field can hold data ranging from an English prose representation of the actual guidance, to configuration scripts that apply guidance specific settings on a target product. 		
Resource Description 	A prose description of the resource. 		
Resource Type 	The format of the resource. Examples include SCAP content, prose, GPOs, security templates, etc. 		
SHA-1 	The SHA-1 hash for the resource. 		
SHA-256 	The SHA-256 hash for the resource. 		
Change History 	Running log detailing any changes made to the checklist since its inclusion in the repository. This field is updated with each version of the checklist. 		
Dependency/ Requirement 	Indicate that another checklist or guide is required to properly use and implement the current checklist. 		
References 	Any supporting references chosen by the developer that were used to produce the checklist or checklist documentation.