Wiz Defend is Here: Threat detection and response for cloud
Eliminate Critical Risks in the Cloud

Uncover and remediate the critical severity issues in your cloud environments without drowning your team in alerts.

Understanding the Shared Responsibility Model

The shared responsibility model is a framework establishing cloud security responsibilities between cloud service providers (AWS, GCP, Azure) and customers.

Wiz Experts Team
5 minutes read

What is the shared responsibility model?

The shared responsibility model is a framework establishing who is responsible for securing different aspects of the cloud-computing environment between the cloud service provider (CSP) and the customer. The CSP is generally tasked with the security of the underlying infrastructure, while it is on the customer to secure its cloud-hosted data and applications.

CSPs are responsible for securing data centers and all networking equipment. They also handle tasks such as patching and updating operating systems as well as ensuring the availability and reliability of the cloud services. This is known as the "security of the cloud" responsibility.

Customers’ security responsibilities include setting up secure access controls, encrypting data in transit and at rest, managing user accounts and credentials, and implementing application-specific security measures. This is called the "security in the cloud" responsibility.

For instance, as a CSP, Amazon S3 ensures the physical security of their data center and protects against infrastructure-level threats. However, it’s the S3 users’ responsibility to properly configure access control and permissions for their S3 buckets, implement encryption for sensitive data, and regularly monitor and manage access to stored data. 

These responsibilities are not widely understood. Although 98% of businesses report a cloud-data breach within the past eighteen months, only 13% understand their cloud-security responsibilities. Many organizations erroneously rely on their CSPs for data protection and application security. Closing this knowledge gap is an essential step toward fulfilling cloud security obligations. 

How shared responsibility varies by service type

The level of a CSP customer’s shared responsibility depends on service type: software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS).

In the SaaS model, CSPs bear most security responsibilities. They secure the software application, including infrastructure and networks, and they are responsible for application-level security. Customers’ responsibilities often include managing user access and ensuring data is protected and accounts are secure. In short, customers rely heavily on their cloud service provider for security, uptime, and system performance.

In the PaaS model, CSPs manage infrastructure and underlying platform components, such as runtime, libraries, and operating systems. Customers are responsible for developing, maintaining, and managing data and user access within their applications.

Of the three models, IaaS customers have the highest level of responsibility. The CSP secures the foundational infrastructure, including virtual machines, storage, and networks—while customers secure everything built on the infrastructure, such as the operating system, runtime, applications, and data. 

Source: Center for Internet Security

While the responsibilities mentioned above provide a general overview, the exact division of responsibilities varies across CSPs. It’s best practice to refer to specific service-level agreements and documentation provided by CSPs for more information about responsibility distribution..

Customers’ cloud-security responsibilities

Customers, rather than CSPs, often bear responsibility for most cloud-security incidents.

By 2025, 99% of cloud-security failures are forecast to come from customers.

Gartner

To ensure success in the shared responsibility model, let’s take a look at customer responsibilities. 

Customer ResponsibilityDescription
Data protectionEnsuring data confidentiality, integrity, and availability is the customer’s purview. Best practices involve implementing proper access controls, encryption, and backups.
User access managementImplement appropriate permissions, enforce strong passwords, and adopt multi-factor authentication to keep user access secure.
Application securityCustomers are accountable for securing cloud-hosted applications. Follow secure coding practices, conduct regular vulnerability assessments, and implement appropriate security controls to reduce application-level security threats.
Network controlsFirewalls, virtual private networks (VPNs), security groups, and other network-control configurations are essential customer responsibilities that protect cloud resources from unauthorized access.
Compliance and governanceMeeting regulatory requirements and implementing appropriate governance controls are also customer responsibilities. Each industry has unique regulations and frameworks.

CSPs’ typical cloud-security responsibilities

CSPs’ share of responsibilities usually includes the security of the infrastructure and attendant dependencies. Some of their security responsibilities include the following.

CSP ResponsibilityDescription
Physical securityAs previously mentioned, CSPs are responsible for securing physical access to their data centers, using tools like surveillance systems, restricted-access areas, and environmental controls.
Network-infrastructure securityEach provider is responsible for securing cloud-network infrastructure, including routers, switches, and load balancers by implementing appropriate controls, such as intrusion detection and prevention systems.
Host-infrastructure securityCSPs secure underlying host infrastructures, including servers, virtualization layers, and storage systems. They implement proper configuration, patching, and security controls on these resources; update operating systems; and ensure overall availability and reliability of cloud services.
Compliance certificationsCSPs often undergo independent audits and attain certifications to demonstrate compliance with industry standards and regulations. These measures provide customers with assurances regarding their security practices.

Overlapping responsibilities

Some responsibilities are shared by both parties based on service type (SaaS, PaaS, or IaaS). For instance, within the Microsoft shared responsibility model, CSPs and SaaS and PaaS customers share responsibility for securing identity and directory infrastructure. Alternatively, application security and network controls are shared under the PaaS model. CSPs clearly define the boundaries of responsibilities through service level agreements (SLAs). Overlaps usually exist in the following areas: 

Operating systems

Whether a user brings their own operating system (OS) or deploys an OS provided by the cloud provider, the responsibility of choosing the appropriate OS to meet an organization’s security requirements lies with the user. If the user chooses the CSP’s operating system, then they are responsible for its security. However, if a customer brings their own OS, their organization is responsible for its security.

Native vs. third-party tools

