CMMC ESP Scoping for Managed Service Providers

The CMMC ecosystem is poised to be very strict in a very short amount of time, which means a lot of organizations are quickly finding that they need to do a lot of work in short order.

A significant area of concern is where MSPs fall into the spectrum of security. Managed Service Providers are a key part of how modern digital businesses operate, but they’re also distinct and separate from the businesses themselves.

As an MSP, what do you need to do with regard to CMMC?

Do MSPs Have to Adhere to CMMC?

CMMC is based on securing controlled unclassified information throughout the defense industrial base and supply chain. Anywhere the information touches needs to be secured at an appropriate level, which is often Level 2.

As an MSP, do you touch CUI? Or, more specifically, do your systems touch it?

This is where a lot of businesses get it wrong.

A company providing data storage likely needs to be secured to CMMC standards if any of that data, at any point, contains CUI. It doesn’t matter if you, as the MSP, actually access or interact with that data at all. You’re the owner of the hardware that stores it, so it’s your responsibility to secure it.

Now, this shouldn’t come as a surprise to you. Your clients shouldn’t be using an insecure vendor to store CUI, and if they are, they are violating CMMC. But, if you’re claiming you offer CMMC-secured services, and you aren’t, then you’re in for a heap of trouble.

On the other hand, some MSPs don’t actually touch or handle CUI. A company that provides remote vulnerability scanning and configuration utilities doesn’t touch the information itself, just the systems that secure it. That kind of MSP wouldn’t need CMMC at all.

It’s all about following the information. We’ve discussed this from the point of view of a client hiring an MSP, but now we’re addressing the MSPs directly.

If you’re an MSP that does not in any way touch or handle CUI, you’re good to go. If you provide temporary access services like vulnerability scanning or penetration testing, if you provide staffing services, or if you’re a provider of a commercial off-the-shelf product, you can be exempt from CMMC as well.

A few of you just breathed a sigh of relief. For the rest of you, read on.

What is an ESP in CMMC?

An ESP is an External Service Provider. An MSP is a Managed Service Provider. While these seem like different words for the same thing, there’s an important difference.

MSP is an industry term used for a classification of business. ESP is a specific definition ascribed by the DoD in the CMMC rules. An ESP is a third-party entity that processes, stores, or transmits FCI, CUI, or Security Protection Data (SPD) as part of its operations within the defense supply chain. ESPs are MSPs that need CMMC, basically.

Whether or not you’re an ESP doesn’t depend on the services you provide, the size of your business, or your location. It depends entirely on whether or not your systems touch any of the secured information that CMMC protects. Again: follow the information.

When you’re an ESP, you need to comply with CMMC, and that means going through the process everyone in the ecosystem does sooner or later: scoping.

How Scoping Works for ESPs

Scoping is, generally speaking, the process of identifying what elements of your business need to be secured, and to what level. It’s the foundational work you need to do to know where you should even begin with implementation.

Scoping is also a key part of how you manage your overall burden, in terms of time, effort, and money, for implementing CMMC. When you understand what is in and what is out of scope, you can adjust your business to narrow what is considered in scope, to reduce the overall work and expense necessary to implement and maintain security.

Step 1: Determine Your Level

The first thing you need to do as a managed services provider is determine what level you need. The majority will be level 2, but some of you may be level 1 or level 3.

Level 1 is for businesses and systems that store, process, or transmit Federal Contract Information (FCI), but not more sensitive information like CUI. FCI is considered sensitive but of generally low impact if there’s a breach, which is why the standards are lower.

Level 2 is for systems that store, process, or transmit CUI, which can include controlled unclassified information, security protection assets, contractor risk managed assets, and specialized assets. All four of these categories have slightly different rules governing them, as defined in 32 CFR 170.19.

Level 3 is also for CUI, but at a higher level and with more expectation of persistent threats. Generally, if you’re in a position to need level 3, you probably aren’t reading basic guides on whether or not you’re in scope on a blog. You’ll be working more closely with DoD vendors and C3PAO experts already.

Since the majority of MSPs that have to adhere to CMMC are going to be Level 2, that’s what we’re primarily going to be covering. Level 1 is just 17 controls and is a self-attestation, and Level 3 is very similar to Level 2 but with another handful of controls and higher standards.

Step 2: Identify and Define Your Strategy

Here, you have a few options and choices to make.

One option you might have is to decide that, actually, handling CUI and working as part of the DoD supply line isn’t worth it. It’s a perfectly valid decision to make; if you don’t want to have those contracts, you don’t need to. If any of your existing contracts are part of the DoD supply line, or if you wanted to win a contract that is part of it, you’d have to decide to end that relationship.

