As we move forward with accountability around cyber for the Defense Industrial Base (DIB), the specific language in the rules, controls, and requirements becomes increasingly important. In the previous no-accountability world if something was stupid and bad for security in your particular instance you could ignore it with little concern. Of course, the problem was that the vast majority of DIB companies were just ignoring cybersecurity en toto and as a result, the DoD has rightly relearned the lesson that, “you don’t get what you expect, you get what you inspect.” So, here come inspections.
Assessments are needed but now we must ensure that the rules are executable across the DIB. That they work well to raise the bar and do not drive “malicous compliance” behaviors. What is malicous compliance? Well, doing things that are low cost, and compliant, but counter to the intent of the regulation. I will fully admit that I consider myself on occasion guilty of malicious compliance.
A good example is the AC.3.021 (old model)/NIST 800-171A 3.1.15 assessment objective [a] privileged commands authorized for remote execution are identified. In an enterprise environment this is dumb. There is ZERO way to know what commands you will need, and even LESS way to control at the command level how to limit operating system commands for remote access. But… we must “identify” them in order to be compliant. So I wrote a documentation appendix that listed all Windows and Linux operating system commands and marked them as authorized. Not the intent of the rule, but compliant. A waste of time for real security, but compliant.
In keeping with the need to broadly examine the rules/regulations/requirements/controls to make sure that they are actually executable and make sense, one of the BIGGEST disconnects and assumptions has been the decision, taken years ago, that CSP’s that process handle or store CUI must be FedRAMP Moderate Certified.
From a government regulatory perspective, this makes perfect sense and seems reasonable. There is one major problem. FedRAMP, its processes, and its implementation have NEVER been designed to meet the requirements of the commercial marketplace. If we leave FedRAMP in as the standard for Cloud Compliance and then require it for commercial compliance we need some changes.
The biggest issue is that FedRAMP requires a government sponsor and a government need that is being fulfilled. What if there is a requirement like sales or proposal writing, that is totally unique to industry and no government requirement? The Federal government disdains anything to do with bid and proposal. Sales eewwww. Slimy contractors. We will deal with them at arms length and try not to let any of the sales slime stick. Good luck generating a government requirement for anything having to do with the sales cycle. Yet companies must have processes to develop offerings and sell to the federal government and increasingly large swathes of industry IT services are cloud or have some aspect of cloud enablement. It gets harder every day to buy IT for on prem purposes, particularly for SMB’s that make up a large swath of the DIB.
Let’s move this onto “or provide security for” language and the recent scoping guides. For anyone not familiar the scoping guides aligned with this "or provide security for" phrase in NIST 800-171, as clarified that “anything” security must meet full-stack CMMC requirements. Now I will make the leap that where this touches on cloud, the intent of the department is that FedRAMP certification would be sufficient. The Department to my knowledge has not said that in writing or in public comment anywhere, but we will go with the security community’s general feeling that “the must mean that FedRAMP is compliant too.”
Ok, for the sake of argument, FedRAMP is good enough. There are hundreds of thousands of security tools with a cloud component. There are 243 approved FedRAMP offerings in the marketplace after 10+ years of operation. The security tools that exist in FedRAMP are focused on government customers. In my discussion with some vendors, they were unwilling to sell their FedRAMP instance for commercial purposes for fear that it might invalidate their FedRAMP certification and endanger their support of their clients. This is not even touching on the extreme challenge of commercial entities, particular smaller commercial entities, being able to buy FedRAMP services when there are offerings. I spent 6 months chasing the leading offering in the space, and finally, the intervention of the CEO at a leading provider company was required to get authorization to buy it.
The Government and the associated contract support with decades of experience in the FedRAMP space find it very very easy to say “just be FedRAMP.” In some cases (many cases?) perhaps it is the world they know and are familiar with. Coming from a real commercial entity perspective though… this is much much tougher than it sounds.
We need some changes. We need modifications to the FedRAMP process to allow for non-government customers. We need faster mechanisms for approving FedRAMP offerings to meet commercial industry needs. Perhaps this could fit under the current regulation by writing a process for “or equivalent” FedRAMP compliance. One that companies can hang their hat on and know that their offering meets the standards, and organizations seeking certification know that what they are using from the offeror meets the grade as well.
So far, I don’t feel like the DoD or the professional community is really thinking about this. We need a re-look at FedRAMP when applied to commercial requirements with an eye toward enabling companies to meet the “reasonable security” standard, well… reasonably.