The origin story of Cybersecurity Maturity Model Certification (CMMC) goes back more than 20 years. Having roots in 32 CFR 2002, the Homeland Security Act of 2002, and the 2010 Executive Order 13556, the standard’s public narrative is the result of more than two decades of lawmaking and bureaucratic shuffle. The cast of characters has changed with elections and rule iterations alike. The rhetoric has been muddied by NIST-speak. In some cases, the requirements themselves have been outmoded by the lightning speed of modern technological advancement.
NARA to NIST. NIST to DoD. Elected official to appointed administrator. Year to year. And so on. As a result, the process has produced a kind of oral tradition, complete with a number of CMMC myths.
These myths are the work of several “generations” of community professionals. They are also the subject of growing attention in the wake of the recent CMMC 2.1 update. Below, I consider seven foundational myths that have clouded the CMMC narrative — for both rulemakers and those who must implement the requirements.
1.“CMMC is just the basics.”
The very first public draft of NIST SP 800-171 “Protecting CUI in Nonfederal Systems” was published in 2016. Its Abstract claims,
"NARA has taken steps to alleviate the potential impact of such requirements on nonfederal organizations by jointly developing with NIST, Special Publication 800-171 — and defining security requirements for protecting CUI in nonfederal systems and organizations. This approach will help nonfederal entities, including contractors, to comply with the security requirements using the systems and practices they already have in place, rather than trying to use government-specific approaches."
This illustrates the original, guiding understanding behind 800-171; government contractors could not and should not be held to the same standards and methods of information security as government entities. Nonfederal organizations can’t be expected to support the financial and temporal demands of a federal-level cybersecurity program. CUI needed to be protected, but it was recognized that a seamless lockdown of the information could not be the program’s goal.
This original intent has been repeated to the Defense Industrial Base (DIB), and behind closed doors at the DoD, for over 8 years now. It morphed, somewhere along the myth-chain, into “CMMC is just the basics.” The platitude, however, lost its ground as the CMMC rule was twisted into the zero risk-acceptance model it is today.
So what exactly does CMMC ask of contractors? NIST SP 800-171 Revision 2 includes 320 assessment objectives (requirements). Among these are requirements that necessitate the acquisition of expensive tools, or outlaw the use of common, useful ones. Uniquely, CMMC also requires a near-perfect implementation rate. Under CMMC 2.0, two-thirds of the assessment objectives are no-fail. If a contractor fails to implement a single one of these no-fail controls, they will be ruled non-compliant. If the missed controls add up to more than 27 SPRS points, they will be ruled non-compliant. If they fail to remediate any missed controls within 6 months of the assessment, they will be ruled non-compliant.
Given the holistic nature of the standard and its high bar for success, the average cost of compliance to small and medium-sized contractors can exceed $100,000 annually, and that’s without expert consulting to ensure the money is well-spent. The ongoing maintenance of that compliance is, at the very least, one person’s full time responsibility.
Given this, two stories exist in tandem: 1) CMMC is super-duper simple (“I can implement this standard on my home network in 30 days”) and the DoD is just swinging by to make sure the basics are buttoned up, or 2) this standard is asking for a scrupulous execution of hundreds of essential requirements, and any minor control failure ought to result in a ruling of total noncompliance.
This leads to our next myth.
2. “NIST SP 800-53 is harder than CMMC.”
800-171 has fewer controls, perhaps. But the assessment and certification process is massively more challenging than what the government faces in their own internal certifications. As discussed above, 171 was originally intended to ensure the standards imposed on contractors to protect CUI weren’t as demanding as those put forward in federal systems via 800-53. So the myth that 800-53 presents a stricter set of controls was originally a true account. However, today, two major differences between the two documents mitigate this: 1) 800-53 enforcement allows government agencies to mark controls “not applicable,” “risk accepted,” or “waived,” and 2) CMMC 2.0 enforcement of 171 requires contractors to attest to total, ongoing compliance.
Let's start with the latter. The DoD CIO’s office will never, ever be in a position to make such a legally binding commitment as 100% implementation with no N/A etc for DoD networks. Why? Because it’s 2024. The DoD is an organization of enormous complexity, with thousands of moving parts. In the cyber world, things change from moment to moment. The IT guy in the basement tweaks the firewall rules so he can look at vacations on VRBO. A maintenance person two buildings over unplugs something important. The guest log fell under the desk and we forgot to have the fireman sign it because a trashcan was in flames. Whatever.
Information security programs are always works in progress. Requiring 100% compliance to such an enormous list of requirements at any point in time is a challenge, but in an ongoing capacity, it's not executable. This is a burden laid on contractors by CMMC 2.0, and left altogether out of government enforcement of their own controls.
But what of the former about Not Applicable? Nonfederal entities are not allowed to name assessment objectives Not Applicable, while the Federal authorization process allows government entities to do just that, in addition to “risk accepted,” and “waived.” If a contractor wants to eliminate a requirement because the corresponding portion of their architecture does not exist, they need written approval from the DoD CIO’s office.
This is particularly apparent in the tailoring of controls. When the DoD decides that a control is too onerous, or when operations demand that they make changes to security requirements to meet operational requirements, they do it. There is no such allowance for industry, or at least a vanishingly small, near mythical opportunity for them to do so. The pursuit of perfection with no opportunity for variation makes the full and enduring implementation very hard and very expensive.
3.“We are just assessing the implementation of cybersecurity that has been required for years.”
This is no longer the case with the CMMC rules as written. The most recent version of the CMMC rule expanded requirements not only to contractors, but to their ESPs providing CUI Protection Assets or Security Protection Assets (SPAs) as well, regardless of whether or not they process, store, or transmit CUI. This presents a major blow to the contractors who have been developing their CMMC programs in good faith. It also eliminates the capability of the vast majority of the DIB to seek the outside assistance they desperately need. Finally, it quintuples the number of organizations that will require a certification.
In addition to adding never before seen cascading dependencies from other organizations, the application of these controls to broad new classes of assets and the invention of new classes of data (Security Protection Data) that must be protected with the same controls is a huge expansion of the requirements.
This is no longer just assessing the existing requirements. The scope of the DIB, in the context of the new CMMC rule, just swelled. Not to mention, the few companies truly prepared for CMMC just had to find new MSPs (of which exactly none are currently certified as required).
4.“This is only for contractors who handle Controlled Unclassified Information (CUI).”
Not any more. We have expanded this to a whole host of companies that have nothing to do with CUI; External Service Providers.
5.“We allow POA&Ms.”
Sort of. For a brief time, for a small number of controls. As discussed briefly above, two thirds of the controls are considered “no fails.” Moreover, under CMMC 2.0, missed controls must be:
a) among the one third of controls considered eligible for POAM to begin with,
b) not add up to more than 27 SPRS points, and
c) be remediated within six months of the assessment’s conclusion.
We have heard “we allow POAMs” quite a bit in the community as a rebuttal to the objections raised against CMMC’s stringent compliance requirements. But when one reads the fine print, this statement becomes less of a comfort, and, well, more of a myth.
6.“CMMC is a maturity model.”
CMMC was originally developed using Capability Maturity Model Integration (CMMI) as a foundation, at the recommendation of Carnegie Mellon. CMMI, like other maturity models, includes differing levels of “maturity,” or degrees of compliance, from Maturity Level 0: Incomplete to 5: Optimizing. The determination of an organization’s maturity level is the result of scoring in a variety of categories, taken together to create an average. Typically, Maturity Level 3: Proactive is considered sufficient for many of the security controls and contracts to which it applies. If a contract is particularly demanding or sensitive, a Level 4 or 5 Maturity may be required.
CMMC has maintained “levels” but abandoned the maturity models’ methods of 1) assessing the maturity of each control’s implementation and 2) allowing for variation. Essentially CMMC now demands Level 5 maturity for every control and varies the levels by adding more controls that require Level 5 maturity (perfect and complete implementation everywhere). There is pass, and there is fail, and passing requires a perfect score. The only remnants of a maturity model approach to be found in the standard today are in its name.
7.“The money should have already been spent, so don’t bother the DoD about cost.”
The incoming CMMC final draft has often been described to me as a runaway big mac truck, moments from sliding into a busy intersection against the red light. It will create a crash, but no one quite knows where all of the pieces will end up.
Small businesses, as has been made clear by many a Cyber-AB Town Hall, are the knowing sacrifice made by the authors of this rule for the sake of information security (which admittedly, has been insufficient in the DIB for decades).
Conform or leave the DIB. We are not concerned by DIB shrinkage. CUI requires the same protections everywhere, whether it's held by a supermajor worth billions or in Mom and Pop’s Machine Shop. This is directly at odds with the Small Business Goals regularly published by the DoD; but it is a large organization with many stove pipes that do not always communicate well.
Small businesses make up the majority of the DIB right now; many of whom are subcontractors with critically needed subject matter experts, or small shops specializing in that one kind of bolt or screw. These small businesses cannot bear the costs of CMMC. They live below the ‘cybersecurity poverty line,’ a.k.a. their gross income cannot cover all the costs of a compliant cyber program. They will either dissipate to nothing, leave the DIB, or be subsumed by a larger monopoly in the wake of “the crash.” The large and medium-sized businesses who survive “the crash” will be those best able to transfer the enormous costs of CMMC onto the DoD. One estimate projected at least a 10% cost increase for all DoD weapons systems.
Beyond the devastation to thousands of DIB small businesses and the eye-watering costs to taxpayers, all of this implies a loss of expertise, and an unquantifiable impact on the timelines and quality of work essential to national security. This kind of long-ranging economic turnover may even lead to complications as serious as those the CUI program was designed to prevent.
(Think Boeing 737 boltless doors. Now how will that work out on a nuclear submarine?)
(But hey, at least their encryption is FIPS-validated.)
In the end, these myths weave together, creating a picture of a cybersecurity standard somehow basic, essential, and overdue, and yet devastating to the DIB. 171, and by extension CMMC, began as an effort to apply necessary information security protections to government information outside of government systems. This we need to do!
However, over the course of decades of employee rollover, publishing and rescinding governing documents, delays, and rapid technological advancement, the goal, the narrative, the standard itself changed. The intent to introduce basic cybersecurity requirements without overburdening contractors morphed into contractors don’t think protecting CUI is as important as minimizing overhead, and I need to create a rule that forces them to eliminate all risk in its handling.
Notably, the DoD calls their own process the Risk Management Framework, because for their networks, it is recognized that eliminating all cyber risk is not possible. We have lost that key point in building these requirements for industry. The consequences of this will be brought not only to the Defense Industrial Base, but to the DoD and its constituents if these myths are not recognized for what they are. Beginning with “CMMC is just the basics.”