Cybersecurity Maturity Model Certification 2.0: What It Means for Higher Education

min read

The first iteration of the Cybersecurity Maturity Model Certification program (CMMC 1.0) approached cybersecurity as an abstract set of rules that were largely removed from how security is practiced. The changes in CMMC 2.0 seem to be a direct response to the weaknesses of CMMC 1.0.

Cybersecurity Maturity Model Certification 2.0: What It Means for Higher Education
Credit: vs148 / © 2021

When the Department of Defense (DoD) recently announced version 2 of the Cybersecurity Maturity Model Certification (CMMC) program (CMMC 2.0), I was encouraged by the clarity and practical thoughtfulness that went into the new program. I wanted to take a moment to call out some of the changes that I feel are worth highlighting and reflect on what lessons the infosec community can learn as a result of the abandonment of the original program.

The changes in CMMC 2.0 seem to be a direct response to many of the weaknesses of CMMC 1.0.

  • CMMC 1.0 required an external assessment for all environments, even at the foundational level (Level 1). The impracticality of providing sufficient assessors for more than 300,000 members of the Defense Industrial Base was clear. In CMMC 2.0, the majority of assessments have moved to self-assessments, which is consistent with previously established practices and the foundational level of required safeguards.
  • CMMC 1.0 was an entirely new set of standards. CMMC 2.0, while retaining the foundational Level 1 (L1) from the original CMMC specification, focuses only on NIST 800-171 and 800-172. In addition, the DoD has committed to basing future enhancements to the CMMC program on the NIST standards process.
  • CMMC 1.0 was generally a pass/fail assessment. With the introduction of somewhat limited Plans of Action and Milestones (POAMs), the DoD has acknowledged that the practical challenges of compliance require a measure of collaboration between the assessor and the assessed.
  • CMMC 1.0 requirements will never appear in any agreements. CMMC 2.0 requirements will not appear until the federal rulemaking process runs its course, which the DoD estimates will take anywhere from nine to twenty-four months.

So how do these and other changes impact higher education, and what should your institution consider as a result?

First, CMMC 2.0 truly establishes the seventeen Level 1 controls as the foundational baseline for all contracts, that is, all "Federal Contract Information" (FCI). While most of the L1 controls are (hopefully) being met in your administrative environments, now would be a good time to create formal assessment processes for your research programs. At UC San Diego, I'm considering approaching L1 as the foundation for a rewrite of our minimum security standards, applicable across all infrastructure.

Second, the new bright line for research cybersecurity is controlled unclassified information (CUI). If you maintain CUI enclaves, that's a great start, but it's time to start planning for research involving CUI that can't be moved into an enclave. The challenge of "securing in place" is much harder. Those without a sizable DoD footprint may think this is unnecessary, but remember, not only has the federal government leaned into CUI, but most sponsoring agencies have been following the CMMC program very closely. With the adoption in CMMC 2.0 of 800-171 and 800-172 as the standards for the foreseeable future, it's not hard to imagine others quickly following suit.

Finally, it's time to earnestly and honestly assess whether your information security function is resourced to support the broad imposition of security controls across your research mission. While it may be tempting to hold a bake sale, this is a great time to form or enrich partnerships with other campus staff members who support researchers. Research facilitators, research affairs staff, high-performance computing (HPC) staff, and divisional staff can and should play a role in supporting cybersecurity in research environments—especially when it comes to L1 processes and controls. Institutions will have to significantly increase their investments in cybersecurity and support for researchers over the next few years, and harnessing investments that are already in place is the best way to start.

As we at UC San Diego revisit our own very aggressive CMMC program in light of the release of version 2.0, one thing stands out: almost all the work required under 1.0 remains. We have hundreds of labs that will need (institutionally assessed) L1 certification. We have CUI in agreements that must continue to meet 800-171, whether they're assessed externally or through a self-assessment process. We'll need to create new processes and services for researchers. These new capabilities will need to provide highly secure services across domains and do so in such a way that avoids disrupting science. Plus ça change, plus c'est la même chose.

Yet, as a security professional, I feel compelled to ask what cautionary lessons can be learned from the dismantling of CMMC 1.0? Surely there was no shortage of very bright, dedicated professionals contributing to the program—people who viewed CMMC 1.0 as a critical leg in our national defense and approached it with the requisite seriousness. I know some of those people, and they continue to have my utmost respect. In addition, the original maturity model always struck me as a pretty reasonable way to divvy up the controls, so the basic logic of the framework made sense.

However, mistakes were made in planning for and establishing CMMC 1.0—mistakes that reflect a systemic failure in its approach. For example, I never understood how something could truly be a maturity model without incentives to move an organization from one level to the next. A maturity model without an agent of maturation is just a set of standards to be met. Moreover, did anyone honestly believe there'd be enough assessors for a 2020 kickoff or the full application of CMMC requirements across all DoD contracts just a few years later? If we look at other highly regulated industries, points of comparison start to emerge that help to explain where the CMMC train may have jumped the tracks. Ask any doctor about the bureaucracy associated with practicing medicine and they'll tell you that in highly regulated spaces, regulatory bureaucracies tend to become industries unto themselves. It's possible to see CMMC 1.0 in the same light: a failure largely because it required establishing an enormous, healthcare-class bureaucracy that couldn't be created out of whole cloth.

In the abstract, CMMC made perfect sense: define a standard, collect data proving you're meeting that standard, and ask a third party to validate that you're meeting the standard—wash, rinse, and repeat. But is great security merely adhering to highly refined and relatively static sets of controls? Should security necessarily require the kind of overhead that is implicit in CMMC 1.0? Our world is full of parallels. Regulations are written that are blind to the agency of human psychology as well as operating principles and processes driven by inherent necessities, and they require ever-increasing and expensive policing.

Are we, the community of security professionals, complicit in the collapse of CMMC 1.0 through our adherence to the theology of control sets? Security as practiced is tremendously nuanced and highly contextual. The great NIST library of 800-53 is just that, an inventory of controls from which to choose as appropriate for a given problem.

Cybersecurity is not merely a set of regulations; it is a living, breathing program that exists at the intersection of principled best practice (control sets) and reality (systems as designed, deployed, and curated). That is to say, a successful security program must impact behavior and thinking and thus encompass the intellectual style in which systems are architected. The overarching mistake inherent in CMMC 1.0 is that it approached cybersecurity as merely an abstract set of rules to be adhered to, without sufficient thought to the implications of the supporting bureaucracy.

Marrying regulations with security as lived is a high bar to strive for. All of us get daily value from policies and regulations that are little more than control sets, which we leverage as proxies for our limited span of control. A standard is not merely a blueprint, though. It's also a liability shield, protecting us from accusations of incompetence when our efforts prove to be for naught. CMMC is not dead, and the challenges it presents to our campuses remain daunting. However, I hope we can take some time as a community to learn from the DoD's move to CMMC 2.0 and ask ourselves whether tomorrow can be more than a more rigorous today.

Mike Corn is Chief Information Security Officer at UC San Diego.

© 2021 Mike Corn. The text of this work is licensed under a Creative Commons BY-NC-ND 4.0 International License.