FedRAMP IaaS vs PaaS vs SaaS – What’s The Difference?

If you’ve browsed the FedRAMP marketplace in the interest of using a government-certified service, either as part of your own services or on behalf of an agency, you’ve likely seen the various -aaS designations.

The “aaS” stands for “as a Service”, and it’s part of how modern internet services function. What are the different kinds of services, and how do they engage with FedRAMP? The differences can be important.

Are IaaS, PaaS, and SaaS Part of FedRAMP?

First of all, let’s get one common question out of the way. Are IaaS, PaaS, and SaaS designations within FedRAMP? Are they part of the overall risk and authorization management program?

The answer is no. While they have meaning and potential repercussions within the FedRAMP environment, these aren’t designations created by or issued by the GSA or the federal government.

Instead, they are categories of digital services. There are many -aaS services available to consumers, to businesses, and yes, to the government. Whether or not an individual service is FedRAMP-authorized is an independent determination.

What Are IaaS, PaaS, and SaaS?

So what are these service categories?

IaaS stands for Infrastructure as a Service. These are online service providers that offer an underlying infrastructure that can be rented as a service. They’re very common, with major examples including Amazon Web Services, Microsoft Azure, and the Google Cloud Platform. Companies and government agencies can use the infrastructure as a service rather than spinning up their own datacenters or on-premises networks, while building their own custom apps and code on that infrastructure.

PaaS stands for Platform as a Service. While there’s a lot of thematic crossover between infrastructure and platform, platforms as a service are more built up. They aren’t just a hardware environment; they include elements of software or developer environments for a client to use. Companies like Amazon offer PaaS on their IaaS systems, so Amazon Elastic Beanstalk or Amazon Lambda, or Google App Engine, as well as third-party PaaS like Heroku, are all examples.

SaaS stands for Software as a Service. These are cloud-based applications, providing specific functionality to their clients. Instead of using an infrastructure to build an environment or using a platform to develop an app, SaaS has the app already available. There are a million such examples, ranging from Dropbox to Office 365 to Google Workspace to HubSpot.

There are also a lot of other “as a service” categories, though a lot of them are really just subcategories of SaaS. You have things like:

• Containers as a Service
• Hardware as a Service
• Knowledge as a Service
• Monitoring as a Service
• Security as a Service

… and many more. Realistically, though, most people aren’t using these overly-niche categorizations.

How the -aaS Categories Affect Businesses Seeking FedRAMP Authorization

If you’re a business and you’re seeking FedRAMP authorization so you can work with a government agency providing your services, the categorization can impact your operations in a few different ways.

First of all, you need to consider what dependencies you’re using for your own operations. If you’re building a task-focused app that would be useful to the government, and you’re using a Platform as a Service to host and run it, that could become a liability, or at the very least, a consideration you need to take into account.

A common question is, if you’re building an app based on IaaS or PaaS that has itself already been FedRAMP-authorized, does the authorization trickle down to you? For example, if you’re using the government-validated offering from Amazon Web Services, does that automatically mean you’re secure?

The answer is no, of course. There can be plenty of security controls that apply to you separate from the infrastructure you’re using. In fact, using a cloud-based platform can even open you up to more than if you were an on-premises app that the government could install on its own. FedRAMP even has a dedicated FAQ page for this question. FedRAMP does account for this separation, however, so some security will be inherited as relevant.

Next up, you need to consider the limitations on types of services, as viewed by the agencies. There are two main scales to think about.

The first is functionality. A piece of software offered as a service can perform the tasks the government needs, as-is, in place, without much extra configuration. When it’s validated and authorized, it can be trusted to be secure according to FedRAMP rules. On the other hand, infrastructure as a service requires the government to develop its own app (or install a third-party app on the hardware), according to its needs. This offers less immediate functionality, but more control over the entire environment.

The opposite scale is ownership. These three categories can roughly be considered tiers of vendor ownership. With IaaS, the vendor owns very little; they provide the hardware and base-level software like firmware or operating system, while the ownership of everything built on top of that is the responsibility of the agency. With SaaS, the vendor owns much, much more, and thus has a higher responsibility to keep it secure.

Beyond that, your type of operation will determine the kinds of security controls you’ll need to implement. SaaS often has the highest bar here, as they have the most ownership of components and the greatest responsibility in securing government data.

It’s worth pointing out, though, that though these three categories describe broad groups of online offerings, they aren’t firmly delineated. There’s a whole spectrum ranging from “renting an access account on a server farm and nothing else” to “subscribing to a task service that performs direct operations on government data”, with everything in between. A balance can be found between ownership and functionality, to suit every possible set of needs.

How Categorization Affects Agency Service Selection

From the agency’s point of view, the choice of what kind of service to use is significant.

