Discussion on N/A for 800-171 and CMMC

EDIT: This article was written for CMMC 1.0 and has not been updated for CMMC 2.0.

Usual disclaimers, this article and the opinions within are my own and not those of any of my employers. I also will not be attempting to sell you anything. Article is meant to create an open dialogue on the topic and nothing in here is legal advice. Hope you enjoy and find a benefit from the article.

This article will discuss some nuances around the use of the Not Applicable (N/A) status against NIST SP 800-171 controls and Cybersecurity Maturity Model Certification (CMMC) practices.

A couple of quick primers before we jump into the topic. DFARS 252.204-7012 clause dictates the use of NIST SP 800-171 security controls to protect Controlled Unclassified Information (CUI). DFARS 252.204-7021 dictates the use of Cybersecurity Maturity Model Certification (CMMC) practices to protect CUI. All 110 controls from NIST SP 800-171 overlap with CMMC, while currently the CMMC model adds 20 additional practices on top of the 110 controls from NIST SP 800-171 for CMMC Level 3.

As a first precautionary tale to the topic of Not Applicable, it is important to note that the 7021 clause does not replace the 7012 clause, and you will have both clauses in your contract. In other words, you will have to meet both 800-171 and CMMC if you are processing CUI in your environment.

Another note that I wanted to add up front is that Not Applicable does not mean Do Not Assess, it just changes the verification procedure. There is still an examination of relevant documents and review of the system operating environment to verify the documentation is accurate to the actual system.

If you review DFARS 252.204-7012 (https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting), section (b)(2)(ii), sub-bullets (A) through (C) describe the process of e-mailing the DoD CIO. In short, you can e-mail the DoD CIO to obtain approval of N/A status for your covered information system, or approval for alternative security measures.

I asked a clarifying question to the DoD CIO "for CMMC / DFARS clause 7021, will the process be the same to email the DoD CIO for anything that would be not applicable or have an alternative implementation?" and received their approval to post their answer here:

"The CMMC certificates required of contractors at DFARS 252.204-7021(b) are separate from the requirements found in DFARS 252.204-7012.?CMMC certificates will be issued in accordance with the requirements addressed in the CMMC Model and CMMC Assessment Guides found at https://www.acq.osd.mil/cmmc/draft.html .?DoD CIO will not adjudicate requests to vary from the CMMC Model and/or Assessment Guides.?DFARS 252.204-7012(b)(2)(ii)(B) – which states that DoD CIO must adjudicate any request to vary from NIST SP 800-171 and implement an alternative but equally effective security measure or that a NIST SP 800-171 requirement is not applicable - applies only to the implementation of the NIST SP 800-171 security requirements under DFARS 252.204-7012.?

In as much as the CMMC Model directly references NIST SP 800-171 security requirements, the CMMC assessor should accept a properly implemented DoD CIO approved alternative security measure or a requirement adjudicated as ‘not applicable’ by the DoD CIO as ‘met.’?Assuming DFARS 252.204-7012 is in the contract, nothing under CMMC or DFARS 252.204-7021 changes the contractor’s ability to submit a request to vary from NIST SP 800-171 as addressed DFARS 252.204-7012(b)(2)(ii)(B).??As such, the process for requesting approval for an alternative but equally effective security measure does not change under CMMC or DFARS 252.204-7021.?"

Really some good information in their answer. Where 800-171 overlaps, any approvals from DoD CIO should carry over and be acceptable against CMMC practices. However, the DoD CIO as of right now will not be adjudicating N/A or alternative security measures for any of the delta 20 practices that are above and beyond the 110 controls from 800-171.

Speculative note here, we will see changes coming to CMMC in the near future, the delta 20 may go away as a possibility, and we may hopefully receive more information about N/A and what level of authority an OSC would have for declaring themselves N/A to a particular practice for CMMC.

Bringing up another set of clauses from DFARS, the 7019 clause dictates that the Offeror shall have a current assessment (i.e., not more than 3 years old unless a lesser time is specified in the solicitation) (see 252.204-7020) for each covered contractor information system that is relevant to the offer, contract, task order, or delivery order. This score is entered into Supplier Performance Risk System (SPRS).

DFARS 252.204-7020 dictates that the DoD Assessment Methodology (DoDAM) is to be used when calculating the score to be entered into SPRS.

