Is “Dumpster Fire” too strong a word to describe CMMC 2.0 compliance concerns with many MSPs & MSSPs?
Tom Cornelius
Senior Partner at ComplianceForge | Founder & Contributor at Secure Controls Framework (SCF)
Editorial: The original version of this article was published in July 2020 and it is as accurate today as it was when it was first released, which is both unfortunate and surprising, as well as a bit comical in a really sad way. Since this article is still a popular reference within the CMMC practitioner community, we decided to refresh it for CMMC 2.0. Enjoy!
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 CMMC and their compliance activities as strictly an IT issue, when that is a very misguided assumption. For most Small and Medium Businesses (SMBs) within the Defense Industrial Base (DIB), IT is very rarely fully managed in-house, rather it is usually outsourced to a local Managed Service Providers (MSP) or Managed Security Service Providers (MSSP) thinking that these “IT experts” will handle it 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. There are some MSP/MSSP that fundamentally understand this concept, but 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 model, compliance is not driving concern and that is not good for CMMC compliance. I am rejoined by Levi Kapilevich from Neqter Labs to shed light on this flaws business model, how that 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:
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 an 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, it is “buyer beware” for what is actually being provided.
One of the common misconceptions by many MSP/MSSP is around the concept of their clients’ CMMC compliance through “inheriting” broader controls. From a CMMC compliance perspective, the 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, an 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. 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 make 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 that can have a cascading effect over related practices:
1. Compliance-Specific Documentation (NFO Controls – NIST SP 800-171)
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 NIST SP 800-171 / CMMC controls. 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 (NFO controls). 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) (CA.L2-3.12.4) and Plan of Action & Milestones (POA&M) (CA.L2-3.12.2) 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 of 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 assessment-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 (multiple NFO Controls)
What is the issue you should be aware of? An MSP/MSSP cannot manage all of your cybersecurity needs since it likely does not know all of your requirements. 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). This requires understanding the co-ownership nature of security controls and maintaining a unified picture of compliance efforts so that any deficiencies can be remediated promptly.
This oversight function is where documented, cybersecurity-specific roles and responsibilities are crucial. By documenting and educating stakeholders on their roles and responsibilities for CMMC, it eliminates assumptions and misconceptions about who is responsible for what 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. It is also important to understand that the more work you assign to an MSP/MSSP, the more your managed services bill will increase.
Your MSP/MSSP must have an established and resourced security program (NFO controls) that specifically covers the monitoring of security controls (CA.L2-3.12.3) and the periodic assessment of those security controls (CA.L2-3.12.1). This ties into the broader concept of developing and implementing risk mitigation plans (RA.L2-3.11.1) 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.L2-3.3.3)
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 (AU.L2-3.3.3), performing vulnerability scans (RA.L2-3.11.2), where it involves staying current on evolving threats and performing risk assessments 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 (SI.L2-3.14.6) and identify anomalous behaviors (SI.L2-3.14.7). It is one thing to monitor the logs of a perimeter device (SC.L1-3.13.1) 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.L1-3.1.2)
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 (IA.L1-3.5.1). Administrative controls that promise the MSP/MSSP won’t use their admin rights to access regulated data (FCI/CUI) is meaningless (AC.L2-3.1.5), 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) (MP.L2-3.8.1 & MP.L2-3.8.4).
A SOC 2 report for an MSP/MSSP that covers its data center for evidence of physical controls does not adequately cover CMMC/NIST SP 800-171 controls. Access control extends beyond just a datacenter, but anywhere regulated data (FCI/CUI) is stored, transmitted, and/or processed (PE.L1-3.10.1-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.L2-3.4.3)
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.L2-3.4.3-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.L2-3.6.1)
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:
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 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 (IR.L2-3.6.2) falls onto the OSC. There is also a need to test the response capabilities regularly (IR.L2-3.6.3) and perform Root Cause Analysis (RCA) upon closing an incident to learn from it in hopes of preventing a similar incident in the future.?
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 (MA.L2-3.7.1)
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 (SC.L2-3.13.2). This is where the MSP/MSSP needs to provide expert-level guidance and solutions for:
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 ITA 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/MSSPs
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:
Questions You Should Ask Your MSP/MSSP
We want to see the DIB succeed! We also know there are a lot of very competent CMMC practitioners, but there are also a lot of charlatans that only want your money. This comes to the “money grab” badging problem where there are unqualified people and businesses with legitimate-looking badges from the CMMC-AB (e.g., RPO program) that can often provide OSCs with a false sense of security by enabling consultants to literally wave a badge around for marketing purposes, even though the RP / RPO badges do not equate to competence with CMMC. Unfortunately, the badging program is essentially a money-making scheme by the CMMC-AB to pay its bills, where consultants, MSPs and MSSPs have eagerly paid money for a false sense of legitimacy with the RP / RPO badges.
?If the first thing you hear from a MSP/MSSP is, “We are a RPO and we have [x number] or RPs on staff [blah blah blah]…” just walk away and keep looking for a better option. If you want to keep talking with them, focus on competence and ask these questions:
If you want to save a bunch of money and possible frustration, this is what we recommend:
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 Accountability practices of standards.
President, Operations (SMB Manufacturing) | Community Volunteer | Humorist
2 年Great article. Just curious: Do you think the situation would look differently if MSPs were involved in the CMMC conversation earlier than now?
Framework Fanatic | Social Butterfly
2 年Excellent article . I think it would safe to say the flames on the dumpster fire are even larger now . Under the 2.0 model an even larger emphasis is put into the roles played by ESPs , especially MSP/MSSP. In the article one thing stood out that I encounter as I help OSCs find their way with CMMC: “Where this traditional MSP/MSSP model breaks down is haphazard IT hygiene and cybersecurity practices are not compatible with CMMC compliance requirements.” In my time interacting with OSCs this statement and what it represents is one the most common obstacles encountered. The PPT which are inherited as a part of the service no longer meet the appetite of the customer. Staffing constraints and philosophy of the provider do not support the requirements; and have no intentions of shifting to do so . Leaving the OSC in a position where they must navigate out of a contract, while making the decision on a new one .
Security Compliance Aficianado | Certified CMMC Professional | Governance, Risk & | CCA, CCP, CMMC-RP, CISSP, CCSP, CCSK | NIST, CMMC, FedRAMP, HITRUST | Patent Infringement Expert
2 年Love the picture
Solving the Log Aggregation Struggle for SMBs
2 年Honestly the fact the article holds so true almost two years since we wrote it, is something that should deeply concern most OSCs and the Cybersecurity Maturity Model Certification Accreditation Body (CMMC AB). I'm hoping that as we continue down this path of rulemaking with CMMC, groups like the CMMC Industry Advisory Group will shed more light and begin to accept members and insights from the MSP/MSSP community as they too are crucial aspects of the DIB.