Is CMMC really a maturity model?

Welcome to another instance of "Coffee Thoughts With Tom" - this article is about words having meaning, since the basis of Governance, Risk Management and Compliance (GRC) efforts is to identify and govern both technical and non-technical requirements that manage risk in an optimal manner - those efforts are directly tied to the terminology used in laws, regulations and contractual agreements. Specific to the Cybersecurity Maturity Model Certification (CMMC), the “elephant in the room” is the heavily-debated concept that CMMC is/isn't a Capability Maturity Model (CMM). Since CMMC is going to have such a significant impact on the Defense Industrial Base (DIB) and potentially the entire Federal contractor space, I think it is important to level set on some terminology. This article will demonstrate how CMMC is really not a CMM. Although some elements of a maturity model may seem to exist, CMMC is ultimately just a catalog of controls that is organized into five baseline control sets.

First off, a lot of DIB-focused cybersecurity practitioners are emphatic that CMMC practices and processes are not “controls” and NIST SP 800-171 is not a “control set.” In reality, they are incorrect in their disdain for the word “control” in this context, since when you look at the definition of control it means the power to influence or direct behaviors and the course of events – exactly what NIST SP 800-171 and CMMC are trying to accomplish. If you look at the NIST Glossary for how NIST defines the word “control,” it is a “means of managing risk” that includes policies, procedures, guidelines, practices, or organizational structures, which can be of an administrative, technical, management or legal nature. For control wording super-haters reading this article, it gets better where even ISO 27000 describes controls as a “measure that is modifying risk” that includes any process, policy, device, practice or other actions which modify risk. That means CMMC practices and processes are actually controls.

It might be useful to take a step back to try and understand why this argument exists amongst CMMC practitioners in the first place. Ultimately, controls are implemented to satisfy applicable statutory, regulatory and contractual requirements. Cybersecurity practitioners tend to avoid calling NIST SP 800-171 requirements and CMMC practices a “control” primarily because they prefer more granular, specific and quantifiable requirement statements (à la NIST SP 800-53 controls). Those same people tend to argue that these NIST SP 800-171 requirements and CMMC practices are really “control objectives” and not “controls,” since control objectives are generally less granular and focus on a broader intent than what is typical with a NIST SP 800-53 control. However, personal preferences do not change the meaning of the word “control” in this case. What is somewhat ironic, if you look at the NIST Glossary, you will not find a definition for “control objectives” since it is not a NIST-used term and you need to dig into alternative sources such as AICPA’s SSAE No. 18, Attestation Standards: Clarification and Recodification that defines a "control objective" as "the aim or purpose of specified controls at the service organization. Control objectives address the risks that controls are intended to mitigate." When you look at it from the control objective perspective, it is pretty clear that the “CMMC Capabilities” listed within the CMMC Model Main could be viewed as control objectives that exist as a middle ground between the 17 domains and the actual practices/processes (e.g. controls) that make up CMMC (see table 1 below from CMMC v1.02). At the end of the day, CMMC practices and processes are still the textbook definition of controls.

Capability Maturity Models

Now that the concept of controls is settled, how about we move on to dispelling Santa Claus, the Tooth Fairy and the Easter Bunny? Too soon? Okay, we’ll focus on CMMC as a maturity model instead. Maturity models have been around for decades. The Systems Security Engineering Capability Maturity Model (SSE-CMM) summarizes a CMM as “a framework for evolving an engineering organization from an ad hoc, less organized, less effective state to a highly structured and highly effective state. Use of such a model is a means for organizations to bring their practices under statistical process control in order to increase their process capability.”

For a little background on criteria from other maturity models, Information Systems Audit and Control Association (ISACA) acquired the CMMI Institute back in 2016 and their CMMI website has a lot of good information on it about what a maturity model is meant to be. Just to simplify a few key points from CMMI about maturity models:

• A CMM is meant to implement a “culture of continuous improvement”
• Process improvement goals should be based on an organization’s business objectives
• Practices provide an evolutionary path to performance improvement

When you shift your focus to CMMC, based on that CMMI criteria listed previously, you will see that:

• CMMC is not focused on a “culture of continuous improvement” and is intended to focus on protecting regulated data (Federal Contract Information (FCI) / Controlled Unclassified Information (CUI)) at varying, static levels of rigor. (e.g. Level 1 Practices for FCI protections and Level 3 Practices and Processes for CUI protections.)
• CMMC is agnostic of business objectives (see example later in this article about this topic)
• CMMC is not evolutionary, since Organizations Seeking Certification (OSC) have relatively static business models that preclude the need to advance to a more “mature” level.

