Nearly four years ago, the Department of Defense released the Cybersecurity Maturity Model Certification (CMMC). This was created as a complement to NIST SP 800-171, which focused on protecting Controlled Unclassified Information (CUI). If you are unfamiliar with what constitutes CUI, the simple way to think of it is to apply the broadest terms of privacy to any information that relates to any government relationship with a company. For example, any information related to general privacy, contract details, and law enforcement all fall under the definition of CUI. Each government agency has its own specifics about the CUI relevant to them.
The CMMC provides a method for agencies seeking government contracts to prove their cybersecurity preparedness through specific assessment criteria. The first version of the CMMC contained five levels, corresponding to greater cybersecurity hygiene. As originally reported here, these levels contained were quite involved, and, for a small company seeking to achieve certification, prohibitively expensive.
Welcome to CMMC v.2
Recently, a new version of the CMMC has been released, which hopes to make the process more accessible to companies of all sizes. The new version is reflective of a strong effort to streamline the process. A “notional” comparison chart is offered on the CMMC website:
It should be noted that although the new version seeks to clear up some of the problems of CMMC v.1, it is not without faults. In fact, the public comments solicited by the DoD indicate exactly why the update was initiated:
“The Department values feedback from industry, Congress, and other stakeholders and received over 850 public comments in response to the interimrule establishing CMMC 1.0. These comments focused on the need to enhance CMMC by (1) reducing costs, particularly for small businesses; (2) increasing trustin the CMMC assessment ecosystem; and (3) clarifying and aligning cybersecurity requirements to other federal requirements and commonly accepted standards. CMMC 2.0 was designed to meet these goals, which also contribute toward enhancing the cybersecurity of the defense industrial base.”
One of the most significant modifications in the new CMMC is the allowance for an organization to perform self-assessments in order to achieve compliance with Level one. Yet, there is still some apprehension with the proposed revision, as NIST has also been working to update SP 800-171.
While NIST and the DoD are not competitors, the sometimes fluid nature of document references gives a different impression. For example, as one commenter notes: “I believe there is a conflict because CMMC references NIST SP 800-171 revision 2 while DFARS 252.204-7012 references the version of NIST 800-171 that is ‘in effect at the time the solicitation is issued’”. The commenter continues, “I recommend updating DFARS 252.204-7012 to specify NIST 800-171 revision 2 in a separate rulemaking activity, otherwise when NIST 800-171 revision 3 is released, CMMC and DFARS 252.204-7012 will be in conflict regarding which revision of NIST 800-171 should be implemented.” It is easy to disagree with such a literal interpretation, as it is arguably presumed that the most recent document (in this case, NIST 800-171 revision 2) should be applied to any previously authored reference, however, that does not diminish the fact that some confusion exists.
Looking Ahead to Full Enactment
The new version of the CMMC is still in the “rulemaking process,” which means that it will not be in effect until the end of 2024, at the earliest. For those who are working to implement CMMC v.1, the effort will not be lost when the new version is finalized.
Anyone who has ever written a security policy document understands the intricacies not only of covering every aspect important to a particular organization, but also the practicality of implementation. While the new CMMC may be perceived as imperfect, it still offers more opportunities for organizations that were previously in peril of losing valuable government contracts.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of Tripwire.