The Cybersecurity Maturity Model Certification (CMMC)

Part 1: Why do we need another framework?

By: Shawn Scott, Vice President of Success at PlexTrac, Inc.

CMMC PART 2 | CMMC PART 3

If you even tangentially touch the world of U.S. Federal contracts, you have undoubtedly heard about the looming introduction of a new framework for assessing cyber maturity: The Cybersecurity Maturity Model Certification (CMMC). The CMMC is one of the most significant regulatory requirements ever imposed on industry suppliers to the Federal Government, and its introduction has resulted in much controversy and gnashing of teeth. However, the Feds see this new certification as so important that not even COVID-19 has delayed implementation. And it is now here — like it or not.

If you are a federal contractor, you undoubtedly have concerns about the cost of compliance, and perhaps are even concerned whether your organization will even be able to compete for future contracts. These concerns are valid, but so are the requirements that resulted in the creation of the CMMC. This article won’t argue whether or not the CMMC is the correct solution to the underlying requirements. However, by understanding those underlying requirements, we at least hope to help organizations achieve some degree of acceptance and begin to focus on implementation. Thus, in this first of a series of articles on the CMMC, we will examine the requirements and the prior failed attempt that brought us to where we are today.

Controlled unclassified information (CUI) is everywhere

The products which we rely upon for our national security are the result of immense investment, and our technical edge is how our nation of ~350 million maintains military superiority over more populous nations. Our military and other federal agencies have long sought to protect the performance data for these products through a combination of technical, physical, and administrative controls. For the most part, they have done a fairly good job despite the efforts of concerted espionage programs by our adversaries (and sometimes, even our friends). However, even if the feds were perfect in their defenses, a glaring problem remains.

The federal government doesn’t actually make the vast majority of products that provide us with our technical edge. They issue contracts to prime contractors to deliver these products — big names that you have undoubtedly heard of like Raytheon, Lockheed Martin, L3, and others. These are giant organizations that generally have robust, mature information security programs. The “primes” have long been subject to stringent security requirements based on control frameworks like NIST 800-53.

But most national security-related products are immensely complex, made of tens of thousands discrete parts. No single prime contractor possesses the in-house expertise or manufacturing capability to deliver all the components necessary to fully assemble the final deliverable. Instead, they act as integrators and program management for a vast network of hundreds of thousands of smaller suppliers. The collection of all these suppliers and the primes are referred to as the Defense Industrial Base (DIB).

Many of these sub-contractor suppliers are small — some very small. These are the organizations that provide everything from the covert LEDs used in aircraft lighting to the gear assemblies used in the drivetrains of fighting vehicles. The specifications and performance data of these sub-components may not be classified, but they are still sensitive. Disclosure of this information by itself may not result in significant harm to our defense capability. However, if aggregated with data from related sub-components, the situation can change. If you look at an individual puzzle piece, you can’t tell what the picture looks like when complete. If you have 25% of a puzzle put together, with a little thought and context it becomes very easy to surmise the content of the final picture.

In a perfect world, we would classify the entire supply chain down to the smallest ball bearing. But that is unrealistic — procurement costs would be astronomically higher than they already are. (Anyone remember $600 toilet seats?) That’s not to mention the problem with providing and maintaining security clearances for the millions of workers that touch these products.

Our adversaries have long recognized this inherent weakness in the supply chain for federal defense contracting. So while advanced persistent threats (APT) do target our federal agencies and prime contractors, they often achieve a greater return on investment from targeting the smaller suppliers. Given the relatively small size of many of these suppliers, it is not unexpected that many have immature information security defenses. So how do we reconcile the “American way” of distributed, private-sector procurement with the requirement to safeguard our intellectual property?

The first effort: NIST 800-171

Before a solution could be implemented for how to safeguard information, the feds needed to define what information to safeguard. “For Official Use Only” has long existed as a classification in the DoD, but standardization amongst all federal agencies has been lacking on both what information should be treated as sensitive and how to protect that information.

As far back as the 9/11 Commission Report, the interagency community recognized that the disparate control mechanisms for sensitive but unclassified information were an impediment to horizontal information sharing. In 2010, Executive Order 13556 established a formal program for unifying the agencies’ handling of controlled unclassified information (CUI). However, it wasn’t until November 14, 2016 that 32 CFR Part 2002 was finally published, establishing standardized data labelling for CUI across the federal landscape.

With a common understanding of what to protect in place, the remaining issue was how to protect it.

The National Institute of Standards and Technology (NIST) was once again charged with defining the set of controls necessary to achieve the desired level of protection. In June 2015, NIST published the first version of Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.

This new set of controls was a distillation of the more robust standards found in FIPS 200 and NIST 800-53, and compliance with these controls was made mandatory as a precondition for award of federal contracts that involve CUI. Beginning on January 1, 2018, DoD contractors were required to achieve a baseline level of compliance with these controls. Problem solved, right?

Unfortunately, NIST 800-171 came with an Achilles heel that caused many security professionals to correctly predict that it was doomed from the start. Thanks in no small part to the lobbying efforts of the same contractors that NIST 800-171 was designed to secure, compliance was determined by self-attestation.

Security isn’t cheap, and defense contractors are not non-profit organizations. Self-attestation created an incentive for organizations to rate their compliance levels generously. It was no surprise when audits of these self-attestations were showing up to a 90% non-compliance rate for self-attestations among organizations that claimed compliance.

Shocking.

NIST 800-171 also suffered from it’s simplistic “yes/no” method of evaluating controls areas. Neither the strength of the solution nor the maturity of the process for maintaining the solution were considered. Once a bare minimum of compliance was obtained, there was no incentive to work towards a more robust security posture. So even if respondents were being truthful in their self-attestations, all we really could be sure of was that they hadn’t left the front door completely open. That’s checking a box, not security.

The CMMC is born

With the early skepticism of information security professionals buttressed by the deplorable audit results, things clearly had to change — and boy, have they changed fast. If there is a good news story to the failure of NIST 800-171, it is that corrective action has been swift.

Within 18 months of the rollout of the NIST 800-171 requirements, the DoD initiated an effort to replace the failed program. Bringing together experts and stakeholders from academia and industry, a collaborative initiative was launched to address the two fundamental flaws that we have discussed. By November 2019, just 23 months after NIST 800-171 compliance became mandatory, a draft version of the replacement program was unveiled: The Cybersecurity Maturity Model Certification (CMMC).

In our next installment in this series, we will discuss the major differences between the legacy NIST 800-171 program and the new certification. We will also cover the timelines for implementation, but spoiler alert: CMMC certification requirements are being written into RFIs being issued now.

We will present the CMMC as it stands and without editorialization. We have only just begun this new journey, and only with time will its effectiveness become evident. We should close, however, by remembering that both NIST 800-171 and CMMC are attempts at countering the very real threat insecurity in the DIB poses to our national security. Our solutions will always be imperfect, but we owe it to our community to continue improving, maturing and striving for a more secure tomorrow.