This is part two of a two-part series.
In the first installment of this two-part series, I unpacked the nuances and complications of FedRAMP and navigating the federal marketplace. To conclude, I will explore the implications of this system for both the private and public sectors, as well as solutions for startups hoping to break in.
The Federal Government
The impact on the Federal government is obvious. A select set of civilian agencies can modernize with the 320 FedRAMPed applications out of the 30,000 SaaS applications in the marketplace. The DoD has roughly 15 to choose from. This puts our government in a vulnerable position, having to make do with less choice and arguably less capable software than our adversaries. The timelines to implement innovative technologies is increased, causing our agencies to modernize without the most modern technology. The pace of change in the software industry is incredible and productivity gains, insights, and even security of the newer software solutions are better than the older ones. The Federal Government cannot effectively serve the citizens, protect the homeland, fight pandemics, and protect American interests without modern software. Unfortunately, for the Government, SaaS software is where all the innovation is taking place in software.
The CSP
If there is a winner in the bureaucracy, it is the Cloud Service Providers. Afterall, there is less competition. Contrary to what you might think, cloud service providers don’t only offer infrastructure. They sell applications as well. Looking at AWS’s portfolio, “Amazon Web Services offers a broad set of global cloud-based products including compute, storage, databases, analytics, networking, mobile, developer tools, management tools, IoT, security, and enterprise applications: on-demand, available in seconds, with pay-as-you-go pricing. From data warehousing to deployment tools, directories to content delivery, over 200 AWS services are available.” The CSP’s have 100’s of SaaS applications. The CSP’s must go through the same process as everyone else, but they benefit greatly from economies of scale. They hire one compliance team for all 200 products. They have one monitoring service for all 200 products. They have hired a 3PAO and they’ve built a working relationship with that 3PAO, accelerating their path. They have deep pockets and can make the investment because they know the market is less competitive because there are only 320 competitors in this market compared to the 30,000 vendors in the broader market.
The Software as a Service Company
For most of these companies, it’s game over before the first inning. As described, the path is so audacious that few ever attempt to achieve Federal compliance. Some take a shot at FedRAMP, usually disappointed that they invested so much money, only to later realize that FedRAMP only opened a select set of Civilian agency customers on the very specific cloud that they got their authorization on. A fast-growing SaaS company has so many places requiring investment. Do you invest in a region to open the South American market, or a tiny part of the Federal market? Southeast Asia or a portion of the Federal market? Tel Aviv and the middle east, or a small part of the Federal market? You get the point. AWS has 32 commercial regions (in addition to the 4 or so classified regions) around the world that all require investment. Companies must go where the opportunities are greatest and the barriers to entry are lowest.
Recommendation for Startups
You can simply dismiss the Federal market. However, The Federal Government is the single largest market for IT solutions. The Federal Government spends roughly $90B annually on information technology.
The solution has been there all the time. Forget about FedRAMP. FedRAMP only applies to “cloud services”. It doesn’t apply to all software, only software that is delivered “as a service”. So, if FedRAMP only applies to software as a service, then what regulations apply to traditional software not delivered “as a service”? Remember our friend, FISMA? FISMA is the prevailing requirement for all software. FISMA had a few very desirable characteristics. FISMA is the “easy button”.
- The certification and compliance responsibility falls entirely on the Government. The vendor’s software must meet the regulations, but the certs and compliance are the agency’s responsibility.
- When a CISO authorizes a FISMA ATO, he or she does not have to share his justification beyond his own agency. There is no spotlight on the CISO.
- As a SaaS vendor, once you have achieved one FISMA ATO, it is quick and easy to obtain others.
You might be asking, “what designates something as a cloud service?”. From the GSA web site, “Private cloud deployments intended for single organizations and implemented fully within federal facilities are not subject to the FedRAMP mandate and are the only exception to FedRAMP being mandatory for all federal agencies”. The CSP is considered “within Federal facilities”. For example, Gmail and Instagram are cloud services for email and photo sharing. We don’t have to manage the installations of the software, the upgrades, or even back things up. That is the responsibility of Google and Instagram respectively. Those applications are delivered “as a service”. But what if you delivered the software to the agency and they simply “install it” within their cloud boundary and manage it themselves. By definition, that is not a cloud service. It’s not terribly difficult to change the installation approach for the SaaS vendor to have the entire SaaS application run within the Government’s cloud infrastructure. As long as nobody from the SaaS company has access to the software and no information leaves the agency cloud boundary, you’ve met the criteria. It is possible to modify most software so that it looks and acts like a cloud service, despite not actually being a cloud service.
Sure, there are compromises with this approach for the Government and the SaaS vendor. It requires engineering action from the SaaS vendor to modify the software appropriately and have two different “stacks” as it’s called. It also makes upgrades and support more manual and more difficult for both the vendor and the Government. But it opens the entire Federal market with this one software change. Agencies can run the same software on the commercial cloud, GovCloud, and secret and top-secret clouds. And you can easily repeat this process for each cloud service provider. It can save the SaaS vendor millions of dollars while opening the market. This approach allows the SaaS solution to get to market almost immediately versus at least 18 months as a cloud service. Viola!
Recommendation for the Government
An important question to raise is, is there any data that we have today on Federal Government systems that we’d want our adversaries to have? I recognize that the DoD’s data is sensitive to our national security, but is our privacy data not essential to Americans? I would argue that there should be one standard for data security. It is either secure or it is not secure. And rather than having many different levels of security, let’s have one level of security for all civilian agencies and the DoD. Let’s standardize on either FedRAMP High or IL4. Under my plan, any SaaS application that achieves either level should be accessible to anyone in the DoD or Civilian agencies. We’ll leave the Intelligence Community out for the moment. Some might argue that requiring more rigorous standard over FedRAMP will increase the price for all. I would counter that achieving all the varying compliances (FedRAMP, FedRAMP High, IL4, IL5) raise the price for the SaaS vendors, which they pass down to their customers. With one required compliance, SaaS providers would have access to more than 2/3 of the Federal market (excluding the IC) and would be able to justify the expenses required to meet the one compliance. I recognize that it’s too late to eliminate the various region (GovCloud versus Commercial) requirements. There is too much infrastructure deployed, and it would be expensive to move everything to GovCloud.
Of course, we’ll need separate air-gapped clouds for secret and top-secret. I don’t see a way around the need for air-gapped clouds, but I would expect that the IL-4 compliance would be sufficient to meet the requirements of the air-gapped secret cloud and at least the lowest level of compliance for the Intelligence Community’s top-secret clouds, especially since it’s running in their air gapped clouds.
Summary
There is no Federal system that should be accessible to hackers. The idea that less secure systems result in lower prices to the Government is false. Too many different regulations increase the cost of SaaS software to the Government and eliminate choice. The government can actually improve security and reduce costs by going to a single compliance standard based on IL4. Until these changes are ratified, startups and SaaS vendors should modify their software so that it is not delivered as a SaaS service, enabling them to deliver solutions to much of the Government, now!
