Avoiding the Pitfalls of the Shared Responsibility Model for Cloud Security

This post is also available in: 日本語 (Japanese)

The shared responsibility model for cloud security is one of those things that seems simple enough on the surface, but is actually very complex when you try to put it into practice. That’s probably why as many as 73% of organizations report being unsure about where their cloud service providers’ (CSP) responsibility for securing cloud workloads stops and where theirs begins.

Overcoming this confusion by understanding the details of the shared responsibility concept and how to put it into practice is critical for securing modern, cloud native workloads. This article offers an overview of what shared responsibility means and how to navigate its complexities.

What Is Shared Responsibility in Cloud Security?

At a high level, the shared responsibility model is easy enough to define: it’s a concept that specifies that CSPs share responsibility with their customers when it comes to securing workloads hosted on their clouds. The various CSPs have their own definitions – like those from Amazon Web Services (AWS) and Azure – but they all boil down to the same core idea.

The shared responsibility concept makes sense given that CSPs don’t have full control over everything users do on their clouds. They can’t force customers to configure IAM policies in a secure way or make sure that they patch their applications against the latest vulnerabilities, for example.

Likewise, organizations that use public clouds have limited control over their cloud infrastructure. They can’t monitor for vulnerabilities in a CSP’s servers or detect intrusions inside its network.

Thus, it’s only reasonable that CSPs and their customers must share responsibility for security, with each party taking the lead in securing the resources it controls.

Why Shared Responsibility Can Be Confusing

The shared responsibility concept probably sounds straightforward enough. For several reasons, however, it can be very difficult for organizations to understand how to apply it and ensure that they don’t mistakenly assume their CSP (or CSPs, if they use multiple clouds) is securing resources when it’s actually not.

Shared Responsibility Differences between IaaS, SaaS and PaaS

Probably the greatest source of confusion surrounding shared responsibility is the fact that the way organizations consume cloud resources varies widely. There are three main cloud service models – infrastructure-as-a-service (IaaS), software-as-a-service (SaaS) and platform-as-a-service (PaaS) – and each has different implications for shared responsibility.

IaaS

The shared responsibility concept can be applied most cleanly when you’re dealing with IaaS, which is the bread-and-butter service model for major public clouds like AWS and Azure. IaaS means that the CSP provides access to cloud-based hardware resources, such as virtual machines and storage, which organizations access over the internet. Under this architecture, it’s pretty clear that the CSP is responsible for the security of the infrastructure it provides, while the customer has to take charge for securing any applications and data that it chooses to run on that infrastructure.

SaaS

Things get a bit murkier when you are dealing with SaaS. If a CSP offers a SaaS application, meaning it provides the host infrastructure as well as the software, the line separating customer responsibility from CSP responsibility can be harder to define. Because the CSP rather than the customer controls the software in this case, responsibility for ensuring that the SaaS application is free of vulnerabilities shifts to the CSP. Likewise, the CSP is typically responsible for securely storing any customer data that the SaaS application ingests. At the same time, however, organizations that use the SaaS software are responsible for securing any data they download from it as well as securing access to it.

To put this into context, consider an organization that uses Microsoft 365, Microsoft’s cloud-based productivity suite. Microsoft is responsible for ensuring that the software it delivers through the Microsoft 365 platform is secure. It also takes responsibility for ensuring that Word documents or emails (among other files) that you create in the platform and store in its cloud can’t be accessed by people to whom you haven’t given access. But it’s up to the organization to ensure that access to Microsoft 365 resources is properly locked down, and that any files downloaded to local infrastructure are secure. The organization can’t blame Microsoft if one employee reads another employee’s email because access controls were not properly configured, for example.

PaaS

Matters may be even more complicated if you use a PaaS, which lets you develop and run applications in the cloud, because a PaaS blends SaaS and IaaS together. The CSP would be responsible for securing any underlying infrastructure that hosts the PaaS offering, but responsibility for securing software testing and deployment environments lies with users. Software applications that the CSP provides as part of the PaaS must be secured by the CSP, but software developed with them (including software offered to end-users using an SaaS model via a PaaS service) has to be secured by users.

In short, then, the meaning of shared responsibility depends in part on which type of cloud service model you are using. Given that most major CSPs offer IaaS, SaaS, and PaaS solutions, you need to be cognizant of which type of offering you are using in order to understand how shared responsibility breaks down between you and the CSP. It’s not as simple as saying “on AWS shared responsibility means this, while on Google Cloud it means that,” for example.

Multi-Cloud, Hybrid Cloud, and Shared Responsibility

The fact that many organizations now use multiple clouds at once can also complicate shared responsibility, especially if some of their workloads run in a public cloud and others run in a private cloud.

If, for example, you have a private cloud running on-premises to host some of your applications, and you host other workloads in a public cloud, the conventional shared responsibility model only applies to the public cloud portions of your workload. Responsibility for securing your private cloud lies solely with you, because you manage both the infrastructure and the workloads running on it.

If you use multiple public clouds, your various CSPs should all follow the same shared responsibility guidelines. Keep in mind, however, that the extent to which a CSP secures your data and workloads depends on which category of cloud service you are using, as noted above. Thus, if you are using AWS just for IaaS but you rely on Azure for SaaS, those two CSPs will provide different levels of security services.

Managed Cloud Services and Shared Responsibility

Matters can be complicated further if you use a “managed” cloud service. While different companies have different ways of defining what counts as a managed cloud service, it generally entails a solution where an external provider takes responsibility for deploying, configuring, and (usually) updating your software. The provider (which could be a CSP or a company that merely provides management services for cloud-based workloads) may also provide hosting infrastructure for your workloads, or it may not. It may even offer security-as-a-service as part of its management offering, or it may not.

Given all of the variables at play when using a managed service, there’s no one-size-fits-all rule for applying the shared responsibility model in the context of managed cloud services. You’ll need to look at the details of what your service provider does and doesn’t manage.

And above all, don’t assume that just because you are using a managed service, the provider takes full responsibility for security. For example, if you use Amazon Elastic Kubernetes Service (EKS), a managed Kubernetes service, AWS is responsible for securing the Kubernetes instance that it provides, but it’s up to you to make sure applications you deploy on Kubernetes are secure. Likewise, if you use Platform9 to manage an OpenStack cloud, Platform9 will provide security updates and other services, but it won’t secure the underlying hosting infrastructure, because Platform9 doesn’t provide infrastructure.

Applying the Shared Responsibility Model

Putting the shared security concept into practice for your cloud workloads requires assessing the details of the way those workloads are configured. As a rule of thumb, you should assume that you are responsible for securing anything that you have the power to secure within the context of whichever cloud service model you use. That approach will mitigate the risk that some security considerations might fall through the cracks, because neither your CSP nor you deal with them adequately.

However if the line between your workloads and the CPSs security still seems blurry, you're not alone. One of the most common cloud security myths is that a CSP will handle all of the security a company needs. To learn some of the others and for a further rundown of shared responsibility, check out the recent webcast 3 Myths Of Cloud Native Security, hosted by Matt Chiodi, CSO for Public Cloud at Palo Alto Networks.