Shared Responsibility Model: What It Means for Cloud Security

Every industry has begun migrating most of its digital assets to the cloud as organizations worldwide embrace cloud adoption. As a result, tech stacks and data volume are growing at an unprecedented rate, making cloud security more important than ever. Despite such wide popularity and rapid adoption, the public cloud can lead to security risks for its users, which largely stem from the misunderstanding of one key concept: the shared responsibility model (SRM).

Many organizations often wrongly assume that data protection of cloud-resident data is the responsibility of the service providers and not theirs. This is a costly mistake, resulting in the majority of cloud data breaches/leaks. Gartner predicted that by 2025, 99% of cloud security failures would be the customer’s fault due to challenges around measuring and managing cloud security risks. That’s why it’s imperative for organizations to have a clear understanding of the shared responsibility model.

In this blog, we will explore the division of responsibility under the SRM, its benefits, limitations and best practices while discovering what Spanning can do to secure your cloud-resident data.

What is the shared responsibility model?

The shared responsibility model is a cloud security framework that clearly outlines the responsibilities of cloud service providers (CSPs) and the users with respect to the security of the cloud environment. The CSP and the cloud user are accountable for different security aspects and must work in partnership to ensure foolproof data security.

As per the model, the security “of” the cloud — physical facilities, utilities, cables and hardware — is the CSP’s responsibility, whereas the organization (user) is responsible for the security of its data as well as users, accounts and access management.

What is the purpose of the shared responsibility model?

The shared responsibility model provides a clear distinction of the security responsibilities between the organizations and the service providers. This division of responsibility allows the CSPs to handle more operational activities and helps the organizations to focus on their core competencies. Technical security practitioners get to understand what configurations, settings and controls are under the scope of the organization’s influence, which can ultimately lead to a more robust security posture.

Why is the shared responsibility model important?

It’s pretty clear that without the familiarity of the cloud environment security, cloud security architects of your organization will not be able to spot risky configurations. This could eventually expose your organization to tremendous risk. A thorough understanding of the model helps to understand who the onus is on for certain aspects of cloud security, making it feasible to be well prepared to tackle serious security risks.

However, due to misconceptions about responsibility distribution, most organizations depend on service providers for data protection. A recent ESG report revealed 33% of companies depend solely on the service provider to protect their SaaS-resident application data.

How does the shared responsibility model work?

The shared responsibility model works only if service level agreements (SLAs), roles and responsibilities are distinctly understood by each party. The exact dissection of the cloud security responsibilities depends on the type of cloud service model used (IaaS, PaaS and SaaS) and the division of responsibility (user, service provider and shared).

Types of shared responsibility model

Whether you use IaaS, PaaS or SaaS — the shared responsibility model is part of the mix. However, the ownership of security tasks and functions depends on the delivery model used. It is usually observed that the users’ responsibilities generally increase as we move from SaaS to PaaS to IaaS.

Infrastructure-as-a-Service (IaaS)

Under this model, the service provider is responsible for the virtualization layer, disks and networks. The provider is also responsible for physical data centers. IaaS users are responsible for the security of the operating system (OS) and software stack used to run their applications and data. They also need to take care of the security of middleware, containers, workloads and code.

Platform-as-a-Service (PaaS)

This platform delivery model can be used to develop, manage and run applications. Here, the service providers take more responsibility for patching and maintaining OSs. Although the provider ensures that user subscriptions and login credentials are secure, the user will still be responsible for the security of any code or data the platform produces.

Software-as-a-Service (SaaS)

In SaaS, the provider controls all the aspects of application security, whereas the user is tasked with security responsibilities, like protecting login credentials from phishing or social engineering attacks.

It must be noted that the users and the CSPs don’t share responsibility for the same asset. Either the CSP or the user has full responsibility for the security of all assets under their direct control, irrespective of the service model type.

Division of responsibility

In the case of an on-premises data center, the entire IT infrastructure is managed by the user. As we move toward the cloud, some responsibilities get transferred to the service providers. But not all of them.

Users always retain specific responsibilities, regardless of the deployment type. These are:

• Data
• Endpoints
• Accounts
• Access management

Customer responsibility

The customers (users) get to manage and run an application and its data. So, cloud configurations and settings are always under the direct control of the customers.

• Data and information — Customers must ensure any data created on or uploaded to the cloud is adequately secured. They can create authorization to access and encrypt the data to prevent unauthorized access. The control over information and data allows customers to maintain how and when the data gets used. The service provider has zero data visibility, which the customer completely controls.
• Identity and access management — This framework allows the IT team to control access to systems, networks and assets based on the user’s identity. It is essential to restrict access to cloud infrastructures only to authorized users. Basically, all facets of identity and access management, including authentication and authorization mechanisms, access keys, certificates, user creation process and password management, are the user’s responsibility. The users also control other aspects of credentials, such as login mechanisms, single sign-on (SSO) and any multifactor authentication items.