I will agree that CMMC’s increasing levels do build on the previous level(s) to add new functionality or rigor, with a resulting increase in security capability. However, a cogent argument can be made that NIST SP 800-53’s low, moderate and high control baselines add “new functionality or rigor, with a resulting increase in security capability” as you progress from low to moderate to high, but does that stepped increase in functionality make NIST SP 800-53 a CMM? Absolutely not. The reason for this is a control catalog with different baselines is not intended to be a maturity model, because the defined baselines are intended to provide prescribed controls for mitigating specified levels of risks relative to protections for regulated data. This is also the basis for the NIST Risk Management Framework (RMF).

Within RMF, processes includes identifying data categories (NIST SP 800-60) in scope of a system boundary and categorize the potential risks relative to impacting the Confidentiality, Integrity and Availability of the identified data with the impact levels being Low, Moderate and High (FIPS 199). RMF then defines the overall system security category using the “highest water mark” impact level, which then designates the baseline control selection of NIST SP 800-53 controls designed for Low, Moderate and High Impact systems (FIPS 200). This approach was designed by NIST for Federal agencies to prescribe risk mitigations on regulated data. The same is true for CMMC, where the DoD prescribes a baseline control set for regulated data (FCI/CUI) and other risk factors (e.g. Level 1 for FCI protections, Level 3 for CUI protections, Levels 4 and 5 for additional protections against Advanced Persistent Threats (APTs)). Unlike RMF, the data selection and categorization work is already done for you with CMMC.

CMMC Does Not Have A Maturity Model “Sweet Spot”

When you look at the various maturity models used across industries, it is possible to identify a “sweet spot” that is unique to each organization’s risk appetite and budget. That sweet spot is made up of four different considerations:

1. RISK. Risk decreases with maturity, but noticeable risk reductions are harder to attain as maturity increases.
2. PROCESS REVIEW LAG. Process improvements increase with maturity, based on shorter review cycles and increased process oversight. Artificial Intelligence (AI) and Machine Learning (ML) can make process improvements near real-time in a world-class environment.
3. STAKEHOLDER VALUE. The perceived value of security controls increases with maturity, but tends to decrease once the value of the additional cost and complexity becomes harder to justify to business stakeholders or where cost and complexity outweigh the risk reduction benefits.
4. NEGLIGENCE THRESHOLD. Without the ability to demonstrate evidence of both due care and due diligence, an organization may be found negligent. In practical terms, the “negligence threshold” is when maturity is progressing out of ad hoc practices and are formalized to the point that documented evidence exists to demonstrate reasonable steps were taken to operate a control.

Since CMMC is not focused on evolving capabilities, CMMC does not have an organization-defined sweet spot. The reason for this is the CMMC level required is dictated to the OSC by:

• The type of regulated data (FCI or CUI); and
• If the OSC is required to address additional controls for mitigating risks relative to Advanced Persistent Threats (APTs).

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 the CMMC levels focus on, it is clear that evolving maturity is not the focus and intent of CMMC. The reason I state this is CMMC levels are focused on prescribed data sensitivity-based 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 section on CMMC discrepancies at the end of the article);
• Level 3 focuses on necessary practices to both FCI and CUI; and
• Levels 4 and 5 add a risk-based component specific to APTs that the DoD will supposedly designate for select OSCs that are at a higher risk from that specific threat.

If you look at what CMMC has for its 5 “maturity levels” you will see that it is not directly aligned with any of the major maturity models. It is a conglomeration of various concepts that might have once been used to design CMMC as a maturity model, but what remains is only a catalog of baseline controls. That rigid structure of dictating to an organization the specific requirements it must meet is irrelevant to a “continuous improvement” strategy that a CMM is intended to address, since CMMC merely assigns a predetermined baseline control set to meet a certain data protection requirement.

What Are Other Maturity Models?

These are several legitimate maturity models that you can compare CMMC to:

• System Security Engineering Capability Maturity Model (SSE-CMM)
• Security & Privacy Capability Maturity Model (SP-CMM) (based on SSE-CMM)
• Control OBjectives for Information and related Technology (COBIT) maturity model (COBIT 4 maturity model)
• ISO 15504 (criteria used in the COBIT 5 maturity model)
• Capability Maturity Model Integration (CMMI)

You can download the graphic shown below to see a comparison of the various CMM level definitions for yourself:

CMMC Focuses on Business Practices

For a real-world example of how CMMC is focused on business practices, consider a landscaping company that has a DoD contract to mow lawns on a military installation. This landscaper would 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 is static and will keep it at a Level 1 (e.g., mowing lawns with only FCI-related contracts). That landscaper is not incentivized to increase that maturity level, so there is no “continuous improvement” for most Level 1 OSCs as that example demonstrates. Based on the type of regulated data that is stored, transmitted and/or processed by the landscaper, there is no reasonable path or incentive for “improvement” to Levels 2, 3, 4 or 5 and in practical terms it would be a foolish business decision for a landscaper to expend the time and capital to attain a higher level of CMMC certification.

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 dedicated IT staff – just a completely virtual/mobile/BYOD/remote workforce business model (note - the majority of the micro-smalls look like this at the 1-20 employee level). We’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 and risk to the DoD that dictates certification level.

