NIST SP 800-171 / DFARS 252.204-7012 SCOPING

There seems to be so much confusion regarding the topic of scoping.? Much of this topic seems to be related to understanding what requirements must be met for systems that provide protection to systems that process, store, or transmit CUI.

Let’s start at the beginning… well, not the very beginning.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Rev. 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations para 1.1 Purpose and Applicability has a few sentences that are key to the discussion regarding scoping.

The requirements apply to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components. If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.

The first sentence tells us that the 110 security requirements found within NIST SP 800-171 apply to components of non-federal systems that process, store, or transmit CUI, or that provide security protection for such components.? The term components often leads to a great deal of debate because many assume that the only items in-scope would be the computer that processes CUI.? However, NIST SP 800-171 provides additional information regarding the term components.?

System components include, for example: mainframes, workstations, servers; input and output devices; network components; operating systems; virtual machines; and applications.

That is a conversation for another day.? Let’s look at what Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting says to us regarding scoping.

Let’s start with a couple of definitions:

“Covered defense information” means unclassified controlled technical information or other information, as described in the Controlled Unclassified Information (CUI) Registry at https://www.archives.gov/cui/registry/category-list.html, that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Governmentwide policies, and is—

(1) Marked or otherwise identified in the contract, task order, or delivery order and provided to the contractor by or on behalf of DoD in support of the performance of the contract; or

(2) Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.

?

“Covered contractor information system” means an unclassified information system that is owned, or operated by or for, a contractor and that processes, stores, or transmits covered defense information.

Now, here is the part that defines the scope.

(i) Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations” (available via the internet at https://dx.doi.org/10.6028/NIST.SP.800-171) in effect at the time the solicitation is issued or as authorized by the Contracting Officer.

NIST SP 800-171 said that the requirements from NIST SP 800-171 applied to “components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components.”

Department of Defense (DoD), via DFARS 252.204-7012 said that “the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171”

For the Defense Industrial Base, the covered contractor information system is the scope.

Traditionally, the covered contractor system was operated on-premises. There was no Managed Services Provider (MSP). There was no Cloud Service Provider (CSP). Scoping was simple. Scoping IS simple, at least where the DIIB is concerned.

The DoD has actually established precedent for how they handle scoping already and it is quite simple?

What are you talking about AJ? I'm so glad you asked? Let me tell you. Here is a scenario that illustrates how the DoD currently handles scoping and the precedent that has been set? It is also in alignment with DFARS 252.204-7012

Scenario:

• ACME, Inc. is a DIB Contractor.
• The contract identifies that ACME will receive Controlled Technical Information.
• ACME will receive the information via DoD Secure Access File Exchange (SAFE).
• ACME will only process CUI on one computer.
• The computer that ACME is using is a part of ACME’s corporate domain.

Facts:

• ACME is operating a Covered Contractor Information System
• ACME’s Covered Contractor Information System is subject to the 110 requirements from NIST SP 800-171.
• DoD doesn’t care if ACME is using just one computer.

The same concept applies when a DIB contractor has a component that provides security protections to its covered contractor information system. In Figure 1, you may have noticed a SIEM was located within the covered contractor information system. Because that component providing security protections to the covered contractor information system was located within the same system, its requirements are met along with the covered contractor information system.

Let's consider what happens if the SIEM was being provided by a CSP. The precedent doesn't change. The SIEM is protecting the covered contractor information system; but it is no longer directly part of the covered contractor information system. Therefore, it is no longer inheriting the requirements from the covered contractor information system.

The CSP system that is hosting the SIEM service would be responsible for meeting the 110 requirements of NIST SP 800-171.

This is often a tough concept for some to understand but it shouldn’t be.? When a system is subject to the requirements, the owner of the system always has the option of reducing the scope of the requirements. Consider the second sentence from the first quote that I referenced from NIST SP 800-171.

If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.

The same concept applies for components that provide security protection. It is not possible for a CSP/MSP/MSSP/ESP (ESP) to use corporate Active Directory for single sign-on for its SIEM that is protecting a DIB contractors' system and for the ESP or the OSC to expect that the ESP's domain controller to not be in-scope. That is why ESP systems need to be assessed for the services they provide to DIB contractors. You can’t have a SIEM receive authentication from a domain controller and not expect the domain controller to be in scope.? What about physical security?? What about boundary requirements for that network?? All 110 requirements have to be met for the information system that is providing the SIEM service.? NIST SP 800-171 is the beginning. We didn't even talk about the requirements that are in place when CUI is stored, processed, or transmitted in an external cloud service provider.

Proper scoping considers risk to the information system and the information.

Final Thoughts

There are two things that a CMMC assessor has to consider when an external service provider is being used:

• External Service Provider System Compliance
• Shared Responsibilities/Control Inheritance

When conversations are being had regarding applicability of requirements, I believe that these are sometimes confused and, although related, are not the same thing.

External Service Provider System Compliance

The data that will travel into an external system, how the external system will be used, the type of connection the external system has, etc. plays a role in determining the type of compliance that has to be met by an external service provider's system.

The most obvious requirement is what is required when a DIB contractor intends to use an external CSP to store, process or transmit CUI.

If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline (https://www.fedramp.gov/resources/documents/) and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.

There may be other requirements to consider as well. If a tool is going to be used to provide remote support to users, validation that FIPS 140-2 cryptographic modules are employed to protect the remote sessions is required.

Ensuring that systems offering security protections meet NIST SP 800-171 requirements. Of course, the method of validation has not yet been decided as CMMC rulemaking is not yet complete.

Shared Responsibilities/Control Inheritance

During an OSC assessment, an assessor will need to understand the role of the external service provider and the role of the OSC regarding shared responsibilities. One of the benefits of using external service providers is control inheritance. However, control inheritance only speaks to the controls that will be inherited by the OSC when implementing their system or when being assessed. Control inheritance does not speak to the applicability of controls to a providers for a provider's system. The provider has to implement the requirements for their in-scope system as well.

I hope this helps some that may not have understood this topic.

Feel free to reach out if you have any questions.