Shared Responsibility Model

What is a shared responsibility model?

A shared responsibility model is set up to demarcate which cloud security security actions, processes and responsibilities lie with a cloud service provider and which ones lie with the end user. Think of a shared responsibility model as a cloud security framework that clearly lays out the security obligations of a cloud service provider and their customers.

You might wonder why a shared responsibility model is needed?

It begins with organizations adopting cloud services at an unprecedented rate. Cloud adoption was further accelerated by the Covid-19 pandemic. According to technology research and consulting firm Gartner, as much as half of spending across application software, infrastructure software, business process services and system infrastructure markets will have shifted to the cloud by 2025, up from 41% in 2022. By embracing the cloud, organizations gain agility, improve competitiveness, lower IT costs, and provide users with anytime, anywhere access to resources and data.

At the same time, cloud security has become one of the topmost concerns in the minds of CISOs and security teams in general. In a traditional IT model, your computing infrastructure is hosted on-premises. You are responsible for ensuring security across your operating environment, including the security of your hardware, applications and data. You are responsible for patching, managing security controls and more. There is no ambiguity about IT security ownership and accountability in an on-premises setup.

In a cloud environment, computing services are provided by external, third-party cloud providers. Irrespective of the cloud computing model you choose, from a security perspective, the cloud provider assumes a portion of responsibility for the protection of your data and assets. It is fair to say that cloud security becomes a shared responsibility between you and your cloud service provider.

How do you determine which aspects of cloud security your cloud provider is responsible for and which ones you are? This is the question the shared responsibility model helps to answer.

Simply put, the shared responsibility model helps delineate the cloud security responsibility between cloud provider and the organization leveraging the cloud services.

To understand this concept better, let’s consider a simple analogy from our day-to-day life. Assume that you love riding and buy a new motorcycle from a trusted company. The manufacturing company ensures that the motorcycle adheres to government safety standards and undergoes the necessary tests. After you make a purchase, you own a part of safety and maintenance. You do so by investing in additional safeguards, by driving within the speed limits, by wearing your helmet, and so on. Post purchase, the manufacturer co-owns the maintenance by offering you some initial free servicing and a longer-term warranty for some parts.

Similarly, the shared responsibility model in cloud computing ensures that the security ownership is clearly defined between the cloud provider and the organization using the cloud services. By working together with your cloud provider and sharing the security responsibilities, you ensure that the accountability lines are clearly defined. The shared responsibility model helps you maintain a secure cloud environment with less operational overhead on your part.

Every cloud service provider has its own shared responsibility model. Let’s look at the policies of a few key providers: Amazon, Google and Microsoft.

Amazon Web Services (AWS) shared responsibility model for infrastructure

How does AWS demarcate cloud security responsibilities?

Two phrases that delineate responsibility between AWS and its customers are: “security of the cloud” and “security in the cloud’.

AWS is responsible for “security of the cloud” wherein it is accountable for securing the infrastructure that runs each service offered in the AWS Cloud. That includes securing the hardware, software and networking and the physical security of the facilities that house AWS cloud services.

The customer is responsible for “security in the cloud”, the scope of which is determined by the AWS Cloud services that the customer selects. As an example, a customer using Amazon EC2 (Elastic Compute Cloud) is responsible for the security configurations and related management tasks. AWS requires the customers that deploy EC2 instance to be responsible for:

• Installing updates, security patches and the overall management of the guest operating system (OS).
• Managing security of any software applications installed by the customer.
• Configuring the AWS-provided firewall.

In summary, AWS manages controls for the host OS, virtualization layer and physical security of the infrastructure. The customer manages security for the guest OS and any installed software and the configuration of AWS-provided security.

Google Cloud Platform (GCP) shared responsibility model for infrastructure

Google Cloud Platform’s shared responsibility model is build with the assumption that you know the security and regulatory requirements for your businesses and how to protect your data and hosted resources.

GCP’s shared responsibility model varies according to three characteristics:

1. Workloads
2. Industry and regulatory framework
3. Location

Workloads

There are four categories of GCP cloud services:

• Infrastructure as a service (IaaS): Examples – Compute Engine, Cloud Storage, Cloud VPN
• Platform as a service (PaaS): Examples – App Engine, Google Kubernetes Engine (GKE)
• Software as a service (SaaS): Examples – Google Workspace, Chronicle
• Function as a service (FaaS) or serverless: Examples – Cloud Functions

The diagram below shows how responsibilities are split between GCP and its customers for each of these service categories.

Industry and regulatory framework

Shared responsibilities also vary according to the regulatory frameworks mandated for specific industries. For example, if your organization does payments processing, then Google Cloud: Shared Responsibility Matrix (PDF) defines how responsibilities are shared between you and Google with respect to the Payment Card Industry Data Security Standard (PCI DSS).

Location

How responsibilities are shared can also vary by country since every country has their own regulations. This is especially true for how organizations store their customer’s data. For instance, if you have customers in the European Union your organization will need to adhere to the requirements specified by General Data Protection Regulation (GDPR). The Google Cloud and GDPR resource clarifies how responsibilities are shared between you and Google.

Microsoft Azure shared responsibility model for infrastructure

Microsoft offers a variety of services: SaaS, PaaS and IaaS. For all of them, Azure expects you to retain the responsibility for data, endpoints, and accounts and identities. The division of responsibility varies for other functions. The following image explains the division of responsibility between you and Microsoft Azure, according to the service:

