A Practitioner’s Thoughts On CMMC

Editor’s comments:

This article is an excellent read if you have experience doing cyber-security compliance based on NIST SP 800-171 or DFARS 252.204-7012. If you don’t have prior experience on these topics, the article may not make much sense to you.

Of particular interest to me is the scoping conflict between FCI and CUI, which is discussed in the section Reciprocity Considerations. Organizations which need to protect CUI at level 3+ will normally want to segment their contract operations away from the rest of the company. This makes sense when you are only protecting CUI. But adding FCI to the scope is extremely confusing. FCI can be introduced by simple emails between the government and the sales department. Let’s say the contract requires CMMC Level 3. Does that mean the audit ignores the fact that FCI is on the corporate network and only considers the the CUI enclave?

Anyways, thanks to Tom for his in-depth article! Please comment with your thoughts.

A Practitioner’s Thoughts on CMMC

Published June 29, 2020

Author: Tom Cornelius, Senior Partner at ComplianceForge, Founder & Contributor at Secure Controls Framework (SCF)

The intent of this article is to generate a professional discussion on CMMC that will make its way to the DoD PMO to hopefully remediate several issues in future releases of that standard. This article is written from the perspective of a cybersecurity practitioner with significant experience on the topics of NIST SP 800-171 and CMMC who has genuine concerns with the current state of the CMMC rollout. Essentially, if a “CMMC superfan” has serious concerns, the CMMC-AB and DoD should take the time to pour a cup of coffee and consider the points that are raised in this article, as well as the recommended steps to resolve those issues.

I would be remiss if I did not voice my concerns about these issues and I welcome constructive feedback, so please feel free to comment. However, for those who may think I am merely bashing on the CMMC, CMMC-AB or DoD PMO that would be an entirely misguided assumption – I encourage you to rationally evaluate the issues I bring up before attacking my position. To date, I applaud what the DoD and CMMC-AB have done, but that does not mean the standard is without errors that need correcting.

As for the backstory on where I am coming from as an advocate for the Defense Industrial Base (DIB):

• I am a West Point graduate who served as an officer in the Army for over a decade and still lives by the concept of “Duty Honor Country,” so supporting the DIB is important to me since the DIB faces unprecedented threats from state actors across the globe.
• I know Information Assurance (IA). I successfully led efforts to take a prime contractor through DIACAP certification to earn and maintain an Authority To Operate (ATO), so I am intimately familiar with the significant effort it takes for a contractor to address DoD requirements.
• I’ve been heavily involved in NIST SP 800-171 compliance engagements with clients since late 2016 and have closely followed CMMC developments since it was first discussed publicly. I would categorize myself as qualified to discuss conflicting CMMC guidance.

The main issues this article addresses include:

1. Binary compliance (100% conformity to pass)
2. Non-Federal Organization (NFO) controls
3. FAR cybersecurity documentation requirements
4. Reciprocity considerations
5. CMMC as a “maturity model”

Issue #1: Binary Compliance

CMMC is a conformity assessment. If you are unfamiliar with what a conformity assessment is, NIST did a superb job writing NIST SP 2000-01 “ABC’s of Conformity Assessment” that is well worth reading to get a fundamental understanding of what the CMMC is meant to be. A conformity assessment is not meant to exact perfection in order for an organization to be awarded a “passing” compliance designation. It is meant to be a risk-based approach to determine if an organization conforms with a certain standard, not a binary pass/fail that requires 100% perfection in order to achieve a passing score.

There is an adage that “the path to hell is paved with good intentions” and I believe this is applicable in the DoD PMO’s overt disdain for the concept of a Plan of Action & Milestones (POA&M). If you are unfamiliar with a POA&M, it is a long-used, risk-based methodology to address control deficiencies through the application of compensating controls. You will find POA&Ms going back to DITSCAP and DIACAP, but it is still a valid way to remediate risk in NIST SP 800-171, RMF, FedRAMP, FISMA and even outside of the government with compliance obligations such as PCI DSS. Compensating controls are a good security practice, when done properly.

