The DoD Industrial Base (DIB) has long awaited guidance on what IT system components are in scope for cybersecurity protections under the National Institutes of Standards and Technology (NIST) 800-171 standard and the DoD’s Cybersecurity Maturity Model Certification (CMMC). Thankfully, the DoD has provided some answers in its recently released CMMC Scoping Guide. In this post we break down the guide and discuss how it impacts small business DIB members, especially manufacturers.
First, some definitions
First let’s explain some terms. The CMMC Scoping Guide uses the word “asset”. We use that term as well as “system component” and “covered component”, all interchangeably. These assets/components are things that support your organization’s information:
- the information itself, and in this context especially Controlled Unclassified Information (CUI)
- hardware such as servers, workstations, and mobile phones
- the software and applications installed on that hardware such as web browsers, email clients, office documentation apps, and antivirus
- the network devices that link various hardware components together
- the users that actually use the hardware and software, and
- the physical facilities that house all the above.
If an asset stores (e.g. paper document, file server, DVD), processes (e.g. workstation developing an engineering drawing), or transmits (e.g. send a document to a colleague via email) CUI, we say that asset “handles” CUI.
We say assets are “traditional” if they are used for hosting data, services or applications that are owned, controlled, operated and managed by the same organization or individual such as a data center, server farm, or other non-cloud computing-based IT solutions. An example of a traditional asset is a desktop a programmer uses to create code that controls a milling machine.
Cloud computing assets are those hosted by a cloud service provider, such as Microsoft 365, Google Workspace, or Cocoon Data SafeShare.
Managed Service Providers (MSP) are external companies we hire to perform day-to-day IT system administration for us. Managed Security Service Providers (MSSP) are external companies we hire to perform ongoing security operations for us. MSP and MSSP use a variety of assets to execute their services.
The Scoping Guide refers to cloud service providers, MSP, and MSSP as External Service Providers (ESP).
If an asset provides protections to an asset that handles CUI, the CMMC Scoping Guide calls it a “Security Protection Asset”, for example:
- the facility itself
- endpoint protection software, such as antivirus
- MSSP security analysts
There are also “non-traditional” IT assets that may or may not handle CUI but that are connected to our other system components, such as:
- test equipment,
- research and development (R&D) computers,
- industrial control systems (ICS) and supervisory control and data acquisition (SCADA), known as Operational Technology (OT)
- Internet of Things (IoT), and
- Government Furnished Property (GFP).
The CMMC Scoping Guide refers to non-traditional IT components as “Specialized Assets”.
The term “scope” or “scoping” refers to three related processes:
- Determining which assets either handle or protect CUI
- Determining what cybersecurity safeguards to apply to those assets, and
- Determining how the effectiveness of those safeguards will be assessed
The CMMC Scoping Guide (which, BTW is concise and to the point, surprisingly for a government document, you should read it!) is important because it helps us determine those three things. An asset can be “in-scope” for any one of the processes.
The Scoping Guide release confirms the advice we’ve been giving to clients for years, but it also provides some much needed relief to those of us that were worried about having to make significant changes to our IT architecture to properly implement NIST 800-171 and pass a CMMC assessment. The rest of this post will explore the salient features of the guide.
The bottom line
The bottom line is that if an asset handles or protects CUI, or is connected to an asset that does, at a minimum you’ll have to:
- maintain an inventory list that includes that asset
- document — in a formal System Security Plan (SSP) — your organization’s expectations on how that asset is to be protected, and describe the organizational processes, procedures, or technology that provide that protection
- include it in diagrams of the organization’s IT system
For safeguarding, you’ll have to apply all the applicable NIST 800-171 safeguards (aka “controls” or “practices”) to traditional and ESP assets that handle or protect CUI. These assets will be assessed against all those safeguards, either through self- or third-party assessments using the DoD 800-171 Assessment Methodology and CMMC.
There are a few exceptions to the safeguarding and assessment scope, however. We’ll talk about these next.
Nuances of the CMMC Scoping Guide
As noted above, Specialized Assets (i.e. non-traditional IT) that handle CUI must be inventoried, addressed in an SSP, and included in system diagrams. These assets must be safeguarded as well; however, aside from checking that the assets are addressed in the SSP, the scoping guide instructs assessors not to assess them against the bulk of the 800-171 practices.
This means that, for instance, a manufacturer won’t “fail” an assessment because it operates networked legacy — but expensive and still operationally useful — CNC machines whose controller operating systems cannot be upgraded because the machine controller software hasn’t been supported since 2002. This seems to be an acknowledgement by the DoD that it would bankrupt a significant portion of its supply chain if it required them to modernize all in-scope assets. This does not mean, however, that the manufacturer shouldn’t perform due diligence and apply all available cybersecurity safeguards to protect that asset and the information that it handles. For instance, that machine (and any like it) should be isolated to a separate subnet or Virtual Local Area Network (VLAN) and physical access to it should be tightly controlled to safeguard against incidents such as malware infection or data exfiltration. We’ll discuss the concept of “isolation” below.
There is one other category of in-scope assets that has some exceptions to the assessment scope: what the DoD calls “Risk Managed Assets”. In the DoD’s words, these assets are
capable of, but are not intended to, process, store, or transmit CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.
Like Specialized Assets, Risk Managed Assets must be inventoried, addressed in an SSP, and included in system diagrams. And like Specialized Assets, if the appropriate documentation exists, the assessors are instructed not to assess Risk Managed Assets against the bulk of the 800-171 practices.
What distinguishes Risk Managed Assets from the other asset categories identified by the Scoping Guide, however is that these are assets that are capable of handling CUI, but by policy are not intended to, and that these assets do not have to be isolated from other assets.
In our view, the inclusion of Risk Managed Assets by the DoD is one of the great gifts the CMMC Scoping Guide offers to small businesses. For many of us, this inclusion alleviates the fear of having to procure expensive new technologies just to comply with 800-171 / CMMC, and justifies the concept that proper prohibitive policies backed up with user training is a reasonable compensating control for lack of preventative technology. In essence, the safeguards required are commensurate with the risk to the asset. The best way to explain this concept is through an example:
Let’s say you use Google Workspace for your email and document storage. For various reasons, Google Workspace is not fit for handling CUI. So you put a policy in place that prohibits the handling of CUI in Workspace, but allows it for handling other corporate information that Workspace is well suited for, such as Federal Contract Information (FCI) or human resources communications. You also put other safeguards in place, such as enabling multifactor authentication and require users only to access the Workspace from company-provided devices. You publish an Acceptable Use Policy (AUP) that explains these policies, train your users on the AUP, and show them how to use more appropriate technology options when they need to handle CUI. Nothing prevents users from handling CUI in Workspace, but there are reasonable prohibitions in place, and other accessible options for handling CUI.
Before the Scoping Guide was released, there was serious concern that the DoD would not allow such compensating policy and procedural-based safeguards, and if the organization wished to continue the use of Workspace, to be compliant would either have to isolate the Workspace environment (again, we define isolation below), implement expensive Data Loss Prevention (DLP) technology, or a combination of both. Instead, the Scoping Guide provides confirmation that reasonable documented risk management of Workspace is acceptable.
Note, however, that if your documentation has discrepancies, is not consistent or finished, or if they notice other questionable practices, the assessors can choose to “spot check” Risk Managed Assets. It is implied that the results of these spot checks may cause an organization to fail an assessment. The good news is that the DoD mandates the spot checks not add to the cost or duration of the assessment, so you won’t have to pay the assessor more to confirm your risk management practices.
What does it mean to "isolate" an asset?
The CMMC Scoping Guide states that for an asset not to be in scope for 800-171 and CMMC, it must not handle or protect CUI and must be isolated logically or physically from other assets. Isolation is also a great practice, where feasible, to provide a buffer between Risk Managed or Specialized Assets and CUI or Security Protection Assets. The buffer can hamper the spread of adversarial activity in an environment.
So what does IT system “isolation” entail? Well, the Scoping Guide refers back to the overall guiding document for protecting CUI: the NIST 800-171 standard itself. Section 1.1 of that standard states:
organizations may limit the scope of the security requirements by isolating the designated
system components in a separate CUI security domain. Isolation can be achieved by applying
architectural and design concepts (e.g., implementing subnetworks with firewalls or other
boundary protection devices and using information flow control mechanisms). Security domains
may employ physical separation, logical separation, or a combination of both.
Logical isolation means segregating the asset (or group of assets) in a separate subnetwork or VLAN, and then putting strong information flow and access control on that segregated environment. This control can be achieved by a two part system:
- by routing all traffic to/from that VLAN through a firewall that is configured only to allow the very specific and minimal network traffic required for that asset to function, and,
- restricting user account access to only those users that absolutely need access to the asset to perform their job function
Physical isolation means at a minimum “airgapping” the asset, and removing all wired and wireless network connections to other asset categories. Physical isolation may also mean segregating the asset to a completely separate space in the facility and tightly controlling human access to the asset.
Some of you may have worked in “locked down” facilities where Classified information is handled, and have therefore experienced first hand the concept of both logical and physical isolation.
By the way, cloud services are by their nature both logically and physically isolated from your on-premise assets, and so using a cloud service is a nice way to achieve isolation.
In a figurative sense, isolation is akin to erecting the Great Wall of China around an asset. You can’t hope to climb or jump the Great Wall, you can only hope to pass through by way of one of a very limited number of constricting and highly guarded gates.
Wrapping up
We think the CMMC Scoping Guide is a boon to small business DoD contractors. The DoD has taken a risk management approach to the scoping problem, and allowed us plenty of “wiggle room” to operate our businesses in an efficient manner and still protect the CUI entrusted to us. There are still more specific scoping questions to be answered, for instance, which specific 800-171 controls are applicable to Security Protection Assets, e.g. “if it is not possible for CUI to traverse a security application’s network connection, must that connection employ FIPS-validated encryption?” But there are always more questions, and for now the DoD has put a lot of our questions to bed with the Scoping Guide.
If you’re interested in learning how to apply the Scoping Guide to your specific environment, or you’d like to learn more about how to isolate assets, we cover these topics in depth in our DFARS/CMMC Workshops. We’d love to have you with us!
Also check out our offering of free tools that you can use to categorize, inventory, and safeguard your in-scope assets.
Finally, as a small business DoD contractor ourselves, we love just talking about this stuff. Drop us a line and start a conversation!
Good Hunting!
–Adam
Download our CMMC Compliance Roadmap!
Like this post? Share it!
