This webinar is published by Carnegie Mellon University’s Software Engineering Institute (CMU-SEI). Andrew Hoover and Katie Stewart discuss how to read and use the CMMC Level 3 Assessment Guide. This organization is very authoritative on all topics CMMC due to their role in helping the DoD create the model.
Additional review and information about the CMMC Assessment Guide is below the video.
CMU-SEI webinar on CMMC Level 3 Assessment Guide
Additional review and notes about the Assessment Guide
The CMMC Level 3 Assessment Guide can be found here:
How to give feedback on the Assessment Guide:
If you see something wrong in the Assessment Guide and wish to give formal feedback to the source, I recommend the following methods:
Feedback to CMU SEI: https://www.sei.cmu.edu/contact-us/
Feedback to the DOD Acquisitions Office: https://www.acq.osd.mil/cmmc/contact-us.html
Credit where it is due – 171A and the CMMC-AB Working Groups
I want to give credit to two major influences on the Assessment Guide. The NIST SP 800-171A (“A” for Assessment) document is essentially absorbed wholly into the CMMC Assessment Guide for Level 3. All 800-171-inherited Assessment Objectives were moved word-for-word from 800-171A. So lots of credit to NIST and their working groups for creation of this original document. Also, from what I’ve heard (I haven’t seen it myself), the current Assessment Guide uses a lot of the material provided by the CMMC-AB Working Group to the DoD. So well done to the CMMC-AB Working Group for doing most of the legwork on volunteer hours!
FCI and CUI
The level 1 requirements in the Level 3 document still use “FCI” only. They don’t mention CUI. This can lead to confusion about whether the Level 1 requirements also apply to CUI. They do, of course, because CUI is a sub-category of FCI, but it would be more clear to state “FCI and CUI” rather than just “FCI” in those items.
The word “Policy” conflicts between 171-inherited practices and CMMC Maturity Level practices
Use of the word “policy” is inconsistent within the Assessment Guide. The Maturity Level (.999) practices define policies in a very limited way per CMMI best practices. Several practices inherited from 800-171 use the word policy in cases where it makes more sense to reference “procedure” or “control” or “practice description”. For example:
- AU.2.044 AO states “[a] the organization defines one or more policies and/or procedures for the event types to look for when information system audit records are reviewed and analyzed;”
- CM.3.069 AO states “[a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;”
- SC.3.193 states [a] the organization has a security policy which restricts publishing CUI to any externally owned, publicly accessible information system;
My (Amira’s) complaint:
There are already implementation problems based on the CMMC Maturity Level definitions for policies.
If the recommendations in CMMC-AB Registered Practitioner training and CMU-SEI are followed to the letter, organizations would have one policy per CMMC Capability (50+ different policies) plus a minimum of one procedure or control document per capability to actually implement the policy (50+ different documents), to total upwards of 100 documents for CMMC level 3.
Almost every company today uses combination policy/control documents (20 or so) to both authorize and implement cybersecurity practices. This is technically allowed, but isn’t following best practices as described in the CMMC. It adds a slight worry about unfavorable assessment if a company sticks with their current document set.
Clarification / response about policies and procedures
Andrew Hoover from Carnegie Mellon University | Software Engineering Institute (from the video above) provided this response:
“Just to clarify, there is no requirement that you need one policy per capability or domain. We’ve mentioned in several of our blogs and podcasts that how an organization chooses to document their policies is entirely up to them.
In the blog linked below we say, “Even though an organization is required to have policy guidance for each of the 17 practice domains, they do not need to have 17 individual policies. A single policy could include directives for more than one CMMC practice domain. It is up to the organization to decide how they want to structure and document their policies.”
The same concept applies to the practices. In the same post we say, ‘The level of detail of a documented practice can vary from a handwritten desk procedure to a formal organizational SOP …’
I think it’s much more likely that the policy requirement for several domains would be included in a common document like an IT Security Policy. Same for the procedures.
Back to Amira – This description is much more achievable than my literal interpretation (which I wasn’t sure if I could perform for my own business or clients). Thank you very much for this response and clarification! I’ll stop complaining now <grin>
The Assessment Guide clarifies but also amplifies the requirements
My overall concern about this version of the Assessment Guide is that it provides too much information and clarification. You may be thinking at this point: “What did you say? Weren’t you begging for an Assessment Guide to clarify expectations?”
First off, my requests for an Assessment Guide were to answer questions about determining the scope of an assessment and identifying the materiality threshold (assessment term for deciding when a problem is big enough to fail an assessment). This version of the guide does not have that information in it!
What we really needed from the Assessment Guide was what was left out.
- SCOPE SCOPE SCOPE (ideally this would be in the Model document).
- What defines an effective segment / border, to take other systems out of scope (ideally this would be in the Model document).
- Whether and how to evaluate cloud systems.
- Whether and how to evaluate connected systems (such as MSPs or management processes).
- Whether we should evaluate FCI systems at ML1 and CUI systems at ML3 (assuming very good segmentation between them) and be able to grant the company an ML3 certificate.
- Whether a company could get CMMC level 1 for their FCI systems and CMMC level 3 for their segmented systems in two different assessments (there are major process issues at the contract officer side if that is the case, as we are seeing with the DFARS 2019 enforcement now).
- Whether CMMC ML3 assessment requires level 3 security for all systems that have FCI, which is almost impossible to do for medium and large companies.
- Does a requirement need to be perfectly implemented to pass, or is there some wiggle room?
But I digress. My original complaint was that the Assessment Guide adds too much information.
So what information is problematic?
The Assessment Guide adds Further Discussion, Example(s), and Potential Assessment Considerations to each practice. These topics typically add about 1/2 page of new information per practice. This information includes plain language explanations, best practice examples, and questions that can be asked during an assessment to gauge whether the right actions are being taken. Sounds good, right? More explanation is helpful, right?
The problem is that these pages of new information effectively add new requirements / expectations on top of the model, making it mandatory for companies to review both documents during their preparation. This is counter-intuitive and just plain confusing. For example, if the Assessment Guide discusses a higher technical bar than the Model, but the company only performs to the Model document, should an assessor mark that practice “NOT MET”? I don’t know the answer to that. Let’s not put companies and the assessors in this situation.
Recommended action: All additional explanations in the Assessment Guide should be moved into the model document. Only Assessment Objectives (AOs) and Potential Assessment Methods and Objects should be listed in the assessment guide. Note: This follows how the NIST SP 800-171A guide is designed.
The Assessment Guides replace the CMMC Model Appendix
My complaint that the Assessment Guide has more requirements than the CMMC Model Appendix set off a discussion on LinkedIn here.
We had a few authoritative figures weigh in that the CMMC Model Appendix is outdated at this point and the Assessment Guide should be the primary source of explanation.
Katie Stewart (CMU-SEI, from the video above) gave this clarification:
“I would also direct the readers to the errata document that states at the bottom of page 2 that the newly released assessment guides supersede the existing Appendix B. Future releases of the model will not include Appendix B.“
Regan Edens (CMMC-AB) gave this recommendation:
“my practical recommendation is … CMMC Practitioners should reference the Assessment Guide v.1.10 when guiding OSC’s on the path toward CMMC compliance and certification.”
This is important information. Spread the word.
Small mistakes in the document
John Cook, CMMC Registered Practitioner, pointed out that RE.3.139 only has 4 assessment objectives but in the example it references a 5th objective.
Several people have pointed out that the ML.3.997 practices for “Establish, maintain, and resource a plan…” skipped lettering for one of the assessment objectives [g]. This is repeated 17 times through the document (one time per domain).
Overall: Good start, please keep it up!
Thanks to the DoD and CMU-SEI for getting the first Assessment Guides out. Thank you for re-publishing them in a form that can be copy-pasted, in response to community request.
I hope this feedback is helpful as you develop the next version of the Assessment Guides. We are all together in trying to protect our country.
Author: V. Amira Armond (CISSP, CISA, PMP, MBA) is a computer systems architect, cyber-security consultant, and owner of Kieri Solutions LLC.
Kieri Solutions LLC is in progress to become a CMMC assessment organization and has several Registered Practitioner and Certified Assessor candidates on staff. Amira is also the chief editor for cmmcaudit.org, a public resource for news and informational articles about the Cybersecurity Maturity Model Certification.