Welcome back everyone to the Deep Dive. You know, we love to really get into the weeds on this show. But today, we're tackling a part of CMMC that really seems to trip people up. Oh, yeah. For sure. It's all about how external service providers, those ESPs fit into the picture in all those different asset types and, even things like VDI. Yeah. Those are real head scratchers for a lot of folks. Absolutely. And thankfully, we've got our hands on some freshly updated guidance to help us sort it all out. That's good because there's a lot of noise out there. There is. And our mission today is to cut through that noise, make those technical requirements as clear as we can. That's right. The goal is to give folks the confidence to actually take action and, and move forward on their CMMC journey. Exactly. And, you know, you're likely already familiar with the whole idea behind CMMC, protecting that federal contract information and the controlled unclassified information that's CUI within the defense industrial base, the DIB. Right. The whole point is to safeguard that sensitive data. And remember, that three tier model from level one up to level three, it's not reinventing the wheel. It builds upon those existing cybersecurity regulations. Yeah. And I think that's important to remember. Levels one and two are really about validating where you stand today with your cybersecurity posture. Right. It's proving you're already doing the right things. Exactly. And then level three, that's where you ramp up the security specifically for those high value DOD programs handling really sensitive stuff and facing those persistent threats. The APTs. Exactly. And a key point here is that the CMMC level you need to achieve that actually becomes a condition for winning a lot of contracts that involve FCI or CUI. Yeah. That's not optional. It's a must have. Right. And the primes, those prime contractors, they're gonna flow down those CMMC requirements to all their subs based on what kind of data is being shared. So if you're in the DIB, this applies to you. Absolutely. Now we know these CMMC levels are closely tied to those NIST standards, the special publications Yeah. Like the big one, s p eight hundred one seven one r two. Oh, yeah. NIST is the foundation here. For our listeners who are already deep in this world, can we just do a quick breakdown of the practical differences between those CMMC levels? Absolutely. Think of it like climbing a mountain. Level one, that's base camp. Right? You're focused on those 15 basic security requirements you find in f r 52.20421. Right. That's all about protecting that federal contract information, that FCI. Exactly. And it's a self assessment. You do it yourself and affirm it annually affects about a 40,000 companies out there. So that's a lot of folks starting at level one. Huge number. Now level two, that's why we step it up. Right? We're dealing with CUI now, and it impacts about 75,000 TIB companies. Still a significant number. Absolutely. And here, we're aligned with DFARS 252.2047O12 and those 10 security controls you find in NIST SP eight hundred one seventy one r two. So things get a bit more complex here. A bit more involved for sure. Now depending on the type of CUI you're handling, you're either looking at a self assessment or you're bringing in a c three PAO, a certified third party assessor organization to do a formal assessment every three years. Okay. So an external assessment comes into play at level two? It can. Yep. But even with a c three PAO assessment, you still have to do those annual affirmations in between. Got it. So ongoing compliance is key. Always. Now that brings us to level three, the summit of our CMMC Mountain. Right. The peak for the most sensitive data. Exactly. What sets level three apart? Level three, that's specifically for CUI that the DOD program managers have designated as critical or high value stuff. Really, really important stuff. And it only affects a smaller group about 1,500 companies. Okay. So a much more select group. Much more targeted. Now here's the kicker. You've gotta do the full c three PAO assessment against all of NIST SP eight hundred one seventy one r two, all 10 controls, plus you're adding on another 24 requirements that come from NIST SP eight hundred one seventy two. Wow. So that's a total of a 34 security controls. That's right. It gets pretty intense. And the assessment process itself is way more rigorous. You have to undergo a DIBC CAC assessment. That's the Defense Industrial Base Cybersecurity Assessment Center. And that's on top of the c three PAO assessment. Exactly. You have to complete the level two c three PAO assessment first, then DIBC CAC comes in. Okay. So it's a multistep process. It is. And just like level two, it's required every three years with those annual affirmations in between. So you're always on your toes maintaining compliance. You have to be. Now as companies are working towards achieving these CMMC levels, they often rely on those external service providers, the ESPs. Right. Everyone needs help sometimes. This could be anything from your cloud hosting to your IT support, your security monitoring, all sorts of services. Pretty much any external company you rely on to run your business. Exactly. But how do we figure out where those ESPs fit into this whole CMMC puzzle? How do we scope them in? That's where things can get a bit tricky. So ESTs, essentially, they're companies that provide services to organizations that are undergoing a CMMC assessment. Those are called OSAs. Organization seeking assessment. Right. Now this includes your managed service providers, those MSPs, the managed security service providers, the MSPs, and, of course, your cloud service providers, CSPs. So a whole range of external vendors. A whole ecosystem. And the really important thing to understand is that how you scope these ESPs into your CMMC assessment at level two and level three, well, depends on two main factors. Are they handling your controlled unclassified information, that CUI? And are they considered a cloud service provider or not? Okay. So two key questions. Mhmm. CUI and CSP. Exactly. Those are the biggies. Let's break that down a bit. Let's start with those non cloud ESPs. If they are touching our CUI in any way, what's the rule? Okay. So if you have an ESP and it's not a cloud service provider and they're processing, storing, or transmitting your CUI in any way? Any of those actions. Right. And this includes situations where they might also be handling what's called security protection data SPD that's related to that CUI. Okay. So even data about how we protect the CUI? Exactly. If that's the case, then their entire service, the part that relates to that CUI, falls directly within your CMMC assessment scope. You've got to be able to demonstrate that they're meeting the applicable CMMC requirements as part of your overall assessment. So we're responsible for their compliance, essentially? In a way, yes. You need to show that they're meeting the requirements for for the services they provide to you. Now what changes if that ESP is a cloud service provider and they're handling our CUI? Okay. Well, for CSPs that are handling CUI, the baseline expectation is that their services need to meet FedRAMP moderate authorization. Authorization management program. Right? That's it. And moderate is a specific authorization level. It means they've gone through a rigorous security assessment and authorization process by the federal government. So they've been vetted, essentially. Exactly. And this aligns with the current DFARS requirements. So it's not a new thing with CMMC? Not at all. Mhmm. The logic is if you're putting your CUI in the cloud, that cloud environment certain level of preapproved security. Makes sense. Now what if we have an ESP, whether it's cloud based or not, and they don't handle our sensitive CUI, but they do manage things like our security tools? Okay. You're talking about what we call security protection assets, those SPAs. Right. Those are the tools we use to protect our systems. Exactly. So if an ESP only processes, stores, or transmits security protection data, things like configuration files for your firewall or logs from your intrusion detection system The intrusion detection system. The data generated by our security tools. Right. And they're not directly accessing or handling the CUI itself. Okay. So they touch the tools, but not the CUI itself. Right. In that case, their services are considered SPAs within your environment scope. So they're still part of our CMMC assessment? They are. You need to document them, and they'll be assessed as part of your overall compliance efforts. Just to confirm then, if we have an external vendor who, let's say, only fixes our printers and they have absolutely no access to our network or any of our CMMC related data, they're completely outside of our CMMC scope. Right? You got it. If an ESP isn't processing, storing, or transmitting either CUI or SPD on your behalf, then they're not considered an ESP in the context of your CMMC assessment. So it really all boils down to the data they interact with. Exactly. It's about the data or the security functions they provide within your assessed environment. Okay. That makes sense. Now it's interesting that you mentioned earlier that an ESP could choose to proactively get their own CMMC level two certification. Oh, yeah. They can absolutely do that. What's the benefit of that for them and for their clients? So when an ESP gets that level two assessment from a c three PAO, it's a big plus. It shows they're serious about security and that they've achieved a baseline level of maturity for the services they offer. So it's like a seal of approval. Kinda like that. Now it doesn't automatically make their clients CMMC compliant. Right. They still have their own work to do. For sure. But it does provide a level of assurance, and it can streamline the client's assessment process. Because they've already demonstrated some compliance. Exactly. It shows that the ESP is already operating under CMMC principles for the services within their declared scope. So it reduces the burden on the client? To a certain extent, yes. But one thing that's really important for everyone to remember is that even if an ESP has their own CMMC certification, the OSAs, those organizations seeking assessment, they still need to detail in their system security plan their SSB. Their own documentation. Exactly. They need to explain how those ESPs are meeting the relevant security requirements within the context of the OSA's environment. So it's not a free pass. It's just part of the puzzle. Right. You still need to connect the dots in your own documentation. Let's talk about some real world examples. Can we walk through some tangible examples of ESP services and what their CMMC implications might be? Absolutely. Let's take staff augmentation, for example. So that's when a company provides us with additional staff to fill gaps. Right? Exactly. It could be anything from IT help desk personnel to even a fractional chief information security officer, a fractional CSO. So we're essentially outsourcing some of our workforce. Right. Now if those individuals have access to your systems or if they hold administrative credentials They can log in as an admin. Exactly. Then they're very likely handling security protection data, that SPD. Because they elevated privileges. Right. Another example is procurement services. So a vendor who buys and installs equipment for us. Exactly. Think about a vendor that sets up your network equipment. They're probably gonna handle configuration details, which again falls under SPD. That makes sense. Then you've got infrastructure as a service, IS. This is a big one. This is where things get a little murky sometimes. It can be. So RIS is essentially when an ESP is managing physical servers for you in their data center, or maybe they've got a private cloud setup. So we don't own the hardware. It's hosted by them. Exactly. Now this is different from a full cloud service provider in that you the customer, you typically don't have those rapid on demand provisioning capabilities that you would get with a major cloud platform. So we can't just spin up a new server with a click of a button. Right. It's usually a more traditional managed hosting model. Yeah. Think of it like renting a dedicated server versus using a service like AWS or Azure where you have a lot more direct control. Okay. So less flexibility with IS. Generally speaking, yes. Now here's where it gets tricky. If that IS environment that the ESP is managing, if it houses your CUI Our sensitive data. Right. And it's not FedRAMP authorized, then your CUI is sitting on their infrastructure. And that's a risk. It can be. So in that case, how well they've isolated and secured your environment becomes a central part of your CMMCS central part of your CMMC assessment. So we need to scrutinize their security posture. Absolutely. And finally, let's not forget about the MSSPs, those managed security service providers who might be operating a security operations center, and SOC for you. They're the ones monitoring our systems twenty four seven. Right? Exactly. They're looking for threats and responding to incidents. So their whole operation is a key part of our security. It is. Their security tools and the analysts themselves, those are all considered SPAs. And the logs and alerts they manage, that's all SPD. So they're both providing security services and handling sensitive data. Exactly. They wear both hats. Let's go back to that staff augmentation example for a second. If our outsourced IT help desk has the password to our domain admin account Oh, that's a powerful password. It is. So that means they're definitely handling SPD. Right? Absolutely. Anyone who holds or uses administrative credentials within your CMMC scope is handling SPD. So that needs to be documented and assessed. You got it. You need to account for that in your documentation and assess it against the relevant CMMC requirements. No exceptions. Nope. And with IAs, you mentioned the distinction from those full blown CSPs. Can you elaborate on that a bit more? It seems like a crucial difference. It is. And the core difference often comes down to what's called elasticity and self-service. Elasticity mean? The ability to rapidly scale resources up or down. So with true CSPs, you can typically spin up a new server or add storage almost instantly through a web interface. Very little human interaction. Right. And you have a lot of control as the customer. But with IS from an ESP, it's often a more traditional hosting model. It's like having a dedicated server in someone else's data center. So less agility. Exactly. And that distinction is important because it affects how you approach CMMC compliance. If that IAS environment with limited flexibility houses your CUI and it doesn't meet those FedRAMP moderate equivalency requirements, then you really need to scrutinize how well the ESP has isolated and secured your environment. Because our CUI is at greater risk. Potentially, yes. It depends on their security controls. Let's zero in on MSSPs for a moment, specifically those operating a security operation center at CMMC level two. What are the key assessment considerations for an organization using their services? So when you've got an MSSP running your SoC at level two, their security monitoring and incident response capabilities, those are all considered SPA security protection assets. They're providing those security functions. Exactly. And that means you need to document them. They go in your asset inventory. You describe how they contribute to your overall security posture in your system security plan, your SSP, SSP, and you show their place in your network diagram. So we're mapping out their role in our environment. You got it. And you also need to be prepared to demonstrate how those SPAs, those security capabilities, meet the relevant level two security requirements. So we need proof that they're doing their job securely. Exactly. And remember that the SOC is handling security logs and alert data, all that stuff, which is all considered SPD. So we need to assess that aspect as well. Absolutely. That aspect of their service is assessed against the applicable level two controls. So we're looking at both their capabilities and how they handle our data. Right. It's a two pronged assessment. And how does that scrutiny change when we move up to CMMC level three for organizations that are relying on an MSSP for their SOC? At level three, the documentation requirements for the MSSP SOC, those remain pretty similar to level two. You still need to document them as both SPAs and handlers of SPD. So no change there? Not really. But the assessment itself, that's where things shift. At level three, the assessment includes a limited check against the level two requirements just to make sure those foundational security practices are in place. A quick sanity check. Exactly. But then the primary focus shifts to a full assessment against all the level three requirements that are relevant to the security services that MSSP is providing. So it gets much more in-depth. It does. The expectation at level three is a much higher level of sophistication and resilience in those security capabilities. Right. Because we're dealing with more sensitive data and more sophisticated threats. Exactly. The stakes are higher at level three. We've talked a lot about cloud service providers throughout this conversation. Let's make sure we're all on the same page. What officially qualifies ESP as CSP under CMMC? What's the defining characteristic? So CMMC leans heavily on the NIST definition of cloud computing, specifically NIST SP eight hundred one forty five. Okay. So NIST sets the standard. They do. And the key here is the provision of on demand network access to a shared pool of configurable computing resources. We're talking servers, storage applications, the whole works. Exactly. But it's more than just providing those resources. It's about how you provide them. With a true CSP, you have the ability to rapidly provision and release these resources with very little management effort or interaction with the service provider. So it's all about that self-service and rapid scalability. That's it. You can spin up a new server in minutes with a few clicks. That's the hallmark of a CSP. And for CSPs that are handling CUI, we've talked about that FedRAMP requirement. Can you reiterate why that's so crucial? Absolutely. That FedRAMP moderate or equivalent requirement for CSPs handling CUI is there to give you that assurance that the cloud environment itself has gone through a really rigorous security assessment and authorization process. And it's the federal government doing that assessment. Right. It's not just some internal checklist. It's a thorough evaluation. So it gives us confidence that the CSP is taking security seriously. Exactly. And without that FedRAMP authorization, there's a real risk to the confidentiality and availability of that sensitive information. So it's a nonnegotiable for CUI? Pretty much. Now one thing to keep in mind is that there isn't a formal registry for what qualifies as equivalent to FedRAMP moderate. So how do we prove equivalency? It's on the OSA, the organization seeking assessment to make that case. They need to demonstrate and justify why a non FedRAMP cloud service meets that same bar. And believe me, the c three PAOs and the IBC CAC, they're going to scrutinize that justification very closely. So we need strong evidence. You do. It's not something you can just hand wave away. What if we're using a cloud service for something that has absolutely nothing to do with CUI? Mhmm. Does FedRAMP still come into play? Nope. If your cloud service provider isn't processing, storing, or transmitting any CUI, then you don't need that FedRAMP authorization for that specific service. So FedRAMP is CUI specific? It is. But here's the catch. If that CSP is providing services that contribute to the security of your CMMC scoped environment, things like security monitoring or log management Even though they're not touching our CUI? Right. In those cases, those services would likely be considered SPA's security protection assets. So they still fall under our CMMC assessment? They do. They'll be assessed as part of your overall compliance efforts. So even if it's not CUI, it could still be in scope. That's right. You Look at the big picture. It sounds like figuring out if a particular ESP is actually a CSP Yeah. Can be a bit of a judgment call in some cases. Are there any rules of thumb we can use to help make that determination? There are some good indicators. If a provider is marketing their services as as a service, things like software as a service platform, as a service infrastructure, as a service, those ASS offerings Those are strong clues. Right. And if you subscribe to it and you have that ability to quickly scale up or down your usage The self-service aspect we talked about. Exactly. That's a strong indication that they're likely a CSP. On the other hand, if you're just hosting your own hardware in a data center managed by the ESP or if they're hosting your data in a way that feels very much like a traditional on premises setup. We're we're just renting space from them. Right. Then they're probably not a CSP. The gray areas often come up when you have an MSP sitting between you and a cloud provider. So an MSP managing our cloud environment. Right. If the cloud tenant is in your organization's name and you're getting billed directly by the cloud provider, even if the MSP is helping you manage it, the MSP isn't typically considered the CSP. So it depends on the billing relationship? It can. Yes. But if the MSP is the one contracting with the cloud provider and they're essentially reselling or significantly modifying that cloud service You're adding their own layer on top. Right. Then they might be acting as a CSP. And in those cases, they might need to meet that FedRAMP equivalency. So those situations need careful documentation. They do. You need to explain those relationships in your SSP and why you made a particular determination. Transparency is key. Let's go back to those security protection assets and data SPAs and SPD. You mentioned some important points about ESPs that only handle these things. The key takeaway is that if an ESP is solely handling SPD things, like managing your firewall, your intrusion detection systems, or if they're just providing the SPA itself, the tool. Not touching our CUI. Right. Then they don't need to have their own CMMC assessment or that FedRAMP authorization. So it simplifies things for those ESPs. It does. It clarifies that they're not subject to the same level of scrutiny. And one thing that often gets overlooked is that the configuration data that's needed to actually operate an SPA that's also considered SPD. So even the settings for our security tools are sensitive. They are. They need to be protected. And we look at how SPAs are treated at level two versus level three. Are there any key differences we should be aware of? There are some nuances. At level two SPAs are those assets that are providing security functions for your CMMC assessment scope. Pretty straightforward. So they're protecting the stuff that's in scope. Right. And you need to document them. They go in your asset inventory. You describe them in your SSP, and you show them in your network diagram. Same as before. Exactly. But you also need to be prepared for those SPAs to be assessed against the relevant level two security requirements. So we need to prove they're configured securely. Right. Now at level three, the documentation requirements are pretty much the same. So no change there. Not really. But the assessment itself gets a bit more intense. At level three, the assessment includes that limited check against level two controls just to make sure you've got the basics covered. A quick checkup. Exactly. But then they do a full assessment against all the relevant level three security requirements. And here's the kicker at level three. The scope of assessment for SPAs isn't tied to whether they're processing CUI or not. So even if they're not touching our CUI? Right. If they're providing a security function for your in scope environment they're in. So the net widens a bit at level three. It does. Let's move on to virtual desktop infrastructure VDI. It sounds like under the right conditions, a VDI setup could actually simplify our CMMC scope. Yeah. VDI can be a real asset in that regard. How so? So if you have an endpoint device, let's say a laptop, and it's configured solely as a client to a VDI environment. So it's just a terminal for accessing virtual desktops. Right. And it's specifically designed to prevent any local processing storage or transmission of CUI beyond just the keyboard video and mouse interactions. So the CUI never actually touches the laptop. Exactly. It all stays within the secure VDI environment. In those cases, that endpoint device can be considered an out of scope asset. So it's outside of our CMMC assessment. That's right. But there are some caveats. You typically need to use secure authentication methods like tokens or certificates. To prevent unauthorized access. Exactly. And you have to make sure that no CUI data can actually persist on that local endpoint. So it needs to be wiped clean after each session? Essentially, yes. The assessors, they're gonna look very closely at how that VDI system is configured to make sure those controls are in place. So we need to be able to prove it's secure. Absolutely. And if the VDI isn't properly locked down, if there's any chance that CUI could be handled on that local device, then that endpoint is treated as a CUI asset, and it's brought into scope. So VDI can be a great tool, but only if it's configured correctly. Right. Gotta make sure it's airtight. Now we've talked about different types of service providers, but there are also some interesting differences in how specific types of assets are handled between CMC level two and level three. Yeah. The asset categorization can get a bit nuanced. Let's start with specialized assets. What makes an asset specialized in the context of CMMC? So specialized assets are those assets that can process, store, or transmit CUI. So they have the capability. Right. But because of their nature, they can't fully meet all the CMMC's security requirements. There are exceptions to the rule. In a way, yes. Think about things like industrial control systems, those ICS devices that control physical processes. So like the systems that control our manufacturing equipment. Exactly. Or medical devices that are connected to your network. Those are often very sensitive. They are. You also have government furnished equipment, GFE, that might have inherent limitations. Because the government gave it to us, and we can't modify it. Right. Or maybe you have specialized test equipment in a lab environment. That's not connected to our main network. Right. So at level two, you need to document these specialized assets in your asset inventory. So we still need to track them? Absolutely. You describe in your SSP how you're managing the risks associated with these assets using your organization's policies. So we explain how we're mitigating the risk. Right. And you include them in your network diagram. So they're not invisible. Nope. But here's the difference. At level two, the CMMC assessment for these specialized assets only involves reviewing that SSP documentation. So they're not fully assessed against all the controls? Not at level two. The assessors will look at how you're managing the risk, but they won't assess them against all the other CMMC security requirements. There's a lighter touch. It is. Now at level three, the documentation requirements remain the same. So we still document them. Yep. But now you need to be prepared for them to be assessed against both the level two and the level three requirements. So things get more rigorous. They do. The assessment at level three includes a limited check against the relevant level two controls and then a full assessment against the relevant level three controls. So they don't get a free pass at level three? Nope. But the good news is that level three allows for the use of intermediary devices or compensating controls to help those specialized assets meet some of the CMMC requirements. So there's some flexibility. There is. It recognizes that you can't always fully secure the specialized system. And finally, let's unpack those contractor risk managed assets, those CRMAs. This seems like a category where the intent behind how the asset is used is really important. It is. Intent is key here. So CRMAs are those assets that have the capability to process, store, or transmit CUI. So they could handle CUI. Right. But they're not intended to do so because of your organization's established security policies and practices. So we've made a conscious decision. Exactly. You've decided that these assets will not handle CUI. And unlike specialized assets, they don't have to be physically or logically separated from the assets that do handle CUI. Right. They can be on the same network. So what's the catch? The key thing with CRMAs is the language in the CMMC assessment guidance. It says, if sufficiently documented, do not assess against other CMMC security requirements except as noted. So it hinges on our documentation? It does. So at level two, if you clearly document in your SSP how you're managing that CRMA to prevent it from handling CUI So we explain our controls. Right. Or if you describe how you're protecting any CUI that it might potentially access In case something slips through. Right. Then generally speaking, it won't be assessed against all those other level two requirements. This good documentation is our friend. It's essential. But if your documentation is lacking or if the assessor finds some potential risks during the assessment, they might do a limited check. So they might dig a little deeper. They might. So the goal is to have really robust documentation that clearly demonstrates how you're effectively controlling these CRMAs. And that's how we avoid those extra checks. Exactly. Now here's a really important distinction. If an asset can't meet any of the requirements in NIST SP eight hundred one seventy one r two It just can't be secured. Right. Then it should be categorized as a specialized asset, not a CRMA. Okay. So there's a clear line there. There is. And when we move from level two to level three, what's the big change in how CRMAs are treated? The big change is that if you have assets categorized as CRMAs within your level two scope and those same assets fall within your assessment scope for level three. They're still in scope at level three. Right. And then they become CUI assets at level three. So they're no longer exempt? Nope. They're treated as if they're handling CUI. So if you're planning to pursue level three after achieving level two, you have a couple of options. You can either fully secure those CRMAs and have them assessed during your level two assessment. So get it out of way early? Exactly. Or you can be prepared to treat them as COI assets at level three, which means they'll be subject to the full assessment. So we have to make a strategic decision. You do. And some organizations choose to define their level three scope as a subset of their level two scope, the speaker.