Assessment Scoping: the CMMC-AB Standards Podcast Episode 4

The CMMC-AB recently released Episode 4 of the Standards Podcast. Episode 4 focuses on a topic of interest to many OSCs (Organizations Seeking Assessment), Registered Practitioners, and others who are working on their CMMC strategies: assessment scoping. Before diving in, they also touched on some additional points that are of note, including:

• Another Provisional Assessor class is being run in March and is expected to add 40 more Provisional Assessors to the pool; and,
• Staff is being hired with 8 open positions [although only 4 appear on their website currently] which, when filled, will bring the total staff to 11 people.

Scoping

The scoping conversation focused on what is taught to the Provisional Assessors. It is important to note that the scoping advice may change when DoD issues written scoping guidance, but for now the CMMC-AB stressed a few key topics, including:

• Scoping is a negotiation between the “sponsor” at the OSC [i.e., the senior-most person at the OSC who is involved in supporting the assessment], the contract requirements, and the assessor’s opinion of the scope.
• Assessors are experts in the field and needs to agree with the OSC on the scope, especially where the OSC says something is out of scope. The assessor will need to document the assessment scope in a common terminology that ensures the organization, the organization unit, and the network/enclave(s) that are assessed are clearly defined. The CMMC-AB is still working on the exact taxonomy.
• The SSP is/SSPs are the cornerstone of defining the scope.
• CMMC encompasses not only people and process, but also technology. You need to be able to define your data flows. Assessors will need to look at a wider variety of information, including network diagrams, data flows, policies and procedures to understand if OSC is making good decision for scoping. Assessor will need to look at network diagrams, diagrams, SRSs, org charts, and other documents during planning, not only during assessment process. This means a CMMC assessment will require extensive planning up front and knowledge of the organization before the assessment begins.
• NIST SP 800-171r2 takes some of the ambiguity out of what is in/out of scope. Unless there is physical or logical segmentation in place, the entire network will be in scope.
• OSCs will be keen on narrowing scope, and the CMMC-AB can appreciate their concerns. Limiting scope lowers cost and is easier to implement, but OSCs need to ensure they are protecting national security. The CMMC-AB would like to see CMMC create a set of priorities (a “tension table” as it is referred to in Agile) that helps OSCs understand what the priorities should be.
• Assessments, and especially assessment preparation, will likely include educational components, including helping the contractor understand why things are done a certain way (e.g., to prioritize national security).
• Assessors will need to worry about scope being limited in an effort to avoid assessors looking somewhere (i.e., creating an ethics issue). Assessors who feel something fishy is being done, should walk away. The CMMC-AB’s original CMMC Ecosystem design included provisions for C3PAOs and Assessors reporting OSCs who the Assessor/C3PAO felt were acting unethically. It included placing a “red flag” in the OSC’s file that would provoke a CMMC-AB audit of the assessment results. Under the ISO 17000-series architecture, it isn’t as clear whether such a scenario can still be implemented because C3PAOs will issue the certifications directly to the OSC, meaning the CMMC-AB may not have the visibility needed to implement such a system.
• Another concern that was addressed is process maturity. Ultimately, the issue is whether the assessor believes the practices and processes will continue to be followed when they walk out the door. That is, the assessor needs to feel confident that the OSC has embraced the cultural changes that CMMC requires and those changes will be part of their work going forward.
• The more cloud services you use, the more complicated scoping becomes because those cloud providers will likely need to be included in the scope, too.

Opinion/Analysis

We note a few interesting issues in what was discussed including:

• Contracts and Scoping: It wasn’t immediately clear exactly how the contract requirements play into the scoping discussion. The contract-specific issues may be relevant during the DoD “Pathfinder” and “Pilot” programs, but as the program expands beyond these initial contracts, most contractors will likely pursue their assessments/certifications in advance of a contract award, and even in advance of the contract’s announcement. As a practical matter, the only way we can see the contractual requirements factoring in is if the OSC wants a Maturity Level 1 assessment and the contract requires a higher level, but that is a matter for the prime contractor and/or DoD Contracting Officer to address, and should be outside the scope of the assessment.
• SSPs: While we understand how an SSP helps define the scope at Maturity Level 3, an SSP is not required for Maturity Level 1. Thus, asserting that it is the cornerstone of all scoping is inconsistent with the CMMC Model.
• Assessor Latitude: We understand and share the CMMC-AB’s concerns about OSC ethical behavior and the need for assessors to address such issues. However, we are concerned that the current regime gives the assessors too much latitude in the other direction. For example, in the following scenario, the assessor could hold up the OSC’s assessment, demand additional assessment fees, and take other actions that could jeopardize an otherwise legitimate approach to CMMC compliance.
  • Let’s say an OSC has been a government contractor for a long time.  As is typical for contractors, they aren’t certain but have a strong suspicion that they have at least a little CUI (most likely unmarked) in their environment.  Trying to conduct a data inventory and clean up the existing environment is going to be a monumental effort.  Rather than spend the time and effort to clean that environment up, they say “OK, we’re drawing a line in the sand.  We’re going to create a new environment for our CUI going forward.  The work for every new CUI-involving contract that we are awarded (and any CUI-laden RFI/RFP information) will be funneled into that environment.  Once the current contracts wind down, we will either retire the old environment or use it for ML1/non-government work.” They set everything up, including creating policies that clearly define where CUI is to go for all of those future contracts.  They even go so far as to create fictitious documents that are marked with CUI and run different tests to help proactively demonstrate that the system works as intended and to show (as best is possible in a sample environment) process maturity.  They are pretty confident that the new system will properly protect CUI going forward, and are committed to “doing the right thing”.  They bring in the Assessment Team to perform the assessment, and one of the assessors sees that there is CUI in the old environment.  Does that bring the old environment into scope?  Can the assessor threaten to raise a red flag and cause issues for the OSC when the OSC unless the OSC pays additional assessment fees? How does the OSC push back?
  • We have asked the CMMC-AB for feedback on this issue and will share their response if/when one is received.
• Physical and Logical Separations: The language added by NIST to Section 1.1 of SP 800-171 r2 states “solation 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.” To properly separate two security domains (e.g., separating one part of a network that is used to handle FCI and another that is more open), only physical and logical separation (or the combination of the two) can be used. Other forms of separation will not be acceptable. NIST SP 800-171 does not define logical separation, but NIST SP 800-53 does include some additional clarification, especially in SC-7(21) through SC-7(23).
• Cloud Services: Cloud services can significantly streamline an organization’s implementation of certain controls. However, it is important to understand that there are significant differences in the OSC’s security responsibilities depending on whether services being consumed are provided as Software, Platform, or Infrastructure as a Service provider. This will impact the OSC’s ability to “inherit” any CMMC or other certifications the cloud provider may have. Some cloud providers, such as Microsoft, are providing additional information that helps customers understand the providers’ position on some of these issues. However, we note that the advice given is not legal advice and when it comes to issues such as whether all CUI should be treated as though it is export controlled, OSCs should defer to the opinion of their attorneys.

Although there are some open issues, the information provided in the podcast should be helpful to many OSCs and RPs as they create their CMMC strategies. If you had a chance to watch the episode, or if you are preparing for your CMMC assessment what other scoping-related questions/issues did you have? Head on over to our Communities to start a conversation!