Words From the Author
As outlined in our CMMC 2.0 in 2022 post, NIST Special Publication (SP) 800-171 is more important than ever for cybersecurity compliance as it related to federal contracts. Not only is NIST 800-171 the current law of the land under DFARS 7012, it is also the control target for CMMC level 2, and will also be required for CMMC level 3 along with additional controls under NIST 800-172. For the full context on when, how, and why NIST 800-171 applies (spoiler it applies to the entire DIB as of this writing) checkout the post listed above.
My goal is to dive into the specifics around NIST 800-171 assessment including methodologies, scoping, scoring, and the correct way to evaluate and document an NIST 800-171 assessment based on the official assessment methodology released by the government (NIST 800-171A).
For the uninitiated, or those who are in a hurry (like I typically am), here is a quick refresher to provide some context on the framework and the business problem it poses to most organizations.
NIST 800-171 refers to National Institute of Standards and Technology Special Publication 800-171, which governs Controlled Unclassified Information (CUI) in Non-Federal Information Systems and Organizations. The current DFARS clause 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, is required in all Department of Defense (DoD) contracts. Basically, this means is that if you want to do business with the DoD, as a prime contractor or a subcontractor, you will be required to tackle this compliance framework in order to be awarded the work, and are likely on the hook for these compliance objectives under any currently held contracts with the DoD.
DoD contractors are required to “self-certify” all “covered contractor information systems,” which are generally those that store, process, generate, transmit or access DoD-related controlled unclassified information (CUI), which DoD terms “covered defense information.”
What are the controls?
NIST 800-171 covers 110 control objectives across 14 control families covering various focus areas within information security operations.
Each control family is broken up into Basic and Derived controls. Straight from NIST 800-171:
The security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations have a well-defined structure that consists of a basic security requirements section and a derived security requirements section. The basic security requirements are obtained from [FIPS 200], which provides the high-level and fundamental security requirements for federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in [SP 800-53]. Starting with the security requirements and the security controls in the moderate baseline (i.e., the minimum level of protection required for CUI in federal systems and organizations), the requirements and controls are tailored to eliminate requirements, controls, or parts of controls that are:
- Uniquely federal (i.e., primarily the responsibility of the federal government);
- Not directly related to protecting the confidentiality of CUI; or
- Expected to be routinely satisfied by nonfederal organizations without specification.
The take-away is that all NIST 800-171 controls come from established government frameworks for securing sensitive information including FIPS 200 and NIST SP 800-53. This is important because the controls can be mapped to other frameworks such as ISO 27001 which organization may have already completed.
So, we have 110 controls which must be implemented. What is the most efficient way to tackle this control set? For those who are familiar with Payment Card Industry (PCI), you might be able to guess where I am going based on the title of this section.
NIST 800-171 compliance objectives are typically applied to a “system” the organization uses to create, store, process, or transmit CUI data. For this purpose, a “system” is defined as all of the components, (computers, servers, network device, etc.) which contain CUI data, or support the systems which contain CUI data. Functionally, this means that a system could be a single application with proper segmentation and control, or, it could be an organization’s entire network environment without proper segmentation controls. If you have any experience with PCI compliance, you are most likely familiar with the concept. This means that in practice, limiting the scope and footprint of CUI data to a single “system”, and applying the segmentation and access management controls to that system, is often much easier than applying the controls across the enterprise.
The takeaway here is that limiting the footprint of CUI data on a network is a VERY effective way to reduce the cost and level of effort when becoming compliant with NIST 800-171.
The Outputs – SSP, POAM, SPRS Score
One nice thing about NIST 800-171 is that documentation requirements are outlined as one of the controls which must be documented.
Additionally, the footnote expands with:
So deliverable number one is the System Security Plan (SSP) and we have some creative control over the format as long as we document:
- System boundaries
- Environments of operations (I.e., physical locations)
- Control implementations
- Relationships and interconnections with other systems
Sounds easy enough right? Not really but we will have more on that later. In addition to the SSP, 800-171 has another control that outlines a second output from the assessment, the Plan of Action and Milestones (POAM).
So basically, for any control which is not currently met, this control requires documentation of a POAM which includes the deficiency and a plan to correct.
The final output of the NIST 800-171 assessment is the score. I would highly recommend reading the full scoring methodology which has been released by the DoD. Under the scoring methodology, each control has a weighted score which is awarded if the organization has a current control which can be applied.
It’s important to note that a failure to apply one of the Basic controls will automatically render a number of Derived controls useless. Once an assessment has been completed, and an organization has evaluated where they stand across all 110 controls, the weighted score for every unmet control is subtracted from 110. Therefore, it is possible (and common) to have a negative score. Another caveat is that it is possible that some controls may not apply to the environment (e.g., the organization does not use a wireless network), which would render associated controls “not applicable”. However, the organization should be prepared to defend the decision for every “N/A” control and likely have a policy to support the decision.
At this point we know a little more about the NIST 800-171 framework, some scoping tips at a high level, and also the outputs of the assessment. Time to dive deeper into the assessment itself. NIST 800-171A enters the arena.
Assessment Methodology – NIST 800-171A
One of the biggest challenges with NIST 800-171 the first time I read it was the way extremely complex cyber security tasks were summed up in extremely short control statements. While the control text might only be a sentence or two, it addresses very complex tasks that require a combination of technology, policies, procedures, and people to properly implement.
From my perspective as an assessor, how can I comfortably decide if an organization is meeting a control from such a short statement? Fortunately for me, I eventually discovered NIST 800-171A, which is the official assessment methodology for NIST 800-171 the government has released. The goal of NIST SP 800-171A is to provide organizations assessment procedures and a formal methodology for conducting NIST 800-171 assessments. The procedures outlined within the methodology can be used to generate evidence to support the claim that the security requirements have been satisfied.
For each security requirement outlined under NIST SP 800-171, an associated Assessment Procedure has been defined under NIST 800-171A. An Assessment Procedure consists of the following:
- Assessment Objectives
- Assessment Objects
- Assessment Methods
Each Assessment Objective includes a determination statement linked to the CUI security requirement to ensure traceability of the assessment.
Assessment Objects identify the specific item being assessed under the Assessment Objective:
- Specification – Document based artifacts (policies, procedures, standards, security plans/requirements, functional specification, architectural designs, etc.)
- Mechanism – hardware, software or firmware safeguards present within a system (e.g., Firewalls, IDS/IPS, SIEM, backups, etc.)
- Activity – Protection related actions (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic)
- Individual – People applying specification, mechanisms, or activities
Assessment Methods are the nature and extent of an assessor’s actions when reviewing an Assessment Objective:
- Examine – The examine method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities) for the purpose of facilitating understanding of the control, achieving clarification on the implementation, or to document evidence of the control.
- Interview – Holding discussions with individuals or groups for the same purpose.
- Test – Exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior. i.e., traditional audit process including sampling.
Organizations are not required to employ all assessment methods on all assessment objectives, or even address every assessment objective associated with a control. This determination is made based on how the organization can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.
In summary, the Assessment Objective defined for each Assessment Procedure is achieved by applying the designated Assessment Methods to the selected Assessment Objects and compiling/producing the evidence necessary to make the determination associated with each control.
NIST 800-171A defines over 300 assessment objectives mapped to the 110 controls under NIST 800-171. The results of these assessments are going to complete an organization’s SSP, and the identified gaps will make up the POAM.
At this point, we have covered wthe basis for NIST 800-171 including the controls and associated origins, the scope the framework is applied to, the required outputs, and the approved methodology. The next steps in actually getting this process rolling is going to depend heavily on a number of factors:
- contractual deadlines
- scope of CUI data
- maturity and complexity of the organization and environment
- and most importantly the buy in for an organization’s stakeholders.
NIST 800-171 compliance is a complex and expensive process but with the right tools and expertise is achievable for all organizations. Compliance Cloud Solutions offers a number of different services which can help organizations move forward with cybersecurity goals, and surpass their compliance objectives. Click here to schedule a conversation with our experts!