Provider responsibility

Cloud providers are always responsible for the vast and complex infrastructure public clouds have. Responsibilities revolve around components like:

• Physical layer — The service provider manages and protects basic elements of physical infrastructure, like server, storage, network gears and other hardware. Resilient architectures like redundancy and failover, redundant power and network carrier connectivity also fall under the responsibility of the providers. Hyperscale cloud providers like AWS and Azure safeguard their servers from physical intrusion and tampering with native backup, restoration and disaster recovery implementations. Also, a range of pre-built services like databases, caches, firewalls and big data processing are offered by the providers, mainly used and provisioned by users but managed by the former.
• Virtualization layer — In the public cloud environment, users can provision and use as many resources and services as they want. This demands a high level of virtualization, automation and orchestration within the provider’s infrastructure. The provider needs to implement and maintain this virtualization layer and its various APIs responsible for user access and interaction with the infrastructure.

Shared or divided responsibility

Certain security responsibilities are interchangeable and hard to categorize between the user and provider. For such facets, proper attention must be paid to the provider SLAs, and users must precisely understand the lines of responsibility.

• Operating systems — The user generally gets to decide which OS to use, regardless of whether it’s their OS or supplied by the provider. As a result, a lot of security issues creep in. The user needs to maintain proper configurations and settings of the OS, along with regular checking for patch levels. In the case of the serverless (event-based) computing option, the user gets to manage the code uploaded to the service and any configuration options.
• Network controls — Much like the OS, the user is responsible for laying down the rules to control network services like the firewall — whether they deploy it themselves or use a provider’s service. They can also ensure the firewall is properly configured to protect any associated applications or other network elements. A provider can only maintain the network that’s directly under their control.

Examples of the shared responsibility model

Although there’s a clear outlining of the responsibility between the provider and the user, the actual line isn’t always clear and varies depending on the nature of the cloud model and provider discussed below. These three cloud providers are the most common ones and are synonymous with the shared responsibility model.

Amazon Web Services (AWS)

AWS is a major IaaS provider and has security and compliance as a shared responsibility between the customers and itself. This relieves the customer’s operational burden as AWS takes care of the components from the host OS and virtualization layer down to the physical security of the operational facilities. Customers are responsible for managing the guest OS (including updates and patches), other apps and configuration of the firewall provided by AWS. Customer’s responsibilities can vary depending on the services used, integrations of services to the IT environment, and applicable laws and regulations.

Figure 1 depicts the differentiation of responsibility in the AWS ecosystem, commonly referred to as Security “of” the Cloud vs. Security “in” the Cloud.

Microsoft Azure

For Microsoft Azure, users own their data and identities. In addition to protecting data and identities, the users are also liable for the safety of on-premises resources and any cloud components controlled by them.

Figure 2 illustrates the areas of responsibility between the customer and Microsoft based on the deployment type.

Google Cloud Partners (GCP)

Google Cloud generally divides responsibility categories into multiple sections. These include content, access policies, usage, deployment, identity, operations, authentication, network security, storage and encryption. In this ecosystem (see Figure 3), the cloud provider is always responsible for the network and infrastructure, and the customers control the access policies and data.

What are the benefits of shared responsibility?

The shared responsibility model can be confusing since it’s a new concept that recently gained popularity. However, its benefits are clearly evident.

Improved security

Service providers are religiously focused on cloud security and leverage significant resources to ensure their customers get complete protection. Under the shared responsibility framework, CSPs need to conduct robust monitoring and testing, along with timely security updates and patching. All these enhance the overall level of protection, reducing the mistakes that could lead to data breaches.

Enhanced focus

In the traditional on-prem model, the user managed the security of hardware, infrastructure and the virtualization layer. This responsibility gets shifted to the CSPs once we move to the shared responsibility model. The move takes a chunk off the users’ workload, allowing them to refocus their efforts on other tasks and needs.

Reduced costs

Leveraging a provider’s security and infrastructure means lesser management from the user’s end. This saves users a considerable amount of money in leveraging impactful resources in cloud security and stretches their budget.

Expertise

The resources and expertise the CSPs provide in cloud security are substantial and effective. This can benefit small and midsize businesses (SMBs) that lack in-house security expertise.

What are the challenges with shared responsibility?

Cloud users must also consider the potential risks or disadvantages associated with the shared responsibility model.

Trust

For the framework to function successfully, users need to trust the service providers. They must believe that the providers are delivering on their security responsibilities. This can be difficult for large businesses dealing with sensitive data and might be impossible for other companies.

Understanding

