Shared Responsibility Model: Addressing Key Challenges to Cloud Security

Cloud adoption exposes businesses to multiple data security challenges. Learn how the shared responsibility model can help protect your assets Updated on August 20, 2024 Enterprises actively adopt new digital technologies to rethink their operations following modern-time demands. The top three cloud giants—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—continued to compete for dominance in global cloud market share during the first quarter of 2024, as the cloud market reached a new high of $76 billion. The growing cloud market share demonstrates that cloud services are effective and satisfy ongoing business demands for easily deployable and rapidly scalable computing and network resources. However, cloud adoption also raises a set of cloud security challenges and requires reconsidering traditional approaches to handling data and securing environments. Moving to the cloud, organizations often “lift and shift” their on-premise workloads and infrastructures with a little refactoring. However, it is impossible to migrate to the cloud by using only the legacy security philosophy and tools. The cloud environment requires rethinking all security processes and generating new approaches to security. Misunderstanding of who is responsible for securing data in the cloud – cloud providers themselves or their customers - is very common. To ensure the security of cloud-based data, one must understand and follow a shared responsibility model. In short, this model means that the cloud provider — AWS, Microsoft Azure, GCP, etc. — is responsible for the cloud’s physical and network infrastructure (security of the cloud). Their customers — your organization — are responsible for the security of your data, applications, and other assets that belong to your organization (security in the cloud). Let’s explore the cloud shared responsibility model in more detail to understand who is responsible for what in the cloud.

Common Misconceptions Regarding Cloud Security

All cloud providers offer the same level of security

Not all cloud providers are created equally when it comes to security. Each provider offers different security features, settings, and controls. For example, GCP encrypts data storage by default, while AWS requires customers to explicitly configure the encryption. Another example is Identity and Access Management (IAM). AWS holds a robust IAM system, allowing granular control over user permissions and roles, with support for IAM and integration with SAML for single sign-on (SSO). GCP, in contrast, provides IAM with a focus on simplicity, offering basic roles, predefined roles, and custom roles, but it does not offer as many granular controls as AWS. In addition, different cloud providers may have different security and compliance certifications. Most modern cloud service providers hold a vast array of compliance certifications, including ISO 27001, SOC 1/2, and HIPAA, making it a preferred choice for industries with strict compliance requirements. However, it is still necessary to review the certification to make sure your cloud service providers are certified, as some of them can lack industry-specific certifications.

“Set It and forget it”

Businesses that adopt cloud services should have sufficient expertise not only for their initial cloud setup but also for the ongoing management process. Unfortunately, it rarely occurs in practice. Many organizations believe that once service settings are configured, the ongoing maintenance will require less attention. This assumption is one of the most common reasons why companies have difficulties with ensuring security for their cloud-based data. As part of the initial cloud service adoption, organizations must define key configurations and maintenance processes for the service. This would help avoid cloud misconfiguration that could lead to non-compliance, unsanctioned data access, and exfiltration. Among other things, organizations should define specific security requirements, such as complexity and rotation of credentials, privilege settings for users and administrators, users’ access to applications, administrators’ hierarchy, etc. Although organizations should regularly check for the state of these configurations, they often drift away from them to focus on supporting the overall business. Some enterprises defer configuration checks to audits.

Cloud security is only the provider’s responsibility

A key misconception regarding the cloud shared responsibility model is the belief that the cloud provider is fully responsible for all aspects of security. Many organizations assume that once they move their data and applications to the cloud, the cloud provider will handle everything related to security, including data protection, access management, and compliance. In reality, the cloud shared responsibility model divides security duties between the cloud provider and the customer. While the provider secures the cloud infrastructure, including the physical data centers, networks, and hardware, the customer is responsible for securing their own data, applications, user access, and configurations within the cloud. Neglecting the customer’s role in this model can lead to vulnerabilities, such as misconfigurations, weak access controls, and unpatched software, making the organization susceptible to cyber threats.

Explaining a Cloud Shared Responsibility Model

The above challenges and misconceptions support the idea that security is one of the greatest concerns of the cloud environment. So both, cloud providers and their customers should properly bear their part of the burden and ensure security in clouds. A shared responsibility model was articulated to define the borders of responsibility for securing data in clouds. The shared responsibility model outlines the provider’s responsibility for maintaining a secure and continuously available service and the organization’s duty to ensure secure use of the service. There are two main approaches for defining the shared responsibility model in the cloud security context:

• security OF the cloud vs. security IN the cloud
• boundaries of responsibility

These approaches demonstrate the best practices of top cloud service providers, such as AWS, Microsoft Azure, GCP, and IBM Cloud. Let’s examine these approaches in more detail.

Security OF the Cloud vs. Security IN the Cloud

The first approach conveys how the cloud provider is responsible for managing the security of the cloud while the customer is responsible for securing what is in the cloud. Such differentiation of the shared responsibility model pertains to AWS and includes the following:

• To maintain the Security of the Cloud, cloud providers are responsible for protecting the infrastructure that runs services offered in the cloud. This infrastructure involves software, hardware, networking, and facilities.

