The shared responsibility model for cloud security

As a cloud user, your responsibilities to secure your infrastructure vary depending on your cloud service provider (CSP), the services you use, your industry and the country you’re based in. The matrix can become complex, with responsibilities often unclear. In this post, I’m describing the different shared responsibility frameworks used by the three cloud platforms AWS, Google Cloud, Azure, and DigitalOcean.

What is the shared responsibility model? ​

Both the cloud providers and customers have roles in maintaining security and compliance in the cloud. The shared responsibility model defines who is responsible for what.

• Cloud providers are in charge of “security of the cloud,” which is the underlying infrastructure, including hardware, software, networking, and data centers.

• Customers are in charge of “security in the cloud,” meaning they must secure their data, applications, and configurations. That includes includes managing user access and encrypting data.

Let’s use an example to illustrate this separation.

Shared responsibility with a storage bucket example ​

I’ll pick the classic example of an object storage bucket (Amazon S3, Google Cloud Storage, Azure Blog Storage). A storage bucket like S3 is an abstracted service, see How does S3 work under the hood? on Reddit. AWS keeps the file content in the bucket and the metadata that describes the content separate. The file contents are chunks of data stored in arrays with copies in at least three separate availability zones (essentially data centers). The metadata is stored in a database and points to the files. Here’s then how the shared responsibility applies.

• Cloud provider. AWS ensures the physical security of their data centers (literally as in who can enter the premises and walk into the door) and protects against threats against the operating system, the arrays, the metadata database, and the endpoints for customers to store and retrieve data.

• Customer. The user (typically a developer) is responsible for access control and permissions for all S3 buckets, and for classifying and encrypting the data in the buckets.

This separation is important, and developers usually understand it. It’s a persistent myth especially among non-technical users that the cloud provider, and the cloud provider only, is responsible for security. This can lead to arguments with management about the necessity of budget for security staffing, tooling and training.

Misconfigured by default ​

The shared responsibility model means that a cloud user needs to have an in-depth understanding of each service and the configuration option it provides, and what the cloud provider does to secure the service. Every service has a different configuration profile, and it can be difficult to determine the best security configuration.

This understanding is crucial when we talk about “defaults.” Each cloud service comes with a default setup. When you deploy a new resource with this default setup, it is “not secure,” meaning the resource is misconfigured and unprotected. This happens because the cloud vendors’ primary goal is to make the service work for you. So, by default, a service is “open” or “permissive,” allowing it to do whatever you need it to do.

The cloud provider can then refer to the shared responsibility model, showing it’s your job to configure and secure the resource. In other words, the needs of security are opposed to the needs of a convenient developer experience. Improving one typically hurts the other. As an example, let’s take the default settings of an security group in AWS. Security group controls inbound and outbound traffic for associated resources (e.g., a virtual machine).

By default, security groups allow all outbound traffic. That is absolutely not secure and probably unnecessary. But it’s also easy. If the default was “block everything,” your machine wouldn’t be able to communicate with anything when you start it up. You’d then need to spend time fixing it, which slows you down.

Security controls and access to markets ​

A triggering event for better understanding the SRM can be a compliance audit or a customer contract with specific security requirements, because they impact the levels of control a developer and a company have to implement and monitor.

Security is usually considered a tax on the business, because it doesn’t generate any revenue and consumes resources. But with regulatory compliance and customers, the conversation shifts from a tax to access to markets and contracts, because to conduct business you need to provide evidence of your security posture to regulators, auditors or a customer’s procurement.

To decide which security controls to implement, consider the three factors:

• Industry. Your regulatory compliance obligations

• Customers. Your customers’ security requirements

• Company. Your organization’s security standards

Let’s stay in the example of our S3 bucket, and for the sake of the argument let’s assume that we don’t have controls in place to understand if data in our buckets is encrypted, who has access rights, or even how many buckets and where (cloud accounts, regions, etc.) we have to start with.

• Industry. Different industries have developed their own specific security standards and compliance frameworks that also apply to cloud infrastructure, such as healthcare (HIPAA compliance), financial services (PCI) and government (FedRAMP). For example, HIPAA compliance regulates how Protected Health Information (PHI) data needs to be encrypted in transit and at-rest, which affects our S3 bucket and the connections to store and retrieve data.

• Customers. You might need to consider your responsibilities based on the location of your and your customers’ business. Different regions have regulations for processing and storing customer data. For example, in the European Union you need to follow General Data Protection Regulation (GDPR) and keep customer data in the EU. For our S3 buckets, that means we need to ensure that data is stored in buckets in AWS regions in the EU, or vice versa detect any buckets outside of the EU. Another more recent EU example is the NIS2 Directive, with its own cybersecurity and notification requirements. In some cases, the cloud providers have dedicated offerings to meet specific customer security demands. Examples include Amazon GovCloud for the US Government, or Google Cloud’s T-Systems Sovereign Cloud for the EU.

• Company. Organizations typically have their own security-related requirements. A popular use case is asset tagging across resources. Tagging helps manage cloud resources by categorizing them based on ownership, purpose, or cost center. A tag is a key-value pair to group resources, such as our S3 buckets. With tag rules, we can protect S3 buckets across multiple accounts and regions by applying a consistent set of policies. On the flip side, an untagged bucket may mean it’s unprotected and therefore become the source of a breach.

