NIST Special Publication (SP) 800-53, titled “Security and Privacy Controls for Federal Information Systems and Organizations,” is commonly referred to as the “Control Catalog”. This is because 800-53 primarily provides guidelines for selecting and specifying security controls for organizations to protect their information and systems from a diverse set of threats including cyber attacks, natural disasters, privacy risks and human errors. It is the spiritual sibling to NIST 800-37, aka the Risk Management Framework (RMF); it provides the specific controls that organizations can utilize in order to fulfill the risk management program that is developed by following the RMF process.
Beginning in 2013 with the publication of the fourth revision (Rev 4) of NIST 800-53, software supply chain security was informally addressed in these federal information security requirements documents. It wasn’t until 2018 when the second revision of the RMF (NIST 800-37 Rev 2) was published that software supply chain security was prominently highlighted. Two years later in 2020, software supply chain security was codified into its own family of controls with the latest major update to the Control Catalog (NIST 800-53 Rev 5).
Two major technological trends have led to NIST prioritizing and highlighting software supply chain security in its latest revisions. The first is the rise of open source software and how these composable legos of software can be glued together to create more powerful software faster. The second is the rise of the containers as the abstraction of choice for composing applications from the open source software components.
Anchore has developed secure software supply chain systems that are focused precisely on solving the complexity that has evolved from these two trends. Having a robust and performant system to produce a full catalog of open source software components as well as a way to manage cloud-native deployment patterns (i.e. containers paired with CI/CD build systems) has allowed Anchore to help numerous federal agencies achieve compliance objectives like NIST 800-53. Over these engagements Anchore has developed significant expertise in how to meet the requirements of these frameworks in the least burdensome and most efficient manner.
NIST 800-53, colloquially known as the Control Catalog, is a security standard and compliance framework for all U.S. federal information systems and any enterprises that want to provide their cloud hosted services to a federal agency that stores classified data. It is tied very closely to NIST 800-37, the Risk Management Framework. Both are normally considered together and not separately. It is published by the National Institute of Standards in Technology (NIST) as a catalog of specific security controls that organizations can use to evaluate their own implementation of security controls to assess compliance with the standard. It currently has 5 revisions.
This is an important standard for both federal agencies and any cloud service providers that want to do business with federal agencies. While compliance with NIST 800-53 is not directly equivalent to FedRAMP authorization, it did heavily influence FedRAMP requirements. If you are compliant with NIST 800-53, you are well on your way to FedRAMP compliance. NIST 800-53 is both comprehensive and general enough that it is a good foundation for not only federal compliance standards like FedRAMP and continuous authority to operate (cATO) but is highly transferable to health and commercial compliance standards like HIPAA and PCI DSS.
NIST 800-53 has five revisions to-date, with the most recent published in January 2022. We’ll provide an overview of each here, starting with the most recent revision:
NIST SP 800-53, titled “Security and Privacy Controls for Federal Information Systems and Organizations,” is the 5th revision of the document and was published September 2020.
The largest changes made in this revision was the relocation of the catalog (i.e. spreadsheet) of controls to a separate document NIST SP 800-53B and the establishment of a supply chain risk management family of controls.
This second major update is of particular importance since this is what Anchore specializes in and have been helping agencies accomplish for years.
If you’d like to read the entire revision in full, you can find it here.
NIST SP 800-53, titled the same as revision 5 “Security and Privacy Controls for Federal Information Systems and Organizations,” is the 4th revision of the document and was published April 2013.
This revision was meant to address the substantial changes in the threat landscape since the previous revision that was published in 2009. Supply chain security was addressed in this revision but it wasn’t broken out into its own distinct family of controls until revision 5.
The other major change to this revision was the incorporation of controls focused on privacy. This document was primarily intended as a document focused on security previously.
If you’d like to read the entire revision in full, you can find it here.
NIST SP 800-53 revision 1-3 are all roughly the same document with minor updates between each. The final revision is titled, “Recommended Security Controls for Federal Information Systems and Organizations“. Across the three revisions only the word “organizations” is added to the title. Revision 1 was published in December 2006, followed a year later by revision 2 in December 2007. The final revision was published in August 2009.
Later revisions of NIST 800-53 (e.g. revision 4 & 5) update the document via a system of re-publishing the same revision with Errata for minor updates. The original three revisions updated the revision number even though the differences between the three can be thought of as iterative updates to the same general document.
The purpose of this series of documents was to more clearly define the specific controls that would help organizations comply with the control families that were defined in Federal Information Processing Standards (FIPS) 199 and 200 which ultimately fulfill the mandate of the original Federal Information Security Management Act (FISMA) of 2002 law.
NIST 800-53 contains 20 control families with a total of more than 1,000 individual controls. A control family is a group of related security controls. The term “control family” is used to organize the security controls in a manner that makes them easier to reference and manage. Each control family typically covers a particular aspect of information security, such as access control, incident response, or system and information integrity. Below is a list of each of the 20 control families as well as a short description:
Controls that limit access to information systems and the information they process and store based on the principle of least privilege. Access controls can be both technical (such as logins and passwords) and physical (such as locked doors).
Controls that aim to ensure that individuals within the organization are adequately trained and informed about security risks and their responsibilities towards mitigating those risks.
Controls that record and examine activity in information systems to detect and respond to security incidents.
Controls that deal with the initial authorization to operate the system and ongoing monitoring of security controls.
Controls that focus on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing, and monitoring the configurations.
Controls that focus on planning for, responding to, and recovering from system or service interruptions.
Controls that ensure the identity of an entity (a user or a system) is verified before access is granted.
Controls that establish the capability to respond to, manage, report, and learn from information system incidents.
Controls that involve the routine, periodic, or emergency maintenance of information systems, including any potential security impacts.
Controls that protect information in print or electronic format from unauthorized access, disclosure, alteration, and destruction.
Controls that provide measures to safeguard physical resources and support facilities of an information system.
Controls that involve system security plans, rules of behavior, and more to guide the implementation and operation of the information system.
Controls that ensure trustworthiness and appropriate training for roles and responsibilities for individuals having access to the system.
Controls that guide the identification and assessment of risks to organizational operations, assets, or individuals.
Controls that address the life cycle of information systems, including system development, system integration, and outsourcing decisions.
Controls that protect the integrity of transmissions and information flows in information systems.
Controls that protect the integrity of information and information systems by protecting against malware, providing intrusion alerts, and ensuring information input and output integrity.
A control family added in Revision 5 that deals with reducing the risk that an adversary will exploit vulnerabilities in the system’s supply chain.
Controls that provide a strategic view of the organization’s information security program. This family is not applicable to individual information systems.
An additional control family introduced in Revision 5, reflecting the need for privacy considerations in systems that handle personally identifiable information.
Like we mentioned, there are more than 1,000 controls put forth by NIST 800-53. We won’t list them all, but we will highlight one to help turn these general ideas into more specific examples:
Let’s examine control SR-4(2) “Provenance | Track and Trace”. This control states an agency must:
Establish and maintain unique identification of the following systems and critical system components for tracking through the supply chain.
For software systems specifically this means that there must be a unique identification for each individual software component/framework/library that is used to build an application.
The discussion uses the examples of labels or tags as a general method for achieving this control:
Labels and tags can help provide better visibility into the provenance of a system or system component…[i]dentification methods are sufficient to support a forensic investigation after a supply chain compromise or event.
The important point here is that the label or tag “support a forensic investigation after a supply chain compromise or event”. This can be implemented in many different ways but the open source software security industry has quickly come to the consensus that Software Bill of Materials (SBOMs) are the preferred method for satisfying this control. SBOMs allow agencies to reliably produce unique identifiers with accompanying metadata that allow for forensic analysis in the event of a supply chain compromise.
Anchore Enterprise was purpose built with this control in mind. It helps agencies to manage their SBOMs. Organizations are able to complete remediation activities within hours rather than the industry standard of days.
As mentioned above, there are more than 1,000 different controls. Attempting to accurately apply all of these controls is easily a full-time job and likely a multi-year project.
View the full Control Catalog spreadsheet from NIST here.
You can find many NIST 800-53 compliance checklists with a quick Google Search but all of these checklists are more like cliff notes than actual checklists. This is primarily because the one-two combo of the Risk Management Framework (NIST 800-37) and the Control Catalog (NIST 800-53) are straightforward guides to achieving compliance to both standards. Take a look at the 7 primary sections of the RMF below:
If those titles read like a checklist for how to reach NIST 800-37/53 compliance it’s because they were designed as a checklist to reach NIST 800-37/53 compliance. If you’re interested in understanding the RMF in more detail, we have written a guide to the NIST SP 800-37, the Risk Management Framework in plain english on our website.
With so many security standards published by various groups and government organizations around the world, we’re outlining how NIST 800-53 stacks up.
The primary difference between NIST SP 800-171 and 800-53 is the number of control families, the number of controls and the target audience of the standards.
The security requirements in NIST 800-171 are derived from the moderate control baseline of NIST 800-53 which makes NIST 800-171 a subset of NIST 800-53 with some modifications applied to the individual controls that effectively makes them easier to achieve. The reason for this is because these organizations only handle Controlled Unclassified Information (CUI) which is not classified but still considered sensitive or private. You can think of CUI as Personally Identifiable Information (PII) with some additions like proprietary business information, law enforcement information or information that could affect national security.
The control families that have been removed from NIST 800-171 are:
ISO 27001 is an international standard on how to manage information security. It is very similar in scope to NIST 800-53 but its scope is for any global organization rather than being US-centric. Published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), the standard is formally known as “ISO/IEC 27001:2013 – Information technology – Security techniques – Information security management systems – Requirements“
ISO 27001 is more similar to NIST 800-37, the RMF, in that it is a framework and high-level guidance for managing information security in an organization. The detailed controls are laid out in ISO/IEC 27002 which accomplishes roughly the same objective as NIST 800-53.
The RMF (NIST 800-37) and the Control Catalog (NIST 800-53) are very comprehensive and extraordinarily intimidating. As agencies are determining whether to accomplish meeting these compliance standards, they have to decide whether to DIY the entire process or work with 3rd party vendors that are experts in the process.
Anchore, in partnership with its many federal service integrator (FSI) partners, has sheparded countless agencies through this process with its NIST compliance solutions. Anchore provides a number of different features that not only make meeting controls simple but automate the continuous process of maintaining compliance in real-time.
The Anchore Enterprise platform was specifically designed to address the software security supply chain management of federal agencies. The platform is an automated system that manages a comprehensive inventory of the entire software supply chain, automatically scans all software packages for vulnerabilities and compliance and utilizes pre-built policy packs to report and ensure compliance standards are met.
If you’re interested to learn more about how Anchore can help your organization meet its compliance requirements, learn more by visiting our public sector page.