History
A long-time requirement for any auditable process or standard has been documentation. I sometimes think that early cave paintings quickly moved from art to “documenting your hunting process” for future audits. Perhaps it did not start quite that long ago, but we certainly have extensive documentation programs aligned with our many compliance requirements today.
CMMC, or the Cybersecurity Maturity Model Certification, is no different. As the new DoD standard for cybersecurity, it could be expected to have documentation requirements. CMMC has the added benefit of being a “capability maturity model.” Not surprisingly the capability maturity model was developed out of DoD funded research at Carnegie Melon University in 1986. Along the way, it has developed into CMU’s Software Engineering Institute’s (SEI) Capability Maturity Model Integration (CMMI), and now further honed into CMMC again by SEI. It has a significant amount of time to be polished at the Ph.D. level, and unfortunately in my view, that has led to over-complication.
In general, I am enormously supportive of CMMC for one key reason. Accountability. The assessment aspect of this is what was needed. Self-attestation was (again) an abject failure in driving human activity. Sounds good but doesn’t work. One of my first Chief Petty Officer’s told me, “you don’t get what you expect, you get what you inspect, Sir.” As usual, wise words. So for me, the key element of CMMC has nothing to do with the specific controls and has everything thing to do with checking to make sure that whatever controls you require are actually implemented.
Many of the modern standards are simply restacking the well known security control blocks in different groups and orders. There is some differentiation but in actuality on implementation, I think the existing mainstream cyber standards share far more controls than they do not. For myself, I like the NIST Cyber Security Framework (CSF) as the best of the current lot, primarily because it elevates detection, which I feel is the most under-appreciated cyber capability, to a root requirement. This helps drive detection as a main effort. I am not particularly hard over however on that view. Pick one. Do it well. That will serve you far better than any multitude of half-hearted efforts against the coolest cyber buzz word this week, quickly abandoned in favor of the coolest cyber buzz word next week. I was disappointed we chose to write a new standard at all, although the incorporation of NIST 800-171 does give it some continuity with other Federal cyber requirements.
Today
CMMC sought to incorporate the 20+ year history of CMM and CMMI and the result is not the right one for industry. I know that far more learned people than I have developed this, and for the most part, I have only very tactical input on the standard. The set of confusing, and redundant mush though that is “what do I actually have to write down,” is terrible, and should be a major point of revision. Even the SEI Ph.D.’s who wrote it contradict themselves in regular conversations about what a Practice is or is not, or have that relates to a process or a procedure. If SEI Ph.D.’s cannot always keep it straight how do we expect small and medium-sized business owners who only vaguely understand IT much less cyber to keep it straight?!
What should we write down?
In the standard and in our community forums there have been a number of answers to this question which often boil down to, “do what fits for the company.” That sounds nice but will it fly with the assessors? Maybe. No doubt over time we will develop a body of case law around what does and does not meet the standard. If you are starting from scratch, here are my recommendations on how to proceed. These recommendations are only recommendations. We do not have any hard and fast rules published for this yet.
Level 1 - You still need documentation
CMMC Level 1 is equivalent to the Federal Acquisition Regulation (FAR) clause 52.204-21 Basic Safeguarding of Covered Contractor Information Systems. It does not contain any of the CMMC “Maturity Level” requirements that call for documentation explicitly, but if you are going for a Level 1 cert, then you should plan on have a Cybersecurity Policy that addresses the 17 level one controls. Pay special attention to words like “define” in the controls. Those equate to having that written down somewhere. This will also put you on the path toward more advanced maturity and compliance in the future.
My recommendation: Write a Policy anyway.
With the advent of the CMMC Assessment Guides in December of 2020, Assessment Objectives were applied to the standard. These for the most part existed in NIST 800-171A, the assessment guide for 171, but now they are the foundation of the standard. Write everything with the assessment objectives in mind, not just the controls. This is critical! The assessment objectives add work, and they specifically add a lot of things that require documentation. Look for keywords like, “defined,” and “designated,” in the assessment objectives. Those things must be included in your documentation.
My recommendation: Explicitly include every assessment objective in your documentation.
Level 2 - Two ML Requirements
No one is aiming to be CMMC Level 2. It is simply the stepping stone to Level 3. At this level, two different Maturity Level or ML requirements kick in. These are ML.2.999 Establish a policy that includes [Domain Name] (so each of the 17 CMMC Domains), ML.2.998 Document the CMMC practices to implement the policy. Is this one document or two? It is two separate and explicit requirements. So far the collective wisdom is that it could be either.
My recommendation: Write a single cyber policy that covers all 17 domains. Write 17 separate Practice/Procedure documents to document your controls for each domain.
Could you go with one? Yes. Could you have 17 Policy and Practice combined documents? Yes. Could you have one Policy and one Practice document that covers all 17 domains respectively? Yes. At the high level though, I recommend that it is easy to do the high-level policy writing in a single document. Hopefully, you can divide up the responsibility for the practices amongst several people, and dividing those up gives you opportunities to spread the ownership.
System Security Plan. Recall that from your NIST 800-171 work and the DFARS Basic Self Assessment? Still in the requirements as CA.2.157. You must have and maintain a system security plan. I recommend continuing to use the NIST provided free template here. Just expand it to include the needed additional 20 security controls for CMMC Level 3 (which you will need in the next step). In my approach, I kept the SSP at the higher level and then referenced the individual Practice/Plans by domain with more detail. This serves as a documentation reference or matrix then for the future assessor. They understand SSP’s and giving them where they can go to look for more detail is an easy tool that smoothes an assessment, and makes sure you don’t miss anything in writing your doctoral thesis in cyber documentation.
My Recommendation: Include every control in the SSP and then reference your Policy/Practice/Plan documentation as applicable for more detailed information.
Level 3 - You need a Plan
At level three the requirement to ML.3.997 Establish, maintain, and resource a plan, comes into play. This is different than your SSP and has different requirements. The key question here, and why I think the model should be streamlined, is what is the difference between my practice and my plan? Do I need both? And hey I used to have all this, as a small or medium-sized company in a single policy document! Now I am writing War and Peace, is that needed? This does work out to be redundant and hard to sort. There are some instances, like your Training Plan, where having a separate plan document makes a lot of sense. How does my Configuration Management plan, differ really from my Configuration Management practice is murky at best. My recommendation: Combine your Practices and Plans into a single document, including the required elements of both. This helps cut down the redundancy aspect.
Maintain a Cyber Budget. Dollar resourcing is a requirement in the plan per the standard and must cover every domain explicitly. My approach has been to write and maintain a real annual budget and in each plan, just refer to it. It changes and having the budget linked into a controlled document, as needed to show assessment proof, is too complicated scattered across 17 different areas. Make one for cyber and refer to it, but make sure it covers all 17 domains and is referred to in all 17 Plans.
Level 4 - Time to Measure
At level 4 we have ML.4.996 Review and measure [Domain Name] activities for effectiveness. Metrics programs are advanced programs and take a fairly mature level of organization to make them truly effective. Fortunately, there is a big leap in the expected level of maturity at Level 4 and projected to be a corresponding reduction in the number of companies that need to go to this level. This may end up, as level 2, as simply a waypoint to level 5. My recommendation: Develop a Practice/Plan for Metrics. This will allow you to focus your metrics with a single practice owner who can help embed the habit of developing and maintaining metrics across your various domain owners. At this level, you will likely have at least several different organizations and teams involved. Metrics development can be challenging so having the right person to help drive that part of your program will be key.
Level 5 - Optimizing
At the final level of maturity, we receive our last ML requirement. ML.5.995 Standardize and optimize a documented approach for [Domain Name] across all applicable organizational units. A process for optimizing our operations is at the top of the maturity pyramid.
My recommendation: Wrap Optimizing into your Metrics Practice/Plan. Really optimizing is what you are gathering those metrics for. Your metrics and optimizing practices should be one and the same, and you can document your process for that in a single Practice/Plan.
Our standard has become “Document in the PPP,” or the Policy, Practice, or Plan. You may have a governance hierarchy in place already, or have none at all. How you fold this into your existing governance model is a critical decision to make early and stick with it. There are a number of ways to slice the documentation pie, and probably none of them are perfect.
As you dig to actually follow the guidance, understand that many other people when putting pen to paper have scratched their heads and said, “Now why do I have to write this… again?” You are not the only one confused by this! For now, we have the standard as written and all companies need to start documenting their cyber processes in a real way. Documentation is going to be key and my experience with outside assessments in this space has been document, document, document. The assessors, who more often than not are not technical people at all default to looking for controls to be addressed in the documentation. Explicitly include answers to every one of the 705 assessment objectives through level 3. Hard but a great risk reducer.