What is the Shared Responsibility Model?

The global market for cloud computing is set to more than double by 2029. That’s not a surprise, considering that institutions like Gartner expects it to become a necessary business investment in the coming years and a basic requirement for organizations to compete. As companies embrace the cloud for innovation, they must be keenly aware of the Shared Responsibility Model and what it means for them. Understanding this framework can mean the difference between fully securing their cloud environment or experiencing significant consequences from a security breach. 

In this in-depth guide, we examine the Shared Responsibility Model in detail, defining what it means for your organization, why you should care about it, and how you can comply with it successfully. 

What is the Shared Responsibility Model?

Cloud service providers (CSPs) and their customers directly affect the security of public cloud environments. Failure by either party can put the cloud at risk, which is why both agree to the Shared Responsibility Model. This model defines the security obligations of each party in protecting the cloud. 

Generally, CSPs must protect cloud infrastructure, while organizations must secure their applications, endpoints, accounts and identities, and data. Yet the exact requirements depend on the CSP and type of cloud service delivery used. The specific requirements of the Shared Responsibility Model are contained in the service-level agreement (SLA) between the CSP and customer.

The Shared Responsibility Model helps protect the cloud from security risks. It also aims to help CSPs and their customers avoid the consequences that accompany a security incident, including negative financial, operational, regulatory, legal, and reputational outcomes.

How does cloud service delivery change shared responsibility?

Three different forms of cloud service delivery: IaaS, PaaS, and SaaS (serverless). The following sections describe each service type method in detail. 

Infrastructure-as-a-Service (IaaS)

In this delivery model, the CSP manages the IT infrastructure—including networking, storage, servers, and other components—and delivers it to the customer via an Internet connection. Meanwhile, customers maintain their operating systems, databases, applications, identities and accounts, endpoints, and data. Of the three service models, IaaS assigns customers the greatest responsibility over security. 

Examples of IaaS offerings include AWS, Google Compute Engine, and Microsoft Azure.

Platform-as-a-Service (PaaS)

In this delivery model, the CSP manages the IT infrastructure, as well as a platform and tools for application development, all of which customers can access via Internet connection. In this model, customers often need to secure their data, endpoints, applications, identities and accounts, as well as certain aspects of the application platform. 

Examples of PaaS offerings include AWS Elastic Beanstalk, Google App Engine, and Azure App Services.

Software-as-a-Service (SaaS) or serverless

In this delivery model, the CSP manages every service except for developing and deploying application code. The CSP handles resource allocation and server provisioning to automatically scale resources up or down based on workload demands. In this model, the customer remains responsible for securing their data, endpoints, identities, and accounts.

Examples of SaaS/serverless offerings include AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions.

How does shared responsibility vary by cloud service provider?

CSPs such as AWS, Azure, and Google Cloud all approach the Shared Responsibility Model similarly, yet with important distinctions. Below, we review how each CSP defines the Shared Responsibility Model. 

What is the AWS Shared Responsibility Model? 

AWS defines its Shared Responsibility Model as a combination of “Security of the Cloud,” and “Security in the Cloud.” AWS retains responsibility over the former, while customers own the latter. This means AWS oversees the cloud’s compute, storage, databases, and networking. 

Meanwhile, customers must protect their data, user accounts, endpoints, applications, operating system, network and firewall configurations, and more. Like the general definition of Shared Responsibility, the specific responsibilities between the two parties depends on the delivery type of cloud services.

What is the Azure Shared Responsibility Model?

Azure defines the Shared Responsibility Model by grouping responsibilities into three categories: those owned by the customer, by the CSP, and by both parties. Responsibilities assigned to this third category vary depending on the arrangement of IaaS, PaaS, or SaaS/serverless.

Regardless of how services are delivered, Azure must protect the underlying and physical infrastructure supporting the cloud, while customers need to secure accounts and identities, endpoints, and data. Other responsibilities—such as securing operating systems or applications—belong to either one or both parties. 

What is the GCP Shared Responsibility Model?

