NIST SP 800-37 risk management framework for information systems

What it is

NIST Special Publication 800-37 Revision 2 sets out the Risk Management Framework (RMF), the seven-step process the US National Institute of Standards and Technology built to bring security and privacy risk management for federal information systems and organizations into one repeatable framework. It is mandatory for federal government use; NIST wrote it so that "the RMF can be applied to any type of nonfederal organization" as well, on a voluntary basis, and FISMA and OMB policy separately require external providers that handle federal information or operate systems on the government's behalf to meet the same requirements as the agencies themselves. This is Revision 2, published December 2018.

Who it addresses, and how it binds

The document names its participants directly rather than describing a generic "organization." The authorizing official is the only person who can accept the security and privacy risk to the organization's operations and assets, and, for federal agencies, that role "is an inherent U.S. Government function and is assigned to government personnel only." The system owner, and, where controls are shared across systems, the common control provider, assemble the evidence and submit it for a decision. A control assessor, selected to a degree of independence the authorizing official sets, tests the implemented controls, and a senior agency official for privacy runs a parallel track for any system that handles personal information. A wider set of supporting roles, the chief information officer, the senior agency information security officer, the senior accountable official for risk management, enterprise, security and privacy architects, and the people who actually administer and use the system, recur throughout.

Because FISMA and OMB policy extend the same expectations to "external providers handling federal information or operating systems on behalf of the federal government," the framework also, in effect, addresses any contractor or cloud provider standing in that relationship to a federal agency. For those organizations it binds the way most federal requirements do: through the contract or agreement that brings the relationship into being, not by existing on its own.

Prepare, and the organization-level / system-level split

Prepare is the framework's foundational step, and it runs at two levels. At the organization level, done once rather than per system, an organization assigns its risk management roles, sets a risk management strategy and risk tolerance, runs an organization-wide risk assessment, identifies which controls it can provide centrally as common controls for other systems to inherit, and sets an organization-wide continuous monitoring strategy. At the system level, repeated for every system, Prepare identifies the mission the system supports, its stakeholders, the assets needing protection and, critically, the system's authorization boundary, "what the organization agrees to protect under its management control." Everything inside that boundary is this system's problem; everything outside it belongs to another system, or another organization's boundary entirely. The same system-level work continues through identifying the information types the system will process, a system-level risk assessment, defining security and privacy requirements, placing the system in the enterprise architecture, and registering it with the organization's management offices.

Categorize, Select, Implement and Assess

The system owner and the information owner or steward document the system's characteristics and categorize it, typically against FIPS 199 and FIPS 200's impact levels, before the authorizing official reviews and approves the result; a system spanning multiple impact levels takes the highest one that applies. Select draws controls from a pre-assembled baseline matched to that impact level, tailors them to the system's actual circumstances, and allocates them across the system and its operating environment, with the plan documented in security and privacy plans the authorizing official approves. Implement puts the controls in place and updates the documentation to describe the system as actually built. Assess is where an independent control assessor, working to whatever degree of independence the authorizing official has set, tests what was implemented and reports the results; for a system-level assessment the assessor does not retest controls the system inherits from a common control provider, only what the system implements itself. Deficiencies are either remediated and reassessed or carried forward in a documented plan of action and milestones.

Authorize and Monitor

The system owner or common control provider assembles an authorization package, an executive summary, the security and privacy plans, the assessment reports, and the plan of action and milestones, and submits it to the authorizing official, who analyzes the risk, decides how to respond, and then makes the authorization decision itself: an authorization to operate, a common control authorization, an authorization to use (typically where one organization relies on another's already-authorized system), or a denial where the risk cannot be brought down to an acceptable level in time. That specific decision cannot be delegated to the authorizing official's designated representative. Monitoring does not stop once a system is authorized: it begins at the start of operations and continues through disposal, tracking changes, running ongoing assessments that can double as the annual assessment FISMA itself calls for, and keeping the authorization package current. A defined set of event triggers, a new vulnerability, a significant change, a change of authorizing official, forces an immediate review. An organization whose continuous monitoring meets the required rigor can move a system onto ongoing authorization, where the authorizing official's current knowledge of the system substitutes for a fixed reauthorization date.

For systems that depend on an external provider's infrastructure, the framework lets an organization leverage the provider's own controls and assessment results, while cautioning that scope, rigor and assessor independence vary by provider and that organizations "should exercise caution" relying on them. One example the document names directly: a provisional authorization to operate issued under the Federal Risk and Authorization Management Program (FedRAMP) can be the basis a customer organization relies on for its own authorization to use a cloud system.

How authorization decisions are evaluated

Nobody is "NIST SP 800-37 certified." There is no certification against this document: it names no accredited certification body and describes no certification scheme. Conformity runs through the authorizing official's own risk-acceptance decision, recorded in an authorization decision document that sets out the decision, its terms and conditions, and either a termination date or an ongoing-authorization review frequency. Nothing here is issued by an outside body: it is one organization's own senior official accepting risk for a system that organization owns, and the decision does not transfer to another organization except where that organization deliberately relies on it, as a customer does when it issues its own authorization to use on the strength of a provider's existing authorization.

Standards it references

NIST SP 800-37 is built to work alongside a cluster of other NIST publications rather than stand alone. The control catalog the Select step draws from lives in the separate publication SP 800-53, whose companions SP 800-53B (baselines) and SP 800-53A (assessment procedures) support the Select and Assess steps respectively. FIPS 199 and FIPS 200 supply the impact levels Categorize applies. SP 800-39 supplies the organization, mission and system risk model the framework sits on; SP 800-30 the risk assessment methodology; SP 800-137 the continuous monitoring guidance. None of these is held separately in this catalogue.

Outside the NIST series, NIST publishes a mapping from its own control catalog to ISO/IEC 27001's security controls, and to ISO/IEC 15408-2 and 15408-3's Common Criteria security requirements. The document is explicit that the mapping is background reading, not an equivalence to rely on directly: it calls such mappings "inherently subjective" and expects an organization to review one itself before leaning on it.

Standards it references

• ISO/IEC 27001Background