Five takeaways from NIST SP 800-70 update
National Checklist Program for IT Products: Guidelines for Checklist Users and Developers
Revision 5 of NIST SP 800-70 on the National Checklist Program (NCP) for IT Products is out for public comment through January 16. NIST’s announcement summarizes the high-level changes from Revision 4 to Revision 5.
To help public comment reviewers and anyone else interested in the details of the changes, we’ve done a side-by-side comparison of the revisions and identified the five most significant takeaways. We encourage you to do your own review of 800-70 rev 5 (and submit your own public comments!) But the takeaways will give you a jump start.
Takeaway 1: New appendix on CSF 2.0 automation
This appendix is a welcome addition to the document, as it connects multiple NIST-offered tools together to provide value to users. Appendix C contains information on how Common Configuration Enumeration (CCE) content and other SCAP content can be connected to SP 800-53 controls, which then can be connected to NIST CSF 2.0 Subcategories through the Online Informative References (OLIR). This traceability connects the server room and the boardroom and allows for organizations to use a data-driven approach to informing cybersecurity risk management.
It is important to note the direction of this relationship. If you start at the NCP content, and work “up the mapping chain,” you are guaranteed to achieve SOME Subcategories. By simply selecting a CSF Subcategory and working “down the mapping chain,” you may or may not find content that is related to your organization’s cybersecurity risk management activities. This phenomenon stems from the overall mapping approaches. It is critical to verify your cybersecurity risk management processes from both a top-down and bottom-up perspective to ensure an effective and efficient program.
Takeaway 2: New content on CCE identifiers
In addition to the CCE content in the new Appendix C, Section 5.4 contains new content encouraging the creation of CCE identifiers:
“Checklist developers are encouraged to contact NIST at cce@nist.gov to be assigned a set of CCE identifiers (i.e., globally unique identifiers) for their configuration settings. Although CCE is often associated with SCAP content, it can also be used apart to ensure globally unique identification for individual security settings in a checklist. See Appendix C regarding the use of CCEs to demonstrate connected paths from requirements to actual settings on the IT product.”
Takeaway 3: Refined definition of “security configuration checklist”
The rev 5 abstract states (with italics added by us for clarity), “A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product.”
Adding “technical content” reinforces the concept that a checklist doesn’t have to be a document; it can be a script or other machine-readable content, for example.
Adding “securely” emphasizes that the main purpose of these checklists is to improve security. Many configuration settings do not affect security, so this addition indicates that checklists not affecting security are out of scope.
Adding “risk tolerance” indicates a philosophical shift from configuring based on what type of environment needs secured, to configuring based on the risk the organization faces and how the organization has chosen to handle that risk.
Note that this definition is different from the one in the rev 5 glossary and elsewhere in rev 5. We will be noting this in the detailed public comments we will be submitting to NIST, and we will be encouraging NIST to adopt this refined definition throughout rev 5.
Takeaway 4: Removal of the United States Government custom environment and USGCB
The United States Government custom environment and the USGCB (United States Government Configuration Baseline) were established nearly 20 years ago to identify security configuration settings for federal agency use of Windows and Internet Explorer. With the USGCB no longer active, it was time to remove these mentions from 800-70. See NIST’s USGCB FAQ for more information on the history of USGCB.
Takeaway 5: Demotion of SCAP mentions
Previous versions of 800-70 had many mentions of SCAP (the Secure Content Automation Protocol) because it was the predominant form of checklists at that time. SCAP is still in widespread use, and NIST recently released an update to the SCAP specification, but today there are many other widely used forms of checklists. Accordingly, 800-70 rev 5 has demoted mentions of SCAP to being examples of automated content. Rev 5 also adds similar mentions of NIST’s macOS Security Compliance Project (mSCP) as examples.