Cloud Shared Responsibility Model explained

TL;DR 

• The cloud is not secure by default! The cloud providers do their best to follow good security practices and protect workloads, but there is a lot to do on the cloud consumer side to make the cloud secure. 
• The Cloud Shared Responsibility Model defines which responsibilities are covered by the cloud providers and which should be covered by the cloud consumers – and this is heavily dependent on a computing model in use. 
• Basic Shared Responsibility Models are generic and simplified. Companies should always make their own consideration when assigning responsibilities to cover, based on thorough analysis of their infrastructure and advanced models, like CAIQ. 
• Making the cloud secure is not an action, but a process. The cloud consumers have to constantly analyze the cloud security posture and adapt to each change in the infrastructure.  

Introduction to the Cloud Shared Responsibility Model 

More and more companies decide to move their workloads to the cloud – and for good reasons! Public clouds, like AWS, Google Cloud, or Azure, offer many advantages over on-premise infrastructure, including scalability, flexibility, manageability, and security. For all those reasons, many startups nowadays are emerging as cloud-native, which means that they rely solely on the cloud solutions without any in-house hardware.

In both cases, companies must hand over control over several critical security mechanisms to the cloud providers, for example, enforcing firewall rules or access control enforcement on the cloud accounts level. It is commonly known and emphasized that such delegation of responsibilities requires trust, but in my opinion, the trust should only follow through analysis of what the cloud providers are actually responsible for and which security aspects of the cloud infrastructure are still a cloud consumer’s responsibility. 

Unfortunately, there are still cases when the cloud consumers are shocked that not all the cloud resources are secured by default, and there are actually some actions (quite a lot, to be honest!) that are the cloud consumer’s responsibility and need to be done to protect the cloud workloads.  

This separation of security-related duties is called the Shared Responsibility Model, and in this article, I will explain how to select responsibilities that need to be taken care of by the cloud services consumers and what supportive documents can be used for that purpose.  

What is a Cloud Shared Responsibility Model? 

The Shared Responsibility Model is a concept that precisely describes which security related responsibilities are managed by the cloud services providers (CSP) and the cloud services consumers (CSC). The plot twist is that it heavily depends on a computing model in use – it is completely different for Infrastructure-as-a-service (IaaS), Platform-as-a-service (PaaS), and Software-as-a-service (SaaS). Below, there is a chart that presents the division of responsibilities in all the models:  

On-premise – in the old cloudless world there were no dilemmas – a company owned all the infrastructure (from microprocessors and switches to software and data) and that was solely its responsibility to manage all the security.

IaaS – this model assumes that CSP provides only virtual hardware resources, like EC2 on AWS or Compute Engine on Google Cloud. Of course, CSC does not have physical access to data centers, thus it is the CSP’s responsibility to ensure security of physical premises and hardware components. And here, we have the first potential point of failure – let’s take a look at networking security. The enforcement of network policies is the CSP’s responsibility, however, the network policies definition is the CSC’s responsibility. Of course, there are some default policies defined by CSP, but it is the CSC’s responsibility to verify whether the default policies fulfill CSC’s needs (usually, they do not) and define new ones.  

PaaS – in this model, CSP provides not only virtual hardware but also an execution environment, like App Engine on Google Cloud or AWS Lambdas. In this model, CSC does not need to manage OS security, it just provides code (for example, a web application) which runs on a platform managed by CSP. In this scenario, CSC needs to ensure that its own code is secure (in our example – no security vulnerabilities in a web application).  

SaaS – finally, SaaS is a model, for which CSP provides hardware resources, a platform, and an application for CSC. In this case, it is CSC’s responsibility to manage Identity and Access Management (IAM) and data security. Let’s take gdrive as an example of a SaaS solution – Google Drive.  
We trust that Google enforces security controls that prevent unauthorized access to our data, however, we cannot blame Google if we intentionally (or accidentally) share publicly sensitive data, right? Or if we grant access to such data to an untrusted party.  

Last but not least, keep in mind that the shared responsibility model works hierarchically, which means that if you use the IaaS model, you need to handle responsibilities from IaaS + PaaS +SaaS.  

In the cloud we trust – but should we? 

The Shared Responsibility Model tells us which part of our cloud infrastructure is handled by CSP, and in the perfect world, we should simply forget about those elements and focus only on our responsibilities. Too bad that world is not perfect, and we should still take into consideration the following risks: 

1. Security controls implemented by CSP can be vulnerable.

Like any other software, the cloud components, including security controls, can be flawed.

CSPs are doing a lot to persuade ($) security researchers to report the vulnerabilities under the responsible disclosure protocol, instead of letting them be exploited in the wild. Also, the software quality of the cloud components is exceptionally good ($) and statistically there is less vulnerabilities in the cloud itself than any other type of software.  

Having that said, vulnerabilities happen and sometimes risks associated with them can have a significant impact on CSC For example, in 2021, Google paid $133337 USD bounty to Sebastian Lutz, who found a bug which allows an attacker to bypass Identity Aware Proxy (IAP), which is a fundamental security control for Google’s Zero Trust model.    

2. Generalization of the shared responsibilities.  

The above-mentioned diagram with separation of responsibilities is somewhat generic and should be treated more like a hint than a definitive answer to “who should be responsible for what” question. Let me give you an example: in all the cloud computing models, CSP should be responsible for Logging and Monitoring and it is true that CSPs provide these capabilities but they are not necessarily enabled by default.  

In Google Cloud, Admin Activity Logs are enabled by default, System Event Logs are enabled by default, however, Data Audit Logs are disabled. The reason for that lies in cost optimization of platform usage as this type of logs tends to be quite large. This decision seems reasonable, but if we need to monitor who accessed our Cloud Storage bucket objects, then we need to remember to explicitly enable this type of logging.  