It is understandable that the DoD PMO has concerns with POA&Ms, based on the way the DIB abused POA&Ms with the rollout of NIST SP 800-171 in 2018. However, that doesn’t mean that POA&Ms are bad, just that remediation timelines and other parameters need to be applied to ensure POA&Ms are not abused.

Currently per DFARS 2252.204-7008(c)(2)(i) and 52.204-7012(b)(2)(ii), a POA&M is accepted by the DoD as a way to become “NIST 800-171 compliant.” What many are surprised to learn is that a POA&M is still a mandatory CMMC requirement (practice # CA.2.159). What this means is that when an Organization Seeking Certification (OSC) contracts a Certified Third-Party Assessment Organization (C3PAO) to perform a CMMC assessment of its security program, the OSC is required to have a completed or blank POA&M document in order to pass the CMMC assessment, which means there are no open deficiencies in any practice or process at the point in time of the actual CMMC assessment. However, the following day (and all the way through the next CMMC assessment) the OSC can fill a POA&M with deficiencies and be compliant with CMMC. That does not pass the common sense test.

Traditionally, a POA&M is used for where there is a legitimate technical or business process limitation, such as a computer-based manufacturing machine on the shop floor that is incapable of having antimalware installed since it is either locked by the Original Equipment Manufacturer (OEM) or there is a known issue where antimalware will break the machine. In this case, there is a clear control deficiency associated with the lack of antimalware being installed, but it is possible to reduce risk through the application of compensating controls, such as segmentation, IDS/IPS, enhanced monitoring, etc. Through the use of compensating controls (validated by a C3PAO) it is possible to reduce risk(s) associated with a deficiency in most CMMC practices. A POA&M would document the risk remediation action, which would ultimately still have to follow the POA&M acceptance process, as stipulated in DFARS clauses.

Potential ramifications of a prohibition on POA&Ms:

1. The binary approach to pass/fail will hurt the DIB, which is completely opposite to the intention of the CMMC. This prohibition on POA&Ms places many OSCs in an untenable situation where there are legitimate technical limitations that will cause the OSC to fail a CMMC assessment, even if the risks can legitimately be mitigated through compensating controls. This is echoed by Robert Metzger’s comments that this rigid approach “… is an absence of flexibility, a demand for perfection that I think is going to have to bend when you get into the real world where the customer or requiring activity will be satisfied with something less than 120 and will be interested in or willing to accept a POA&M when the choice is not having a vendor at all when it’s needed.”
2. There is no documented restriction on POA&Ms in the CMMC v1.02 model, so this prohibition is essentially an arbitrary order from the DoD PMO that does not have any basis in existing law or regulation. This opens the door for legal challenges from the DIB to this binary pass/fail “requirement” since it is not currently supported by DFARS, NIST or even CMMC v1.02.
3. This aggressive approach to “compliance over security” lends itself well to corruption, since there will be immense pressure for OSCs to pass at all costs. This pressure may lead to undue influence on C3PAOs to fraudulently pass an OSC’s failing practice(s) or process(es). It is not unthinkable for an OSC to bribe an assessor when there is a contract worth millions of dollars at stake. For those who dismiss any possibility of collusion, I point to the Enron scandal that both led to the demise of Arthur Anderson LLP and precipitated the Sarbanes Oxley Act (SOX) as an example to contemplate.
4. DFARS 252.204-7012(b)(2) is clear that any organization that stores, transmits and/or processes CUI must address NIST SP 800-171 controls, so CMMC v1.02 confuses the subject around protecting CUI in Level 2 practices, since Level 3 and above are meant for OSCs involved with CUI. Level 2 practices are insufficient to address DFARS 252.204-7012 requirements, since it is only a fraction of NIST SP 800-171 controls. CMMC Level 2 is essentially a “built-in POA&M” for OSCs not capable of meeting Level 3 compliance, since Level 2 is an arbitrary “baby step” for those OSCs that should realistically be a Level 3. CMMC states Level 2 is to “serve as a transition step in cybersecurity maturity progression to protect CUI” yet from a Level 3 OSC perspective, the DoD PMO / CMMC-AB precludes the acceptance of a POA&M for Level 3 requirements, when both stated CMMC Level 2 & 3 have terminology that focuses on protecting CUI.
5. It will be unavoidable to have cases involving a company that will be a designated a critical supplier of a product or service to the DoD, where failing to be CMMC certified would impact the military’s ability to support a mission. A willful decision to fail a military mission over a “CMMC compliance checkbox” will be unacceptable and in these situations, it is likely that a case-by-case waiver will be granted. This will set a precedent to bypasses CMMC and it would completely devalue the entire CMMC model, as it currently stands. The price of rigidity will mean the process will be bypassed, since CMMC compliance offers no room for less-than-perfection by the DIB. That scenario is a matter of when, not if.

Recommendations to the DoD PMO / CMMC-AB:

1. Since POA&Ms exist in current US Government laws and regulations, do not exclude the use of this as a method the DIB can leverage to be both secure and compliant.
2. Create parameters for what is acceptable to exist on a POA&M and the duration that would be considered acceptable for an OSC to organize resources to remediate the deficiencies. A great starting point would be NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 to leverage existing risk-ranking practices for core NIST SP 800-171 controls.
3. Use NIST’s parameters to develop a “passing threshold” for a CMMC assessment, similar to the concept of what is found in SOX compliance with defining risk-based criteria that would identify if one or more deficiencies establish a material weakness of the OSC’s security program. Any one or more deficiencies that are not material could then be remediated through a POA&M. This would allow for an interim certification and put a timeline on POA&M items that an OSC would have to engage a C3PAO to validate remediation efforts.

Issue #2: Non-Federal Organization (NFO) Controls

Not many people I speak with on the topic of NIST SP 800-171 or CMMC are familiar with NFO controls, but these requirements have been in NIST SP 800-171 since it was released. I’m not going to go into exacting lengths on the topic of NFO controls in this article, since you can read about it at www.nfo-controls.com to dive into greater detail on that subject. In summary, NIST 800-171 rev2 contains far more than just the 110 CUI controls identified in Appendix D. Appendix E lists an additional 62 NFO controls that are expected to exist for any organization that stores, transmits or processes CUI.

What this means is CMMC v1.02 only addresses a portion of what it requires to be considered “NIST 800-171 compliant” since it neglects NFO controls and only focuses on CUI controls. That is an apparent oversight of the current CMMC model.

Potential ramifications of a lack of NFO control coverage:

1. Without coverage for both NFO and CUI controls in NIST SP 800-171, there is no way to have reciprocity between CMMC and NIST SP 800-171.
2. OSCs focusing on just passing a CMMC assessment would currently be neglecting a significant number of NIST SP 800-171 controls, which are fundamental to protecting the confidentiality and integrity of CUI.

Recommendations to the DoD PMO / CMMC-AB:

1. Adjust the CMMC model to include coverage for all NFO controls. Several of these will be covered by Level 3-5 processes that require documentation (e.g., policies, standards, procedures, etc.).

Issue #3: FAR Cybersecurity Documentation Requirements

FAR 52.204-21 “Basic Safeguarding of Covered Contractor Information Systems” consists of fifteen “cybersecurity requirements and procedures.” CMMC expanded those fifteen requirements to make the seventeen Level 1 practices. FAR cybersecurity requirements are already addressed in NIST SP 800-171, so this is nothing new to those who are familiar with requirements to protect CUI.

From FAR, an organization that stores, transmits and/or processes Federal Contract Information (FCI) is required to “apply the following basic safeguarding requirements and procedures to protect covered contractor information systems” as it pertains to those fifteen basic cybersecurity requirements. FAR defines the term “safeguarding” to mean “measures or controls that are prescribed to protect information systems.” If you look up the term “control” in the NIST Glossary, you will see that the definition refers to documented policies, standards and procedures, so there is a tangible documentation requirement to address FAR 52.204-21. Where the FAR requirements become an issue is with CMMC’s lack of documentation requirements for Level 1 (e.g., no process requirements).

FAR 52.204-21 has clear documentation requirements that CMMC v1.02 ignores for Level 1 OSCs. The FAR controls are specifically focused on protecting the confidentiality and integrity of FCI:

• Documented procedures are explicitly called out in FAR 52.204-21 as a requirement; and
• Documented policies and standards are addressed in the “controls” requirement, since documented policies and standards would reasonably be necessary to direct the actions of employees/contractors/etc. as to their security requirements.

Potential ramifications of a discrepancy with FAR requirements:

1. Level 1 CMMC contradicts the expectations in FAR 52.204-21 for minimum safeguards surrounding the storage, transmission and/or processing of FCI.
2. An OSC could be lulled into a false sense of compliance by addressing Level 1 practices to pass a CMMC assessment with little-to-no documentation, while being non-compliant with FAR 52.204-21 by ignoring the expected documentation requirements.

Recommendations to the DoD PMO / CMMC-AB:

1. Add process requirements for Level 1 to meet minimum expectations for FAR 52.204-21 (e.g., .999 and .998 processes for all CMMC domains).

Issue #4: Reciprocity Considerations

Reciprocity is commonly defined as “the practice of exchanging things with others for mutual benefit, especially privileges granted by one country or organization to another.” There is considerable interest within the DIB to find ways to reduce compliance-related costs through identifying ways to implement reciprocity for CMMC with other cybersecurity-related certifications, such as ISO 27001, FedRAMP, HITRUST and AICPA Trust Services Criteria (SOC 2). Note – NIST SP 800-171 by itself is not a certification, but there is considerable interest to have some form of reciprocity between NIST SP 800-171 and CMMC.

This is another instance where something sounds good on paper, but when you get into the details it quickly falls apart. As the founder of the Secure Controls Framework (SCF), I am well versed on the practice of crosswalking cybersecurity and privacy laws, regulations and frameworks to find commonality. I’ve personally looked into the concept of CMMC reciprocity and explored the feasibility with an open mind, yet I keep finding the same answer – blanket reciprocity statements do not work with CMMC, since it is an apples vs oranges comparison when you account for assessment boundary scoping.

The reason any form of blanket reciprocity statements does not work comes down to scoping the FCI/CUI environment. ISO 27001, FedRAMP, HITRUST and SOC 2 certifications may address part of the FCI/CUI environment, but it is nothing that could be addressed through a blanket statement due to the fact that scopings between the various certification assessment boundaries will be different. The closest way reciprocity would work with CMMC is with a hypothetical FedRAMP example where the OSC has its entire FCI/CUI environment hosted in a FedRAMP-certified cloud instance, including a Virtual Desktop Infrastructure (VDI) where there is no storing, transmitting and/or processing outside of the FedRAMP cloud environment. It is possible, but that would be applicable to a very small portion of the DIB and would only work for OSCs that solely perform consulting services. That FedRAMP example would not be applicable for any OSC that performs manufacturing, since that would require CUI to leave the FedRAMP instance (e.g., machine shop floor).

Potential ramifications of blanket reciprocity statements:

1. In order for an OSC to legitimately claim reciprocity, that OSC would have the added burden of creating overlapping network diagrams / data flow diagrams that would be necessary to clearly demonstrate how assets and processes within the CMMC assessment boundary are equally protected for CMMC practices under a blanket reciprocity statement (e.g., what practices/process could be applicable from a recent ISO 27001 certification to the FCI/CUI assessment boundary).
2. Assumptions of blanket reciprocity statements would feasibly lead to failed CMMC assessments if the OSC does not perform its due diligence with scoping efforts, it will not have the appropriate application of CMMC practices/processes. Most OSCs lack specialized cybersecurity professionals who are well-versed in governance and compliance analysis, who would be individuals expected to perform that type of due diligence activity.

Recommendations to the DoD PMO / CMMC-AB:

1. Refrain from making blanket reciprocity statements for CMMC with other company-level certifications, since the devil is in the details.
2. Provide guidance to OSCs on “best practices” for how the OSC can possibly leverage recent third-party certifications to reduce C3PAO assessment efforts. This would require the OSC to have clear evidence of how the scope of the existing third-party assessment overlays with the FCI/CUI environment. The focus should be on how an OSC should assess applicability.

Issue #5: CMMC As A “Maturity Model”

Maturity models have been around for years. One thing that binds them all is the concept of “continuous improvement” where an organization can measure its capabilities against a benchmark and the expectation is for a continued progression from lower to higher levels of maturity.

CMMC focuses on business practices. For example, a landscaping company that has a DoD contract to mow lawns on a military installation could theoretically be a Level 1 OSC since the contract contains FCI. That same landscaping company will be a Level 1 OSC in 3, 5 or 10 years, since its business model will keep it at a Level 1 (e.g., mowing lawns with only FCI-related contracts). There is no “continuous improvement” for most Level 1 OSCs as that example demonstrates.

There is a widely-held misconception that a Level 1 OSC is going to be limited to small “mom and pop” companies, but that is an inaccurate assumption. An organization is designated a Level 1 when it only stores, transmits and/or processes FCI, not CUI. It is possible to have a Fortune 500 organization be a Level 1 OSC with a robust, well-staffed and mature security program. It is equally possible to have a small company with less than a handful of employees be a Level 3 OSC, even though it has no formal IT infrastructure or IT staff – just a completely virtual/remote workforce business model. I’ve personally worked with numerous smaller defense contractors that will clearly be Level 3 OSCs, since their business practices dictate that they store, transmit and/or process CUI as a prime or subcontractor. Size and maturity considerations have no corresponding influence on CMMC levels – it is all about the data classification.

At first glance, the CMMC looks like a traditional maturity model with its 5 levels and increasingly stringent requirements. However, when you take a closer look at what CMMC levels focus on, it is clear that evolving maturity is not the focus of CMMC. The reason I state this is CMMC levels are focused on data sensitivity-based business practices and do not involve evolving maturity:

• Level 1 focuses on minimum requirements to protect FCI;
• Level 2 is supposedly a “baby step” towards level 3, but that is fraught with its own issues (see Issue #1 POA&MS);
• Level 3 focuses on necessary practices to both FCI and CUI;
• Level 4 and 5 add a risk-based component specific to Advanced Persistent Threats (APTs) that the DoD will supposedly designate for select OSCs that are at a higher risk for APTs.

Potential ramifications of a labeling CMMC as a maturity model:

1. Undue anxiety by Level 1 OSCs that misunderstand future requirements, where OSCs feel they have to attain a Level 3 certification in the future, when the OSC’s business model is static and does not plan to involve CUI.
2. There is contradictory information in CMMC v1.02 about CUI in Level 2 practices that could lead to non-compliance with DFARS 252.204-7012 for Level 2 OSCs. Any organization that stores, transmits or processes CUI must address the complete NIST SP 800-171 CUI and NFO controls (in addition to the other 20 non-NIST SP 800-171 practices in CMMC v1.02). There should be no discussion of CUI in Level 2, just Level 3 and above.

Recommendations to the DoD PMO / CMMC-AB:

1. As referenced in Issue #1 about POA&Ms, where CMMC Level 2 is essentially a “built in POA&M” for OSCs not capable of meeting Level 3 compliance, Level 2 should be eliminated. Streamline CMMC to three levels: (1) FAR cybersecurity requirements, (2) NIST SP 800-171 CUI & NFO controls and (3) NIST 800-171 CUI & NFO controls, with the addition of NIST 800-171B controls to address the risks associated with APTs.

Summary

In conclusion, the DIB brought CMMC on itself from a failed adoption of NIST SP 800-171 in 2018 due to contractors’ underwhelming adoption of those requirements. However, the current version of CMMC overcompensates with excessive rigidity. A “happy medium” is necessary, where there is a third-party assessment component to keep the DIB honest, but a risk-based approach governed by the CMMC-AB to determine “acceptable risk” that takes real-world technical and business process limitations into account. We all benefit from a healthy and secure DIB that makes quality products and services, not from a DIB that is chasing compliance checklists, prioritizing compliance over security for fear of losing a contract.

About The Author

If you have any questions about this, please feel free to reach out. Tom Cornelius is the Senior Partner at ComplianceForge, an industry leader in cybersecurity and privacy documentation. He is also the founder of the Secure Controls Framework (SCF), a not-for-profit initiative to help companies identify and manage their cybersecurity and privacy requirements.