Introduction
Imagine with me for a moment. Your CMMC assessment is about to kick off. You’ve been heads down implementing all this technical stuff, writing your policies and procedures, and updating your System Security Plan (SSP). You’ve been gathering evidence ferociously, and you’re at the point where you’re starting to see the light at the end of the tunnel to get certified. Hundreds of hours’ worth of labor, phone calls, Teams meetings, working sessions endured – all culminating to that moment when you’re confident that you’re ready to put your pencils down and deliver your SSP and body of evidence to your C3PAO Assessment team. You’ve worked so hard and, to top it off, you’ve heeded the advice of friends and experts in the industry advising you to be very careful about how you select and use Managed Service Providers (MSPs). Managed service offerings make the most sense for your business, so you’ve been diligent not to neglect that relationship for your assessment. You’ve obtained the most recent copy of your service agreement and terms of service, confirming they provide a clear, detailed description of the services provided. You’ve reviewed with your team the Customer Responsibility Matrix (CRM) they produced to ensure it makes sense, aligns with the requirements their services affect, and that you’ve implemented your part of any responsibility. For everything in your control, you are ready.
Monday morning comes bright and early, and the first day of the assessment kicks off with a documentation review. The assessors ask a few clarifying questions here and there throughout the day and point out a few minor things that need to be corrected, but otherwise, your documentation is looking good, with no major findings or issues. You queue up the document adjustments that they mentioned and take of them care of right away. All is good and well at the end of Day 1.
Day 2 arrives, and the control assessment begins. Access Control Requirements (mmmmm, my favorite!) The assessor asks, “Ok, so for 3.1.1[a], I see the authorized user list for your team that you provided looks to be in order, so no concerns on that. However, ….” Your heart sinks into your stomach. You could have sworn that, of all the requirements, the very first one wouldn’t have been an issue. You had your authorized user list, your authorization procedures, and your separation of duties in place that shows who can request new accounts for new users vs. approve them vs. create them once approved! You even had performed the monthly user account review procedure to ensure the authorized user list is updated and that the accounts active in the system are consistent with it! “What could I have done wrong? Was all that not enough?” you ask yourself. The following conversation ensues:
Assessor: “However, it doesn’t include names/accounts for all the MSP personnel to be logging into the system. Could I just get an authorized list of all the technical support staff from your MSP who are logging into your system?”
You: “Our MSP representative should be able to explain how they track their staff.”
MSP Rep: “Um, we can show you our Entra ID that has all of our users including those that could log into customer systems. Does that work?”
Assessor: “Hmm… Is there anyway you can show that those accounts are actually authorized to be there? An approval process or anything like that? Even better, could you provide some form of access approval for granting them access to customer environments where CUI might reside?”
MSP Rep: “Um… Not that I know of. We use Entra for everything, and if someone needs an account, we just create the account and give it whatever permissions we think they’re going to need.”
Ladies and gentlemen, apologies for the long introduction, but I really wanted to put an example of how serious the involvement of external service providers, especially those MSPs/MSSPs that have user accounts in your environment, are in your assessment. The above example shows that the MSP in this hypothetical situation was not prepared to demonstrate that they have a way to identify the users in their system who are actually authorized to be there, especially those remoting in and accessing customer systems. You can imagine this bodes poorly for their customer’s assessment.
In this blog, I want to point out some of the major concerns with the use of MSPs and how to select the right one with a lower risk of causing you issues during your assessment. I also want to briefly discuss some of the nuances, inconsistencies, and differing perspectives in the industry right now to, at least, hopefully aid you as you work through these complex topics.
Les’ pitfalls
IntelliGRC has been serving organizations of all shapes and sizes ever since we started this awesome journey. One thing we realized is that MSPs are probably the best way to propagate our GRC SaaS platform and methodologies to the most organizations possible. We’re super happy to engage directly with organizations, but often organizations use MSPs for much of their security and technical needs. Additionally, the rise of Compliance as a Service (CaaS) offerings by these service providers has led us to really prioritize those relationships which, in turn, help the most organizations possible. The reason I mention this is that I want to show that our heart is with these MSPs and we want them to be successful. We know, after a lot of time spent working with, teaching, and learning from these partnerships we’ve been able to foster, that service offerings around security and GRC is no laughing matter or trivial endeavor. These relationships are vital and the success of an organization that depends on such external services deeply hinges on how well their MSP has prepared to support them and their obligations, especially in CMMC.
You can imagine then that, with such responsibility, there can be some severe pitfalls for MSPs that aren’t prepared to support their customers’ GRC goals and cybersecurity requirements, whether contractually or even internally. For organizations that are required to meet the NIST SP 800-171 Rev 2 requirements as part of their contractual obligations with the Department of Defense under DFARS 252.204-7012 (referred to as Organizations Seeking Assessment or OSAs, or Organizations Seeking Certification or OSCs), the involvement of a MSP in an OSAs scope and assessment is pretty regulated. The 32 CFR Part 170 includes several requirements and assessment stipulations for the use of External Service Providers (ESPs) which includes MSPs. The most succinct set of requirements comes from § 170.19 (c)(2)(i)’s Table 4 (See below).
Something I like to point out first when explaining this topic is that an ESP is only an actual ESP for CMMC if it processes (should probably say “stores, processes, or transmits” but I digress) Controlled Unclassified Information (CUI) or Security Protection Data (SPD) as part of the services it provides to the OSA.
The first pitfall to call out in light of this is related to the nature of scoping. Because the definition of SPD is not as clear as it could be, it can be easy to over-scope your environment. You may end up including cloud services or system components outside of your control that don’t actually need to be included. On the flip side, if there’s not a clear understanding of the term “External Service Provider,” based on the CMMC definition for it, then it’s also possible to leave certain entities out-of-scope that should be in scope as an ESP.
Here’s an example of over-scoping we’ve seen. An assumption was made that any data/information that was relevant to the security of an information system was to be considered “security protection data” since the definition from the 32 CFR Part 170 says “.…SPD is security relevant information and includes but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.” The examples in the definition suggest that the intended scope of this data type is limited to technical data. However, because the definition states that it’s security relevant information and includes “but is not limited to…” the technical examples provided, there’s no clear definition of the data that is supposed to be protected and that brings system components or ESPs into scope if stored, processed, or transmitted (S/P/T) within such system components. This led to the OSA including a cloud service provider in scope as a security protection asset that simply provided security awareness training and stores the records of completion. The OSA assumed that the records of completion of security awareness training were considered SPD since the CSP was used to provide a “security-relevant capability” and the records were data directly related to such capabilities. Additionally, there was the logic that adversaries could exploit training records to identify social engineering or phishing targets among those who hadn’t completed training yet. Because the definition isn’t cut and dry, neither is the scoping. The general consensus from the CMMC community is that SPD is focused on tangible technical data like the examples provided in the definition, but it’s not 100% certain, and there’s a lot of subjectivity in the space right now.
To address this concern, our recommendation is to treat vulnerability scanners, scan result storage, SIEM tools, log storage (hot or cold), corporate password managers, key vaults, and configuration baselines (including benchmarks and scan results) as critical components. We recommend the following:
- Include them in your scoping considerations as SPD and SPAs,
- Implement NIST SP 800-171 upon them where practical (you can’t perform a background check of your log storage location and SPD doesn’t require FIPS-validated cryptography or FedRAMP Moderate if S/P/T by a Cloud Service Provider (CSP)
- If stored, processed, or transmitted by an ESP (MSP, MSSP, or CSP), make sure you get a copy of the service agreement and their CRM and make sure you reference it when you’re writing your System Security Plan as required by § 170.19 (c)(2)(ii).
This leads me to another major pitfall that can come up: getting the required documentation. It’s been clear under DFARS 252.204-7012 that the use of a CSP to S/P/T CUI would require FedRAMP Moderate Equivalency (FRME) or Moderate Authorization (FRMA). For a CSP to officially be either of these designations, the documentation required to be gathered by the OSA in § 170.19 (c)(2)(ii) is part of what the CSP has to have anyway, so obtaining it shouldn’t be too difficult since the provider is required to have it. The real struggle is with other in-scope providers that do not S/P/T CUI but SPD instead. Although it’s getting much better out there, there are still a lot of MSPs, MSSPs, and CSPs that would be in-scope as ESPs that don’t really even know what a CRM is. It would not be surprising if the MSP you’ve been with for 5 years tells you that they don’t have a CRM.
To tackle this situation, we recommend urgency and transparency sooner rather than later with the ESP. If you’ve not acquired their services yet, and you anticipate their services and portions of their systems (per the definitions and requirements I’ve already mentioned) will be in scope for your assessment, find out where they are at in developing their CRM and implementing the requirements on their systems where your data will reside and be processed. Use your best judgment as to whether you should proceed with the relationship based on their response. If they have no clue what you’re talking about and/or don’t seem to care, our advice would be to look elsewhere. You, as the OSA, are responsible for your system and scope that will be assessed, and it’s your assessment that would be at risk, so choose your ESPs wisely.
If you’ve already established a relationship with an ESP that doesn’t have all the required documentation and implementations they need for your assessment to be successful, communicate early and often as to what you need from them. If you value the relationship enough, invest your effort to help the ESP meet your needs; help them help you. Some MSPs are so good at what they do that it would be unfortunate for you to move on. Get counsel from others you trust and make wise decisions on how you want to address the gaps. An MSP that understands the weight of the situation you’re in and wants to retain your business will put in the work. I’ve seen this happen firsthand. It’s awesome to watch an MSP step up when they realize there’s a problem and do what they’ve got to do to make it right and protect your system in a compliant way.
This is only the beginning of the conversation. In the next blog, we’ll dig into how MSPs can build the right documentation, strengthen compliance alignment, and become trusted allies instead of weak links in the CMMC chain.