Google Cloud defines its approach to the Shared Responsibility Model as “shared fate,” offering additional support and resources to help organizations achieve better security outcomes. Compared to other providers, Google Cloud provides a more granular overview of what responsibilities between the CSP and their customers. Like the other providers, Google Cloud classifies the requirements by business relationship.

What is the Oracle Cloud Shared Responsibility Model?

Like AWS, Oracle Cloud defines the Shared Responsibility Model as a combination of “Security in the Cloud” and “Security of the Cloud.” Customers own the responsibility of securing their data, identify and access management, applications, network and firewall configurations, and more. Meanwhile, Oracle Cloud is responsible for compute, network, and storage isolation; data center physical security; securing the hardware, software, networking, and physical infrastructure that deliver services; and more. 

Specific responsibilities depend on the cloud delivery model.

What is the Alibaba Cloud Shared Responsibility Model?

Like Azure, Alibaba Cloud groups requirements of the Shared Responsibility Model into three categories: customer-owned, shared, and provider-owned. Generally, Alibaba Cloud holds customers accountable for securing their applications built on the cloud, including data, content, and aspects of IAM. Meanwhile, Alibaba Cloud takes ownership of securing the cloud and providing security capabilities and services to customers. 

Like other providers, the specific responsibilities depend on the service delivery model.

What are the benefits of the Shared Responsibility Model? 

The Shared Responsibility Model enables organizations to leverage the benefits that accompany the public cloud. Those benefits include the following. 

Cost savings

The Shared Responsibility Model drastically reduces the cost of security and infrastructure compared to maintaining a private cloud. For one, organizations avoid the cost of licensing hardware and software, while also eliminating the need to maintain and upgrade infrastructure. Cost is also directly tied to usage, allowing organizations to benefit from providers’ economies of scale. 

Enhanced security

With the Shared Responsibility Model, risk is spread between the CSP and the customer. The former is responsible for securing the hardware and software infrastructure, and the latter is responsible for securing their data and applications. This enables organizations to benefit from the CSP’s infrastructure security measures and services. 

Fast deployment 

The Shared Responsibility Model enables organizations to deploy their cloud environment easily and in a matter of minutes or hours. This stands in stark contrast to private cloud deployments, which can take weeks or months, require significant time and IT expertise, as well as demand complex configurations. 

Increased capacity

With the Shared Responsibility Model, your security team owns fewer aspects of security, which saves them time and capacity to invest elsewhere. These savings prove critical, especially considering that the average security team can only address 10 percent of the vulnerabilities they detect each month. These time savings don’t exist in a private cloud model, where teams must also protect infrastructure components. 

What are the challenges of the Shared Responsibility Model?

Despite its benefits, the Shared Responsibility Model presents several challenges, including the following.  

Understanding security obligations

Cloud environments are complex and constantly changing, making it difficult to gain a clear understanding of responsibilities. Identifying your security obligations before entering a formal agreement allows you to meet the conditions of the Shared Responsibility Model effectively. 

Getting and sustaining full visibility into your cloud environment

Securing the cloud proves challenging for every organization, as these environments are highly dynamic and distributed. The self-service nature of the cloud, in which users can easily spin up and turn down resources on-demand, makes it challenging to attain a complete inventory of the resources and risks in your environment. This prevents effective cloud security and leaves critical gaps in protection.

Analyzing risks holistically and prioritizing them effectively

Organizations often struggle to prioritize risks effectively and remediate their most critical alerts. Part of this comes from the lack of visibility referenced above, while it also comes from the inability to detect different types of cloud risks and analyze them in relation to other risks, resources, and the environment at large. 

If critical risks get overlooked, you stand a greater likelihood of experiencing a serious security breach. Orca’s Cloud Security Alert Fatigue Report found that most security teams report missing critical alerts on a daily or weekly basis.

Remediating risks easily and quickly

When it comes to cloud environments, security teams need to work with DevOps and development teams to remediate risks. This becomes challenging when they lack effective integrations that enhance collaboration, as well as capabilities that easily trace risks from production to development environments. 

The lack of deep integrations often forces developers to use unfamiliar tools or inefficient workflows. Silos between development and cloud environments often require security teams to spend significant time tracking down code owners, who can fix issues. Together, this can impact an organization’s ability to resolve critical risks promptly.

Managing security and compliance in multi-cloud scenarios

A significant number of organizations use multi-cloud environments that involve more than one CSP. This creates challenges in terms of complying with the Shared Responsibility Model. For one, it multiplies the security team’s obligations and workload. It also requires them to understand the tools, environments, technical languages, and responsibility requirements of each CSP. 

Additionally, many organizations rely on the native security features offered by their CSP. These features don’t integrate with other CSPs, which leads to inefficiencies, lost productivity, and critical blindspots for security teams. To overcome these disadvantages, organizations must rely on solutions provided by third-party vendors. 

What are best practices for complying with the Shared Responsibility Model? 

Review and understand the SLA

The SLA fully defines and details the Shared Responsibility Model between your organization and CSP. Because the terms may vary depending on the cloud provider and the service model, you should review it carefully. Understanding this document represents the first step to adhering to the Shared Responsibility Model. Failing to do so puts your organization at high-risk of non-compliance. 

Ensure full coverage of your cloud environment

You can only protect what you can see, and cloud environments make it challenging due to their dynamic and distributed nature. 

That explains the importance of gaining full coverage of your cloud estate, which means you can inventory all cloud resources and risks. It creates the conditions for foundational capabilities in security, including the ability to detect your most critical risks and prioritize their remediation.

Substitute static risk analysis for dynamic, holistic assessment

Static analysis evaluates risks in silos, rather than considering their broader relationship to other risks and resources. In cloud environments, where risks and resources co-exist in a connected ecosystem, static analysis translates to incomplete analysis. That’s because it fails to account for environmental factors that materially affect the severity of a particular risk. 

For example, Vulnerability A, in isolation, constitutes a medium severity risk. Static analysis would treat it as such, even if it enabled attackers to laterally move to a storage bucket containing exposed sensitive data. It may also prioritize the remediation of Vulnerability B ahead of A, with Vulnerability B a high severity risk but one that provides no lateral movement risk or access to exposed assets. 

On the other hand, holistic risk analysis would consider the full environmental context and prioritize Vulnerability A, while reducing the severity of Vulnerability B.

Emphasize risk prioritization

For most organizations, security teams face a shortage of time, capacity, and personnel. Cloud environments are littered with risks, and far more than teams can realistically handle. As referenced previously, security teams can address 10% of the vulnerabilities detected each month. This illustrates the importance of prioritizing the most critical risks to prevent a serious security incident. 

Prioritization not only requires holistic analysis, as mentioned earlier, but also comprehensive assessment across a number of material factors. For vulnerabilities in particular, risk analysis should focus on severity, exploitability, likelihood of being exploited, exposure to the Internet, connection to sensitive data, and more. 

Embrace DevSecOps

DevSecOps is an operational framework that incorporates security into every phase of the application lifecycle, helping organizations develop applications that are secure by design. In terms of the Shared Responsibility Model, DevSecOps minimizes the number of security vulnerabilities and misconfigurations released to a production environment. 

For your organization, it’s important to embrace DevSecOps and utilize cloud security tools that support the framework. Key features of effective DevSecOps solutions include deep, developer-friendly integrations that enable developers to address security issues in their development environments, using their tools and workflows. 

Another feature includes the enabling and automatic enforcement of security policies that establish guardrails for developers and block risky builds from getting released. Also important is cloud-to-dev functionality, which links risks in running cloud resources to their code origins, enabling security teams to quickly discover the source of a risk and the code owner who can quickly resolve it. 

How CNAPP supports shared responsibility

To meet the Shared Responsibility Model, many organizations are relying on Cloud Native Application Protection Platforms (CNAPPs). CNAPPs consolidate a full range of cloud security capabilities into one unified solution, enabling organizations to gain the complete coverage and comprehensive risk detection needed to prioritize critical risks. According to Gartner, 60% of organizations will need to adopt a CNAPP by 2029 to achieve their zero-trust goals. 

Still, CNAPP is a product category, not a measure of efficacy for each solution under its umbrella. An effective CNAPP solution should possess the following features at a minimum, which help support the Shared Responsibility Model:

• Full multi-cloud coverage: Visibility into multiple cloud environments that may involve more than one cloud provider. 
• Comprehensive risk detection: Ability to detect all types of cloud risks, including vulnerabilities, misconfigurations, malware, lateral movement, API risks, AI risks, sensitive data exposure, IAM risks, and more. 
• Holistic risk analysis and effective prioritization: Ability to analyze risk within the context of the cloud environment and use it to prioritize alerts based on potential business impact. 
• Developer-friendly features: Deep integrations that incorporate security into developer workflows and tooling, as well as guardrail policies and risk scanning that catch issues early in the software development lifecycle (SDLC).

About the Orca Cloud Security Platform: a true CNAPP

The Orca Cloud Security Platform is an agentless-first solution designed to secure multi-cloud environments across the application lifecycle. A true CNAPP developed natively, the Orca Platform enables organizations to fully support the Shared Responsibility Model, combining complete coverage, comprehensive detection, effective risk prioritization, and fast remediation in one solution. 

The Orca Platform also supports end-to-end cloud compliance, offering continuous monitoring, tracking, alerting, remediation, and reporting capabilities across more than 160 out-of-the-box frameworks. 

To see how the Orca Cloud Security Platform can optimize your cloud security, book a personalized demo with one of our experts. 

Conclusion 

As organizations increasingly rely on cloud computing, understanding the Shared Responsibility Model is both necessary and challenging. Complicating this task, the model varies depending on the CSP and type of cloud service delivery involved. Cloud environments also rapidly and constantly change, as developers can easily deploy new resources that create risks. 

While organizations must understand and comply with the Shared Responsibility Model, technology can help ease the burden. Solutions such as CNAPPs provide organizations the capabilities they need to effectively secure their environments and fulfill their responsibilities easily and efficiently. 

FAQ

What are customer security responsibilities under the Shared Responsibility Model?

Under the Shared Responsibility Model, customers of cloud service providers (CSPs) are generally responsible for securing their applications, endpoints, accounts and identities, and data. Meanwhile, CSPs are responsible for securing IT and cloud infrastructure. 

However, specific responsibilities vary by CSP and the agreed-upon business relationship. Infrastructure-as-a-Service (IaaS), for example, assigns more responsibility and control to the customer in regard to cloud security. Software-as-a-Service (SaaS), on the other hand, limits customer responsibility the most, shifting more of the burden on CSPs. 

The service-level agreement (SLA) outlines the specific responsibilities owned by both parties.

What is the Shared Responsibility Model in cloud computing?

The Shared Responsibility Model is an agreement between a CSP and their customer that splits the responsibility of securing a public cloud environment. The Model recognizes that both parties control the security of the cloud and any negligence can put it at risk. The model aims to clearly define the specific security requirements of each party, enhancing collaboration and compliance. The Shared Responsibility Model includes three types of cloud service relationships that determine responsibilities. They include: 

• Infrastructure-as-a-Service (IaaS): CSPs manage IT infrastructure, while organizations secure their operating systems, databases, applications, identities and accounts, endpoints, and data. 
• Platform-as-a-Service (PaaS): CSPs manage IT infrastructure, and a platform and tools for application development. Customers manage certain parts of the application platform as well as their identities and accounts, applications, endpoints, and data. 
• Software-as-a-Service (SaaS)/serverless: CSPs manage all services excluding the development and deployment of application code. Customers secure their data, endpoints, identities, and accounts.

How does the Shared Responsibility Model work?

The Shared Responsibility Model defines what aspects of cloud security CSPs and their customers individually own. This enables both parties to clearly understand their responsibilities, with the aim of enhancing collaboration to limit security risks and maximize protections. The specific obligations of the Shared Responsibility Model are contained in the service-level agreement (SLA) between the two parties. CSPs and their customers both agree to these requirements before formalizing an agreement.