Why Your MSP Should Have a Shared Responsibility Model in the Face of Impending Regulations [+ Expert Tips and Examples]

TLDR;

IT service providers are facing regulation in many industries. They can no longer claim to “do everything” or be the “one stop shop” to capture multiple layers of billable services and can no longer assure blanket responsibility for their customer’s IT and cybersecurity status.

In this world of cyber threats, cyber liability, and legislative crackdowns, it is imperative that MSPs shift their strategy to the Shared Responsibility Model (SRM) with both their clients and their vendors.

Here is what we will cover in this blog:

• Why are MSPs About to be Regulated?
• Why Should the DIB Care?
• What is a Shared Responsibility Model?
• What Does a Shared Responsibility Model Look Like?
• Why is a Shared Responsibility Model So Important for the Defense Industry?

Why are MSPs about to be Regulated?

Around 2018, I started hearing (and repeating) the mantra that IT and cybersecurity service providers (MSPs and MSSPs, hereafter referred to as “MSPs”) are facing regulation as an industry. I mean, think about it: if you eat at a restaurant or frequent a nail salon, the purveyors of those establishments have undergone an inspection or formal education and certification to provide you those services. But in the IT service provider industry, the only thing we’ve had to do is hang our shingle and self-proclaim our technical talents – and voilà! We are open for business.

With little or no regulatory requirements in most industries, MSPs carry responsibility for the success or failure of securing our customer’s businesses, simply by how we manage their technical environment. Every security or IT recommendation we make; every password we reset; every server we configure; and every patch we deploy can mean a continuation of business productivity, or loss of control and devastation to our customers’ business operations.  

Why Should DIB Small Businesses Care About MSP Regulation?

Over the past two decades, we have relied heavily on vendors that we leverage to deliver those security and IT capabilities - not just for their technical toolsets, but for their guidance on how to sell those services and benchmark our profitability. So much so that the vendors, not the MSPs themselves, have led the initiative to educate MSPs on cybersecurity, business maturity, M&A, and everything else – in an effort to deliver effective security solutions. So, what kind of security posture and risk & governance maturity have those vendors themselves held while they have guided MSPs on their cybersecurity education and selling journey? And what kind of security posture and risk & governance maturity have MSPs held while guiding customers on their journey? That, my friend, is the million-dollar question. Or at least, the multi-thousand dollar question.

The DoD recently shared that “small businesses make up 99.9 percent of all U.S. businesses as well as 73 percent of companies in the defense industrial base, and last year small businesses were awarded over 25 percent of all DoD prime contracts." [1] Knowing that those small businesses are largely dependent on MSPs for their IT and cybersecurity needs, it is easy to make the connection that we as MSPs are critical to the small business economy.

All of this comes together now in a patchwork of requirements that the Department of Defense (DoD) has pointed to as the first wave of MSP regulation that I believe will lead to mass regulation of all IT and cybersecurity MSPs in all industries over the next few years.

Shared Responsibility Model: The Way Forward for MSPs and the DIB

With the CMMC final rule imminent (late 2024 or early 2025), every Managed Services Provider (MSP) that serves the Defense Industrial Base (DIB) is faced with some tough decisions. To 'play ball' in the DIB, MSPs will need to get CMMC certified at the same level their clients will be.

[Excerpt from the CMMC rule]

With regulation looming, now is the time for MSPs and small businesses who use them to become familiar with models for managing regulatory compliance. Organizations using an MSP are required to have a Shared Responsibility Matrix for CMMC 2.0 and NIST 800-171. As you look for an MSP to support you in your CMMC compliance journey, what are best practices that you should look for in an IT service provider? The Shared Responsibility Model should be at the top of your list.

Let's review what the Shared Responsibility Model means and how it will be leveraged in the context of the Cybersecurity Maturity Model Certification (CMMC) and the MSPs whose customers in the Defense Industrial Base (DIB) will require this assessment as part of their DoD contract award.

To understand the SRM you could harken back to the basics of the Federal Risk and Authorization Management Program (FedRAMP) established in 2011 to provide a cost-effective, risk-based approach for the adoption and use of cloud services by the federal government. The program requires implementation of varying levels of cybersecurity controls validated by a 3rd party, to enable the concept of do once, use many times – allowing the customers (in the case of FedRAMP, the customers would be government agencies) of that cloud provider to trust the validated cybersecurity controls they “inherit” from that provider as well as identify the controls they themselves need to implement, to achieve a standardized level of security.

