Making The Case for CMMC

Dr. Thomas Graham addresses critics and clarifies CMMC facts

Published 6.26.2024

Redspin Blog

Author: Dr. Thomas Graham VP and CISO, CCP/CCA/CMMC Instructor 

There has been a recent surge in articles and opinion pieces claiming that the Cybersecurity Maturity Model Certification (CMMC) is flawed and unnecessary for the Department of Defense (DoD). While many of these critiques lack sound reasoning, we rarely see responses or clarifications from those directly involved in implementing and working with CMMC. Perhaps this is a diatribe born from frustration, but here I am, addressing some of these recurring themes and responding.

First, the biggest argument against the program is the cost of compliance.

The cost discussion generally falls to the implementation costs of the requirements/practices. This discussion and the people leveraging the comments about the cost need to review the information better. CMMC is not the implementation requirement. The implementation requirements are from DFARS 7012 and have been enforceable since December 31^st, 2017. The DoD has continued to state that the cost of implementation was adjudicated during the DFARS 7012 rulemaking. The actual cost for Defense Industrial Base (DIB) organizations imposed by CMMC is the third-party assessment if you store, process, or transmit Controlled Unidentified Information (CUI) per a contract or flow-down requirement (as of June 2024). A third-party assessment is the same requirement as in other regulated industries, and while new to the DIB, it has been a long time coming. DFARS 7012 required self-attestation, but once the DoD started performing “spot checks,” they found organizations that self-attested were often failing, and sometimes failing miserably, when a third party (the DCMA) came in to do an independent assessment. Either these organizations did not know about the requirements, did not know how to implement them correctly, or just ignored them. Because of this, something had to be implemented to ensure the information was properly protected, leading me to the second point.

Second, the complaint that CMMC is a point in time, not truly risk-based, and too prescriptive in nature.

Yes, it is a point in time, as it is an assessment, not an audit. There is a difference in these terms, even though they are often used interchangeably. An assessment relies on sampling and review of evidence from an organization to ensure that procedurally, they are doing what they are supposed to do. In an audit, everything is essentially checked over a period of time to ensure compliance. CMMC is not an audit as every system, user account, etc., is not being checked. Regarding it being risk-based, in truth, it is. There is little prescriptive about the requirements as the NIST framework (800-171r2) at heart seeks to mitigate risk. Also, if you look at the objectives in the CMMC L2 Assessment Guide, you will find the objectives essentially broken into two components:

1. The organization tells you how they define, identify, specify, or document the requirements and
2. Prove that you are implementing it in the way you have defined, identified, specified, or documented it.

CMMC is not a prescriptive process such as the DISA STIGS identify. Instead, the implementations can vary from one organization to the other. If you look into it, there are only a few prescriptive items, such as the requirement for FIPS 140-2 validated encryption to protect CUI when it is being stored, processed, or transmitted.

Third, the protection of CUI is at the heart of the DFARS 7012 requirements.

This data designation, not a classification, was initially born from the 9/11 Commission in that they found Federal Agencies did not have a standard way to designate data to share. Thus, CUI was born. Is it the crown jewel of our nation’s security? No. However, this could be information that, if modified, when utilized upstream, has serious consequences. A friend, Robert Hill, CEO of Cyturus explains it best:

Imagine an organization that makes gaskets for a fighter jet. These gaskets have particular configurations and measurement requirements. Now imagine that a malicious actor gains access to this information and changes the size by only 2mm. Now, unless the organization has monitoring in place, they continue to produce these gaskets in the wrong size. They are fielded, and now we do not have replacements that actually fit the parts they are supposed to. While you may think big deal, it is only a gasket! Well, if you don’t believe that gaskets are important, I advise you to go look at what caused one of the Shuttle Disasters.

Finally, the argument has been made that the items to be implemented are based on DoD requirements.

While it is true that CMMC comes from the DoD, the requirements are not DoD-based. They are NIST and apply to the type of information as a baseline, not as an all-encompassing panacea. It’s the same as when you look at HIPAA requirements in healthcare, PCI requirements in the financial world, or even the new minimum requirements that the SEC requires. These are minimums, meaning they are the foundation that companies should build from, not the goal they should strive for.

As with any new program, CMMC has its proponents and detractors. It’s crucial to understand the context and motivations behind opinions around CMMC, including my own. I firmly believe that CMMC is a necessary step forward. While there are undoubtedly issues to be resolved as the program is fully implemented, speculation is all we have until the work is done. Change is inevitable, and just as the DoD’s processes have evolved over time, so will CMMC. The key is to start. Without taking that first step, progress is impossible. So, let’s begin this journey toward stronger cybersecurity together.