Cloud computing and modern service models of software or infrastructure distribution present a problem to providers and customers alike–namely, how to properly assess and certify components in a way that considers the relationship between different modules, platforms, and apps. FedRAMP requirements define how assessors and Authorization approach different cloud offering service models to mitigate the issues related to this complexity and ensure the security of any given cloud offering used by federal agencies.

NIST and Defining Cloud Computing Resources

Cloud computing is the partitioning and provisioning of resources to users from third-party providers. In fact, much of FedRAMP is predicated on the fact that there is such demand in the federal space). While this provides great flexibility for companies that don’t maintain on-site specialists or IT teams, it also lends itself to unexpected interactions between secure and potentially insecure systems. 

The National Institute of Standards and Technology (NIST) Special Publication 800-145, “The NIST Definition of Cloud Computing,” specifies critical terminology around cloud computing used by federal agencies within different frameworks (FISMA, FedRAMP, etc.). 

Foundationally, NIST defines “cloud computing” as follows:

• On-Demand Self-Service: Users of the cloud offerings can provision resources, application services, or network storage automatically without interaction from the provider. 
• Broad Network Access: Such resources are available for use on standard devices connected to networks (workstations, mobile devices, etc.).
• Resource Pooling: The provider’s resources and infrastructure are comprised of several resources pooled to service multiple customers regardless of load or geographical location.
• Rapid Elasticity: Resources can be provisioned and released rapidly based on demand.
• Measured Service: Resources are metered, monitored, controlled, and reported on for the benefit of the provider and the user.

Service Types

Following these definitional criteria, SP 800-145 articulates the three standard service models that we are familiar with:

• Software-as-a-Service (SaaS): The provider offers customers the ability to operate applications through cloud architecture. Instances of the app must be available to the user through a thin client, such as a web browser. More specifically, the user has no control of the app’s underlying infrastructure outside the app’s specific management capabilities.
• Platform-as-a-Service (PaaS): The provider offers a platform onto which the user can deploy applications, software, or other resources via programming languages, development tools, and framework libraries. The user has some control over the platform, but they do not have control over the underlying infrastructure. Customers can launch their apps on PaaS architectures or host an ecosystem of microservices.
• Infrastructure-as-a-Service (IaaS): The provider allows the provisioning of system resources (networking, storage, computing and processing, etc.) to run arbitrary software (including operating systems, storage types, networking components, etc.). 

Deployment Models

Cloud stacks are only sometimes uniform or managed by a single organization. Modern cloud infrastructure often comes with several deployment models, each providing additional benefits and challenges.

These deployment models include:

• Public Cloud: Public cloud is deploying shared cloud resources on shared hardware. While providers will logically separate each cloud instance between users, they will often use the same processing, network, and storage components. Public cloud is cheap, fast, and easy to scale, but it can suffer from security and performance issues.
• Private Cloud: The opposite of public cloud architecture, private cloud systems are infrastructures in which resources are isolated per user. That is, the user of a cloud system will be the only one using the set of hardware for those resources. Understandably, private cloud systems are more secure and offer the user more control, but they scale less well and can be prohibitively expensive. Most private cloud systems are deployed on-premise, but private cloud vendor offerings exist. 
• Hybrid Cloud: A mix of public and private, hybrid cloud systems can provide the best of both worlds. Users can leverage a private cloud as needed for compliance or security and then burst using public cloud resources to maintain their scalability and keep costs down.
• Multi-Cloud: Unlike hybrid cloud architecture, multi-cloud is a collection of cloud resources (usually all public environments) pooled together across vendors. This arrangement allows more control over different variables based on system usage and helps organizations avoid vendor lock-in.

Authorization and the System Stack

Many larger providers will have several offerings that include all three of these categories, often with higher-level applications (SaaS) running on lower-level platforms (PaaS) and infrastructure (IaaS). Because of this, every layer of that stack (SaaS–PaaS–IaaS) must be FedRAMP Authorized individually.

This fact aligns with the overall approach that FedRAMP takes with cloud technology. Per requirements, every cloud offering from a provider must be authorized on a per-system basis before it is listed on the FedRAMP Marketplace. This is not on a per-provider basis–if a provider offers several solutions (especially those that cover SaaS, PaaS, or IaaS capabilities) then each must undergo the authorization process individually. 

Additionally, complications may arise when some of a provider’s cloud architecture stack is itself hosted by another provider. For example, a CSP may offer cloud platforms for app development that are themselves built within a third-party IaaS system. In this example, even though the third-party component isn’t hosted or maintained by the CSP, it still falls within their stack and must be considered part of the authorization process. If that IaaS provider isn’t FedRAMP Authorized, then the entire stack built upon it won’t be either.

So, Authorization and inventories become critical in hybrid and cloud environments… especially the latter. Adding additional cloud vendors means you have to track compliance across systems or more or less isolate those systems from one another such that no data or apps move between compliant and non-compliant cloud instances. 

Per the recommendations of the FedRAMP PMO, a complete understanding of a cloud stack should be part of the inventory provided as part of the FedRAMP assessment. This inventory creates a FedRAMP system boundary for all components to be assessed. 

Is Your Cloud Infrastructure Ready for FedRAMP Authorization?

Platforms, software, user interfaces, third-party vendors–each component of a cloud system can potentially impact FedRAMP compliance. It takes serious attention to detail regarding inventories, component interactions, and proper security protocols to ensure that every device and module within your FedRAMP boundary is adequately protected.