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.
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.
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 CMMC regulation to include the role of the ESP, which I believe will set the bar for IT and cybersecurity MSPs in all industries over the next few years.
With the CMMC final rule now finalized and expected to be published by Dec 16, 2024, 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 decide if they will get CMMC certified at the same level their clients will be, or participate in every client’s CMMC Level 2 assessment to provide evidence of the capabilities they provide specifically for that client.
With CMMC Certifications 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:
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.
Components of the SRM (see Figure 1):
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
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?
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: