Why FedRAMP actually makes it harder for government agencies to move to the cloud

TL;DR: The government’s new FedRAMP requirements — intended to make it easier for federal agencies to make the jump to the cloud — actually make it significantly harder for agencies to keep pace with the private sector.
7 minute read

Update 2018–10–25: The FedRAMP landscape has changed substantially since this post was originally authored, including the introduction of FedRAMP tailored under which GitHub is now FedRAMP authorized. The post remains unchanged for historic purposes.

Update 2015–03–17: Since this post was first published, the FedRAMP sites has moved from cloud.cio.gov to fedramp.gov, and much of the content originally referenced has been moved or removed. This post has been updated to remove failing links, but the content remains otherwise unchanged. You can see the full change history.

The government’s new FedRAMP requirements — intended to make it easier for federal agencies to make the jump to the cloud — actually make it significantly harder for agencies to keep pace with the private sector, let alone catch up. Designed as a centralized approval process for cloud service providers seeking to do business with the federal government, in practice, FedRAMP instead erects a walled garden around perpetual government contractors, and dredges a steep moat of bureaucracy to keep innovative and low-cost solutions at bay. Put simply, FedRAMP is GovSpeak for “no” at a time when we should be making it easier to say “yes”.

Everywhere you look, anyone talking about Federal IT reform — from CIOs to civic hackers — is saying one of two things:

  1. The federal government needs to be more agile; to work more like a startup; hashtag innovate!, and
  2. We can’t continue to rely on the same short list of traditional beltway insiders to get there.

Yet FedRAMP makes it harder to do just that, and here’s why:

How we got here

In the olden days (three years ago in government years), any time an agency wanted to stand up a new application in their data center, the agency would have to spend about six months and around $150,0001 going through a FISMA certification framework that included things like assessing the degree to which Something Bad™ happening would affect the agency’s day-to-day operations (for example, the IRS taxpayer database getting hacked would be “high”, the FCC’s kidz zone being inaccessible would be “low”).

As agencies began spinning up servers in data centers they didn’t own (“the cloud”), the same process continued to apply. Level headed IT innovators quickly realized that multiple agencies were certifying the same datacenter, with each agency individually required to go through that lengthy process each time. Enter FedRAMP:

FedRAMP creates a centralized mechanism whereby, if a cloud hosting environment has already been evaluated by one agency, other agencies can rely on that certification for their own use. That’s great for making it easier for the government to use government-specific services like Amazon Web Services’s GovCloud, services which typically have contracts in the hundreds of thousands of dollars, across what I’d suspect to be hundreds of agencies.

Where things went off the rails

The problem is that FedRAMP is both exclusive - everything must be FedRAMP — and over-inclusive — everything is FedRAMP. Most sources look to NIST’s definition of the cloud to determine FedRAMP’s scope:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

On-demand infrastructure like Amazon or Microsoft’s web hosting services, along with services targeted directly at government (for example, CGI Federal or Lockheed Martin’s cloud platform) fit squarely within that definition. These external systems replace what would otherwise be servers in the agency’s datacenter, and government contractors can easily offset the cost of certification and compliance for their purpose-built offerings. It’s logical (and efficient) to ensure such services jump though a centralized hoop before they are eligible for federal contracts, and as a taxpayer, I’m glad to know that those systems are secure.

The entire internet as an edge case

But what about the rest of the internet? The part not purpose-built for government? The services that meet industry standards that predate this one arbitrary government standard? You know, the things consumers use on a daily basis and ask “why can’t government just use X”? The part we want government to be able to more easily use?

The General Services Administration (the agency that oversees FedRAMP) has been spending the past few years quietly amassing just such a list of cloud-based services approved for government use. This includes things we’d largely assume the government should be able to use to engage with citizens — things like Facebook, Twitter, or yes, even Myspace — to services that the government can use for free or at a negligible cost to work smarter — things like WordPress.com/Tumblr, Socrata, and yes, even GitHub.

The problem is — under GSA’s own logic — these services are now (culturally) verboten, and are likely to remain that way for the foreseeable future, unless FedRAMP suddenly says otherwise.

Policies that scale on demand

Like many well-intentioned government efforts, in centralizing the authorization of cloud service providers, the FedRAMP team scaled up the batch size, but failed to also scale it down, or at least carve out an exception where it doesn’t make economic sense, essentially raising the barrier to entry for non-insiders, the same non-insiders which we want the to government to use to experiment with to break out of its old ways.

Take GitHub as a use case.2 GitHub’s a small business. The bulk of technologies you touch on a daily basis, large and small, trust GitHub with their source code. Government is no exception. About 200 US government organizations use GitHub, and more than 5,000 government employees already use GitHub in the US alone. The problem is, most of that use is either free (a great thing for taxpayers), or a negligible cost for government agencies. A typical government agency might spend $300 a year with GitHub, several powers less than I suspect that same agency spends on paperclips each year (presumably with less stringent review).