Shared responsibility model for containers

Containers are often compared with virtual machines but they are not the same. Virtual machines virtualize the hardware stack whereas containers run on top of the OS kernel directly. Containers virtualize at the operating system level. Being lightweight, containers offer many benefits such as speed, portability, scalability, isolation and more.

Given their benefits, the use of containers is on the rise. Gartner projects that 75% of organizations globally will be running containerized workloads in production in 2022, up from around 30% in 2020. With the growing demand and usage of containers, system administrators need a better way to manage all the containers in their environment. They typically do this via an orchestration system. One of the most popular orchestration systems is Kubernetes. Kubernetes, also written as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications.

Large cloud services providers offer container specific services, for instance, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), and Azure Kubernetes Service (AKS).

When it comes to the shared responsibility model for container services, the fundamental framework that each cloud provider defines remains the same as described above, though there are some nuances. For example, with GKE, Google describes how responsibility is split between Google and the end user as follows.

Google Cloud is responsible for securing the:

1. Control plane: The control plane is the key GKE component that manages how Kubernetes communicates with the cluster and ensures that the user’s desired state is applied. Google is responsible for hardening the control plane and making it more secure.
2. GKE Infrastructure: Google secures the underlying infrastructure running GKE, which includes hardware, kernel, storage, network, physical security and more.
3. Operating system: For each node’s operating system, such as container-optimized OS or Ubuntu, GKE promptly patches as they become available.
4. K8 distribution: GKE provides the latest upstream versions of Kubernetes, and supports several minor versions. It is Google’s responsibility to provide updates to these, including patches.
5. Google cloud integrations: Google maintains integrations to its Identity and Access Management, Cloud Audit Logs, Cloud Key Management services and more.

End users are responsible for securing the:

1. Nodes: This includes managing the security of nodes that run your workloads, including security for any newly installed software, configuration changes, etc.
2. Workloads: This includes workload security policies related to container images, data, identity and access management, etc.

Challenges with a shared responsibility model

Though the shared responsibility model is well-intentioned and helps segregate the roles between you and the cloud provider, it has also led to a few challenges. Here are three common key challenges with the shared responsibility model:

Misconfigurations

Security misconfiguration is one of the top sources of vulnerabilities in the cloud. This is outlined in several reports such as the 2022 Cybersecurity Insiders Cloud Security report, National Security Agency’s (NSA) guidance on mitigating cloud vulnerabilities and Cloud Security Alliance’s Top Threats to Cloud Computing report. A security misconfiguration in the cloud typically happens when the configuration settings in cloud services are missing or are erroneously implemented, thereby leading to an unauthorized access. The shared responsibility model typically includes workload-specific configurations as a part of the customer’s responsibility.

Few examples of cloud misconfigurations are:

• Misconfigured encryption: Incorrectly configured encryption settings in the cloud compute instances can potentially expose confidential information.
• Misconfigured logging: Cloud storage containers lacking appropriate logging and/or log storage can limit your ability to detect unauthorized data access.

A significant number of security misconfigurations happen due to human error. The constantly changing nature of cloud products plus the lack of visibility into misconfigurations also leave cloud deployments vulnerable.

Multi-cloud scenarios

According to the Cybersecurity Insiders report, 76% of organizations are now multi-cloud, i.e. using two or more cloud providers, compared to just 62% in 2021. Multi-cloud deployments have allowed organizations to work more efficiently and scale more easily but in doing so they have also added a new dimension of complexity from a cybersecurity standpoint. One of the challenges of using  multiple cloud services is that each cloud provider handles security differently. While there is reasonable documentation available via the cloud service providers, security teams must constantly stay on top of changes for each cloud service provider that they use.

Incident management challenges

Many cloud breaches have occurred in the recent past and the number is growing. The Accenture data breach in 2021 is just one example of a high profile cloud security breach. By accidently leaving four of its AWS S3 buckets open to the public, the company left itself open to a massive data exposure. The largest exposure was on a server that contained more than 137 gigabytes of data, including databases of credentials. The lines of responsibilities between you and the cloud provider can be blurry. Managing such events requires close collaboration and tight communication between the two parties to successfully respond to these incidents.

Securing the cloud with Balbix

Balbix enhances your cloud cybersecurity posture, and especially helps you overcome the key challenges of the shared responsibility model. Balbix’s cyber asset attack surface management (CAASM) solution improves your visibility of multi-cloud environments (it also extends to on-premise environments). To do so, it provides you with a complete asset inventory with which you can group and analyze your assets by business unit, by asset type or geographical location.

Balbix provides more than just visibility. Unlike other vendors, Balbix combines CAASM with risk-based vulnerability management (RBVM) and cyber risk quantification (CRQ) solutions.

Our RBVM solution allows you to discover unseen risks and prioritize and mitigate identified risks across multi cloud and hybrid environments. Balbix’s RBVM solution identifies exposure to common attack vectors, notably misconfigurations – the most exploited attack vector for the cloud – including issues with data encryption and overly permissioned instances.  It also allows you to respond to risks such as unpatched software vulnerabilities, weak credentials, missing security controls, poor encryption, trust issues and cloud infrastructure misconfigurations. In addition, with the Balbix CRQ solution, you can measure and report on breach risk in monetary terms, such as dollars (and other local currencies).