Cloud Shared Responsibility Model: Time for an (R)Evolution?

A look at the Cloud Shared Responsibility Model and calls for an Evolution towards "Shared Fate"

For anyone who has been consuming Cloud Computing for some time and using it to deploy organizational workloads and enable business outcomes, you have (or should have) heard of the Shared Responsibility Model. It is essentially the delineation of the responsibilities between the Cloud Consumer and the Cloud Service Provider (CSP).

In this article we will discuss the traditional Shared Responsibility Model (SRM) and calls for a push towards an evolution and what a leading CSP (Google Cloud) has dubbed “Shared Fate”.

To expedite our journey, I will be re-using an article I published at CSO Online in 2021 and then building on it as we discuss the Shared Fate concept and potential drawbacks of the traditional SRM, as well as complicating factors such as insurance and societal dependence on CSP’s and Cloud in general.

Cloud adoption has accelerated in the past years as organizations scrambled to support a remote workforce. Despite this rapid adoption and growth, companies often misunderstand a key cloud concept: the shared responsibility model (SRM).

Many business leaders still ask, “Is the cloud secure”?

This is the wrong question.

A more appropriate question would be, “Are we, as a security team and organization, securing our share of the cloud?”

The overwhelming majority of cloud data breaches/leaks are due to the customer, with Gartner predicting that through 2025, 99% of cloud security failures will be the customer's fault. For this reason, it is imperative that all security practitioners understand their responsibilities.

What is the shared responsibility model?

The shared responsibility model delineates what you, the cloud customer is responsible for, and what your cloud service provider (CSP) is responsible for. The CSP is responsible for security “of” the cloud—think physical facilities, utilities, cables, hardware, etc. The customer is responsible for security “in” the cloud—meaning network controls, identity and access management, application configurations, and data.

That said, this division of responsibilities can change depending on what service model you use. At a basic level, the NIST Definition of Cloud Computing defines three primary cloud service models:

Infrastructure as a service (IaaS): Under the IaaS model, the CSP is responsible for the physical data center, physical networking, and physical servers/hosting.

Platform as a service (Paas): In a PaaS model, the CSP takes on more responsibility for things such as patching (which customers are historically terrible at and serves as a primary pathway to security incidents) and maintaining operating systems.

Software as a service (SaaS): In SaaS, the customer can only make changes within an application’s configuration settings, with the control of everything else being left to the CSP (think of Gmail a basic example). Although it should be emphasized here that the customer still dictates what data gets put into the SaaS environment and you can’t outsource accountability, so approach SaaS accordingly.

Each comes with a tradeoff, with the customer relinquishing control in exchange for more of a turnkey/managed experience with the CSP handling more of the operational activities and letting the customer focus on their core competencies.

Each CSP has a varied version of the SRM and for the purpose of this article we will leverage the example from Google Cloud, since they have been championing the Shared Fate concept that we will discuss later.

(Source: https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate)

How security practitioners can prepare for the SRM

While the SRM involves non-security issues such as contracts and financial implications, it also includes several security considerations. Security practitioners must understand what they are responsible for in the SRM based on the services they are consuming and their organizations’ implementations and architectures.

Remember how nearly all cloud data incidents occur on the customer side of the SRM? This is a major reason to understand the SRM and ensure you are doing your part of the model.

Your responsibilities depend on which of two primary security role perspectives you have: the technical security practitioner or security executive.

Technical security practitioners, such as cloud security engineers or cloud security architects, need to understand what cloud services your organization is using, how to securely architect those solutions, and what configurations, settings, and controls are under your purview that you can influence and lead to a more robust security posture.

Technical security professionals should be intimately familiar with the platforms and services their organization is using and understand how to implement them securely. Cloud security engineers/architects often work with engineering and development teams. If you are not able to guide them to secure solution, or spot risky configurations (remember how these account for most cloud data incidents), you could be exposing your organization to tremendous risk.

Look to your CSP for security resources. Amazon Web Services (AWS), for example, offers an incredible database of security documentation, broken down by categories (e.g., compute, storage, security, identity, and compliance) where you can find specifics associated with each of the services your organization is using. This includes myriad information from how to securely configure the services, what configurations you can manipulate, and troubleshooting guidance.

