What the heck is shared responsibility in CMMC?

Most Department of Defense (DoD) contractors, especially small businesses, rely on the help of External Service Providers (ESP) for their operational needs. Whether for day-to-day IT administration, physical security monitoring, or cybersecurity compliance planning, ESPs are deeply intertwined in the fabric of the Defense Industrial Base (DIB). Without ESPs, small- and micro-businesses would find it very challenging to support their defense contractor clients and meet contractual obligations. While it’s clear that ESPs are essential for small businesses to operate in the DIB, there are important CMMC considerations that any defense contractor and ESP should be aware of prior to working together. The topics we cover in this blog will have relevance not only to the contractor’s CMMC compliance, but potentially its ESP as well. In this post, we unpack these CMMC considerations through analysis of the concept of shared responsibility in DoD cybersecurity.

Be sure to grab a copy of our Shared Responsibility Matrix (SRM) Template, which you can download for free at the end of this post!

What is an External Service Provider?

Before exploring shared responsibility, it’s important to understand the various roles of ESPs in the CMMC “ecosystem”. An external service provider, in general terms, is any third-party entity that enhances the capabilities of an organization, typically by providing services that the organization would prefer not to perform internally. This could include IT, cybersecurity, software development, HR, accounting, and more. In the context of CMMC, an ESP would be any third-party entity that enhances the capabilities of an organization to meet the CMMC requirements, typically IT and cybersecurity. An ESP will fall into one or multiple of the following categories: Managed Service Providers (MSP), Managed Security Service Providers (MSSP), and Cloud Service Providers (CSP).

It’s not uncommon for an ESP to fill both the role of MSP and MSSP, providing both the day-to-day IT administration and cybersecurity monitoring. If the ESP provides a cloud service, such as a customized cloud CUI enclave, they would be considered a CSP, and their service may be subject to the FedRAMP requirements.

For a more formal definition of an ESP, we look to the DoD’s CMMC Level 2 Scoping Guide, which provides an explanation:

"To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets as set forth in 32 CFR § 170.19(c)(2)."

CMMC Level 2 Scoping Guide Definition of ESP

There is a lot to unpack here. The DoD views ESPs through the lens of how they handle DoD information. This is very important when discussing shared responsibility. Remember that CMMC exists to protect DoD information, specifically Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). It is not just a general mandate to secure the entire organization; it requires that cybersecurity be done specifically wherever CUI/FCI flows. So, it makes sense that the DoD, when considering how to mitigate cybersecurity risk among ESPs, focuses on if/how DoD information touches ESP “assets”. Not handling (storing, processing, or transmitting) CUI or Security Protection Data (SPD) on ESP assets? Not a true ESP.

A quick note on Security Protection Data. SPD, per the CMMC Final Rule, could include “configuration data required to operate a Security Protection Asset (SPA), log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.” If you are an MSP/MSSP providing vulnerability scanning, privileged access management (PAM), or event log analysis via a Security Information and Event Management (SIEM) tool, among other services, you’ll want to ensure you know exactly where your logs and config files are being stored.

Confused yet? The bottom line is that if you are an ESP handling (storing, processing, or transmitting) CUI on your assets, you will need to get your own CMMC Level 2 certification. If you are an ESP handling SPD on your assets, you will need to, at a minimum, create a Shared Responsibility Matrix and prepare to sit through each client’s CMMC assessment and describe to the assessors how your services align to NIST 800-171A. Alternatively, you can get your own independent CMMC Level 2 certification and avoid having to provide an SRM and participate in assessments. We explain more about the CUI/SPD relationship in our post on the CMMC Final Rule.

This is why ESPs are brought to the table when talking about CMMC compliance and shared responsibility, as, depending upon how the ESP helps facilitate the handling of CUI (or SPD), the ESP will either need its own CMMC certification or an SRM and prepare to participate during its client’s CMMC certification assessment. From our experience, this can be a real shock to some ESPs, to the point that they may choose not to support defense contractors at all.

Identifying shared responsibilities

Hopefully, you are already on the same page with your defense contractor client or ESP that achieving CMMC compliance is a collaborative effort. A contractor cannot fully outsource CMMC to an ESP, nor can an ESP fulfill all CMMC responsibilities on behalf of a defense contractor.

Knowing this, we can explore shared responsibility. Shared responsibility means that both the defense contractor and its ESPs (MSPs/MSSPs/CSPs) are jointly accountable for implementing and managing, fully or partially, the NIST SP 800-171 security controls needed to safeguard CUI/FCI. In other words, while an ESP may state that they provide IT administration and cybersecurity monitoring, the first question posed to the ESP should be: which NIST SP 800-171A Assessment Objectives are covered, fully or partially, by these services? This creates a direct link to the actual requirements for safeguarding CUI/FCI and makes it abundantly clear which Assessment Objectives may be “inherited” by the contractor by using the ESP’s service.

