Scoping is often overlooked when preparing for a cybersecurity maturity model certification (CMMC). That statement is part of the reason why we made a checklist in the first place.
The scope includes assets that provide security or process, store or send sensitive information.
The purpose of this blog is to provide a resource that documents how to tailor the 320 objectives within NIST SP 800-171A to the CMMC scope. Oftentimes, though, you'll see and hear the phrase "scope applicability matrix". These exist to help ensure you've implemented the requirements across the entire relevant scope.
In this post, we’ll discuss the following points:
Definition of Federal Contract Information (FCI)
The (ir)relevance of scoping for Level 1
Definition of Controlled Unclassified Information (CUI)
The relevance of scoping for Level 2
How to create a scope applicability matrix
In December of 2021, the Department of Defense (DoD) released two versions of the scoping guide. The Level 1 Scoping Guide applies to organizations handling federal contract information (FCI). The Level 2 Scoping Guide applies to organizations handling controlled unclassified information (CUI).
There are some key differences between these guides but both reference three types of assets…
Image Source: CMMC Self-Assessment Scope Level 2
We’ll walk through the guidance of these scoping guides and then apply our findings to the assessment objectives. After all, if you don’t understand how the scope applies to each of the 320 assessment objectives, how can you assess their implementation?
Table of Contents
Federal Contract Information (FCI)
Federal Acquisition Regulation (FAR) 52.204-21 defines FCI using five parts:
The information was not intended for public release.
The Government provided it or received it as part of a contract.
The contract delivered a product or service to the Government.
The information was not provided by the Government to the public.
The information is not simple transactional information such as necessary to process payments.
How does the contractor know if the information qualifies for public release?
Unless marked for public release, contractors should treat anything provided by the government as FCI.
What about the information that the contractor creates?
If the contract doesn’t approve information for public release, then they should treat it as FCI.
What isn’t FCI?
Information not received from the Government and not developed under a contract with the Government would not qualify as FCI.
The (ir)relevance of scoping for level 1
Now that we’ve defined FCI, let’s take a look at the CMMC Level 1 Scoping Guide.
There are three categories of assets defined:
FCI Assets - process, store or transmit FCI (people, technology, facilities, ESPs)
Out-of-Scope Assets - do not process, store, or transmit FCI.
Specialized assets - includes
Government Property
Internet of Things (IoT) or Industrial Internet of Things (IIoT)
Operational Technology
Restricted Information Systems
Test Equipment
Reading the definition of each asset category would lead you to the conclusion that only FCI Assets are relevant. However, the guide cautions that, “...because FCI is a broad category of information, the contractor will likely focus the self-assessment on their entire environment.”
This statement isn’t definitive. It does provide an unlikely option to restrict implementing the basic cybersecurity safeguards.
But, nobody’s going to assess these controls across any scope unless you’re certifying at Level 2. And at that point, we only care about scope defined in the Level 2 Scoping Guide.
Definition of Controlled Unclassified Information (CUI)
CUI is a subset of FCI. The National Archives and Records Administration (NARA) breaks the definition into three parts.
The Government, or an entity acting on their behalf, created it or possesses it.
A law, regulation, or policy permits using safeguarding or dissemination controls.
It does not include classified information.
CUI is a term defined by executive order 13556 and applies to all executive branch agencies.
While the FAR defines requirements for FCI, it doesn’t (yet) specify protection of CUI. The Defense FAR Supplement (DFARS) details protection of covered defense information (CDI). CDI is a term used by DoD that is synonymous with CUI.
We wrote a separate post about CUI designations if you’re interested in learning more about CUI.
The relevance of scoping for level 2
There’s a misperception that CMMC is a third party verification of the DFARS 252.204-7012 clause. Although both draw most of the security requirements from NIST SP 800-171, the scoping fits within NIST SP 800-171.
The DFARS 7012 clause defines contractor information systems using three parts:
an unclassified information system
owned or operated by or for a contractor
processes, stores, or transmits covered defense information
NIST SP 800-171 rev 2 defines the term organizational system using three parts:
components of nonfederal systems
that process, store, or transmit CUI
or that provide protection for the system components
This NIST definition of organization system aligns with the first two categories referenced in the CMMC Assessment Scope Level 2. CUI Assets process, store or transmit CUI. CMMC places equal importance on Security Protection Assets. These are assets that provide security functions to the CMMC Assessment Scope.
The CMMC Assessment Scope also includes Contractor Risk Managed Assets (CRMA). CRMA are assets that can, but aren’t intended to, process, store or transit CUI. A recent white paper published by Peak InfoSec, an authorized CMMC 3rd Party Assessor Organization (C3PAO), examined the definition of CRMA through the lens of NIST SP 800-171.
The CMMC Assessment Scope Level 2 reduces the applicability of requirements for CRMA to:
Document in the asset inventory
Document in the System Security Plan (SSP)
Manage these assets using the contractor’s risk-based security policies, procedures, and practices
Document in the network diagram of the CMMC Assessment Scope
Does this mean that CRMA aren’t assessed against the 110 security requirements?
According to Matthew Titcombe, the answer is emphatically no. NIST SP 800-171 rev 2 details the approved method of limiting the scope. Achieving this happens by isolating designated system components into a separate security domain.
According to Mr. Titcombe, unless CRMA are physically and/or logically separated from CUI assets, they will be subject to the full extent of the 110 security requirements.
Image Source: NIST SP 800-171 rev 2 Chapter 1 page 2
The same conclusion holds true for Specialized Assets. According to Titcome, specialized assets “require the implementation of the NIST SP 800-171 requirements” unless you move them outside the scope.
Out-of-scope assets are physically or logically separated from CUI assets. Separating CUI assets into an enclave reduces the implementation burden of the security requirements.
A C3PAO will review your scoping documentation. This will help discussions during the pre-assessment readiness review. It does not need to list each asset, rather it should focus on the major systems in the network.
Amira Armond, owner of Kieri Solutions LLC, has put together a series of terrific examples. Her work includes sample…
Information flow diagrams
Network diagrams
Facility diagrams
Organizational charts
There are free tools that would allow you to create your own. We found creately was easy to use. It allowed us to draft the following diagram in less than a few minutes.
Image Source: Creately
Scoping will generate three tables of assets, including people, technology, and facilities. We recommend keeping them separate as the columns detailing each will vary from table to table.
Applying the scope to the assessment objectives
The purpose of this exercise was to create a tailored scoping guide for each assessment objective within CMMC. We looked at the 320 objectives and tailored the scope for each. These reflect our own understanding of the controls and whether the different types of scoped assets are capable of implementing the security requirements.
Let’s look at a few examples in more detail.
AC.L1-3.1.1 - Authorized Access Control
The control statement reads “Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).”
The subject of this technical control is the information system. Let’s dig a little deeper into the objectives:
Identify authorized users
Identify processes acting on behalf of authorized users
Identify devices (and other systems) authorized to connect to the system
Limit system access to authorized users
Limit system access to processes acting on behalf of authorized users
Limit system access to authorized devices (including other systems)
The subject remains information systems across all objectives. An information system is a technology asset or an external service provider. The scope for these objectives would be technology assets and external service providers.
AC.L1-3.1.22 - Control Public Information
The control statement reads “Control information posted or processed on publicly accessible information systems”.
The subject of this operational control is the information posted on publicly accessible information systems. Let’s look at the objectives for this control:
identify individuals authorized to post or process information on publicly accessible systems
identify procedures to ensure FCI is not posted or processed on publicly accessible systems
a review process is in place prior to posting of any content to publicly accessible systems
review content on publicly accessible systems to ensure that it does not include FCI
mechanisms are in place to remove and address improper posting of FCI
People implement operational controls through defined procedures. But in order for individuals to identify FCI, they need training on how to identify nonpublic information. Mechanisms to remove improper posting of FCI refers to the technical aspects of the publicly accessible information system. This level 1 practice is a great example that relates to multiple scopes:
procedures addressing publicly accessible content
People authorized to post information on publicly accessible systems
procedures addressing publicly accessible content
People reviewing information on publicly accessible systems
Technology and/or External Service Providers with publicly accessible information
There are a handful of practices that require training for those people implementing the control. We wrote two summary blogs detailing these practices for both CMMC Level 1 and Level 2.
IR.L2-3.6.1 - Incident Response Handling
The control statement reads “Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities”.
The subject of this operational control is the incident-handling capability. Let’s look at the objectives for this control:
establish an operational incident-handling capability
the operational incident-handling capability includes preparation
the operational incident-handling capability includes detection
the operational incident-handling capability includes analysis
the operational incident-handling capability includes containment
the operational incident-handling capability includes recovery
the operational incident-handling capability includes user response activities
The objectives break down the capability into six parts. Objectives C through F include technical capabilities. These include detection, analysis, containment and recovery. These technical requirements apply to technology assets and external service providers. Personnel with incident response assistance and support responsibilities are also in scope. They should receive specific training on forensics, reporting, system recovery and restoration.
Objective (b) and (g) refer to procedures implemented by people. Objective (b) includes personnel with incident handling responsibilities as they prepare and establish the incident-handling capability. Objective (g) would include regular users with system access who receive training on how to recognize an incident and who to call.
Personnel with incident response training and operational responsibilities develop and deliver the training requirements across all objectives. Objective (a) is a roll-up that would cover all aspects of scope identified in other objectives (b thru g).
Summarizing the relevant scope for this control would look like:
In a recent webinar with Preveil, Ryan Bonner shared his thoughts on this exercise. His methodology involved evaluating whether the type of assets (people, technology, facilities) were capable of implementing the assessment objectives. He used three objectives from the Media Protection domain to demonstrate the applicability of scope for each.
He expanded upon asset types by then specifying their characteristics. For example, he separated Technology assets into network assets, operating systems and applications. He separated facilities into perimeters, internal zone sand racks/enclosures. This allowed for identification of specific technologies within the scope of each objective.
The outcome of this exercise produces an applicability matrix. The matix lists all relevant requirements for each asset. This is ideal to present to a C3PAO during the scoping discussion of the assessment. It also assists with managing the continuous compliance. This happens by identifying requirements tied to specific technologies. If the EDR solution changes, having a list of the related requirements tied to that technology makes it easier to go through and update documentation associated with the implementation of those requirements.
Conclusion
Breaking down the scope at the objective level requires critical thinking about the subject of the control. You have to determine whether the requirement is technical or operational.
There hasn’t been a publication from The Cyber AB or DoD that connects the scoping guide to the objectives. Organizations must interpret how scoping will apply at the objective level.
The resource we drafted is our own interpretation. It came to fruition after numerous discussions with consultants and provisional assessors. We developed this to map our CMMC compliance application to incorporate aspects of scope for each objective.
By defining how to tailor the scope for each control allows us to automate the creation of new objectives when the scope changes. We demonstrate this in a brief video below.