For GitHub to go through the FedRAMP process, it’d be forced to invest upwards of a quarter of a million dollars up front,3 and seriously disrupt its internal operations in perpetuity. If every federal agency (A) joined GitHub the day we became certified, (B) upgraded their account to our highest listed service level, and © never downgraded, GitHub might break even in a few years. Needless to say, FedRAMP isn’t in GitHub’s future right now.

That doesn’t stop a different federal government agency from emailing GitHub each day, explaining that they’re being told by their CIO that GitHub is “illegal”, and that they must close their account immediately, now that FedRAMP is the law of the land. Like any federal regulation, an extra-legal cloud of lore surrounds FedRAMP, chilling perfectly valid, innovative efforts.

The “sniff” test

For most private sector technologists, the proposal that Facebook, Tumblr, or GitHub4 constitute a “cloud service provider” simply doesn’t pass the “sniff” test. Yet fedramp.gov, FedRAMP’s official site, draws a clear line in the sand, stating that the following is to be considered “cloud”, if it resides out side of the agency’s HQ:

  • Blogging
  • Online surveys
  • Social networking
  • Information and knowledge sharing
  • Online communications
  • Collaboration
  • Productivity

The FedRAMP site even has a section dedicated to the “social media cloud”, to discuss things like “bookmarking”, “displaying multimedia”, and “RSS” feeds.

In a time when government IT is trying to “do more with less”, does every single system — including the one used to share funny animated GIFs — really need half a million taxpayer dollars worth of certification? Most startups get off the ground with significantly less capital, not to mention, we’d be doing ourselves a disservice if we flat-out refused to use any service that failed to comply.

Federal procurement made the same mistake

Don’t get me wrong. Government agencies shouldn’t trust fly-by-night sites. Cloud services shouldn’t just apply the “it fell off the back of a truck” level of service when given the public’s trust, but common sense tells us the same standard can’t apply to both building out a top-secret desert datacenter and clicking publish on a public-facing Facebook page.

Federal procurement has this same fatal flaw. The same multi-billion dollar process used to procure tanks and battleships is also used to get access to sub-thousand dollar industry standard services — a rounding error in any agency’s budget. The difference being, petty purchases below a certain threshold — purchases that would require the government to spend more in man-hours doing paperwork than the thing itself costs — have a simplified process: you just buy it. This creates a federal marketplace to test good and services in a low risk, low cost way before ramping up the procurement dial to eleven.

No as the default

It’s not that FedRAMP says “you can’t” use service X. In fact, it’s the exact opposite. It’s that they haven’t said “you can”, and in that silence, FUD — fear, uncertainty, and doubt — reigns supreme. There’s neither organizational incentive, nor a CYA-URL you can send your boss to turn the wheels of bureaucracy and get from “no” to “let’s take a look”. And that’s the problem.

If government is going to innovate, we have to get past “no” as the most common word in our collective federal IT vocabulary. Unknown does not mean unapproved, nor does it mean unapprovable.

Innovative efforts are by definition new, untested, and unproven. That’s why they’re able to provide a technologically superior or less costly solution than the status quo. As a trade-off, however, innovative initiatives don’t come with the traditional safety net of rubber-stamped paperwork that you might expect from established offerings like Microsoft Outlook or Sharepoint.

No one gets fired for buying IBM, but also nothing changes

Established solutions have their place in federal IT, just as do innovative technologies. When it comes to innovation, adoption necessarily involves some level of calculated risk, just as all technology does. However with outside-the-beltway efforts, you can’t look to long-established empiricism or a governing body to indemnify your decision. Success in the private sector needs to begin to carry some currency within government.

If you’re fighting to break from the status quo, it’s important to realize that “no” is often a stand-in for “I don’t know” or “we don’t have enough information yet”, and FedRAMP is simply the latest variation on this theme, just as FISMA, PRA, and countless acronyms were before it.

Don’t take no from someone not empowered to say yes. Can that same logic be used to tell you not to use Facebook, Twitter, Socrata or other services already relied on daily?5 Prototype small pilots, test the waters, expand. Most importantly, be that empiricism you want to see. The existence (or in this case nonexistence) of a URL can go a long way towards empowering government-wide shifts in how agencies work on a daily basis, and can have a tangible impact on the delivery of citizens services. Don’t let a single checkbox get in the way of that.

  1. Based solely on my not-remotely-scientific experience standing up several apps at several federal agencies. ↩

  2. As a reminder, I lead GitHub’s government team, but speak for myself. ↩

  3. Per consultation with a FedRAMP certified third-party accrediting organizations. We tried, really, we did. ↩

  4. I’d argue that GitHub isn’t a cloud service provider, as it fails to meet NIST’s definition of a cloud service. GitHub stores code, it doesn’t execute it, and as a subscription service, resources cannot be “rapidly provisioned or released”. ↩

  5. FWIW, the official FedRAMP site, uses UserVoice, a service which as far as I can tell, has not been FedRAMP accredited. ↩

Originally published July 29, 2014 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit