Last Updated on January 18, 2024
Organizations in the US defense industrial base (DIB) and other government sectors are increasingly moving towards mandated protections for controlled unclassified information (CUI), notably CMMC 2.0 certification or NIST 800-171 compliance.
This movement is elevating compliance scrutiny on managed service providers (MSPs) and managed security service providers (MSSPs) that deliver security services in scope for CUI. Impacted clients are asking these critical third parties increasingly challenging questions about how exactly they deliver their services and what controls they have in place.
To address a range of applicable use cases where MSPs/MSSPs may have CUI protection requirements, Caleb Leidy, CUI Protection and CMMC Consultant at Pivot Point Security, joined a recent episode of The Virtual CISO Podcast. John Verry, Pivot Point Security CISO and Managing Partner, hosts the show.
What is shared responsibility around CUI and CMMC?
Obviously, the onus of responsibility for protecting CUI is ultimately on the organization seeking CMMC certification (OSC). But many such firms rely on MSPs and/or MSSPs, to which they outsource various IT and/or security functions that store, transmit and/or process CUI. Examples include security operations center (SOC) or security information event management (SIEM) services that monitor systems or applications within the CUI scope.
In these commonplace situations, client and service provider need to work together to ensure that CUI is protected in a CMMC-compliant manner. Who does what is a matter of control as well as ownership of the CUI.
3 shared responsibility use cases
To frame the discussion around shared responsibilities to protect CUI and comply with CMMC, Caleb and John posit three use case scenarios:
- The CUI related controls that are the client’s responsibility within their own environment
- The CUI related controls that an MSP has responsibility for within a client’s environment
- The CUI related controls that an MSP needs to implement in its own environment to ensure CMMC compliance pursuant to flowdown of requirements to suppliers per DFARS contract clauses
Where to begin?
Caleb suggests that a good starting point for determining and documenting specific shared responsibilities is within the client’s gap assessment or compliance self-assessment process. In this context you can most effectively identify what controls the MSP/MSSP has responsibility for within each CMMC practice, from the client’s viewpoint.
“It’s [about the client] identifying, ‘Hey, for this practice, we know our MSP manages that, [and this is how they do it]’ says Caleb. “you can start to lay out the responsibilities that way, and also make sure that they’re being implemented in a way that complies with NIST 800-171/CMMC.”
Layers of responsibility
The CMMC scoping guide references MSPs as falling under the Security Protection Asset type—because MSPs often function operationally as security protection assets. This potentially encompasses not only technologies but also people and overall services, which provide functions that implement controls to meet the requirements.
But these security protection assets can be subject to protections as well. Access controls and physical protections for the CUI, for example, can pertain not only to the OSC’s environment but also the MSP’s. This is why Caleb advocates examining shared responsibility implications “control by control” across the NIST 800-171 framework, as an auditor would.
For example, if a DIB org engages an MSP to connect into its environment and remotely manage some IT infrastructure that transits CUI, the client is responsible for compliance with access control and authorization requirements because it’s their environment. But it’s the MSP’s responsibility to ensure that their processes and procedures meet CMMC/NIST 800-171 guidelines.
What’s next?
Click here to listen to the complete episode with Caleb Leidy, which is basically a free CMMC consultancy briefing that no MSP/MSSP should miss.
Interested in shared responsibility’s impact on third-party risk management? Here’s the perfect post: “Shared Responsibility” is Key to Managing Third-Party Risk