Security in the cloud is the organization’s responsibility, and it is determined by the services that the organization selects. This, in turn, defines the amount of configuration work that must be performed. Configuration usually involves security controls for the guest operating system (including updates and security patches), application software or utilities installed by the customer, as well as network security management tools provided by the cloud vendor.

Figure 1. (Source: AWS Shared Responsibility Model)

The responsibility models typically provide a list of control types based on how the responsibility for the control is assigned.

• Inherited controls – physical and environmental controls that the organization inherits from its cloud provider.
• Shared controls – the cloud provider and the customer are responsible for certain aspects of the control. Examples of shared controls may include configuration management, patch management, training & awareness.
• Customer-specific controls – controls in which customers have full implementation and management responsibility. For instance, organizations are responsible for managing access and protecting external communications.

Boundaries of Responsibility: SaaS, IaaS, and PaaS

The second common approach to the shared responsibility model is based on the boundaries of responsibility. Namely, responsibility shifts depending on the level of the cloud deployment between the platform as a service (PaaS), infrastructure as a service (IaaS), and software as a service (SaaS). This approach is commonly used by Microsoft Azure, Google Cloud, and IBM Cloud:

• In an IaaS, the provider is responsible for physical layers and shares responsibility with the customer for the security of the host infrastructure and network. The customer is responsible for all the rest.
• In a PaaS, the provider also takes full responsibility for host infrastructure and network security, but it also shares responsibility with the customer at the application and access control levels.

In a SaaS, the provider takes full responsibility for application controls while sharing responsibility with the customer for access control as well as client/endpoint protection. Figure 2 visually demonstrates how boundaries of responsibility are shared:

Figure 2. (Source: Shared Responsibility for Cloud Computing, Microsoft Azure)

Limitations of the Cloud Shared Responsibility Model

While the cloud shared responsibility model brings clarity into the critical security responsibilities within the cloud environments, there are some critical areas where the shared responsibility model falls short, placing more burdens on cloud customers to try to fill the gaps is simply not going to fix the problem. Some specific ways that the shared responsibility model can break down include:

Lack of technical expertise on the customer side

First, there is often a lack of technical expertise on the customer side. When a model shifts critical responsibilities onto customers who may not have the capacity to manage them, it can be problematic. Overworked IT departments and a shortage of cloud security skills could leave some customers unable to fulfill their security obligations without considerable help. This scenario risks leading to costly cybersecurity breaches and could damage the trust between the customer and the cloud service provider.

There are always more than two parties involved

Second, there are always more than two parties involved in the shared responsibility model. A cloud environment encompasses more than just the customer and the cloud service provider. When third-party service providers are involved, the lines of responsibility can become significantly more complex. The traditional shared responsibility model falls short when it comes to providing clear guidelines for the complex cloud configurations that many organizations deal with.

Misconfiguration issues

A common mistake in the shared responsibility model is using default settings and configurations for cloud services or applications without changing or reviewing them. Default settings and configurations can be problematic for several reasons. They can enable unwanted features that consume resources or disable important services that provide security. They can also leave some options open or unclear, resulting in confusion or inconsistency. For example, some customers may not enable multi-factor authentication (MFA) for their accounts or resources in the cloud, making them more susceptible to unauthorized access. An extortion campaign against Ticketmaster, when threat actors leaked over 35,000 print-at-home tickets for upcoming concerts and events, demonstrates the issue of the traditional shared responsibility model. The fact that the company failed to configure MFA played into criminals’ hands, allowing threat actors to access accounts using stolen credentials. Given the above limitation, along with a constantly evolving cybersecurity landscape, major cloud service providers are looking for ways to update the traditional cloud security paradigm, one that offers more actual solutions and encourages more collaboration.

Understanding a Shared Fate Model

The next stage of the evolution beyond traditional shared responsibility for cloud security is Google's shared fate, a collaborative model for handling cloud risks. Under the shared fate model, the CSP takes a much more proactive role, including providing guidance at the deployment stage as well as recommendations and tools to ensure ongoing security. Shared fate sees the cloud provider accepting the reality of where shared responsibility breaks down and steps up to close the gaps. Secure-by-default infrastructure, security foundations, and secure blueprints are elements of the shared fate model that take some of the security burdens off of customers' teams. In complex cloud environments involving multiple stakeholders, the model provides guides for how workflows and responsibilities should be arranged rather than leaving it up to the customer to figure out alone. Shared fate places a greater emphasis on cyber insurance, a crucial aspect of responsible security that is there to help a cloud customer in the case of a cyber incident.

How Planet 9 Can Help Security in Your Cloud

Understanding the key points of the shared responsibility model is essential while moving to the cloud. Cloud providers offer substantial advantages for ensuring security and compliance, but these advantages do not absolve organizations from protecting their applications and services. Planet 9 has experience in ensuring the security of cloud services, be it IaaS, PaaS, or SaaS. Our cloud security experts will assess your cloud management accounts and infrastructure and provide recommendations for addressing identified security and compliance gaps. Depending on the client’s internal resources, expertise, and availability, Planet 9 can perform all the remediation work, position the client to execute remediation on its own or supplement the client’s team.