For some organizations, the investment in adhering to CMMC is high enough that it doesn’t make financial sense to implement rather than just losing a contract or two. For others, it’s very much a worthwhile endeavor.

If you aren’t abandoning DoD contracts, your next decision is to choose between a full-organization strategy and an enclave strategy.

A full organization strategy means implementing CMMC across the whole of your business, to ensure that every system you have is secure to the appropriate CMMC level and is capable of handling CUI as necessary.

In contrast, an enclave strategy means identifying a set of systems that will handle CUI and segmenting them off from the rest. They will need complete barriers around them. That means:

• Logical separation with firewalls, VLANs, access control lists, and other barriers that prevent anyone not authorized to access those systems from reaching them.
• Physical separation, to ensure that CMMC-secured systems are secured physically in the real world as well as digitally. In some cases, this can even mean a separate server room or facility.
• Operational separation, which ensures that only employees properly trained to access those systems can do so, and no one breaks the rules with unauthorized access or other violations.

Enclaves can be tough to implement and maintain, but once they’re established, they are easier to secure and have a lower threshold for security. It’s kind of like how the TSA secures the gates at an airport, rather than the whole airport itself.

This is why many big-name MSPs and CSPs have “X for Government” versions; these are the CMMC (or FedRAMP) secured versions of their services.

Step 3: Build Scoping Lists

Now, at last, we come to scoping in the mechanical sense. Technically, everything we’ve done to this point is also part of scoping, but most people think of scoping as the actual, tangible work that needs to be done, rather than the strategizing.

Scoping here means identifying what specific systems, assets, operations, and other elements of the business need to be compliant with CMMC rules. For level 2, that means things like:

• A documented asset inventory listing all of the hardware devices that are considered in-scope, including servers, employee PCs, mobile devices capable of accessing systems, and more.
• A similar list of digital assets, including user accounts, cloud services, and other software that is involved in the handling of CUI.
• A list of assets that are within the boundary but do not handle or engage with CUI themselves. Anything connected to the network that could be a means of ingress needs to be secured, but the number of relevant controls is lower for those assets.

Building a comprehensive asset library of everything within the boundary of CMMC is critical. This is the foundational guide you’ll use to validate the security of those assets, which can be everything from direct auditing to configuration management to vulnerability scanning.

You are allowed to define some assets as out of scope. In fact, that’s the core mechanism behind the enclave strategy. You will need to justify why out-of-scope assets are out of scope, and the defined separation between your enclave and the rest of your business is the evidence you use for that justification.

Step 4: Avoid the Common Pitfalls in Scoping

A lot of businesses make a lot of the same mistakes in scoping, so it’s good to be aware of them so you can avoid them.

The first is not mapping your data flows. We can’t stress this enough: CMMC protects the information. That means you need to know where the information goes and what it touches. The information’s security responsibility flows out and floods every system it touches, and every system that touches those systems if there isn’t a tangible separation. It’s like a network of pipes carrying water; they need to be water-tight unless there are valves blocking it from elsewhere, to avoid leaks.

Another common issue is shunting the responsibility of scoping and planning just to your IT department. While a lot of CMMC is technical, some of it centers around operations, some on personnel and training, and more. Every department needs to be involved in some level.

It’s also common to create an asset library, but let that library fall out of date. Things change on a daily basis in businesses, especially businesses on the scale of an MSP. Every time a piece of hardware is decommissioned, it needs to be removed from the asset list and disposed of properly. Every time a new device is added, it needs to be recorded in the asset list.

Finding Success with CMMC as an MSP

Many MSPs have found themselves surprised that they have to comply with CMMC after previously being able to funnel responsibility to clients. Many others have found ways to limit scope and shift responsibility through careful planning.

The goal is not to find loopholes to an attestation; it’s to provide appropriate security and avoid the expenses and penalties that come from a data breach.

As an MSP, you have decisions to make regarding how much you want to provide your services to the DoD supply line and how much investment you have in being able to implement that security.

Fortunately, there are tools that can help you succeed. In fact, this is all a big part of why we developed the Ignyte Assurance Platform in the first place. A big part of what the Platform does is help you maintain your asset library, along with the milestones and task status, in the process of implementing CMMC (and other frameworks) security. Along the way, all of the proof, artifacts, audit logs, and other documentation can be gathered in the platform for easy access both by your compliance teams and by your C3PAO.

To see what the platform can do for you, simply reach out for a discussion and a demo tailored to your needs. We’ll help you identify the right path forward as an MSP and how our platform can help you achieve that level of success.