FedRAMP authorization incorporates several documents required from the cloud service providers, three of which are critical to understanding applicability of the SRM in the MSP industry:

• System Security Plan (SSP) – A formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements. With FedRAMP, this applies to various levels of controls contained in NIST SP 800-53 R5 according to the level of authorization sought (Low, Moderate, High)
• Control Implementation Summary (CIS) – The CIS summarizes the implementation status of each control and the party responsible for maintaining that control, whether the customer is fully responsible for the control, partially inherits the control (there are some customer responsibilities), or the control is fully implemented by the CSP (no responsibilities for the customer). [2]
• Customer Responsibility Matrix (CRM) – Provides details of what customer responsibilities are for any given control, including responsibilities for optional services (applicable depending on which services the customer acquires). [3]

In establishing the MSP requirements for the CMMC program, we can point to the existing criteria for FedRAMP as a model for MSPs to follow but applying it to the NIST SP 800-171 r2 standard instead of the NIST 800-53 r5 control baselines. In readying for their own CMMC Level 2 assessment and demonstrating proof to their customers of their NIST 800-171a R2 control implementation, the CRM (more commonly referred to as the SRM or Shared Responsibility Matrix or Model) is one of the heaviest lifts for MSPs to tackle – but carries the highest return on investment.

Let’s review what goes into the SRM and why.

What a Shared Responsibility Model Should Look Like [+ Expert Tips and Examples]

Components of the SRM (see Figure 1):

• The SRM will be populated with the NIST SP 800-171A (r2) controls the MSP will perform and manage on behalf of their customer (Columns A, B, C). Many MSPs will limit the NIST SP 800-171 r2 control capabilities they offer for their customers, based on risk to the MSP as well as the return on investment for tailoring of their service delivery processes applicable to their DIB customers. [4]
• The SRM should be detailed to the level of each Assessment Objective (AO) (D, E). In review of NIST 800-171A r2, you will see that each of the 110 controls has a subset of determination statements (referred to in CMMC as Assessment Objectives or AOs) that an assessor will refer to for validating implementation of that overall control statement. These AOs are often split between the Service Provider, a Vendor, and the Customer. Therefore, the detail needs to be at the AO level for the SRM.
• Control implementation details per asset category and/or service offering (F, G). Most MSPs offer more than one service package, incorporating a Basic or Premium level of support. To validate against each service package, the MSP will identify the AO implementation details in separate columns; a Certified 3rd Party Assessment Organization (C3PAO) will audit against the Premium (or most comprehensive) package which would be inclusive of the Basic package capabilities at the same time (depending on how the MSP service packages are designed).
• Clearly indicating where the Service Provider has full, partial or no responsibility for that control’s AO (F, G indicated with color key of green (full), blue (partial) or grey (none); along with the details of implementation). This allows the customer to understand visually where they will have responsibility (full, partial or none) for those capabilities, for the impacted assets.

Example of a detailed SRM:

Figure 1: Shared Responsibility Model 
Key: Full, Partial, None

Conversely, the implementation details stated above could be moved into the SSP and then reflected with a simple F, P or N (Full, Partial or None) in each of columns D & E above, after the C3PAO has validated the control implementation in a CMMC Level 2 assessment (see Figure 2 below). Generally, the SSP would require additional details linking documentation (policies, procedures, checklists) along with assigned roles and responsibilities for each Control and corresponding AO. The truncated version of the validated or certified SRM could be made available publicly without jeopardizing the security privacy of the MSP, and the SSP would only be provided to customers who are contracted with an SLA from the Service Provider.

Figure 2: High Level SRM example

A note about inheritance vs. reciprocity: The inheritance of controls from a SRM differs from the concept of reciprocity, in that reciprocity represents the substitution of an entire body of controls from a different standard (I.E. if ISO 27002 accreditation were accepted as fulfilling NIST 800-171 requirements). Inheritance on the other hand, is intended to allow for acceptance of a control or controls as being fully or partially implemented by another party, when the implementation of that control has been validated and certified by an accredited 3rd party under the same standard. See Figure 3 Inheritance Example for SRM

Figure 3: Inheritance example for SRM

