The Importance of Scoping and Applicability in CMMC

This post is part of How I Would Assess You (HIWAY)™, an ongoing series of articles discussing the concepts, challenges, and strategies for accurate and practical assessments of safeguarding programs.

Sometimes, while discussing compliance topics, we say one thing while meaning another. A common mistake we see and hear involves scope. Organizations will ask us something along the lines of, "is [system component X] in scope for CMMC?" or, "is [business function Y] in scope for CMMC?" Discussing further, we often find we're having a conversation about applicability, not scope.

What's the Difference?

While establishing the scope is an effort to determine the maximum breadth and depth of an assessment, applicability is a concept embedded inside of an organization's agreed-upon scope. The rules are simple:

1. If even one requirement applies to an item, it is in the assessment scope.
2. If no requirements apply to an item, it is out of the assessment scope.
3. Requirements need not apply to all items in the assessment scope, and that's a good thing.

Determining the applicability of requirements happens after we have an established assessment scope, so let's tackle these concepts in order.

Establishing Scope

In the context of an assessment, the scope can represent several things. Assessment scope can include the requirements to assess, the individuals who will be part of the assessment, the methods used to assess an organization, the facilities where sensitive data exists, and of course, the IT system components involved in handling and securing in-scope data.

Let's look at two statements to establish a scope for IT system components.

The first example is from DFARS 252.204-7012:

"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."

If our assessment scope includes covered contractor information systems, then we would only assess system components matching the definition listed above. I'm likely to have a file storage location, perhaps some network equipment, and almost certainly some endpoints in the scope. Email and data backup systems would also be expected within this scope since all of these systems store, process, and transmit data. If my assessment drifted towards other system components that do not handle "covered defense information," then I would be "out of scope."

Our second example is from NIST Special Publication 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems:

"The requirements [documented in SP 800-171] apply to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components."

As we can see above, the definition of scope  expands to include more system components than our first example. Its scope also includes "systems that provide security protection for components of nonfederal systems that process, store, or transmit CUI." If we plan an assessment using the definition in 800-171, then the scope would likely include antivirus, system monitoring tools, intrusion detection systems, system logging and SIEM tools, vulnerability scanning tools, and other security capabilities for covered contractor information systems.

Establishing Applicability

Regardless of which  approach to scope the CMMC model uses for future assessments (DFARS, or 800-171), there will always be in-scope systems assessed to determine whether requirements are implemented. The fundamental objective when determining applicability is to determine which requirements apply to individual systems or system components within the assessment scope. This step is where you'll reduce complexity and find most of your cost avoidance.

Determining whether a requirement applies to one of your system components is a function of each requirement's underlying conditions. If the condition described in a requirement does not exist for a particular system component, then the requirement itself is not applicable.

Applicability of CMMC practices to Specific Components

The most obvious example of a requirement's applicability differing from one component to another is in the CMMC practices (and NIST 800-171 requirements) with "CUI" in their description. If CUI is not present in the system component, then the condition does not apply to the component. It is not applicable.

Here are some possibilities:

AC.3.022 Encrypt CUI on mobile devices and mobile computing platforms.

If your organization doesn't use mobile devices to store, process, or transmit CUI: this requirement does not apply to your mobile devices even if you have mobile devices in scope for other purposes (such as multifactor authentication or building access).

SC.3.177 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

If your firewall doesn't decrypt CUI data (say, using HTTPS inspection) or encrypt CUI data: this requirement does not apply to your firewall even if your firewall uses encryption for other functions unrelated to protecting the confidentiality of CUI. Your firewall will still be in the assessment scope for plenty of other requirements, such as controlling the flow of CUI, boundary protection, and routing remote access.

MA.3.115 Ensure equipment removed for off-site maintenance is sanitized of any CUI.

If your internal audit team deploys security appliances for semi-annual vulnerability scans and configuration audits of covered contractor information systems: this requirement does not apply to the security appliances even if the instruments capture metadata from covered contractor systems. These appliances can be sanitized off-site for use at another assessment.

Applying Applicability

There are numerous examples where requirements do not apply to particular system components or tools, even though the element is in scope for other requirements in the overall assessment. Your organization can make similar determinations for personnel, organizational processes, facilities, and other aspects of the system.

Determining Applicability Preserves your Security Tools

Once we understand that not all requirements are universally applicable, it becomes easier to compare requirements to individual system components in the assessment scope. Suppose a system component has a unique profile for the requirements that apply to it. In that case, an organization can create statements of applicability for discussion with authorities who grant exemptions or gain agreement with assessors regarding which system components to assess against specific requirements.

Shifting the Discussion

The next time someone asks an overly broad question regarding their assessment ("is my SIEM in scope for CMMC?"), improve the situation by asking, "which requirements apply to that component?"