Although the new Cybersecurity Maturity Model Certification (CMMC) Scoping Guides bring much needed clarification, specific aspects of these documents threaten to severely degrade Defense Industrial Base (DIB) security.
The Department of Defence (DoD) has long recognized the need for a scoping guide to assist in bounding cyber compliance requirements under CMMC. In early December of 2021, the DoD published the first iteration of a scoping guide, but the professional community's reaction was largely nonplussed. “This is what we expected,” seems to be the general feeling. I believe there are some difficult points that must be addressed.
This week one commenter said to me, “Sometimes people make things more difficult than they need to be — you’d be surprised how easy compliance can be with a little creativity.” In reality, I would be shocked to find compliance with this standard easy in any way. I am not trying to make things harder than they need to be. Rather, I am reading what the DoD has said, looking at multiple companies, and asking, “What will we have to do to comply? What will we have to do to pass an assessment?” From my perspective, this can be extremely challenging, and goes far beyond implementing moderate security requirements which every company should be incorporating, as is often touted as the intended effect of CMMC.
Don’t get me wrong. The compliance standard is very necessary, and so are the assessments that go with it. But in this, we must have applied standards that do not create excessive barriers to compliance, and which do not force contractors to forgo real security in order to achieve compliant security. Very small changes in interpretation and enforcement approaches can have huge impacts. We do not want to force Organizations Seeking Certification (OSCs) to spend enormous amounts of time and money on things which fail to enhance security, in favor of enhancing the bureaucracy around security — or worse, which force OSCs to abandon effective security tools because they fail to feed the assessment bureaucracy.
New Requirements
Let’s discuss the new requirements detailed in the recent scoping guides. A number of professionals have noted, “There is nothing new here.” I disagree. The scoping guides carry with them new requirements for all DIB companies’ compliance programs. OSC’s, assessors, consultants, and others working inside the framework should be aware of them. Some of these additions makes a lot of sense, but it is still new work that OSC’s need to accomplish.
The DoD has created CMMC asset categories and mandated that all contractor assets be divided into these bins. The definition of assets, which were formerly viewed as hardware and software under NIST standards, has been expanded. Assets now include, “Anything that has value to an organization, including, but not limited to, another organization, person, computing device, IT system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), and related hardware (e.g., locks, cabinets, keyboards),” [NISTIR 7693, NISTIR 7694]. I did crib this specific definition from the CMMC Assessment Guide, which was published separately; however, the intent of the new scoping guides was clearly to apply the new, expanded definition.
The new work for assets then includes:
Binning all assets according to the new asset category including Out of Scope Assets (OOSA);
Adding new items to the asset inventory. For example, this says that if another organization is “of value” to a company then they must be added to the asset inventory. Company cabinets are now assets that must be accounted for, inventoried, etc. This potentially leads to a very large increase in asset inventory requirements, and associated cost/hours to incorporate and maintain this expanded list of assets in inventory;
Documenting all assets, except OOSA in the System Security Plan;
Documenting all assets, except OOSA in the System Diagram.
Once the assets are detailed by type, the OSC then specifies their intended CMMC Assessment Scope, and uses that scope as either a part of its own self-assessment or as a part of a third party assessment with a qualified CMMC Third Party Assessment Organization (C3PAO). The Good There are several things about the Assessment Guide that I think should be highlighted as positive steps forward. First, as always, this is the result of many people working hard to put together guidance for the good of the nation and the DoD supply chain. This is difficult, and requires careful thought. Thank you to the generally not-public figures who worked hard to bring this guide to completion. Second, the guide introduces the concept of Contractor Risk Management Assets (CRMA) — which are connected to the system, but as the name implies, are risk-managed — and this is a great addition. This ends a running debate on how devices that do not have CUI (or provide security), but are connected to the system, will be assessed. Third, the concept and definition of Specialized Assets is specified. This definition includes government property, IoT, OT, and test equipment, and requires that, “they are managed using the contractor's risk-based information security policy, procedures, and practices.” Again, this is a great clarification that provides needed options in the IoT/OT space especially. The Bad The number one problem here is the treatment of Security Protection Assets (SPA). Any lingering debate about the “or provides security for” phrase in NIST 800-171 has been resolved. However, we have resolved this point of contention in a fashion that, if enforced, will completely abolish security tools for the DIB. This is not the intent of the document’s authors, and many would argue that this will not be its impact. Allow me to make the argument. Any time you make a statement in absolutes, like ‘completely abolish’, it is suspect, and indeed in this case it is for effect. However, if I were to say ‘nearly all security tools for the DIB will be abolished,’ then one immediately jumps to the assumption that we just don’t want to, rather than that we can’t. Perhaps so in this case, but I don’t want to because executing on the order will be very bad for real security across the DIB, and frankly, in the companies I support. Instead of raising the bar, we will be eliminating real security in favor of implementing compliant security. The entire purpose of this expensive and painful exercise is to raise the bar and improve security across the DIB. If we craft that standard in such a way that it actually lowers security instead, then it is a massive failure. The DIB will have spent gobs of money in order to have worse security. I raised this issue over a year ago in my formal comments on the draft interim rule, D041, in the context of enforcing “only FedRAMP” in terms of cloud security tools. Many in the government community see this as a reasonable security requirement. These are the rules the government has had in place for ten years. In the case of the new scoping guides, we have gone a step further, though. FedRAMP is not sufficient or even relevant for all contractors. In fact, the scoping guide does not mention FedRAMP. The new requirement is that those cloud/service-based security offerings must meet full-stack CMMC requirements, and prove that they do so. None of them do. Not one. There are a number of ways that commercial enterprises can and do procure information technology services that are very different from the federal government’s methods. This is not a shock to most, but this fact has real, tangible impacts on what is reasonable for a commercial enterprise to deliver on in terms of its security architecture. A big driver of this problem, which is perhaps not as visible inside of the federal government, is that all security tools for at least the last five years have been moving towards software-as-a-service (SAAS) models. It is becoming more and more impossible to purchase on-prem security tools. Ok, so what? Buy compliant tools. We did not say they had to be on-prem. Unfortunately, in my view, the SAAS space cannot and will not become full-stack CMMC compliant. It is too expensive, too counter to their current architectures, and there is no return on investment for what is a niche market (and yes, from Carbon Black’s perspective, for example US DIB contractors that will be assessed for security compliance is a niche market). This leaves us with on-prem tools as the only ones that can be proved in an assessment to meet CMMC security requirements. Security Information and Event Management (SIEM) systems are a great example of this. SIEM systems are the heart —in my view— of a proactive defensive cyber operation. They are not required under the CMMC standard at Level 2. We can make an argument for them as a derived requirement, but the standard specifically allows for a much less effective manual log management process, primarily for the sake of small companies that might not be able to afford such a system. Under the new scoping guide, we have clarified that a SIEM explicitly, “provides security for,” and must meet all CMMC requirements. So, if you are using a cloud-based SIEM, then that must meet all CMMC security controls. Except, none of them do. So what is the answer? Get rid of it. It is not required to comply, and who cares if it is the heart of an effective security system? We have now traded real security for compliant security. Let’s talk anti-virus (AV). There are cloud-based components beyond the endpoint agent that enhance its effectiveness. The solution will be to cut them off, and therefore to make security worse, because we cannot prove compliance with the enhancement. Or, alternatively, contractors will only use anti-virus on out-of-scope systems. So, contractors will ask to defend the rest of their enterprise, but remove the AV from CUI assets because… well, we cannot make it compliant. The standard gives the OSC the option of designating where AV needs to be, so they will likely designate it on assets that are not Controlled Unclassified Information Assets (CUIA) or Security Protection Assets (SPA). In this way, we have traded real security for compliant security. If they can’t be compliant, the answer will become to get rid of protections, or to never acquire them in the first place, even when we know those tools would improve our security. I am sure many will read this as an exaggeration. However, I am absolutely confident that this is exactly the decision matrix that DIB companies and their compliance departments will go through. How well has the government been executing this for 10 years? Piffle. Fantasy. The government does not follow their own rules. When it gets hard or doesn’t make sense in government land, we risk accept it or ignore it. We like to point fingers at how terribly the DIB has implemented security (which is completely fair), but we forget that the IG has found government organizations to be just as bad or worse than their contractors. The infamous IG report that kicked off CMMC on the Missile Defense Agency contractor base? Try looking at the corresponding and formerly classified IG review of security at MDA itself (it is FOIA redacted… don’t panic). We need to carefully consider these rules and how we craft this framework, because unlike government cyber, we actually intend to hold contractors accountable now with real consequences for non-compliance. We need to make sure the orders are executable and result in the outcomes we want, namely, making security better. Recommended Adjustment The course correction for this is not unmanageably large, but it is very much needed. The easy adjustment is to clarify that in the scoping guide “applicable CMMC controls” refers to the controls that the Security Protection Asset/SPA is providing, as opposed to full stack CMMC controls implementation. Using the SIEM example, the assessor would want to review evidence that the SIEM meets the security requirements/controls for log aggregation and alerting. In fact, in the initial days of the scoping guide, that was the interpretation of a number of the community's security professionals. I strongly recommend formalizing that interpretation as correct via the FAQ or an update to the scoping guides. This will take significant pressure off of OSCs to give up on good security tools. which would introduce far more risk to the security of the DIB than leaving open the real, but much smaller risk of backplane compromise of a security vendor. Yes, I know we have seen that recently in SolarWinds, but I still strongly feel this is a much smaller risk, compared to eliminating all or nearly all existing security tools from the potential security playbook. What do you think? Leave your comments below and I look forward to the professional dialogue.