Users must have a deep and detailed understanding of the provider’s tools, resources and configuration settings to make the shared responsibility a success. They must know exactly where their responsibilities end and that of CSPs begin. Additionally, they need to know how to use the CSP’s tools and navigate their controls to avoid introducing vulnerabilities. A constant adaptation to the change in architectures and systems is also needed to ensure the workloads are secure. All these make the entire process complicated and daunting.

Adjustments

Users need to be ready to embrace changes quickly. Occasional changes to the provider’s infrastructure or services, such as API updates, require users to be diligent, which can be difficult for organizations to follow religiously.

Culpability

Trusting the provider with data is a leap of faith that the users must take. When selecting a provider, users must clearly understand the provider’s SLAs. Organizations will often be at fault if those rules and regulations are violated in a data breach. The workloads and data in the cloud don’t relieve the business of the hack or data breach consequences. As per the provider SLAs, a provider is regarded faultless for any security oversights or errors.

What are the best practices for shared responsibility?

With an array of resources and services involved, cloud security might involve some intervention from both the cloud providers and users. It’s impossible to have a compact set of security measures for every scenario; however, there are several best practices to provide better security and avoid any pitfalls.

SLA comprehension

Organizations must carefully review their SLAs with the cloud vendors to ensure they fully understand the security responsibilities. Complete awareness of the duties is necessary since they differ depending on the cloud model, provider and other factors. The review process also helps identify potential gray areas that must be addressed. When changing cloud providers or opting for a new delivery model, organizations should recheck their contracts meticulously to identify any changes. Even a slight change in the agreement wording can leave an organization vulnerable to serious security risks. For organizations functioning in a multicloud environment, reviewing each SLA individually is critical since there are no standard terms across vendors.

There’s no standard shared responsibility model since user responsibilities vary depending on the cloud provider and service model. Users, therefore, should refer to the SLA they have with their providers. Understanding the security liabilities of every resource and service comprising the infrastructure helps to avoid assumptions and misunderstandings that can lead to security doom.

It’s also essential to keep a tab on the updates CSPs may make to their SLAs and act accordingly.

Working closely with the provider

Cloud security is completely different from on-prem network security. So, updating and adapting cybersecurity strategies to tackle cloud-based risks can be complicated, especially for a hybrid or a multicloud environment. A cybersecurity partner is therefore needed to assist the internal security team of an organization in managing various aspects of cloud security. Also, the updates from the cloud providers, such as API updates and patches to existing services, are something users should pay keen attention to.

Emphasize identity and access management

Diligent management of identity and access controls is instrumental in allowing cloud customers access to cloud-based resources. Such exercise needs to be incorporated into the organization’s IAM policy and solution set. When combined with the large volume of resources and services present in a public cloud, IAM complexity can become overwhelming. That’s why the tools offered by providers are to be used to manage IAM. Users must also develop policies and processes to utilize these tools properly and consistently.

Leveraging security tools

The sheer number of resources, permission levels, APIs and potential attack vectors complicates managing security in the cloud environment. Organizations need cloud management tools designed to simplify complex cloud environments and raise alerts for security issues. These tools also provide automated correction for undesired security changes. To properly utilize these tools, organizations need to stay up to date on the latest innovations in security operations and find ways to adopt them efficiently.

Prioritize data security

Cloud customers are entirely responsible for any data stored in the cloud or produced by the applications in the cloud. A robust data security strategy must be developed to protect the data, whether in use, at rest or in motion. Organizations must make it a priority to enforce policies and data governance. Most organizations classify and categorize data and implement security measures for each category. This means stricter security measures are applicable for more sensitive data.

Although service providers strive to keep the services up and running, they are not immune to occasional disruptions and outages. Service providers are not liable for any disruption or data loss suffered by organizations. So, in an outage, an organization may be unable to retrieve any stored data, unless a proper backup procedure is carried out. Popular service providers, like Microsoft, strongly recommend organizations regularly back up their data using third-party apps and services.

Secure your SaaS data with Spanning Backup

Relying solely on the SaaS vendor is not a viable strategy. In some instances, organizations may be able to recover some data with the help of SaaS vendors, but that’s a rare scenario. For example, in the case of SharePoint in Microsoft 365, deleted items can be retained for 93 days from the time of deletion from their original location, after which they’re permanently deleted. Tools like the Recycle Bin are intended to insulate data retention against user error in the short term. There’s no built-in, enterprise-class backup capability offered by these vendors. A third-party backup solution that is cloud-native and has enterprise-grade backup and recovery capabilities could be the answer.

Spanning Backup — the No. 1 SaaS backup solution in the market — is purpose-built for Microsoft 365, Google Workspace and Salesforce, providing easy-to-use yet powerful capabilities for end users and admins. It automates backup and recovery, ensuring the business-critical SaaS data always stays available, compliant and secure.

Want to take Spanning for a test drive? Start your FREE trial today and discover how it can bolster your SaaS data backup and recovery processes.