On October 27th, the Office of Management and Budget released a draft memo entitled “Modernizing the Federal Risk and Authorization Management Program (FedRAMP).” There are several interesting thoughts in here. One that is capturing a lot of attention in the community is the following:
- FedRAMP should not incentivize or require commercial cloud providers to create separate, dedicated infrastructure for Federal use, whether through its application of Federal security frameworks or other program operations.
Understanding FedRAMP’s Shadow Requirements
There are an abundance of shadow requirements in FedRAMP. These are not captured in the NIST 800-53 control requirements, but are layered on regardless. It’s one of the many reasons FedRAMP is so challenging.
One of the most impactful shadow requirements is that Cloud Service Providers (CSPs) may not comingle federal or commercial data. This includes customer-provided data, the stuff we typically think of as sensitive. But it also includes indirect data like logs, tickets, security information, vulnerability data and access control schemas. All this data needs to be segregated.
There is no FedRAMP control mandating this. It’s just something most US federal agencies require. This is especially impactful for Software- and Platform-as-a-Service (SaaS/PaaS) providers. Infrastructure providers get a pass via strict logical segregation that isn’t always possible in other cloud service models.
The realization that they will likely need to stand up a dedicated federal-only environment is one of the first major shocks that CSPs get as they start down the FedRAMP path. Moreover, since they cannot manage data collectively, they quickly realize that they will need to stand up – and staff – dedicated cloud and security management environments.
In our experience, the costs associated with standing up a dedicated federal environment, often a high six, sometimes seven figure undertaking, is a primary reason that CSPs abandon FedRAMP.
OMB clearly recognizes that this shadow requirement is a major barrier to FedRAMP achievement and would like to see it done away with. Unfortunately, it’s not as easy as just declaring that comingling is now allowed. A combination of FedRAMP’s rules and the intensity of the 800-53 controls push CSPs in that direction regardless.
Let’s look at a few.
Outdated Notions of Secure Access
Another FedRAMP shadow requirement is that CSPs need to implement one, preferably two, access control hops between corporate and FedRAMP systems. To implement this shadow requirement, most agencies mandate a traditional bastion host model for admin access to the cloud environment. Many agency Chief Information Security Officers (CISOs) adopt a very limited notion of what constitutes a bastion host. They expect to see a stripped-down Linux server on the perimeter, partying like it’s 1999. Many others also expect access to the bastion host to be limited to connections traveling a fed only Virtual Private Network (VPN).
Now there’s a lot here that makes sense. Corporate environments are a cyber cesspool, and maintaining separation between corporate and production zones is an essential security best practice. As an example, FedRAMP or not, a threat actor should not be able to compromise a corporate system and easily lateral into a production environment. Bastion hosts indeed serve as a strong access control checkpoint. Meanwhile, access to prod should never be public and a VPN is a straightforward way to achieve that.
But the expected FedRAMP way is not the only, or even best, way. Old school bastion hosts are deceptively difficult to securely configure and represent a dangerous single point of failure. Because they are a single point of failure, there are always back doors. There must be, otherwise you risk losing access to the system due to bastion failure. Meanwhile, corporate VPN compromises are so common, that organizations are increasingly leery of deploying them at all.
We live in an era where there are faster, more secure and more reliable ways to manage a cloud perimeter than the VPN -> traditional bastion host model. And while with effort the old model can work, many CSPs are eager to move on to more modern methodologies, particularly those that better support Zero Trust Architectures.
The Significant Change Request Process
The Significant Change Request (SCR) process is onerous. When a CSP wants to make a Significant Change to their product – which can be as simple as swapping out a piece of security gear or upgrading an OS – this triggers the SCR process. This involves substantial documentation, expensive reviews by a Third-Party Assessment Organization (3PAO) and a lengthy agency oversight process. A modern commercial cloud product simply could not function if it were subjected to the SCR process. So, no CSP will willingly subject their commercial environment to SCRs.
Modern CI/CD Pipeline Disruption
While the SCR process is an extreme example, even small changes can cause CSPs big FedRAMP headaches. Many CSPs operate Continuous Integration / Continuous Delivery (CI/CD) software pipelines. CI/CD pipelines emphasize automation and rapid release. They help small teams move fast and, when done well, produce better code.
There are actually no FedRAMP controls that expressly prohibit automated, CI/CD pipelines. However, the Configuration Management (CM) and Systems and Services Acquisition (SA) control families are complicated. It’s difficult for even experienced compliance pros to fit the CM/SA square peg into the CI/CD round hole. So, most CSPs give up, and maintain a separate, delayed and often limited release cycle for federal clients.
Vulnerability Management Requirements
FedRAMP mandates strict adherence to vulnerability closure timelines. All vulnerabilities, regardless of severity, must be closed within certain timeframes.
Closing vulnerabilities obviously makes sense. First, the relationship between vulnerability score and actual risk is complicated. Second, threat actors are creative about stringing together vulnerabilities to move around an environment post exploitation. Thus, I’m in the “close all of them, regardless” camp, at least as an aspirational goal.
But I am not most organizations. Most CSPs do not spend resources chasing unexploitable low and medium findings. And they don’t want to be bound to the “close everything” standard in their commercial environments. There is little day-to-day security benefit, and a whole lot of operational cost, to doing so. Despite my desire to see all vulnerabilities closed, I sympathize with this.
Strict FedRAMP Rules on Third-Party Services
Modern cloud environments interconnect in complex ways with third-party services. Even our smallest CSP clients often leverage two or three dozen unique third-party services in their cloud products.
These interconnections are a huge risk that the federal government must account for. Each interconnection presents A) an opportunity for sensitive government data to leave the authorized service and B) an opportunity for threat actors to jump from a third-party service into the federal cloud.
To manage this risk, there’s a perfectly understandable FedRAMP rule that third-party services that take federal direct and indirect data must also be FedRAMP authorized. But that severely constrains the availability of third-party services. There are not that many FedRAMP authorized clouds, and they’re all significantly more expensive than their non-authorized versions. It also often means that CSPs need to reengineer their products to make use of different third-parties. This can be an expensive, time-consuming undertaking.
FedRAMP is Really Expensive
Here’s one more, and it’s a big one: FedRAMP is really expensive. Not just to achieve, but to maintain. Commercial customers aren’t interested in paying for all the extra overhead that FedRAMP brings. So CSPs separate environments so that they can charge more for the FedRAMP-versions of their products, while keeping costs lower for their commercial environments. The cost of compliance is going to have to come way down if CSPs are going to be enticed to comingle.
A Path Forward for FedRAMP and Federal Security
I could easily rattle off another five or six FedRAMP nuances that force CSPs to bifurcate. The point is, several FedRAMP changes will be required if OMB’s desire for CSPs to realize OMB’s vision. Here are some thoughts:
- Smart Government Guidance: The FedRAMP Program Management Office (PMO) occasionally publishes smart, detailed, technically savvy guidance on cloud security and compliance challenges. We know from speaking with them that the PMO has some great thoughts on what modern cloud access control should look like, how to run a compliant CI/CD pipeline, how cloud vulnerability management should function and best practices for managing third-party security risk. We need these ideas to be public, so that we can discuss them with agency Authorizing Officials (AOs) and help them make better risk-based decisions in the cloud.
- Overhaul the SCR Process: The following things should NOT be considered Significant Changes: Swapping mainstream security tools, upgrading /switching mainstream OSs, major new feature releases, adding a well-known port or protocol, etc. They almost never materially impact FedRAMP security controls and they do not need to be subjected to federal oversight. FedRAMP has taken a good step in this direction recently, by making the process for adding new features to a product a bit more streamlined. But the community needs way more clarity if OMB’s vision is to be realized.
- A More Focused Definition of Federal Data: Since the FedRAMP boundary must encompass all federal data, the definition of federal data plays a major role in a CSP’s decision to stand up dedicated fed environments. The prevailing definition of federal data is so strict that it effectively forces CSPs to bifurcate. The current draft guidance, which is still in draft despite being originally published in June 2021 and updated in September 2022, relaxes the definition somewhat. But it’s still in draft – so has no real influence – and some additional loosening would be helpful. For example, the guidance should explicitly allow the use of non-FedRAMP authorized service providers for certain classes of indirect data.
- Statutory Protections for CISOs / AOs Moving to the Cloud: Ultimately, merging federal and commercial cloud environments will require the federal government to accept certain risks. Since cloud service adoption is a federal priority, we should carve out legal protections or safe harbors for CISOs, AOs and cloud security personnel willing to take calculated risks on cloud services. AOs and other agency leaders often feel like they are risking their careers when they approve cloud services, which obviously influences their risk tolerance. A safe harbor style protection would encourage the reasonable risk taking that will be required for comingled environments.
Making it easier for CSPs to comingle federal and commercial data would significantly decrease the cost and effort required to achieve FedRAMP compliance. But we need to recognize that there are several compounding FedRAMP forces that compel CSPs to separate environments. Negating these forces will require major changes to how the government thinks about cloud security. Here at 38North we’re excited to see how the FedRAMP program will navigate those changes and make FedRAMP more accessible to CSPs big and small.
Contact 38North Security
FedRAMP is hard. But working with us is easy. Contact us today so we can help you solve the FedRAMP challenges that are keeping you from compliance.
