The National Institute for Standards and Technology (NIST) publishes pioneering cybersecurity standards. In this blog, we look at two of their well known special publications (SP) and discuss:

How to derive CMMC Strategies from the RMF
NIST SP 800-53 Explained
NIST SP 800-171 Explained
Conclusion

How to derive CMMC Strategies from the RMF

This blog will explain the role SP 800-53 plays within the Risk Management Framework (RMF). Then, we explore how NIST SP 800-171 is a derivative of SP 800-53. TL;DR, so here are the key takeaways:

1. Use common controls where possible, especially in PE, PS, IR, IA, AU, AC families.

Implementing common controls is a more scalable approach to meeting security requirements. NIST SP 800-53 identifies a few control families to consider for common controls.

2. Use Appendix C from 800-53 to identify other potential common controls.

Another way to identify common controls is by evaluating Appendix C of NIST SP 800-53. This table suggests implementation methods for each SP 800-53 control. Those controls implemented at the organizational level are also candidates for common controls.

3. Use Appendix C from 800-53 to identify system-specific controls.

Controls implemented at the system component level may be system-specific controls. NIST SP 800-53 reduces the applicability of controls to the components that support the security function. Make sure the system security plan documents any applicability considerations. Also make sure you're documenting implementations for all applicable components of the system.

4. Consult FedRAMP Moderate specifications when asked to assign parameter values.

Both publications use the moderate impact level. Thus, the FedRAMP Moderate parameter values definitions are acceptable for NIST SP 800-171.

To leverage SP 800-53, you’ll need to crosswalk it to SP 800-171. A rudimentary crosswalk exists within SP 800-171. It compares them at the control-practice level. In doing so, some requirements map to many controls. We refined the crosswalk to map objectives from SP 800-171A to controls from SP 800-53. This will help facilitate the latter strategies discussed above.

NIST SP 800-53 Explained

NIST introduced SP 800-53 in 2005. The special publication provides guidelines for selecting security controls for federal information systems. There have been five major updates and the current version is revision 5.

NIST SP 800-53 is a catalog of security controls used in the risk management framework (RMF). The major steps and supporting publications from the RMF include:

Security Categorization - FIPS 199
Control Selection - NIST SP 800-53B
Implementation - NIST SP 800-53
Assessment - NIST SP 800-53A

Security Categorization

NIST published the Federal Information Processing Standard Publication 199 (FIPS 199) in 2004. FIPS 199 is a result of the Federal Information Security Management Act of 2002 (FISMA). FISMA tasked NIST to develop standards that categorized information, systems and security requirements.

FISMA defined three security objectives for information and information systems:

Confidentiality - preserving unauthorized disclosure
Integrity - guarding against improper modification or destruction
Availability - ensuring timely and reliable access to information

FIPS 199 defined three levels of impact based on a breach of these security objectives:

Low - limited adverse effect defined as:

Noticeable degradation in the performance of primary functions
Minor damage to assets, financial loss, or harm to individuals

Moderate - serious adverse effect defined as:

Significant reduction in the performance of primary functions
Significant damage to assets, financial loss, or harm to individuals

High - severe or catastrophic adverse effect defined as:

Severe degradation in performance or inability to perform primary functions
Major damage to assets, financial loss, life threatening injuries or loss of life

These categories are first applied to types of information for each security objective.

Information types contained within a system determine the categorization of the system. The value is the highest value from those resident on the system (high water mark).

Control Selection

After categorizing a system, NIST SP 800-53B identifies a baseline set of controls. There are three security baselines (Low, Moderate, and High). A fourth baseline assigns privacy controls. The privacy baseline addresses requirements related to protecting personally identifiable information (PII).

After selecting the baseline, organizations may tailor the controls to achieve cost-effective solutions. Organizations document rationale for tailoring in the system security and privacy plans.

Common Controls

Organizational systems may inherit common controls provided by another entity (internal or external). When inheriting a common control, there is no need to put the control in place within that system. Implementing common controls provides a standardized and scalable implementation approach.

Scoping Considerations

Controls in the baseline may not apply to every component in the system. Controls only apply to components that provide or support the function addressed by the control. NIST SP 800-53B outlines five types scoping considerations:

Operational and Environmental Considerations: Factors assumed to exist are absent or diverge from baseline assumptions.
Technology Considerations: References to specific technologies are only applicable to systems implementing those technologies.
Mission and Business Considerations: Controls that degrade or interfere with mission or business functions.
Security Objective Considerations: Organizations may downgrade controls that support only one or two security objectives. For example a control supports confidentiality but not integrity or availability. Downgrading involves selecting the corresponding control from a lower baseline. The organization may drop a control if it is not defined in a lower baseline.
Legal and Policy Considerations: Some requirements may only apply under specified circumstances.