I bring this up for a specific reason, the NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 (https://www.acq.osd.mil/dpap/pdi/cyber/docs/NIST%20SP%20800-171%20Assessment%20Methodology%20Version%201.2.1%20%206.24.2020.pdf) discusses the Not Applicable status and how to score it:

"If a contractor received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective in accordance with DFARS 252.204-7008 or 7012, the DoD CIO assessment should be included in the Contractor’s system security plan. Implemented security measures adjudicated by the DoD CIO as equally effective, and security requirements approved by the DoD CIO as ‘not applicable,’ will be assessed as ‘implemented.’ Once DOD CIO assessments approving “not applicable” requirements or “alternative security measures” are included in the Contractor's system security plan, the contractor does not need to submit that documentation for every current contract with the DFARS 252.204-7012 clause unless specifically requested to do so by the contracting officer. When completing the Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment Results Format, the contractor shall score any security requirements for which an assessment of “not applicable” or “alternative security measures” was previously approved by DoD CIO as ‘implemented’."

The DoDAM reaffirms the statement from DoD CIO representatives that adjudication from the DoD CIO should be accepted by any assessor for NIST SP 800-171 control. It also gives the direction that any such adjudications becomes objective evidence that should be included in the system security plan. This means an assessor for either 171 or CMMC will want to see any such adjudications any time you mark something as not applicable to your covered information system.

Here ends the informative portion of the article. Now we get into the more opinion based material.

I'm going to borrow some questions from my trusted colleague @Amira Armond and attempt to answer them here with my opinion.

What sort of documentation / justification should assessors expect for the following situations:

- Setting a practice N/A. Is there an internal person in the OSC that needs to approve N/As? Is there an external entity (such as DoD CIO) that must approve N/As? Are procedures required for N/As?

My Answer: For 800-171, it is an external entity such as the DoD CIO that must approve N/As. Where 171 overlaps with CMMC, those approvals carry over. The delta 20 if they stay in the model remain an unknown as to whether they can be considered not applicable. Borrowing from RMF, typically it is a data owner that can change information protection requirements. The contractor is the system owner but not the data owner, they are merely a data custodian and do not have the authority to change the overall system requirements on their own. Requirements flow down from the data owner to the overall system level. The system owner and their architects should then flow down that requirement to the applicable system components for implementation. Not all requirements will flow down to all system components. It's on my back burner to-do list to write an article specifically on how to do this.

- Use an alternative implementation. If a client tries to say they have MFA enabled so they don't need complex passwords (or similar alternatives), is there any documentation that can be provided which will allow a MET?

My Answer: If the client has adjudication from the DoD CIO that either MFA is not applicable or they have alternative security measures, then that is all they need to satisfy the control or practice. Full stop. An assessor can disagree all they want but an assessor does not get to overrule the DoD CIO.

- Inheriting a practice. Assuming the client has an audit report showing that an equivalent control has been assessed, what do they need to document? Is a Customer Responsibility Matrix a requirement? What happens if the external service provider doesn't have a customer responsibility matrix? Can other documentation from the external service provider (like an email) be used as proof that they are fully responsible?

My Answer: Inheriting a practice from a Cloud Service Provider or Managed Service Provider, lot of parts to this one. First question and we know the answer, is there reciprocity for that assessment? It's likely that FedRAMP will have reciprocity on a control level, where the assessment of the 800-53 control that correlates to a derived 800-171 control will likely be satisfied. However, most things that are inherited end up being hybrid controls instead of full common controls. Hybrid meaning that a portion of the control is common while another portion of the control is system-specific. I mentioned in the above answer about taking a system level requirement and flowing it down to the system component level. That exercise works well here too. A Customer Responsibility Matrix is definitely very helpful as well to help with your traceability of requirements in your system architecture. An e-mail as proof is an interesting question, I'm open minded to it and probably take that one on a case by case basis as there can be a lot of varying levels of detail in emails and what level of coverage of controls they are claiming responsibility for. To reiterate, from my past experience, very few controls are fully inheritable, you will always have a sliver of responsibility. For example, physical and environmental security, yes that's all taken care of for your servers in your cloud, but you still have other equipment like laptops that are not in the cloud, that also have physical and environment security controls that apply to them.

- Policy exception. If your policy says X, but you need to make an exception for some reason, is an exception allowed in CMMC? Who needs to write it? How long and detailed does it need to be, AKA does it need a full "risk assessment" or just "I grant an exception because xyz"?

My Answer: Yes, this is reasonable and should be allowed in CMMC. From my experience, every policy has exceptions. However, you either need to include a section in each policy for how to request and receive approvals, or create a specific standalone policy for how to request exceptions. The exception to policy (EtP) requests should be detailed enough to explain what the policy you are asking for exception from, the business justification why it is needed, any alternative security measures or compensating controls that are to be put into place, the duration of the exception, and likely include it as part of configuration management and go through change control board, with a full risk assessment limited to the change included yes. However, this will probably be case specific and have a lot of variables depending on what the exception is, and the size of the organization. A one person company probably doesn't have or need a full CCB but I would still document any exceptions just for myself so that I remember why I did something. Important to note that the exception to policy does not change the requirement itself to N/A to the overall system, the requirement is still there on an overall system level.

Amira's original questions and discussion link is located here: https://www.dhirubhai.net/posts/amira-armond-25a77a141_cmmc-cmmcab-audit-activity-6850135386274967552-K_y4

Thanks for reading, hope you enjoyed, if you stuck around this long and read it all, I commend you.