The Department of Defense, and where delegated, the CMMC Accreditation Body, are the authoritative sources in regard to CMMC. Their guidance must be followed by all members of the CMMC ecosystem. Early versions of guides and training have been released by both parties.
With that said, there are many gray areas in CMMC which haven’t been addressed yet. CMMC is a complicated topic. There are requirements which come into direct conflict with other requirements. And at a program level, there are things which could be done better in order to build a functional CMMC ecosystem which achieves the goal of cybersecurity for defense contractors.
C3PAOs and assessors need to have a standard understanding and approach to CMMC in order to build confidence in the assessment process. Organizations Seeking Certification need transparency regarding technical interpretations. The DoD and CMMC-AB need feedback and industry recommendations to resolve pain points and identify possible ways forward. The goal of this positions page is to help meet these needs.
We formally request that the DoD and CMMC-AB review these positions and adopt the recommendations within.
Assessment interpretations
These technical interpretations are posted here in the interest of standardization of assessment by C3PAOs and assessors.
Small Assessment Interpretations (FAQ style)
Date approved: 6/13/2023
3.6.3 Incident Response Testing – minimum schedule:
The minimum acceptable schedule for incident response testing is once per year (periodically) for the in-scope information system.
Date approved: 6/30/2023
3.6.3 Incident Response Testing – which capabilities must be tested
IR.L2-3.6.3 – INCIDENT RESPONSE TESTING Test the organizational incident response capability. [a] The incident response capability is tested.
The incident handling (3.6.1) and reporting (3.6.2) capabilities are tested periodically.
Logic: This requirement intends to test the organization’s IR.L2 capabilities, including the IR Plan and the reporting aspects. The two requirements 3.6.1 and 3.6.2 shall be considered the “capability” established to handle and report cyber incidents. Similar to testing the policy statement against the supporting activities, IR.L2-3.6.3 tests the effectiveness of the IR Plan, as written. The IR capabilities can test portions of the IR quarterly, but the IR capability must be tested in its entirety at least annually. Lastly, NIST defines a capability as “A combination of mutually reinforcing controls implemented by technical means, physical means, and procedural means. Such controls are typically selected to achieve a common information security or privacy purpose.” This is why the two controls in the IR family shall be considered a capability tested under 3.6.3. The IR Test requirement does not suggest we test the controls’ effectiveness beyond 3.6.1 and 3.6.2 as other controls are already covered under CA.L2-3.12.1, Security Control Assessment
Date approved: 6/30/2023
Properly encrypted CUI is not considered CUI for purposes of scoping and required protections
CUI data that has been encrypted with a FIPS 140-2 validated module is not considered CUI for purposes of scoping and required protections.. This principle is why secret data can be transmitted across satellite links or the internet – because FIPS validated encryption is considered sufficient to protect the confidentiality of data. In order for ciphertext to not be considered CUI, the decryption key must be protected and kept separate from the encrypted data.
Examples of how this interpretation can be used: 1) CUI ciphertext in the form of backups may be stored in a non-FedRAMP cloud as long as the decryption key is not accessible to the cloud. 2) When transmitting CUI ciphertext between a client and server, all intermediate devices such as switches, wireless, firewall, internet, are considered out of scope for that specific ciphertext data flow. Again, the decryption key must not be available to those intermediate devices.
Date approved: 8/2/2023
Defining assessment expectations for subcontractors, service providers, and vendors
A subcontractor assists in delivery of specified deliverables for a DoD contract under the direction of a prime contractor. A subcontractor is expected to provide proof of CMMC compliance to their higher-tier clients commensurate with the type of data they generate or are provided as part of the contract.
- Example: a manufacturer that heat-treats a part (and has contractual flow down).
- Example: a company that provides skilled labor on an hourly basis (and has contractual flow down).
- Example: a company that manages a database that tracks and reports product completion status and production issues (and has contractual flow down)
A service provider does not meet the definition of subcontractor, however, it affects the CMMC compliance of the OSC due to access to the OSC ‘s system or hosting of OSC data. Service providers are evaluated using 800-171 3.1.20 criteria and are also often expected to perform some aspects of compliance on behalf of the OSC, for example, assisting in investigation of cyber incidents.
- Example: managed service providers
- Example: a cloud hosting service
- Example: security guard services
- Example: managed security service providers
A vendor does not meet either the definition of subcontractor or service provider, however, one or more of its products or services are utilized by the OSC. The OSC is solely responsible for the correct installation, configuration, and provisioning of a vendor’s products and services.
- Example: antivirus software company
- Example: firewall company
- Example: retained incident response firm
- Example: insurance company
- Example: printer repair company
Date approved: 9/1/2023
Split Tunneling to Organizational Clouds
Disclaimer: This interpretation specifically mentions Microsoft 365, which is a well-known cloud provider. This interpretation should not be construed as an endorsement of Microsoft 365 or a statement of appropriateness of Microsoft 365. Other similar cloud providers can be substituted into this interpretation.
3.13.7 only requires an organization to prevent split-tunneling to external networks. 171 defines an external network as “A network not controlled by the organization”. Microsoft 365 is a network that is partially controlled by the organization, as demonstrated by the FedRAMP SRM for that service. Therefore, we can state that the M365 network for our tenant is an internal network, under our shared control.
If we explore further, as the requirement references external networks, we can get clarity from the inverse definition – “internal network” – to see if Microsoft 365 could reasonably be defined as an internal network. 171 defines internal network as “A network where establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or the cryptographic encapsulation or similar security technology implemented between organization-controlled endpoints, provides the same effect (with regard to confidentiality and integrity). An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned.”
Microsoft 365 allows direct application of security controls by the organization. There is cryptographic encapsulation between endpoints, and similar security technology implement between the endpoint and the M365 service. The M365 network for each individual organization is controlled, not owned – it’s not controlled at the network layer necessarily, but it is controlled.
Using the above, we could argue that split tunneling from a corporate VPN to Microsoft 365 is not in scope for the requirement.
800-171 definition of “split tunneling” also provides a case for Microsoft 365 and similar services to be excluded. It is defined as “The process of allowing a remote user or device to establish a non-remote connection with a system and simultaneously communicate via some other connection to a resource in an external network. This method of network access enables a user to access remote devices (e.g., a networked printer) at the same time as accessing uncontrolled networks” – It is clear that Microsoft 365 is a controlled network, the organization has partial control and where it does not have control, Microsoft has demonstrated compliant control via FedRAMP.
Therefore, we could argue again, Microsoft 365 is not in scope for the split-tunneling prohibition.
The discussion in 800-171r2 states the following as the concern behind the enforcement of this requirement: “However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information”. We can infer from this that the prohibition exists to prevent split-tunneling from allowing access to unauthorized external connections – in our scenario, Microsoft 365 is an authorized connection, whether external or not, and has a demonstrated set of controls around its’ access. This is more of a “dynamic routing” rather than a classic example of split-tunneling.
Our proposed interpretation then is that, a CSP environment, like Microsoft 365, when the organization has shared, demonstrable control and has authorized its use, is not in scope for 3.13.7
Date approved: 11/1/2023
Computer accessing VDI
The computers that are used for accessing a VDI – where CUI may be processed, stored, and/or transmitted –
Should not be considered as CUI assets but rather Contractor Risk Managed Assets (CRMA).
1.1 Provided that they cannot, or are restricted from taking the information directly from the VDI to the computer.
1.2 The accessing computer may be able to “see” it and should be considered to be “capable of, but not intended to process, store, or transmit CUI”.
1.3 Additionally, if further restrictions are placed on the computer accessing a VDI such as: screenshot capture, copy paste, record screen, print (either to a printer or to a PDF), and create mappings from the VDI to local drives then consider as CRMA.
1.3.1 OR there would need to be some assurance that cut/paste or screenshots of CUI will not be used, such as a policy.
Can push the device to very limited scope –
2.1 Provided that those functions referenced above in 1.3 are made unavailable through technical means, i.e. can see but have no functions available to copy the data.
Date approved: 11/1/2023
System Security Plan incorrectly describes implementation of requirement
When the implementation of a security requirement is incorrectly or inadequately described in the System Security Plan, but there is adequate and sufficient evidence that the requirement is performed, the assessor should perform the following:
- Mark the poorly described security requirement MET
- Note in detailed findings that the implementation description in the System Security Plan is incorrect or inadequate
- Note in detailed findings the evidence showing that the requirement is performed
Note: Because CA.L2-3.12.4 is a practice which must be “MET” in order for an assessment score to be calculated according to the DoD Assessment Methodology, marking [e] “the method of security requirement implementation is described and documented in the system security plan;” NOT MET creates such a burden on assessors that it will be avoided, even if warranted due to poor description.
C3PAO Stakeholder Forum urges DoD to change the DoD Assessment Methodology to either 1) make it possible to mark 3.12.4 “NOT MET” while completing the assessment and calculating a score, or 2) allow update and re-assessment of System Security Plan during each day of the assessment without penalty.
Date approved: 12/18/2023
Interacting with unencrypted CUI brings endpoint into scope
Opening emails with CUI in them or attachments with CUI in them (email or from a secure storage location such as DoD SAFE) will bring endpoints into CMMC assessment scope as a CUI Asset. The act of downloading unencrypted CUI in the form of an email message or attachment makes the endpoint a CUI asset.
Dragging/dropping CUI to a secure location or “temporarily” unencrypting the file to then put it in the secure location will bring the endpoint into scope as a CUI asset.
This would be because of the act of downloading the information, viewing, and editing the information, puts it into memory and/or storage, (however briefly) on the local machine.
Data flows or processes which purposefully include temporarily processing CUI on a Contractor Risk Managed Asset (CRMA) then sanitizing the asset should not be considered valid to justify keeping the asset a CRMA. Assets intended for use with CUI must be fully secured while CUI is stored, processed, or transmitted by them.
However, if the OSC data flow is taking a suitably encrypted file and dragging and dropping it into a secure location, then that would not bring the endpoint into scope.
If the files are encrypted and moved in this manner, then the decryption key must not be accessible to intermediate devices processing, transmitting, or storing the CUI.
Date approved: 12/18/2023
Not everything is a cloud service
All essential characteristics of cloud services, as defined in NIST SP 800-145, must be satisfied in order to determine that a service is a “cloud service’.
These essential characteristics are summarized as: ““Cloud computing” means a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This includes other commercial terms, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.”
Custom engineered services do not meet the characteristics of “rapidly provisioned and released with minimal… service provider interaction” or “on-demand self-service”, even if the technology is built on top of a cloud service provider. The underlying cloud service provider (which does meet all these characteristics) is considered a cloud service. The use of a cloud service provider to host a custom engineered service is not considered a cloud service.
Example: An individual can sign up, provision, and configure computing services in less than one day without ever interacting with the hosting company’s engineers. The computing service is a cloud service.
Example: A database built to-order then hosted on a cloud service by a third party is not itself a cloud service.
Example: A server designed, built, and operated on behalf of a defense contractor by their Managed Service Provider is not a cloud service.
Example: A third party provides a website which assists contractors in managing efficiency of their projects. Each website requires an engineering review and project to deliver to the client. The website is not a cloud service.
Policy positions
These positions are submitted to the CMMC Program Management Office and CMMC-Accreditation Body as suggestions for resolving problems with the CMMC rollout.
How does the C3PAO Stakeholder Forum identify positions?
- Members of the C3PAO Stakeholder Forum submit topics that need clarification to the forum. For example, a member company might have just assessed a client with a specific situation that is not addressed by existing official CMMC guidance. Submission of a topic may be via posting on the forum or during a meeting.
- One or more members of the C3PAO Stakeholder Forum write a position on the topic. Collaboration and discussion with other C3PAOs to get their experience and thoughts is encouraged. A position is a recommended course of action for a specific situation or recommended prioritization between two conflicting requirements.
- The authors post the position to the C3PAO Stakeholder Forum for review, typically in a channel for that topic (such as the “scoping and boundaries” channel).
- An Advisor (volunteer position) will create a post in the “action items” channel to request review and voting for the position. An due date of at least 30 days from start of voting will be assigned. “Yes” and “No” voting buttons will be assigned to the position so that general members can click the button to vote for the position.
- The weekly C3PAO Forum meeting will review and discuss positions verbally until the due date arrives (two meetings). Members are reminded to vote on the position.
- At the due date, votes are counted by an Advisor. If at least 80% of the votes are “Yes”, the position is considered endorsed by the C3PAO Stakeholder Forum.
- The position is reviewed and packaged for public release (standard template applied, disclaimers applied).
- The position will be listed on the c3paoforum.org website and released publicly to the CMMC ecosystem (DoD, CMMC-AB, all C3PAOs, CMMC IAC, etc) by the C3PAO Stakeholder Forum.
DISCLAIMER
The C3PAO Stakeholder Forum is an industry group of C3PAOs. The group is formed from C3PAOs and aspiring C3PAOs; it is open to all CMMC-AB Marketplace C3PAOs and confirmed C3PAO applicants. The mission is to advance the CMMC assessor and C3PAO input, participation, and consensus within the CMMC ecosystem. This include advocating for policies, sharing perspectives and working alongside the DoD, CMMC-AB, Organizations seeking certification and other stakeholders to advance the mission of CMMC, which broadly is to increase the cyber posture of the Defense Industrial Base. The C3PAO Stakeholder Forum’s participation is voluntary and those individuals that participate do so of their own volition and without compensation. The views of the board and the C3PAO Stakeholder Forum are not necessarily those of each member or their respective companies. The DoD, and where delegated by the DoD to the CMMC-AB, are the ultimate authority with regard to CMMC. Any guidance contained within is not authoritative and if found in conflict with DoD guidance should be considered subordinate. We simply seek to share this guidance to help advance the conversations and drive consistency among the industry. To the extent that subsequent guidance is published by the DoD or similar authorities, this document will be revised.
The information provided here is of a general nature and is not intended to address the specific circumstances of any individual or entity. In specific circumstances, the services of a professional should be sought.