What is your Share of the Shared Responsibility Model?

You are leading your organization's cloud transformation and you have successfully moved your business-critical data and mission-critical applications to the public cloud. Now what? Did you know your journey is just starting and you have a shared responsibility for your data and applications with your Cloud Service Provider, commonly referred to as CSP?

If "Shared Responsibility" sounds unfamiliar I recommend you watch the one-hour virtual Conquer Every Cloud event. During the opening keynote of the CEC event, Lawrence Wong had a moment to briefly discuss the Shared Responsibility Model with Doug Matthews but I wanted to dive into a few more important details.

You might have heard about the Shared Responsibility Model in a meeting, documentation or in an IT podcast. Based on context, you probably have an idea of how this relates to your job. But have you investigated the details of the model yet, or started to map out which pieces of your infrastructure or application in the public cloud are not fully protected by CSPs? Let’s explore what is the Shared Responsibility Model, the top Cloud Service Providers view on the Model, and what you need to protect as your part of the Shared Responsibility Model.

What is the Shared Responsibility Model?

There is a Shared Responsibility Model with the top cloud service providers, that outlines who owns the protection of the infrastructure, the applications that are running within the cloud infrastructure, and the data being stored in the cloud. There is a shared responsibility between the CSPs and their customers around the security and compliance.

Putting it simply: CSPs are responsible for resiliency “of” the cloud, but you—the customer—are accountable for resiliency “in” the cloud. That means your organization must take ownership of your data, its security, consistency, accuracy, and its backup, along with workload architecture and failure management. I am passionate about helping our customers navigate this ambiguity.

I think it buries the lede. How about a stronger opening - like - You are leading your organization's cloud transformation. You moved your business-critical data and mission-critical applications to the public cloud. Now what? Do you know your journey is just starting and you have a shared responsibility for your data and applications with the CSP? 

If "Shared Responsibility" sounds unfamiliar I recommend you take watch our Conquer-Every-Cloud event, in which Lawrence Wong and Doug Matthews share the whole picture.

How much downtime can your business afford now that you moved to cloud? Yes, downtimes do happen in public cloud and no you do not get a relief on SLAs because you moved to cloud.

Figure 1: An overview of responsibility retained by the customer (in red), the cloud providers (in grey), and how the responsibilities vary by type of service (SaaS, PaaS, IaaS, and On-Prem)

Organizations are relying on the public cloud for a range of benefits including data storage, flexibility, scalability, cost savings, mobility, and disaster recovery. But as more organizations rely on the public cloud for these benefits, there is not the same level of due diligence when compared to their on-prem data protection. In some conversations I have had with customers, the Shared Responsibility almost gives them a false sense of security, that they don’t need protection or disaster recovery because their data is stored in the cloud. While CSPSs meet their side of Shared Responsibility, delivering on the resiliency OF the cloud, major events still make the news. Just last year, AWS facilities had issues with power outages in the US West regions taking down online services like Slack, Asana, and Hulu. But in a day, many servers that make up the public cloud go down and come back up and they don’t make the news. Your applications should be able to recover from those blips and continue to function without data loss. How much downtime can your business afford now that you moved to the cloud because you do not get relied on SLAs.

Confusion around who holds the responsibility

In a recent study conducted by Vanson Bourne, The Not-So-Silver Lining of Cloud Service Providers’ Standard Tools, Veritas found that a majority of the respondents incorrectly identified their share of the model. They were asked about the responsibilities listed in Figure 1, and only six percent were able to correctly identify which were the responsibilities of the CSPs and which were their responsibilities.

We work closely with both our customers and our cloud service provider partners; we see these confusions and grey areas, especially when the disaster strike. Veritas seeks these challenges as opportunities and wants to make sure all organizations are reducing their risk, gaining visibility across their entire data footprint, and autonomously protecting their data. Veritas wants to make sure all organizations are reducing their risk, gaining visibility across their entire data footprint, and autonomously protecting their data.

I am passionate about helping our customers not only understand but ensure they are fully protected, resilient, and compliant. Looking beyond the ambiguity of shared responsibility, there is also the concern for organizations using multiple cloud services. While most have a similar model, there are still some notable differences, and it will be important for organizations to have a single solution that provides cross-cloud visibility.

What do CSPs think of the Shared Model?

Looking at how some of the top cloud service providers outline the Shared Responsibility Model can help highlight the key divisions within the model and help ensure you are protected.

For Amazon Web Services, they note they are responsible for the security of the Cloud which includes “protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.” Conversely, the AWS customer is responsible for the security in the cloud but varies depending on the AWS Cloud service selected. Amazon EC2 is considered as Infrastructure as a Service (IaaS) in figure 1 above, so AWS manages the physical hardware and infrastructure, but the customer is required to secure all software and perform all of the necessary security configuration and management tasks. For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

For more details and how to apply the AWS Shared Responsibility Model in practice, visit: Amazon Web Services Cloud Security webpage.

Microsoft Azure documentation provides a similar break down where it depends on the type of deployment, but for all cloud deployment types (SaaS, PaaS, and IaaS) the responsibility of your data, endpoints, accounts, and access management are always retained by you.

For more details on Microsoft Azure security and the shared responsibility in the cloud, visit: Shared responsibility in the cloud - Microsoft Azure | Microsoft Learn.

Completing the trio of top cloud service providers, Google Cloud notes in their architecture framework that is not only a shared responsibility but a shared fate. “Google believes that the shared responsibility model stops short of helping cloud customers achieve better security outcomes. Instead of shared responsibility, we believe in shared fate. Shared fate includes us building and operating a trusted cloud platform for your workloads.”

Similar to the Shared Responsibility, the Shared Fate is defined by workloads that are run on Google Cloud and it is on the customer to identify the security controls needed to configure to protect your confidential data. Google also wants you to consider your responsibilities

For more details on Google Cloud’s Shared Fate, visit: Shared responsibilities and shared fate on Google Cloud  |  Architecture Framework

How to fulfil your Share?

Across all of the descriptions of the CSPs Shared Responsibility Model, your data and your access policies remain your responsibility. Now at this point, you might be asking yourself why you should care. Especially if you have been responsible for your on-prem environment you know your end of the responsibility. By transitioning some of the responsibility of managing hardware to cloud providers, you can focus your energy on being more effective in your data protection and compliance.

According to Gartner, over the next three years, “at least 95% of cloud security failures will be the customer’s fault.” I think we can attribute a lot of that to the grey areas between what CSPs own and what your IT organization owns. The Center for Internet Security illuminates this concern noting, “SPs are constantly adding new services that come with new configuration and security tools to manage those services. While native security tools can be convenient, they may not cover all of your configuration management needs. You’ll also need to ensure that you apply all OS- and container-level security updates. To avoid a gap in protection, consider implementing third-party tools to harden systems in addition to the CSP’s native security tools. It’s better to have overlaps between third-party security tools and the CSP’s security services than to have gaps in your cloud security.” You can read more about the case for third-party security tools, including cost savings, ransomware prevention, application persistent protection, compliance, and governance: The case for third-party cloud backup tools | Veritas

Veritas has a long-standing history of protecting, securing, and ensuring the compliance of your data and applications within your on-prem environments, and we remain committed to protecting your data wherever it resides. Veritas gives you the tools to see, understand, and protect your data across all the cloud providers, no matter your type of deployment or your hybrid environments, so you can rest assured that you cover your share of the Shared Responsibility Model.

Again, if you have not had the opportunity to join the recent Conquer Every Cloud event, I encourage you to watch the product announcements, partner spotlights, including AWS and Microsoft, and all the technical sessions: https://www.veritas.com/company/event/conquer-every-cloud.