CMMC Discrepancies That Compound This Issue

CMMC Level 1 is "Performed" and is directly tied to Federal Acquisition Regulation (FAR) 52.204-21, for the "basic safeguarding of contractor information systems that process, store, or transmit Federal contract information“ where:

• CMMC Level 1 does not have any specific documentation requirements.
• CMMC directly calls out that the focus is to protect Federal Contract Information (FCI) in Level 1.

Carnegie Mellon University's Software Engineering Institute (SEI) wrote the CMMC under contract for the DoD. SEI has some smart people and I find how CMMC completely glossed over the documentation requirements of FAR is pretty astonishing, so I’d be willing to bet it was politically-driven to reduce the complexity for Level 1 OSCs. Those Level 1 OSCs who listen to the DoD that they do not have to document policies, standards and procedures, those OSC will be in direct violation of FAR 52.204-21. At the end of the day, the DoD needs to fix that glaring inconsistency, since it provides conflicting guidance that puts Level 1 OSCs in legal jeopardy.

CMMC Level 2 is "Documented" and is intended for OSCs that should be Level 3, but are not quite there yet. 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 to include the CUI and Non-Federal Organization (NFO) controls (in addition to the other 20 non-NIST SP 800-171 practices in CMMC v1.02). For example, take a look at practice MP.2.120 that requires OSCs to “Limit access to CUI on system media to authorized users.” See the #2 in the practice identifier? That is a Level 2 practice, yet it speaks to protections for CUI. You’re right if you are asking yourself, “Why is there CUI mentioned in a Level 2 practice when those OSCs are not allowed to handle CUI?” That is just a confusing and contradictory statement - there should be no discussion of CUI in Level 2, just Level 3 and above. Since CMMC Level 2 is essentially a “built in POA&M” for OSCs not capable of meeting Level 3 compliance, Level 2 should be eliminated.

CMMC has a perceived distinction between “practices” and “processes.” Processes emphasize a combination of documentation (e.g. policies, procedures, resource plans, etc.) that are meant to provide evidence of both due care and due diligence. However, when reviewing the list of practices and processes you will see some cases where practices are redundant with process requirement, specifically around the practice calling for procedures, which is a pre-existing process requirement. Therefore, if CMMC is already asking for procedures in processes, it should not call for procedure-related documentation in practices. For an example of this unnecessary redundancy:

• AM.3.036 is a level 3 practice that requires an OSC to “Define procedures for the handling of CUI data.”
• AM.2.998 is a Level 2 & 3 process that requires an OSC to “Document the CMMC practices to implement the Asset Management (AM) policy.”

In Summary

On its surface, CMMC appears to be a maturity model, but it quickly falls apart when you start to “peel back the layers of the onion” and discover that:

• CMMC practices and processes are controls;
• CMMC is a catalog of controls, broken down to 5 baseline control sets that are prescribed to protect regulated data specifically; and
• CMMC is not a CMM, based on its lack of traditionally-expected maturity model criteria.

While CMMC lacks the concept of “continuous improvement” where an organization can both measure its capabilities against a benchmark and is expected to implement a continued progression from lower to higher levels of maturity, CMMC is addressing a glaring need within the DIB to meet a baseline set of cybersecurity requirements. Kudos to the DoD and SEI for their work on that front! It is just time to rebrand CMMC as something it is, such as “Regulated Data Security Practices” or something that is accurate and scalable beyond just the DoD and into Federal agencies.

Just keep in mind with CMMC that the DoD prescribes the baseline controls as a means to manage the DoD’s risks, not necessarily your business’ risks! No OSC should seriously consider itself “secure” by meeting just Level 1 or Level 3 CMMC controls. One reason is simply that CMMC only focuses on the DoD’s risk management for Confidentiality and Integrity of regulated data (FCI/CUI), while for the most part ignoring Availability (your ability to stay in business). The other reason is most OSCs also have other requirements that range from ITAR to PCI DSS to state data protection laws that they also have to contend with. CMMC / NIST SP 800-171 should be viewed as a threshold for establishing the “must have” security practices that a modern business should align with, since it is on its way to being a global “gold standard” for identifying the threshold for what would be considered negligent business practices.

About The Authors

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.

Asfand “Ozzie” Saeed is the Director of Cybersecurity Operations at Tiber Creek Consulting and the co-creator of IntelliGRC. Tiber Creek Consulting is a DIB-focused software engineering company that specializes in business process automation. Ozzie leads the team that provides cybersecurity services for federal agencies and commercial entities with a specialty in supporting the DIB. IntelliGRC is a software solution that intends to provide a new approach to the GRC space via automation and intelligence.