What is the soft underbelly of your CMMC program?
For a lot of companies, it is not what they think it is and the reason is primarily based on misplaced assumptions. Too many people and companies view Cybersecurity Maturity Model Certification (CMMC), including compliance with it, as strictly an IT issue. To compound this issue, for most SMBs within the Defense Industrial Base (DIB), IT is rarely staffed in-house and is usually outsourced to a local/regional Managed Service Providers (MSP) or Managed Security Service Providers (MSSP). The assumption is that these “IT experts” will handle all manners of IT and cybersecurity for them. The reality is that the traditional model used by MSP/MSSP is not conducive to CMMC compliance, based on the data-centric nature of the practices that Organizations Seeking Certification (OSC) must implement and govern to attain and maintain CMMC compliance. While there are some MSP/MSSP that fundamentally understand this concept, the vast majority are operating a business model that values economies of scale to provide affordable security services to smaller companies that lack dedicated staff. In this traditional model, compliance is not a driving concern and that is not good for CMMC compliance. I am joined by Levi Kapilevich from Neqter Labs to shed light on this flawed business model, how that model impacts an OSC’s compliance efforts and what can be done to remedy the situation.
When you look at the traditional MSP/MSSP model, it favors the MSP/MSSP over its clients. A few highlights include:
- One-sided contracts from MSPs are more focused on Service Level Agreements (SLAs) than on security and compliance.
- Actionable roles and responsibilities are usually non-existent when it comes to cybersecurity and compliance-related matters.
- There is a general lack of technical controls to prevent abuse of privileges for remote management tools.
- Current MSP/MSSP contracts do not require MSP/MSSP to attain an equal level of CMMC protection and go through a C3PAO assessment.
If you look at the graphic below, you will see that CMMC represents a potential windfall by MSP/MSSP since the vast majority of CMMC practices are either “good IT hygiene” expectations or cybersecurity-focused requirements. The allure is that if a MSP/MSSP can address these technical/procedural requirements, then the client can focus on the business practice-related requirements. In theory, it sounds great. However, in reality, it is “buyer beware” for what is really being provided.
One of the common misconceptions by many MSP/MSSP is around the concept of their clients’ CMMC compliance “inheriting” the MSP/MSSP's broader general IT and cybersecurity controls so those controls will apply to the client’s CMMC compliance efforts. From a CMMC compliance perspective, that mindset requires a data-centric approach that evaluates how controls protect the confidentiality and integrity of regulated data (FCI/CUI), regardless of where it is stored, transmitted and/or processed. Unfortunately, that is a higher bar than most MSP/MSSP are used to dealing with. For example, a MSP/MSSP may have documented change control processes for how it manages its IT infrastructure, but that broad processes would not be sufficient to “flow down” to the OSC in order to cover its specific change management requirements that it must have documented evidence of due care and due diligence of the practice being in place and operational. The MSP/MSSP might partially address the concept, but partial compliance with CMMC equates to a failed assessment.
Identifying The Root Cause
The issue comes down to money. The outsourced IT model that MSP/MSSP benefit from exists because economies of scale makes it more economical for a third-party to manage an organization’s IT resources. To make it economical, MSP/MSSP generally architect the most efficient processes and technologies available to provide “best-effort services” to multiple clients. This process involves the employees of the MSP/MSSP make educated guesses as to what is minimally-acceptable for providing services to clients where the MSP/MSSP likely has only a partial understanding of the client’s business processes and its applications, systems, and processes.
For many organizations, they realize that “best effort services” are better than doing nothing at all or going through the process of insourcing their IT and cybersecurity services, so it is a risk and cost-balancing act that is a part of normal business processes, regardless of the industry. Where this traditional MSP/MSSP model breaks down is haphazard IT hygiene and cybersecurity practices are not compatible with CMMC compliance requirements. MSP/MSSP who truly understand and implement practices to help their clients get and maintain compliance will undoubtedly be more expensive since there is clearly more time and technology-intensive requirement to provide CMMC-compatible outsourced IT and cybersecurity services.
Critical CMMC Issues With MSP/MSSP
Critical CMMC compliance issues with MSP/MSSP that need to be evaluated include the following practices/processes, since they can have a cascading effect over related CMMC requirements:
- Compliance-specific documentation (ML.2.998 & ML.2.999)
- Governance, Risk & Compliance (GRC) oversight (ML.3.997)
- Situational awareness (AU.3.045)
- Access control (logical & physical) (AC.1.002)
- Change management (CM.2.065)
- Incident response (IR.2.092)
- IT Asset Management (ITAM) (MA.2.111)
1 - Compliance-Specific Documentation (ML.2.998 & ML.2.999)
What is the issue you should be aware of? From a compliance perspective, if it is not documented it does not exist. Specific to CMMC, this means that documented policies, standards and procedures need to exist that cover all 17 CMMC domains and their subset of practices. Your MSP/MSSP must have documented policies, standards, and procedures that specifically cover the entirety of the in-scope systems, applications, and/or processes that the MSP/MSSP is contractually bound to address (processes ML.2.999 & ML.2.998). The scope of their documentation needs to address the MSP/MSSP at a corporate level, as well as how their own policies, standards, and procedures are implemented specific to protecting regulated data (FCI/CUI) in the OSC’s environment. In addition to just policies, standards and procedures, this includes developing and maintaining both a System Security Plan (SSP) (practice CA.2.157) and Plan of Action & Milestones (POA&M) (practice CA.2.159) that sufficiently covers those in-scope systems, applications and/or processes.
This co-ownership of compliance-specific documentation is where assumptions lead to non-compliance and will eventually end in a failed CMMC assessment for the OSC. For in-scope systems, applications, and/or processes, the MSP/MSSP must not only be contractually bound to develop the necessary documentation but also properly maintain it. Ultimately, as the OSC, it is your responsibility to evaluate the accuracy and completeness of any MSP/MSSP-generated documentation to ensure it meets your specific compliance obligations.
What can be done about this issue? The OSC needs to take ownership of compliance-specific documentation. This starts with assigning the role and responsibility for managing documentation to the employee who “owns” CMMC compliance operations within the OSC. This individual (or team) needs to work with the MSP/MSSP to create and maintain documentation to ensure the OSC is audit-ready. As business or technology changes occur, a process needs to exist to ensure the documentation accurately reflects those changes.
This process begins with a contractual perspective, the MSP/MSSP needs to have clear requirements to maintain documentation that will support the needs of OSC’s CMMC compliance. If the MSP/MSSP is unclear of those requirements, it is a good indication that the MSP/MSSP is a liability to your CMMC compliance efforts and you should research a replacement for them that can help you achieve CMMC certification.
2 - Governance, Risk & Compliance (GRC) Oversight (ML.3.997)
What is the issue you should be aware of? A MSP/MSSP cannot manage all of your cybersecurity needs, since it likely does not know all of your requirements. In reality, there needs to be an employee of the OSC who has some form of oversight for all CMMC compliance operations. At the end of the day, the OSC is responsible for securing the confidentiality and integrity of regulated data (FCI/CUI) since that is something that cannot be delegated. This legal obligation requires understanding the co-ownership nature of security controls and maintaining a unified picture of compliance efforts so that any deficiencies can be remediated in a timely manner.
This oversight function is where clearly clearly-documented, cybersecurity-specific roles and responsibilities are crucial. By documenting and educating stakeholders on their roles and responsibilities for CMMC, it helps eliminates assumptions and misconceptions about who is responsible for what specific practices and processes. Do not expect your MSP/MSSP to come to you with CMMC-ready roles and responsibilities – that is your job as the OSC to define who owns what, since every organization’s business model is slightly different and a cookie-cutter approach does not work. It is also important to understand that the more work you assign to a MSP/MSSP, the more your managed services bill will increase. With CMMC, you will increase the MSP/MSSP workload so it is to be expected that you will pay more for it.
Your MSP/MSSP must have an established and resourced security program (process ML.3.997) that specifically covers the monitoring of security controls (practice CA.3.161) and the periodic assessment of those security controls (practice CA.2.158). This ties into the broader concept of developing and implementing risk mitigation plans (practices RM.2.141 & RM.3.146) that need to apply to the OSC’s compliance needs. All of those actions need to be tied to their roles and responsibilities for CMMC.
What can be done about this issue? The MSP/MSSP needs to implement and manage a formal cybersecurity program. This starts with resourcing the cybersecurity program and its ongoing process of identifying and managing both operational and technical risks. This starts with getting the MSP/MSSP involved in the SSP and POA&M process, so the MSP/MSSP is intimately familiar with both the OSC’s business processes and technologies. Without that familiarity, situational awareness is a fantasy concept that will not exist in reality.
From a contractual perspective, the MSP/MSSP needs to have clear requirements to perform governance oversight that goes far beyond generic patch reporting or vulnerability scanning. If the MSP/MSSP does not have a resourced and proactive cybersecurity program, it is a good indication that the MSP/MSSP is a liability to your CMMC compliance efforts and you should research a replacement for them.
3 - Situational Awareness (AU.3.045)
What is the issue you should be aware of? Supporting the concept of governance oversight is maintaining situational awareness. Situational awareness goes beyond MSP/MSSP reviewing logs (practice AU.3.045), performing vulnerability scans (practice RM.2.142), where it involves staying current on evolving threats (practice SA.3.169) and performing risk assessments (practice RM.3.144) to understand organization-specific risks. This is one area where the traditional MSP/MSSP model’s “best-effort services” fails CMMC needs since there is an inherent need to understand the business processes of an organization to be able to review logs, monitoring network traffic (practice SI.2.216) and identify anomalous behaviors (practice SI.2.217). It is one thing to monitor the logs of a perimeter device (practice SC.1.175) for obvious failed logins, but it is entirely different to proactively manage the device to both keep it current and manage Access Control Lists (ACLs) based on business practices and be able to establish network activity baselines that allow for anomalous behaviors to be identified.
What can be done about this issue? The MSP/MSSP needs to implement and manage a defense-in-depth approach to situational awareness that covers the OSC’s compliance needs. This starts with getting the MSP/MSSP involved in the SSP and POA&M process, so the MSP/MSSP is intimately familiar with both the OSC’s business processes and technologies. Without that familiarity, situational awareness is a fantasy concept that will not exist in reality.
From a contractual perspective, the MSP/MSSP needs to have clear requirements to maintain situational awareness and share that with the OSC. If the MSP/MSSP does not have a viable process to maintain situational awareness, it is clearly evident that the MSP/MSSP is a liability to your CMMC compliance efforts and you need to replace them.
4 - Access Control (Logical & Physical) (AC.1.002)
What is the issue you should be aware of? Access control (logical & physical) is not about what the MSP/MSSP says it will or will not do but is focused on what it can do. If your MSP/MSSP has domain or enterprise administrative rights, then it has the keys to your kingdom and can do whatever it wants (practice IA.1.076). Administrative controls that promise the MSP/MSSP won’t use their admin rights to access regulated data (FCI/CUI) is meaningless (practice AC.2.007), since it really requires technical controls to prove that the MSP/MSSP cannot access data it is prohibited from having access to. This is where having a comprehensive inventory of your IT assets and data is crucial so that you can appropriately control the systems and repositories that contain regulated data (FCI/CUI) (practices MP.2.119 & MP.3.122).
A SOC 2 report for an MSP/MSSP that covers its data center for evidence of physical controls does not equate to CMMC compliance. Access control extends beyond just a datacenter, but anywhere regulated data (FCI/CUI) is stored, transmitted, and/or processed (practices PE.1.131-136). Does the MSP/MSSP only conduct operations in a secured and segmented Security Operations Center (SOC) or are their employees able to do work on your network from anywhere they have an Internet connection and their laptop? When you start peeling back layers of the compliance onion, you can quickly start seeing how access control can be the Achilles Heel of the traditional MSP/MSSP model.
What can be done about this issue? The MSP/MSSP needs to implement and manage practices that are capable of meeting CMMC’s logical and physical access control requirements. Similar to the issues with situational awareness, this starts with getting the MSP/MSSP involved in the SSP and POA&M process, so the MSP/MSSP is intimately familiar with both the OSC’s business processes and technologies so that appropriate access control mechanisms can be implemented and managed. Without that familiarity, access control will be ad hoc.
From a contractual perspective, the MSP/MSSP needs to have clear requirements to maintain logical and physical access controls. If the MSP/MSSP does not have a viable process to govern access control, it is evident that the MSP/MSSP is a liability to your CMMC compliance efforts and you need to replace them.
5 - Change Management (CM.2.065)
What is the issue you should be aware of? In the traditional MSP/MSSP model, change control is focused on availability, rather than confidentiality and integrity. This is centered around meeting Service Level Agreement (SLA) targets for uptime, where unexpected changes can lead to downtime and lost productivity. For the most part, CMMC does not care about availability beyond an OSC having backups – it is focused on the confidentiality and integrity of regulated data (FCI/CUI). This is where you need to look at change management from a security perspective and less from an operational IT perspective. CMMC requires that changes are analyzed, approved and documented (CM.2.065-066) where the scope of those changes involves the systems, applications, and services that store, transmit, and/or process regulated data (FCI/CUI). The approach has to be a holistic view of change management across all in-scope assets.
Does your MSP/MSSP have a Change Control Board (CCB) that you participate in as the asset/process owner? Is there a written analysis of the proposed change from a security perspective? Is the person reviewing the change qualified to assess the security implications? Those are all questions that you need to ask yourself about MSP/MSSP change control considerations.
What can be done about this issue? The MSP/MSSP needs to operate a formal CCB that governs the change control process for itself and its client environments. The OSC needs to identify one or more individuals who are capable of representing the OSC on MSP/MSSP CCB matters, regardless if it is in-person, a teleconference, emails, or a change management tool.
From a contractual perspective, the MSP/MSSP needs to have clear requirements and appropriate scoping for its change control operations. If the MSP/MSSP does not have a formal change management program that uniquely governs your client environment, it is clearly evident that the MSP/MSSP is a liability to your CMMC compliance efforts and you need to replace them.
6 - Incident Response (IR.2.092)
What is the issue you should be aware of? Per Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012(c), a prime contractor has an obligation to “rapidly report” cybersecurity incidents to the DoD within 72 hours of discovery of any cybersecurity incident. This means that within 72 hours, the DoD must be provided with a report on the incident that includes, but not limited to:
- Identifying compromised computers, servers, specific data and user accounts; and
- Analyzing systems, applications, and services that were part of the incident, as well as other systems on the contractor’s network(s), that may have been accessed as a result of the incident in order to identify compromised covered defense information, or that affect the contractor’s ability to provide operationally critical support.
If you are a subcontractor to a prime, you may have a contractual obligation to notify the prime within 24 hours of discovering a cybersecurity incident. If you are using an MSP/MSSP, you may need to have a 12-18 hour notification requirement so that you can meet your notification requirement to the prime, which then has to report to the DoD within 72 hours of the MSP/MSSP’s discovery. Is your MSP/MSSP capable of meeting that reporting timeline and providing evidence to support DoD reporting requirements?
While it is possible to co-own incident management with an MSP/MSSP, at the end of the day the responsibility to ensure that incidents are detected, tracked, reported, and resolved (practices IR.2.093 and IR.3.098) falls onto the OSC. There is also a need to test the response capabilities regularly (practice IR.3.099) and perform Root Cause Analysis (RCA) upon closing an incident to learn from it in hopes of preventing a similar incident in the future (practice IR.2.097).
What can be done about this issue? Both the OSC and MSP/MSSP needs to operate a formal Incident Response Plan (IRP) that legitimately addresses “reasonably foreseeable” incidents so that a viable plan exists to address the scenario(s) that is capable of meeting the organizations incident response and business continuity requirements.
From a contractual perspective, the MSP/MSSP needs to have a robust incident response capability that can meet both CMMC and DFARS requirements. If the MSP/MSSP does not have a robust incident response capability, it is clearly evident that the MSP/MSSP is a liability to your CMMC compliance efforts and you need to replace them.
7 - IT Asset Management (ITAM) (MA.2.111)
What is the issue you should be aware of? IT Asset Management (ITAM) is the broadest category for MSP/MSSP that really fits into the “good IT hygiene” concept that CMMC is trying to accomplish. Therefore it puts the onus on the MSP/MSSP to maintain a secure architecture and associated infrastructure to accomplish the required CMMC practices and processes (practice SC.3.180). This is where the MSP/MSSP needs to provide expert-level guidance and solutions for:
- Baseline configurations for all technology platforms that employ the principle of least functionality (practices CM.2.061-062).
- Proactive maintenance with the correct tools (practices MA.2.111-112).
- Conduct backups and regularly test the ability to recover from those backups (practice RE.2.137).
- Monitor network communications (practice SC.1.175).
- Implement physical or logical subnetworks to separate regulated data (FCI/CUI) from the rest of the network (practice SC.1.176).
- Implement content / DNS filtering services (practice SC.3.192).
- Conduct ongoing log review that feeds into incident response processes (practice SI.2.214).
- Conduct patch management and other preventative maintenance actions (practice SI.1.210).
What can be done about this issue? ITAM cannot just be left up to the MSP/MSSP since it is too important to be “hands-off” in that it impacts more than just CMMC but the overall viability of your organization to function. This should be viewed from the perspective of “good IT hygiene” that your organization should want to be doing, not grumbling that you must do it to meet a compliance requirement. Good ITAM practices can make your organization more efficient, reduce downtime, and make it more secure. Think of ITAM like eating your vegetables – it is good for you and keeps you healthy.
From a contractual perspective, the MSP/MSSP needs to have mastery of ITAM practices – if they are not masters at ITAM, then you should run away screaming in the opposite direction. If the MSP/MSSP does not have a robust ITAM capability, it should not consider itself a MSP/MSSP and is a detriment to your CMMC compliance efforts, so you need to replace them.
Guidance For MSPs
While many MSP/MSSP are likely hoping this article was never written, it also provides a glimpse at the growth potential for enterprising MSP/MSSP who want to distinguish themselves from the competition. CMMC opens up MSP/MSSP some creative offerings:
- Change management as a service
- Lifecycle management as a service
About The Authors
If you have any questions about this, please feel free to reach out.
Tom Cornelius is the Senior Partner at ComplianceForge, an industry leader in cybersecurity and privacy documentation. He is also the founder of the Secure Controls Framework (SCF), a not-for-profit initiative to help companies identify and manage their cybersecurity and privacy requirements.
Levi Kapilevich is the Director of Business Development for NeQter Labs, a cybersecurity software company that focuses on helping DIB contractors navigate their DFARS, NIST SP 800-171, and CMMC compliance process. Focusing primarily on managing the Auditing and Account
*graphic art credit - https://www.deviantart.com/inkoalawetrust/art/Dumpster-Fire-732775653