Agencies need something that strikes the right balance between functionality and ownership, just as companies need to find that balance to offer.

Agencies generally want to use cloud services specifically because they don’t want to develop their own versions. The government uses cloud productivity apps because there’s no point in developing its own. They use datacenters for infrastructure because it’s costly to build and maintain their own. The pattern repeats.

At the same time, the agencies need to be assured of the security of whatever they’re using. While the point of FedRAMP is to ensure that security with a relatively minimal amount of engagement by the agencies initially, they still take it into account. Securing a large and complex SaaS offering might be a lot harder than a generally simple PaaS option, so an agency might not want to sponsor the SaaS on the long road to authorization.

Agencies have tasks they need to complete, and they’re going to pick the option that allows them to complete those tasks with a minimum risk and a delicate balance of responsibility versus functionality. In short, if it’s no more efficient than spinning up their own solution, it doesn’t offer enough benefits compared to the risks of using it, whatever “it” may be.

Agency Considerations for SaaS

Software as a service is very abstracted. The app exists in a browser window, and everything other than what agency employees access directly is the responsibility of the SaaS provider. Using SaaS involves giving up a lot of control and responsibility, but that’s not a bad thing; that control and responsibility are very labor-intensive and a significant burden. That’s why agencies often pick SaaS applications on the FedRAMP marketplace.

Take something like email, for example. To keep data immensely secure, the government would want to maintain complete control over email servers. That’s how it works for Secret and other classified information. But, for CUI and unclassified communications, lower-tier, less-secure email providers are fine. There’s no reason to spin up an on-premises email exchange server when using the Workspace for Government Gmail offering or the equivalent Microsoft Exchange offerings.

SaaS has a huge benefit, which is that it’s ready to use the moment it’s made available. Once FedRAMP authorization is issued, the application is available for government use. Often, SaaS apps even have data imports and transition tools to help move from whatever previous solution existed, as well.

The downside, primarily, is that SaaS has a high bar to clear for FedRAMP authorization. Since they’re doing everything, they have to be very good with scoping, implementing security controls, and establishing continuous monitoring. The more responsibility they have, the more they need to do to be ready to use.

Agency Considerations for PaaS

The middle ground of a platform as a service is a more hands-on experience for agencies. A good example is web hosting, which is an archetypal kind of PaaS offering. It’s still the agency’s responsibility to make the website they develop secure, but they can trust that the web hosting is itself secure.

It’s trickier with PaaS environments for things like app development. There may be no viable SaaS app that does what the government wants, or there may be limitations such that no viable app could be made. Using PaaS to develop an internal-use-only app would be the best option to avoid spinning up the environment internally as well.

The primary benefit to an agency when using PaaS is cost savings. The underlying infrastructure and platform are often one of the largest ongoing costs relating to managing an application, so offloading that cost and responsibility to the PaaS provider is much cheaper for the government.

When an application needs to be developed, but no extant third-party options are available or interested in pursuing FedRAMP authorization, agencies making their own using a validated PaaS option is the next best thing.

Agency Considerations for IaaS

IaaS is as close to bare metal as can be rented as a service. Agencies can simply buy access to data centers, computing, storage, networking, databases, and other base-level cloud services, and build what they need on top of them.

In a sense, it’s the digital equivalent of renting a building for a government office versus building a new facility. Renting an existing building is cheaper, and everything that goes on within the walls is the responsibility of the agency, while the building owner only cares for things like utilities and structural repairs as necessary.

The biggest paradigm in using IaaS is the “lift and shift” model, of taking something the agency did in-house and lifting it wholesale, shifting it to IaaS, and using it there largely unchanged. This allows for cheaper operations and less maintenance for things like physical hardware, but offers relatively little benefit beyond that.

IaaS is at its best when an agency needs something more or less completely custom, and no existing PaaS or SaaS options can do the job. IaaS is still a cost savings compared to in-house infrastructure.

Is the FedRAMP Process Different for IaaS, PaaS, or SaaS?

If you’re a CSP and you consider yourself one of those categories, is the FedRAMP process going to be tangibly different for you than it is for a CSP in a different category?

Fortunately, the answer is no. FedRAMP doesn’t care what category of service you are, just that you have a defined impact level and implement the relevant security controls to the appropriate standard for that level.

There will be differences, sure, but those are the same as any difference between service providers. Scoping, the selection of controls, and tracking evidence are all the same process.

No matter which category of service you are, we can help. The Ignyte Assurance Platform is perfect for analyzing and aggregating data about your security needs, tracking your tasks and POA&Ms, and much more. As a FedRAMP-recognized 3PAO, we’re more than happy to help you figure out what you need and how we can help you achieve it. All you need to do is schedule a call to see what our platform can do for you.