Assigning Control Parameter Values

Many controls from NIST SP 800-53 contain organizationally-defined parameters (ODPs). Authorities or standards may specify the values of some of these parameters. For example, FedRAMP specifies SP 800-53 ODPs for cloud service provider (CSP) authorizations. The organization implementing the controls defines parameters not specified by an authority.

Capabilities

Satisfying security or privacy requirements often relies on a set of reinforcing controls. Conceptualizing capabilities simplifies the protection requirements for organizational missions and business functions.

Compensating Controls

Compensating controls should provide comparable protection for systems, organizations, and individuals. Organizations use compensating controls when baseline controls are not workable or cost effective.

Control Baselines

Section 3 provides tables of controls and enhancements for each baseline. Some controls and control enhancements are not assigned to any control baseline.

Supplementing Control Baselines

Non-baseline controls or enhancements may address specific threats. For example, insider threats and advanced persistent threats (APTs) target national security systems. The Committee on National Security Systems Instruction No. 1253 (CNSSI 1253) assigns extra security controls for all National Security Systems.

Implementation

NIST SP 800-53 organizes controls families with each having a unique two-character identifier.

NIST arranged the families alphabetically and numbered the controls. Neither order implies any logical progression or prioritization. Each control contains the following structure:

Control - prescribes a security or privacy capability
Discussion - provides more information about a control
Related controls - controls that impact or support a control or enhancement
Control enhancements - numbered sequentially within each control
Reference - list of authorizes and other useful resources

Some controls may also include organizationally-defined parameters to define specific implementation values.

Implementation Approaches

There are three approaches to implementing controls:

Common controls - implementation is inheritable by other systems or programs.

An entity other than the inheriting system implements and monitors the control. Controls from the following families are good candidates for common controls:

PE
PS
IR
IA
AU
AC

System-specific control - the implementation is the responsibility of the system owner.
Hybrid control - one part of the control is common and the other is system-specific.

The common control provider handles the common part of the control.
The system owner handles the system-specific part of the control.

Implementation & Assurance

Appendix C suggests the implementation approaches for controls and enhancements. This table specifies whether the implementation applies to system components or the organization. Organizations have the flexibility to choose their own implementation approaches. This table is helpful to identify common controls and system-specific controls.

Assurance is a measure of confidence that the system produces the desired outcome.. Appendix C also identifies controls that contribute to the achievement of a claim.

Assessment

NIST SP 800-53A facilitates control assessments. This publication provides a comprehensive set of procedures for assessing controls. Assessors are not expected to use all assessment methods and objects. The flexibility of the assessment framework allows organizations to tailor the procedures.

Building an Assurance Case

An assurance case consists of evidence that the controls produce the desired outcome. Appendix C of SP 800-53A defines three assessment methods:

Examine - analyzing one or more assessment objects:

Specifications (policies, plans, procedures, system requirements, designs)
Mechanisms (functionality implemented in hardware, software, firmware)
Activities (system operations, administration, management, exercises)

Interview - discussions with individuals or groups

Test - exercising one or more objects under specified conditions:

Mechanisms (e.g. hardware, software, firmware)
Activities (e.e. System operations, administration, management, exercises)

Organizations can produce evidence from the operational environment. This includes remediation records, security incident reporting, and continuous monitoring activities. The depth and coverage of evidence can also affect the level of assurance. The assessment plan specifies the attribute values for depth and coverage.

There are three possible values for the depth attribute (basic, focused, and comprehensive).

Assessment Objectives

NIST modeled the numbering scheme for the assessment objectives from SP 800-53. NIST deconstructed some controls to clarify the assessment procedures. They used square brackets to denote this dissecting of a control.

SP 800-53A provides ODPs with their own unique identifier. They are also listed before the determination statements. Assessors should determine whether the organization has defined the ODPs, which may include:

Assignment operations - defining a value
Selection operations - selecting one or more options provided

The ODP numbering convention begins with a two-character control family abbreviation. It also contains a two digit control number and “_ODP” at the end. When there are more than one ODP, numbers starting from “01” appear in square brackets at the end.

Image Source: NIST SP 800-53A

Braces { } identify parameter values. A semicolon separates potential values within the braces. Sometimes a selection operation may include an embedded assignment operation. The < > symbols contain the identifier when referencing an ODP in a determination statement.

Control enhancements include the sequential parenthetical numbers within the identifier. For example, the objectives for the first enhancement to AC-17 are as follows:

NIST SP 800-171 Explained

NIST introduced SP 800-171 in 2015. It is the standard for protecting controlled unclassified information (CUI) in nonfederal systems. There have been two major revisions (revision 1 in 2017 and revision 2 in 2020). NIST scheduled the final publication for revision 3 in early 2024.

NIST SP 800-171 Rev 2 contains 110 security requirements. NIST derived these requirements from two source publications:

Federal Information Processing Standards Publication 200 (FIPS 200)
The Moderate Security Baseline from Special Publication 800-53 Rev 4

Basic Requirements

NIST incorporated the basic requirements from the FIPS 200. Out of the 17 security requirements in FIPS 200, NIST included 14 in SP 800-171. These requirements cover seventeen security-related areas. NIST tailored the bold areas out of SP 800-171:

Access control
Awareness and training
Audit and accountability
Certification, accreditation and security assessments
Configuration management
Contingency planning
Identification and authentication
Incident response
Maintenance
Media protection
Physical and environmental protection
Planning
Personnel security
Risk assessment
Systems and services acquisition
System and communications protection
System and information integrity

NIST included these specifications as basic security requirements within NIST SP 800-171. For example, here are the first four requirements from FIPS 200:

Here are the corresponding basic security requirements from NIST SP 800-171:

Derived Security Requirements

NIST derived the other requirements by tailoring the SP 800-53B moderate security baseline. This tailoring focused on protecting CUI from unauthorized disclosure in nonfederal systems. Appendix E of SP 800-171 specifies these tailoring actions:

removing controls not related to protecting the confidentiality of CUI
removing controls that were the responsibility of the Federal Government
removing controls NIST assumed nonfederal organizations would implement without specification.

Assumptions

NIST addressed a few of their assumptions in this publication:

Protection requirements for CUI are consistent regardless of where it resides.
Safeguards implemented to protect CUI are consistent regardless of where the information resides.
The confidentiality impact value for CUI is no less than FIPS 199 moderate.
Nonfederal organizations already have systems and do not buy systems to handle CUI.
Nonfederal organizations have safeguarding measures in place to protect their own information.
Nonfederal organizations may use effective compensating controls.
Many solutions exist to help nonfederal organizations meet these security requirements.

Security Requirement Families

NIST organized security requirements into fourteen families. Except for three, these aligned with the requirements described in FIPS 200. The table below lists the families of requirements:

Applicability

The requirements apply to components of nonfederal systems that process, store, or transmit CUI. They also extend to components that provide security protection for such components. Organizations may limit the scope of applicability by isolating these components. Physical and logical architecture and design concepts may achieve isolation.

Assessment

NIST SP 800-171A contains the assessment procedures for SP 800-171. Nonfederal organizations describe how they meet the requirements in a system security plan. The defined system boundary guides the scope of the assessment. The prescribed procedures assess the implementation and effectiveness of the security requirements.

Assessment Procedures

An assessment procedure consists of an objective and a set of methods and objects. Each assessment objective includes one or more determination statements linked to the requirement. The application of an assessment procedure produces assessment findings

Much like discussed above, assessment methods include examine, interview, and test. The examine method involves analyzing assessment objects (specifications, mechanisms, activities). The interview method involves holding discussions with individuals or groups of individuals. Testing involves exercising assessment objects (activities or mechanisms) under specified conditions.

Organizations are not expected to use all assessment methods or objects. Organizations choose those that are the most useful in obtaining the desired results.

Appendix D describes the attributes of depth and coverage for each assessment method.

Assurance Cases

An assurance case is a body of evidence organized into an argument that demonstrates a claim. An internal or external designated official may gather evidence during the assessment. They process and make determinations about compliance to the security requirements. They conduct system-level assessments to determine the effectiveness and compliance of the requirements.

The Procedures

Assessors achieve assessment objectives by applying a method to the selected objects. This produces evidence necessary to make the associated determination. Each determination statement produces one of the following findings:

Satisfied - the evidence collected indicates the objective produces an acceptable result.
Other than satisfied - potential anomalies exist or there was not enough information.

Conclusion

NIST wrote SP 800-53 for federal systems implementing the risk management framework. Federal agencies categorize their own information and systems. This enables them to tailor a baseline of security controls. Assessors measure the effectiveness of the controls with an assessment. A separate publication details the assessment procedures for each control. Agencies use assessments to authorize and continuously monitor their systems.

NIST wrote SP 800-171 for nonfederal organizations handling CUI. The government categorizes CUI at the moderate impact level. NIST SP 800-171 is a tailoring of the moderate security baseline. The tailoring focuses on protecting the confidentiality of CUI. This makes the control selection more rigid than NIST SP 800-53. A separate publication details the assessment procedures. Until rulemaking (CMMC), there is no formal authorization required to operate these systems.

Featured

Oct 18, 2024

The Go-To CMMC Policy Templates According to NIST

Oct 18, 2024

Organizations should identify the roles assigned to each statement within the policy. Mapping policy commitments to requirements and roles creates a shared responsibility matrix.