If you’ve read through NIST 800-171/A, you know that meeting the requirements will involve a blend of both policy and technology. In many cases, ESPs can’t be the ones adopting and owning policies; this can only be done by the contractor. ESPs can make recommendations, but CMMC assessors want to see a cybersecurity “culture” within contractors undergoing assessment, which starts with understanding and taking ownership of its policies and procedures for protecting CUI. Technology, on the other hand, can often by fully managed by ESPs, and where there are NIST 800-171A Assessment Objectives fully satisfied by technology, it is conceivable for an ESP to take on the full responsibility for those objectives. The bottom line is, for contractors, to be very careful in your System Security Plan (SSP) when designating “full” responsibility for any Assessment Objective to an ESP, especially for objectives that involve a policy or procedure. For ESPs, be careful in your Shared Responsibility Matrix when taking full ownership of any objectives.

Let’s look at an example. Enforcing the principle of least privilege is a good use case for differentiating between contractor and ESP responsibilities. Security control 3.1.5 in NIST 800-171 states the following:

"Employ the principle of least privilege, including for specific security functions and privileged accounts."

NIST SP 800-171 Control 3.1.5

This control has four (4) Assessment Objectives, and we’ll only look at the first two to illustrate this example:

"Privileged accounts are identified."

NIST SP 800-171A Assessment Objective 3.1.5[a]

"Access to privileged accounts is authorized in accordance with the principle of least privilege."

NIST SP 800-171A Assessment Objective 3.1.5[b]

Let’s assume that this contractor is very small, with only a single user handling CUI on one Windows PC. Identifying privileged accounts on the covered system is conceivably pretty easy; just list the administrator account(s) found in the Windows settings. Certainly, this is something that an ESP could help list or perform on behalf of the contractor. For more complex systems, especially those stretching across cloud and hybrid environments, an ESP will almost certainly need to help catalog privileged accounts in some form of a system inventory document, which they likely help manage for the contractor. Even then, the contractor may help play a role in identifying privileged accounts and managing the inventory.

The second objective, however, is one that should be handled by the contractor. Who authorizes access to privileged accounts where CUI is handled? This, ideally, should be done by a senior official within the contractor organization. Certainly, ESPs will help with provisioning access to the right accounts, but they should not be authorizing privileged access AND provisioning accounts. Ironically, this is also a violation of the concept of principle of least privilege. Contractors, therefore, will need to establish a clear policy for how they authorize access to privileged accounts and prepare to demonstrate this process to a CMMC assessor, such as when a new IT MSP domain admin is onboarded.

In conclusion, this simple example further demonstrates that it is important for contractors and ESPs to tread carefully when assigning “full” responsibility to an ESP for any NIST 800-171A objective.

Creating a Shared Responsibility Matrix

Defense contractors preparing for a CMMC assessment will document how they’ve implemented NIST 800-171A in their System Security Plan (SSP). The SSP should describe, where applicable, which protections in NIST 800-171A they are inheriting, fully or partially, from their ESPs, and detail how the ESP helps satisfy those objectives.

From the ESP perspective, before a defense contractor adopts your product or service, you should already have a Shared Responsibility Matrix (also referred to as a Customer Responsibility Matrix) with your offering aligned to NIST 800-171A. That way, upon adoption of your product or service, the contractor can simply adopt the language in your SRM when crafting their SSP. When it comes time for a CMMC assessment, the assessors will then ask to see your SRM as a source of compelling evidence.

At this time, there is no defined DoD template for an SRM. Therefore, for ESPs looking to create one, we recommend going through all of NIST 800-171/A and identifying which controls and objectives your product/service will help satisfy for your clients. Then, identify if your product/service fully or partially satisfies these objectives, and describe in detail how it does so. You can download our SRM template to use for this.

Having an SRM not only will be necessary when it comes time for your clients’ CMMC assessments, but it also is a great resource for level-setting and providing assurance to your clients that you, as an ESP, have a firm understanding of CMMC and are ready to support them with specific NIST 800-171A needs from start to finish.

Wrapping up

This post provided an overview of the role of external service providers in CMMC and described considerations for ESPs looking to identify shared responsibilities. Additionally, we shared strategies to get started building a Shared Responsibility Matrix. If you are an ESP looking for help with crafting your SRM, or if you are a defense contractor trying to implement NIST 800-171A, consider grabbing a seat in our next CMMC Workshop!

If you have any questions about this blog, Totem’s services, or anything else, feel free to contact us. Otherwise, grab a copy of our SRM template below!

Thanks for reading!

Nathan