CMMC is a familiar framework to any contractor working as part of the defense industrial base and handling any form of controlled unclassified information. Whether it’s compliance in general, a specific clause relating to DFARS 252.204-7012 in your contract, or impetus from another source, you’re going to need to implement security standards from NIST SP 800-171 and adhere to the rules laid out in the Cybersecurity Maturity Model Certification framework.

While CMMC isn’t currently a strict requirement, it will be soon, with expectations that the rollout will begin in Q1 of 2025 and that it will be fully required across the board by 2028. Getting on board now is critical to get ahead of the game.

There’s one significant problem for many DIB contractors, but fortunately, the DoD has a solution. Let’s discuss the Shared Responsibility Matrix.

What’s the Problem with CMMC?

The biggest issue with CMMC is that it encompasses a huge number of security controls across a lot of different areas, all of which are required to achieve a baseline level of security for acceptable compliance with CMMC. The lightest possible standard, Level 1, still has 48 required security controls; Level 2 has 110, and the strongest Level 3 is even more comprehensive.

So, what’s the problem there? Well, imagine you’re a small business. You have half a dozen employees working to build and maintain a web app, and it just so happens that the app you’ve developed would be very useful as a part of the supply chain within the overall defense industrial base. You might not work with a government agency directly, or maybe you do, but either way, the security falls to you as part of the overall supply chain.

We’ve seen recently numerous cases where an element of a supply chain is compromised, and the effects can be disastrous much later. The massive 2013 data breach of Target, numerous ATM compromises, the famous 2020 Solarwinds attack on the government, and many more are examples of how these attacks can occur, the vectors they can follow, and the damage they can do.

As a small business, you likely don’t have a dedicated IT team. You might have an IT guy, or IT might be a shared responsibility amongst developers or even an afterthought.

So when you’re handed a list of 48 – or 110 – specific elements of security that you need to follow, along with strict requirements for implementing, validating, testing, approving, and recording each and every one of them, it seems like an impossible task. You don’t have the budget, the leeway, or the time to do it, and yet you have to if you want to be able to work with any member of the defense industrial base as part of the overall supply chain.

The Easy Solution

The easy and obvious solution, especially to tech companies who are themselves already this solution for other people, is outsourcing. For example, instead of running your web app on your own web server and having to bear the burden of keeping that web server entirely secure, you can run that same app on a web server hosted by Microsoft Azure or Amazon Web Services, like so much of the rest of the internet is already doing.

So, why not just find a managed services provider or other external service provider (or ESP, to use more government parlance) and have them handle it?

This sounds fine; you offload the majority of the burden to another company, and if something goes wrong, you can point to them and say it’s their fault. Simple and easy, right?

Of course, then you end up in a situation where everyone is trickling down their responsibility to another company, who is handing it off to another until you have a kind of Omelas situation where there’s one sacrificial company bearing all of the responsibility. Obviously, this doesn’t work.

The CMMC Shared Responsibility Matrix

The government fixes this issue through the Shared Responsibility Matrix. This is, effectively, a way to split the responsibility between you and the ESPs that you use. It may be just you and one ESP, or it may be you and several ESPs all working together. A web app using AWS for hosting and Cloudflare for protection will share responsibilities in the matrix between all three of you.

There are a sum total of 320 assessment objectives throughout all of CMMC. With the shared responsibility matrix, these 320 are assigned to you or to your ESPs, depending on who engages with the systems.

In order for a shared responsibility matrix to be effective and acceptable, it needs to be clearly delineated and defined. It’s a known part of the contract between you and your ESPs. It needs to be clear which security elements are the responsibility of which entities on a granular and detailed level.

Framework and Solution

The CMMC Shared Responsibility Matrix serves as a mechanism and framework for a smaller DIB contractor to relieve themselves of the burden of security controls that they do not directly handle. The AWS example is very common, and Amazon has a special portion of their GovCloud offering called the Landing Zone Accelerator that works to hold up their end of the matrix. Other cloud service providers and systems have their own versions of the same thing, or at least a team that can work with you to harden your systems on their end.

One of the greatest challenges with CMMC and other compliance efforts is the auditing requirements. You can’t generally just self-attest that you’re secure; you need to undergo an audit and validation process, usually conducted by a certified third-party assessment organization like Ignyte.

How do you prove that you’re secure when another company is responsible for those elements of security?

The shared responsibility matrix allows you to define the other company as the one responsible for a set of security controls you have to have implemented. When it comes time to be audited and deliver your reports, you deliver information on the controls that, in your matrix, are your responsibility.

None of this sounds new to me, though.

This is a common comment we see when contractors learn about the shared responsibility matrix. After all, many of us are already used to this kind of shared responsibility model in cloud security. Anyone using a Google service is trusting Google to keep their information secure, and the same goes for thousands of service providers, large and small.

There are two noteworthy differences. The first is that for most uses of something like AWS or Google services, the standards are often lower by default. Google isn’t going to keep or provide detailed audit logs to every single person who uses Google Drive; those features are limited to higher-tier plans with centralized administration. Amazon Web Services isn’t providing top-tier hardened security to their casual web apps; it’s part of the GovCloud services. Even though they do maintain security, they don’t necessarily report that security.

The second difference is simply that the government, until recently, didn’t necessarily recognize this kind of shared responsibility. For much of its history with cybersecurity, the government put out standards and restrictions, demanded auditing reports, and left you to succeed or fail on your own. The shared responsibility matrix, as part of CMMC, is a way to modernize and recognize that the current state of digital enterprise is an interconnected network of service providers, not individual, stand-alone services. We all stand on the shoulders of giants, even other giants.

How to Use the Shared Responsibility Matrix

The first step to using the Shared Responsibility Matrix is making sure that each of the ESPs that you use is aware that it’s part of your and their requirements and that it’s written clearly into your contract.

From there, you start to lay out the entire matrix. The matrix is, essentially, a spreadsheet. It includes four sets of information.

• The name of the security practice.
• The requirements laid out in the specific practice.
• The responsibilities of the ESP.
• The responsibilities of your company.

So, for example, you might have:

• Practice: AC.L1-3.1.1 (Access Control)
• Requirement: Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
• ESP Responsibility: ESP is responsible for adding, removing, and controlling user access, process access, and device access in systems such as Azure and Active Directory, as necessary.
• Your Responsibility: Providing a complete and accurate list of authorized users, processes, and devices, along with their roles, to the ESP.

This set of data is repeated for all of the 300+ security assessment points laid out as part of CMMC. Some of them may be only relevant to the ESP, and some may be only relevant to your firm; in which case, one or the other is set as “No responsibility.”

Does Your Company Need to Use the Shared Responsibility Matrix?

Yes and no.

If your company is NOT part of the defense industrial base at all, OR your company is part of that base, but does not handle CUI, CDI (Covered Defense Information), or any other sensitive information, you likely can adhere to a much lighter security standard.

If your company is part of the defense industrial base and supply chain, AND your company handles CUI and other forms of controlled information like Covered Defense Information, you need to comply with NIST SP 800-171 standards at the appropriate security level.

This, by default, requires the shared responsibility matrix. The shared responsibility matrix comes into play if you meet the requirements to have to adhere to NIST SP 800-171, AND your business uses the services of another cloud service provider along the way.

The reason we’ve used systems like Azure, AWS, and Google throughout this post is because they’re some of the largest, most widespread, and most common ESPs that might be used as part of your processes.

At the same time, you might not need to use the shared responsibility matrix, depending on how you use those third-party systems. For example, if you use something like Google Drive to store assets for your marketing, but no part of your systems touch Google Drive or a Google system for your actual service offering, you probably don’t need to involve Google in a shared responsibility matrix. The moment any form of CUI touches a Google Drive, though, you are in violation of controls and risk everything.

Why Implement the Shared Responsibility Matrix Now?

One of the details we mentioned above is that the shared responsibility matrix is part of compliance with CMMC and that CMMC is not even currently a requirement. That begs the question: why worry about it now?

The easy answer is that it’s proactive work to maintain your service offerings without issues. When CMMC rules come into full force, there’s likely to be a lot of disruption as companies try – and some struggle and fail – to do the work by the deadline. By working on it now, using what information has been made public about CMMC’s requirements, you can ensure that not only are you ready to go the moment the requirements are put in place, but you’re also able to continue your services without interruption.

How to Get a Head Start on CMMC and the SRM

If you’re a service provider as part of the defense industrial base and you want to get a head start on CMMC, we can help. The Ignyte Platform was developed as a comprehensive tool for centralized record-keeping and collaboration, so you can work on everything from your auditing reports to your SRM documentation without needing to use siloed software that can’t be accessed reliably.

Additionally, at Ignyte, we’re one of the certified third-party assessment organizations familiar with providing audits for all of these various frameworks. We’re intimately familiar with the development and ongoing workings of CMMC and can help provide insights through this blog and elsewhere.

If you have any questions, feel free to reach out! You can also book a demo of the Ignyte platform to see what it can do for you right away.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/cmmc/cmmc-shared-responsibility-matrix/