Providers are responsible for deploying, managing, maintaining, and updating services. Though when deploying a third-party tool or application as a workload, the customer is charged with securing the application and its data, while the CSP's responsibility is limited to the infrastructure and virtualization layer.

Server-based vs. serverless computing

In server-based computing, the user is responsible for choosing the operating system, deploying the workload, and configuring the necessary security settings. On the other hand, in serverless or event-based computing, the user is accountable for the deployed code and user-defined security or configuration options provided by the cloud vendor.

Network controls

Whether deploying their own firewall or using the provider’s, customers are responsible for configuring firewall rules and ensuring proper security-standard configuration. 

Examples of the shared responsibility model

Major CSPs like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure have established their own shared responsibility models, which outline provider-customer security responsibilities. 

The AWS shared responsibility model

The AWS shared responsibility model outlines that AWS is “responsible for protecting the infrastructure that runs all of the services in the AWS Cloud.” They take responsibility for both hardware and software, including physical data centers, networks, edge locations, and virtualization layers. 

AWS Shared Responsibility Model

AWS also secures their managed services, such as AWS DynamoDB, RDS, Redshift, Elastic, and EMR. However, customers are responsible for securing their own applications and data, and managing access controls and configurations within their AWS accounts.

The GCP shared responsibility model

Google Cloud Platform (GCP) follows a shared responsibility and shared fate model. GCP introduced 'share fate' to address the challenges where they believe the shared responsibility model fall short.

GCP Shared Responsibility Model
GCP Shared Responsibility Model

GCP secures underlying cloud infrastructures and provides add-on options that customers can leverage to discharge responsibility for securing applications and data, managing user access and permissions, configuring security settings, and implementing appropriate security measures within their projects.

Azure’s shared responsibility model

Microsoft Azure leverages a shared responsibility model that is similar to GCP’s model. 

Microsoft's Shared Responsibility Model
Microsoft's Shared Responsibility Model

Although Azure secures managed services, customers own and secure the whole stack if operating an on-premises data center.

Challenges of the shared responsibility model

Despite its several benefits, the shared responsibility model also presents the following challenges: 

ChallengeDescription
Access controlOrganizations must always protect customer data. However, the shared responsibility model requires that CSPs have unguarded access to sensitive infrastructure to evaluate security posture, contradicting an organization’s exclusive access to customer data. This has pushed many organizations into implementing role-based access control (RBAC) to ensure that authorized individuals have access to perform only pre-specified duties.
VaguenessThere are important areas of cloud security where the model does not clearly spell out the security responsibilities of each party. For instance, cloud middleware—which sits between organizations and CSPs for cloud security posture management—requires regular updates as new vulnerabilities continue to surface and attack surfaces expand. However, many organizations are barely aware of the required frequency of updates, and this exposes them to preventable attacks. Automating the software patching process is a viable solution to combat this issue.
Incident managementWhen cyberattacks occur, identifying which party is responsible for investigation and remediation is critical. Unfortunately, the shared responsibility model does not clearly spell out the delegation of responsibility. Additionally, cyberattacks can be targeted at anyone at either party (customer or CSP), so managing the attack is often slowed down by pinpointing the source and establishing who is responsible for remediation.
ComplexityOrganizations offering multiple services often require multiple CSPs and unifying them into a single system may be cumbersome. Moreover, the multi-tiered nature of cloud deployments often necessitates the intervention of multiple departments, adding complexity to the question of who is responsible for what. Even when CSP versus customer responsibilities are clearly spelled out, identifying departments that are responsible for securing specific aspects of the cloud may be difficult.

A new vision for the shared response to cloud vulnerabilities

In an earlier blog, Wiz CTO Yinon Costica highlights the need for a new shared response model for handling cloud vulnerabilities. Yinon uses ChaosDB as an example of why the current model lacks transparency and clarity in handling vulnerabilities, which leads to confusion and ineffective remediation efforts.

There’s a new middle zone in the cloud shared responsibility model, and vulnerabilities in this gray area have no clear standardized process to handle them

Yinon proposes a new starting point for how CSPs and customers should work together to address new cloud vulnerabilities:

Areas of ResponsibilityCSPsCustomers
Software vulnerabilities
  • Cloud vulnerability database
  • Vulnerability management
Cloud features and security configuration
  • Enumerated cloud security benchmark
  • Threat model change log
  • Correct cloud configuration

Check out Yinon's blog for a detailed explanation of each of the responsibilities above, and why he thinks this new model will allow CSPs and customer respond more efficiently the new cloud vulnerabilities:

Simplify shared responsibility with Wiz

Although cloud service providers and their customers each have specific cloud-security responsibilities, it can be difficult to navigate the boundaries and determine who is responsible for what. Major CSPs advise that customers learn more about these responsibilities and take proactive steps towards cloud security

Wiz seamlessly integrates with your CSP and provides complete visibility into the security state of your cloud environment. Schedule a demo today.

See Wiz In Action

Learn why CISOs at the fastest growing enterprises secure their cloud with Wiz.

Get a demo 

Continue reading

The EU Artificial Intelligence Act: A tl;dr

Wiz Experts Team

In this post, we’ll bring you up to speed on why the EU put this law in place, what it involves, and what you need to know as an AI developer or vendor, including best practices to simplify compliance.

What is Application Security (AppSec)?

Application security refers to the practice of identifying, mitigating, and protecting applications from vulnerabilities and threats throughout their lifecycle, including design, development, deployment, and maintenance.