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)
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.
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
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.
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
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
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.