Another thing to remember is that the cloud, on its own, can only log its own components. For instance, when writing a Java application, we still need to use logging frameworks, like Logback, on our own. Having that done, we can ingest logs from the application into the Cloud Logging with a dedicated library, and all that might be a bit counterintuitive for ones who only take a look at generic shared responsibility models. 

Cloud data breaches – who is responsible? 

Let’s take a look at four cloud security data breaches and consider who is responsible for them – CSP or CSC.  

Capital One data breach: 

Capital One decided to use a third-party WAF (Web-Application Firewall) hosted on the EC2 machine – Apache Mod.d. Of course, this is allowed, after all it’s not enforced to use only AWS solutions. Furthermore, this EC2 machine had the IAM Role attached with permissions to access S3 Buckets. One day, a new CVE was registered for Apache Mod.d, allowing for SSRF (Server-Side Request Forgery) attack, and Capital One did not manage to update their WAF on time.  

An attacker used the vulnerability to access Metadata Server and obtain keys for the IAM Role. Doing that, the attacker obtained the permissions of the EC2 machine – which gave him access not to single bucket but to all 700 of them!  

Verdict: CSC fault.  

The Shared Responsibility Model says that CSC is responsible for updating software which they are hosting and for configurations of their services (like which ports are open to the Internet, which permissions are attached to which IAM Principal). Capital One is at fault, because of not updating their WAF and misconfiguring IAM Role attached to the EC2 machine – WAF should probably have access to only one bucket. 

Pegasus Airline data breach: 

In June 2022, Pegasus Airlines informed that 6.5TB of data with over 23 million documents containing sensitive data leaked from their AWS infrastructure. It turned out that Electronic Flight Bag (EFD) files were stored on an open S3 bucket available publicly without any protection. EFD is a data type that contains information about route, pre-flight checks results, navigation details, insurance documents, crew details (including PII) and much more on each single flight.   

Verdict: CSC fault.  

The Shared Responsibility Model clearly states that customer is responsible for granting accesses to objects stored on S3 buckets. In this case, Pegasus Airlines had granted public access to critical files by mistake, thus it was solely their fault that the breach occurred. By the way, the publicly exposed cloud buckets are frighteningly common. Here is a separate article with many more data breaches caused by public exposure: https://www.securing.pl/en/what-can-you-find-in-57k-aws-s3-buckets-2021-update/ 

ChaosDB Vulnerability: 

In August 2021, security researchers published a paper announcing new vulnerability called ChaosDB. This finding exploited a chain of vulnerabilities in the Jupyter Notebook feature in Cosmo DB service in Azure Cloud. As a result, any Azure user could get full Admin access (read, write, and delete) to another Azure customers Cosmos DB instance without any authorization. 

Verdict: CSP fault.  

Thankfully, this vulnerability was not exploited in the wild but reported to Microsoft under responsible disclosure protocol and was fixed immediately. However, in this particular case, even if a customer had properly configured an access to their database, the breach would have been caused by vulnerability in a service provided by a CSP. When a security incident is a result of a CVE in services provided by a cloud provider, it is their responsibility. 

Chinese Citizens Agency data breach:  

In July 2022, Binance CEO reported that over 1 billion of Chinese citizens’ personal data (including names, addresses national IDs, mobile numbers, and even medical records) were breached. Further investigation established that the reason for the incident was a blog post by one of the developers where they accidentally included an Access Key to Alibaba Cloud platform.  

Verdict: CSC fault.  

There is really nothing much to comment. Publicly exposing a cloud access token is not much different from giving a Ferrari key to a thief and kindly asking them to steal the car. It would be ridiculous to accuse Ferrari of insecure locks or lack of anti-theft systems.  

How to be responsible in the cloud? 

First and foremost, CSCs must precisely analyze and understand what their responsibilities regarding the cloud security are. The Shared Responsibility Model charts can be helpful but should not be taken too literally. Each cloud infrastructure is unique, and architects should thoroughly analyze specific needs and match them with already existing cloud capabilities and security mechanisms. Only then, a list of requirements and CSC responsibilities can be identified.   

Generic charts with shared responsibilities are not enough and this is why Cloud Security Alliance (CSA) introduced Consensus Assessment Initiative Questionnaire (CAIQ). 

This document is filled in by all major public cloud providers and precisely presents which responsibilities are covered by CSP, which should be shared between CSP and CSC, and which lay solely on CSC. CAIQ contains 261 questions divided into 17 categories, below, there are links to CAIQs provided by Azure, AWS and Google Cloud:  

• Azure CAIQ, 
• AWS CAIQ,
• Google Cloud CAIQ. 

When a list of security-related responsibilities is identified, CSC can proceed to enforcing them and properly configuring their cloud infrastructure. This is not an easy task due to ever-growing complexity of the cloud environments and ever-present pressure from the operations and business, which always prioritize ease of use and “just getting stuff done faster” than security. This is the reason why it is so important to execute the cloud security tests regularly. The cloud security configuration assessment will result in identifying security vulnerabilities and misconfigurations and let you verify if good security practices were applied.  

For more information – check out our offer: https://www.securing.pl/en/service/infrastructure-security-testing/cloud-infrastructure-testing/ 

Finally, keep in mind that things can just go wrong, and it is always a good practice to be prepared for the worst. In case of a new exploit in the cloud services or a human error resulting in services misconfigurations, there are a few golden rules that can either protect you from compromising the data or – in worst case scenario – reduce the damage. Those rules are: Least Privileges Principle, Defense-in-Depth, Data protection (both in transit and at rest) and, above-all use of common sense.  

Feel free to reach me out. You can find me on Twitter or LinkedIn.

Łukasz Bobrek Principal IT Security Consultant
Head of Cloud Security