Key considerations for security executives include inventorying service usage (you must know what is being used within your organization or you cannot secure it), ensuring the services you use are compliant with your applicable regulatory frameworks, and understanding contractual/legal aspects such as CSP service level agreements (SLAs), especially when it comes to things such as incident response planning.

Many organizations enter into a partnership with the CSP and share responsibilities. This includes ensuring the services you're using meet the regulatory frameworks you must adhere to. The hyperscale CSPs make this information easy to find, with by AWS and Microsoft Azure providing “services-in-scope" pages where you can determine what services comply with what frameworks and which are still in approval processes as well as Google Cloud offering comprehensive data about their compliance. This helps ensure your team not only builds robust and secure architectures and workloads in the cloud, but also uses services that are compliant with your applicable frameworks to avoid compliance or regulatory issues.

Security practitioners of all levels should strive to implement secure standards and best practices in their cloud environments. This could mean implementing security best practices from your respective CSPs or implementing something such as the Center for Internet Security (CIS) benchmark for your respective cloud environments.

The customer responsibility matrix

A fundamental artifact when dealing with the SRM is the customer responsibility matrix (CRM), which lays out what controls are being provided by the CSP and what responsibilities are left to the cloud consumer. A great place to find a template CRM and learn more about them is the US’s Federal Risk and Authorization Management Program (FedRAMP). FedRAMP is a program that handles the authorization of cloud service offerings for consumption across the federal government (I used to personally serve as a Technical Representative supporting the FedRAMP Joint Authorization Board for the General Services Administration)

A CRM is a critical tool for security practitioners to use. In the SRM, security controls are either provided entirely by the CSP, a hybrid control (with responsibility falling on both the CSP and cloud customer), or entirely left to the customer. Security practitioners can leverage CRMs to get a clear understanding of this security control delineation.

Consuming cloud services can shift responsibility of some security controls and activities to the CSP and let organizations focus on their core competencies. That said, it creates a relationship of responsibilities that security professionals must understand and handle appropriately. Remember, most cloud data breaches will occur on the customer side of the SRM and at the end of the day, you own the full responsibility of your organization's reputation.

Lastly, I want to emphasize that you cannot outsource accountability. In the rare event that an incident is on the CSP’s end, you ultimately still own the data, and it is your organizational reputation on the line, so you need to understand this, not just for cloud but when working with any sort of third-party provider or supplier.

What is Shared Fate?

In early 2021 CSP Google Cloud announced their concept of “Shared Fate”, along with their announcement of a “Risk Protection Program”.

They did so in an article titled “Announcing the Risk Protection Program: Moving from shared responsibility to shared fate” from their VP and CISO of Cloud Phil Venables (if you don’t follow Phil’s blog, you should be) and their VP/GM of Google Cloud Security Sunil Potti.

While there is some obvious aspects of the announcement aimed as positioning Google Cloud as the “most trusted cloud provider”, there is some merit to Google’s discussion of the challenges with the traditional SRM, which we will discuss below, and these are further exacerbated by the reality that we now have a major societal dependence on CSP’s, with some in the Biden administration even using the term “too big to fail” when describing the leading CSP’s/Clouds and also challenges emerging with the concept of cyber insurance.

While GCP may be the CSP who has championed the concept of Shared Fate, as industry leader and GCP employee Anton Chuvakin rightly points out,

“a trust issue in one cloud can impact the trust in all clouds”

If organizations and society collectively begin to fear that cloud overall is insecure, it will have a cascading impact across all CSP’s.

So despite competitive endeavors and pursuits, all CSP’s do share to some extent a collective interest in maintaining trust in cloud computing.

So what exactly is “Shared Fate”?

As summarized in a recent Google article linked to above, it is stated as:

“From a high level, shared fate puts the impetus on the cloud provider to work more actively with customers to help achieve stronger security outcomes - for them and for us”

The overarching concept is rather than a bias for shifting responsibility to the customer, particularly those who may not be equipped resource or competency wise to bear the burden, the CSP uses their expertise to enable secure environments for the customer.

