Understanding the shared responsibility model of cloud services is perhaps one of the most important aspects of cloud security. Knowledge of this model allows organizations to operationalize security programs rooted in a proper understanding of what resources and settings they have control over and visibility into once they migrate to the cloud.

While the shared responsibility model is not new, it is often a lesson that companies new to the cloud may learn the hard way. This is usually through the Shared Responsibilitypainful process of reactively addressing data leaks, breaches, and cloud misconfigurations. This is a fact not just borne out in headlines, but by statistics revealed by groups like Gartner suggesting that through 2025, 99% of all cloud security failures will be the customer’s fault.

 With COVID-19 accelerating the need for cloud technologies, organizations no longer have the luxury of delaying cloud adoption until some hypothetical point in time when they deem the cloud safe. Thoroughly understanding the shared responsibility model will allow teams to confidently adopt cloud technologies and work more effectively with their cloud service providers.

Where does the shared responsibility model come from?

The shared responsibility model is a cloud service provider’s way of addressing major cloud security concerns. Providers like AWS have led the way in setting the expectations for customers regarding the infrastructure and practices used to provide cloud services. Just like companies have standards for their on-prem assets–from the servers they install to the maintenance of the software running on these servers–the shared responsibility model illustrates that cloud providers take into account these same considerations when delivering their services.

What is the shared responsibility model?

As lightly touched on above, the shared responsibility model is the splitting of security and compliance responsibilities between a cloud service provider and its customers. This can generally be broken into two aspects:

    • Security of the cloud. This refers to the processes, practices, and procedures that cloud service providers conduct to secure the assets they use to deliver cloud services. Examples of this include physical security and access, as well as managing the network protocols, uptime, and anything else having to do with physical and network level operations. For a full list of what types of security and operational practices a cloud service provider offers, check their documentation.
    • Security in the cloud. This second part refers to security within the cloud environment itself. Examples of this include application access permissions and security, as well as any tools used to provide protections to data at the application layer.

The division of cloud security into these two areas of responsibility stems from the fact that providers do not have visibility within customers’ environments. Their visibility ends at the hypervisor, the space where users’ operating environments are partitioned within a host machine. Customers have visibility beyond the hypervisor at the operating system and application levels, which means that it has to be their job to deploy the appropriate settings and tools to secure their data and environments.

Does the shared responsibility apply to SaaS cloud services as well?

The shared model absolutely applies to SaaS applications as well as public cloud environments. Within SaaS environments, the responsibilities don’t map in the exact same way as they do within IaaS environments, with SaaS providers taking responsibility for things like application security. But even here customers must take responsibility for application permissions and settings, as well application data itself.

Putting the shared responsibility model into action

What does the shared responsibility model look like in action? Whether you’re using SaaS or IaaS platforms, there are three key must-haves that matter when it comes to securing your cloud environments.

You have to understand configurations and accessibility settings appropriate for your data

All cloud services and applications have default security, permissions, and privacy settings that will impact who has access to your data and what security controls are in place within your environments. It is your organization’s responsibility to determine whether these default settings are sufficient for meeting its specific security and compliance requirements. For example, if teams within your organization have recently adopted Slack due to COVID, it might make sense to harden the application by enforcing 2FA, and limiting what applications users can install within Slack.

These considerations are even more important when it comes to IaaS security. For instance, a 2018 study found that of the AWS S3 Buckets that are publicly available, almost 40% are at least partially writable or readable. Adopting practices like the principle of least privilege and having an understanding of how to secure your credentials are going to be critical for making sure you modify security defaults to appropriately reflect your organization’s security requirements.

You have to understand the appropriate uses of your data in a given environment

Configuring your permissions and security settings are a significant part of improving your organization’s security posture in the cloud; however, doing this is only half the battle. In order to combat insider error and insider threats, it’s critical that security teams develop an understanding of behaviors and activities that potentially violate data policies and leverage tools, like data loss prevention, that can detect and prevent these from taking place.

You have to have eyes on your data at all times

Even assuming your organization has documentation surrounding its security and data governance policies and these policies are readily accessible to employees, it’s important that security teams understand that in order to enforce these policies they need to have eyes on data in the cloud. Tools that automate data classification, as well as data policy violation enforcement, are a way to ensure you know what data you have, where it is, and can respond quickly and effectively to incidents threatening the confidentiality of that data.