In the context of our S3 buckets, not knowing if data is encrypted, not knowing if buckets are consistently tagged, let alone have complete visibility into which buckets exist and where—we would not be able to demonstrate a good security posture or compliance with industry benchmarks.

Shared responsibility by service type ​

So how do I know which controls I have to implement? The answer depends on the type of cloud service you’re using. In general terms, the closer you are to the infrastructure layer, the more responsibilities you have as a user.

The Center for Information Security (CIS) has developed a model that breaks down responsibilities by the four main types of cloud environments or also workloads:

• Infrastructure as a Service (IaaS)

• Software as a Service (SaaS)

• Platform as a Service (PaaS)

• Function as a Service (FaaS)

The diagram below maps the responsibilities to user and cloud provider depending on the environment.

Let’s use another example to make this diagram more specific, and assume we’re in need of compute services and we’re running on Google Cloud. Here are the Google Cloud services that correspond to each type:

• IaaS. Google Compute Engine (GCE)

• PaaS. Google Kubernetes Engine (GKE)

• IaaS. No IaaS type-of-service for compute, but Google Security Operations to monitor your Compute Engine

• FaaS. Cloud Functions

Comparing the responsibilities between Google Compute Engine and Cloud Functions, as a user I’m still partially responsible for the security of the host infrastructure for GCE, such as the host operating system and patches to it. With a Cloud Function, that responsibility is abstracted away.

Examples of the Shared Responsibility Model ​

Each cloud provider has their own flavor of the shared responsibility model. Below are the models for AWS, Google Cloud, Azure, and DigitalOcean. Each provider also has offerings to help with the implementation of shared responsibility.

Amazon Web Services ​

The AWS Shared Responsibility Model is the “original” shared responsibility model. To implement the model, AWS offers training and frameworks like the AWS Well-Architected Framework which contains the Security Pillar, as well as the AWS Well-Architected Lenses for use case- and industry-specific compliance.

Google Cloud ​

Google expands on the shared responsibility model with its shared fate model. For the shared responsibility model, Google follows the separation by type of workload, as in the model below.

Shared fate enhances the shared responsibility model, where Google offers opinionated guidance on secure setups, recommended practices and risk management.

Google also offers foundational security blueprints, the Google Cloud Architecture Framework with a dedicated security section. With its Risk Protection Program, Google even offers cyber insurance.

Microsoft Azure ​

The Azure shared responsibility model is similar to Google Cloud’s model and follows the workload approach.

Microsoft is very specific that data, endpoints, accounts and access management are always the customer’s responsibility. For frameworks, Microsoft has the Azure Well-Architected Framework which equally contains a security pillar.

DigitalOcean ​

DigitalOcean is a smaller provider, but also has a shared responsibility model that follows the workload approach.

DigitalOcean offers product-specific responsibility models (e.g., for Droplets, Kubernetes, and Managed Databases). To implement controls, DigitalOcean recommends using the NIST Framework.

Shared responsibility and cloud security posture management ​

So how exactly do I implement the shared responsibility model in my infrastructure and continuously monitor that it’s applied to my resources so that I don’t have any misconfigurations?

The answer is security benchmarks.

The implementation of the shared responsibility model and security controls is a repetitive effort that every customer needs to go through, or at least “should” go through.

To standardize that process and the controls, the cloud providers and 3rd party associations like CIS, NIST, and ISO have developed frameworks (e.g., Well-Architected) and cloud security benchmarks that operationalize the best practices for each provider and their resources. The benchmarks are version-controlled and give guidance and recommendations on how to configure resources. These recommendations are written in plaintext. For example, recommendation 2.1.4 for the CIS 3.0 Benchmark for AWS says to “ensure that S3 Buckets are configured with ‘Block public access.’”

The information how an S3 bucket—or any cloud resource—is configured is available via the cloud provider APIs or the console. The CIS Benchmark document has step-by-step instructions how to obtain that information; e.g., as in the image below via API by using the command line.

By expressing the recommendation as an API call, I can extract the data, run the compliance check on a schedule, and identify any risks or misconfigurations that I need to fix, aka “remediation.” That way I fulfill my part of the shared responsibility model. This process of scanning my infrastructure to detect misconfigured resources and remediate risks is called cloud security posture management (CSPM).

And that is exactly the job-to-be-done that CSPM tools deliver. Some companies decide to build their CSPM in-house using open source (see my podcast episode with Lyft, Building an open source CSPM service), others purchase a SaaS product that doesn’t require ongoing maintenance.

Simplify shared responsibility with Fix Security ​

I hope this overview is helpful when it comes to understanding the Shared Responsibility Model, and why it matters. With Fix Security we’ve built a cloud security product that integrates with AWS, Google Cloud and Microsoft Azure and helps you determine your security responsibilities. Our CSPM provides complete visibility into the security state of your cloud environment, including more advanced features like our inventory for AI-SPM. If you haven’t seen it yet - sign-up or schedule a demo today!