You’ll notice several parallels in this perspective with those we have heard from Government leaders such as the Cybersecurity Infrastructure Security Agency (CISA) Jen Easterly who has called for “secure-by-design” technology, including cloud offerings as well as alignment with the recently released National Cyber Strategy (which we covered here), which discussed “rebalancing the responsibility to defend cyberspace” to those best positioned to address the risk, which many claim are leading technology companies, including CSP’s.

A specific example of just this is the longstanding issue with customers exposing data inadvertently through AWS S3 buckets, and AWS shifting to having private/non-public default configurations for S3 buckets. This is a tangible example of “secure-by-design”, applied to cloud, it is just unfortunate it took many cloud security incidents to get to this point.

Issues with the Traditional SRM

So what exactly are the cited issues with the traditional SRM? Let’s discuss them based on what Google highlights in their article here.

• Misconfigurations - First up are misconfigurations. As cited above, the overwhelming majority of cloud data breaches are due to customer misconfigurations, and it is a trend that isn’t anticipated to slow down. Google advocates for starting with secure practices and configurations as a default, rather than an activity the customer needs to know about and implement manually.

• The traditional SRM paradigm aligned with IaaS, PaaS and SaaS makes sense on paper but in reality architectures are complex, with customers using a mix of all 3 service models, coupled with hybrid environments as well.

• Businesses simply have and will struggle with the changing regulatory landscape, market trends/changes, M&A and more, and increased involvement and assistance from the CSP will be key.

• Encryption of data is a key consideration, as well as who has access to the keys and who can do what with them

• Incident Response (IR) inevitably requires engagement of not just the cloud customer but often the CSP as well to help investigate and mitigate.

• Organizations are increasingly finding themselves targets of Advanced Persistent Threats (APT)’s (e.g. Nation States) and can use assistance staying up-to-date on the evolving threat landscape, especially if they are an SMB without robust internal security expertise.

While I’ll openly admit that some of these are systemic issues associated with the SRM paradigm and warrant discussion, some of these examples simply won’t go away any time you’re consuming software and services from a third-party and there are and always will be some onus on the consumer/customer.

This recent article from Google provides more specific challenges with the SRM that I feel are more valid.

• Customers simply lack a practical understanding of where their responsibility begins and ends

• A presumption of CSP responsibility

• CSP’s limiting what actions a cloud customer can take, despite the customer bearing the responsibility and consequences

• Default Confusion, where CSP’s overestimate the customers security knowledge/skills and you either have less secure defaults than the customer needs or too secure and the customer inadvertently disables them entirely, leading to risk in both scenarios

These above examples in my opinion are much more valid and reflect the unfortunate reality of the CSP <> Customer relationship in the cloud landscape.

Much of it comes down to a lack of understanding and an asymmetry in expertise between the provider and consumer, an issue that extends beyond cloud to the software ecosystem more broadly (hence calls to rebalance responsibilities in cyberspace in the National Cyber Strategy)

Google provides a robust set of resources to support their perspective of CSP’s taking a more active role in the cloud security conversation.

These include secure landing zones (powered by Infrastructure-as-Code IaC), robust security documentation, assured workloads which facilitate applying security controls to cloud environments and also efforts to drive security improvements on the customer side of the SRM.

As an industry, I think it is worth recognizing these efforts by Google Cloud and their championing of the reality that cloud security and trust in cloud computing requires dedicated effort from both the cloud provider and consumer.

Insurance?

Another key aspect of Google’s Shared Fate announcement and discussion has involved what they dub the “Risk Protection Program”, which allows companies to gain access to exclusive cyber insurance policies designed exclusively for Google Cloud customers.

Google highlights the benefits here of reduces risk, cost and tying into Shared Fate. Consumers can also make use of Google’s Risk Manager services to scan their environment and workloads to identify risks such as misconfigurations and drive down risk and make improvements iteratively.

While I’m not an expert in their Risk Protection Program or Cyber Insurance, I will say there has been quite a bit of industry chatter about cyber insurance in the industry and some, such as the CEO of insurer Zurich referring to cyber as being on a path towards being “uninsurable”.

For a detailed discussion on this topic, I recommend checking out my friend Walter Haydock’s article here.

Systemic Risk