For example, if a service provider has demonstrated they perform maintenance on customer systems to meet the criteria in NIST 800-171A r2 3.7.2 “Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance” and have been validated by an CMMC Third Party Assessment Organization (C3PAO) with a CMMC L2 certification to prove such, the evidence and artifacts provided in their original C3PAO assessment would be directly inherited by their DIB customers for any of the assessment objectives (see Figure 3) where Full or Partial responsibility was validated.

While the CMMC industry awaits an official vehicle granting inheritance from a MSP's SRM, companies who have obtained services with a MSP can effectively leverage the SRM to write their control implementation statements within policies, procedures, and SSP, as outlined above. This achieves the goal of inheritance while ensuring internal documentation does not lack coverage with regard to statements that address how the requirements are being met within an environment the MSP is supporting.

Figure 4 NIST 800-171A 3.7.2

Why is a Shared Responsibility Model So Important for MSPs and Small Businesses?

You can see that the level of detail required in defining, documenting, implementing, and sustaining each of the control AOs is substantial. The MSPs ability to reinforce all of the above controls with proper change management, configuration management, vulnerability management, and even incident management presents a large jump in maturity compared to the services historically provided without regulatory requirements. So why is the SRM concept so important to embrace?

• Liability – Cyber insurance carriers and legal experts contend that detailed roles, responsibilities, and validated cybersecurity control implementation at the MSP level can greatly reduce the liability of the MSP and accordingly, the cost to insure the MSP against cyber threats. The same savings would extend to the customers they support, wherein the customer is being similarly validated against their cybersecurity program with contracted responsibilities being outsourced.
• Accountability – Proper review of the SRM with the MSP customer allows those SMBs to understand more fully what their role is in securing their organization and accountability on each side is acknowledged. The resulting shift in customer culture and attention to cybersecurity reinforces security best practices.
• Gap Identification – Areas of controls not addressed by one or more parties are identified.
• Standardization and efficiency of service delivery – MSPs who are validated against their process and technology for delivery of IT/security capabilities will necessarily embrace standardization of those processes. Training for their helpdesk personnel is reduced after the initial re-education, and efficiency improves as more and more tickets are handled following fewer process deviations in support of the compliance standards.
• Automation – Replication of process across the MSP customer base allows for innovation in the areas of automation, over time resulting in efficiency and price adjustments to offer the same services at a more affordable rate.
• Training – Embracing responsibility across all parties necessitates the need for detailed and ongoing training. In the world of NIST 800-171, training is a control category with multiple objectives. Most cybersecurity standards include training as a function.
• Maturity and expertise – MSPs can hardly undergo the investment of resources in a solid SRM without developing a true governance, risk and compliance approach to service delivery. MSPs who are preparing to serve in the CMMC ecosystem by and large have advanced in maturity well ahead of their peers, reflecting a deeper level of expertise in the associated standard(s) they are aligning to.
• Enhanced security – MSPs who are willing to detail their roles and accountability for security via the documentation and SLAs are generally focused on executing security and IT services beyond the standard requirements they align to, embracing enhancements as part of their security culture.

The era of cyber immaturity for MSPs is now ending. Whether it is one year or four from now, the initiative to mandate a higher bar for outsourced IT and cybersecurity providers is upon us. Embracing the SRM is a strong example of readying for the new era.

If you would like to see a full example of a Shared Responsibility Model, check out Summit 7's below. If you are using an MSP or MSSP for CMMC compliance, you are required to show an assessor a Shared Responsibility Model defining obligations and responsibilities for both your organization and the company that supports you. If you need help finding the right MSP, we are here to help. 

Footnotes:

[1] DoD Releases Small Business Strategy > U.S. Department of Defense > Release
[2] Updated Control Implementation Summary (CIS) and Customer Responsibility Matrix (CRM) Templates | FedRAMP.gov
[3] Ibid.
[4] Many MSPs currently leverage outsourced services for other areas of their service delivery that would not qualify as part of CMMC due to export or dissemination controls applicable to the type of data being processed, stored or transmitted at the customer organizations. For example, if a Service Provider leverages an India-based Network Operating Center (NOC) or Security Operations Center (SOC), they may want to exclude the applicable security controls in their SRM to save the cost of bringing those services in house.

Additional resources:

• Microsoft https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• AWS https://aws.amazon.com/compliance/shared-responsibility-model/
• CSA https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained
• DoD Memo on Reciprocity https://dodcio.defense.gov/Portals/0/Documents/Library/(U)%202024-01-02%20DoD%20Cybersecurity%20Reciprocity%20Playbook.pdf