Remember how Anton’s article above discussed how a trust issue for one CSP impacts all CSP’s/cloud?

Many have begun to raise concerns over the systemic risk that the consolidation and broad scale adoption of cloud computing presents to society.

Everything from our most mundane leisurely technologies and entertainment to mission critical industrial control systems, operational technology, citizen services and sensitive national security workloads now rely on cloud computing.

DoD for example finally announced their long-awaited Joint Warfighting Cloud Capability (JWCC) contract in late 2022, which includes AWS, Google Cloud, Microsoft Azure and Oracle.

That said, the DoD and Intelligence community (along with Federal Civilian Executive Branch (FCEB) agencies have been migrating workloads and leveraging cloud-native services for years, well before JWCC finally got finalized (with the Federal strategy evolving from “Cloud First”, to “Cloud Smart”, and that adoption shows no sign of slowing down.

While many in industry have posited that CSP’s are too big to fail, we now have Biden Administration officials using the term when describing cloud as well.

In a recent speaking engagement the acting U.S. National Cyber Director Kemba Walden stated that “if disrupted, it could create large potentially catastrophic disruptions to our economy and to our government”.

We’ve also seen sources such as The Atlantic Council publish detailed thought pieces, such as “Critical Infrastructure and the Cloud: Policy for Emerging Risk” where they discuss how cloud security is inextricably linked to U.S. economic and national security.

They also hosted a session titled “Getting to Fault Tolerant: Policy for Secure and Resilient Cloud Computing”, which was an excellent panel moderated by Trey Herr and featuring Todd Conklin (Department of Treasury), Jim Higgins (CISO of Snapchat), Kelly Shortridge (industry leader and author of Security Chaos Engineering), and Scott Piper (Security Researcher and longtime Cloud Security expert and industry thought leader, currently with Wiz)

The discourse is timely too, given the past week we’ve seen a major security incident with Microsoft, impacting millions of applications and users, at no fault of their own, with the majority of users lacking sufficient transparency and logging due to not paying the price for a higher subscription premium. You can find a detailed write up on the incident from Wiz here.

Another sign of concerns of the concentrated risk of CSP’s come from a recent RFI from the Federal Trade Commission (FTC), looking into the impacts of the $500 billion cloud computing market, pointing out that nearly 70% of internet users and 60% of corporations along with the CIA, NSA and DoD are using cloud.

Many are acknowledging that CSP’s represent concentrated targets for malicious actors. We’ve seen a tremendous focus on software supply chain security, particularly in the fallout of the SolarWinds security incident, which led to the Cybersecurity Executive Order (EO), with Section 4 focusing on securing the Software Supply Chain.

The irony of CSP’s is that they aren’t just targets of malicious actors but they often serve as a launching pad for malicious attacks, due to the ability for quick anonymous/obscured access to compute and the ability to dynamically spin up and down infrastructure tailored to carrying out attacks on victims, all while ensuring your identity and the origin of the attack is opaque.

The above point is evident in the National Cyber Strategy where on one hand it emphasizes the role cloud plays for modernizing Federal IT systems while also pointing out how malicious actors exploit U.S. based cloud infrastructure to carry out criminal activity.

It’s not hard to imagine why hyper-scale CSP’s will be an enticing target for nation states engaging in future conflicts, which will increasingly be carried out on the digital battlefield, at least initially before reaching kinetic engagement.

You cripple technology (including the major CSP’s), you cripple a nation.

Where do we go from here?

We’ve seen the discussion of responsibilities in the cloud evolve from the original Shared Responsibility Model (SRM) to one of Shared Fate, and now a recognition of the societal systemic risks that concentrated cloud adoption posts.

Responsibility delineations aside between cloud providers and consumers, and there is a lot of merit to the pitfalls and missteps of the traditional SRM, one thing is clear

As a society, we indeed do have a Shared Fate model, and it’s now tied to the security and resilience of cloud computing.

Anton stated that “a trust issue in one cloud can impact trust in all clouds” but the reality is that a trust issue in one cloud can impact all of society, since so much of our digital infrastructure, operations, critical services and national security now depend on a small group of hyper-scale CSP’s.

Whatever we call it, we’re in this together, so let’s act like it.