Is it Time to Adjust the Shared Responsibility Model?

By Nate Nelson, Contributing Writer

When news of Ticketmaster’s breach began to spread last month, some noted just how fuzzy the story seemed to be. Exactly what happened? How?

Details uncovered weeks later would only serve to confirm that fuzziness. This wasn’t your average story of a hacker, a vulnerability, and a company paying the price.

But those experienced in cloud security know that this is par for the course. It’s almost as thoughthe complexity of the cloud invites complex attacks or, at least, complex interpretations of simple ones.

Is there a way to fix this? To make cloud security more straightforward?

“What the hell is cloud computing?”

Back on September 25, 2008, Oracle founder Larry Ellison ranted at a crowd of financial analysts. “What’s cloud computing?” he asked, rhetorically, before answering: “It’s using a computer that’s out there.”

“That’s one of the definitions,” he bemoaned. “These people who are writing this crap are out there. They’re insane!”

Even for the CTO of a company which, over the following years, would be transformed by it and come to rely on it for revenue, cloud computing was this weird, amorphous thing.

The very term “cloud computing” is an acknowledgement of the concept’s underlying complexity. Whether you’re marketing or simply trying to explain it to someone, it has always been simpler to just draw a cloud than to describe the reality: a labyrinth of networked devices and supporting technologies, along with the various ways they connect to one another and why.

And though a lot more people understand, work with, and build on the cloud today as compared with 2008, some of that same confusion has remained with us. That’s doubly true when it comes to cyberattacks.

The Shared Responsibility Model

Forget Ticketmaster for a moment. Uber in 2016, Accenture a year later, and countless other case studies have revealed just how unsure many of us are about who is responsible for securing what when in the cloud.

In 2019, a former Amazon Web Services (AWS) employee identified that a web application firewall (WAF) protecting large volumes of Capital One’s customer data was not properly validating input commands. Using a server-side request forgery (SSRF), she was able to extract financial and personally identifying information (PII) from somewhere in the range of 100 million people.

At face value it reads like any other hack, but there was more to it—a misunderstanding endemic to cloud security. Summarizing the issue to SC Magazine, one expert (among many) lamented about how “There is an assumption amongst businesses that a cloud storage provider will provide all of the necessary security protection for the cloud-hosted services.”

It’s obvious that you need to secure your own computers. When your company outsources its computing to a service provider, however, it’s easy to assume that the provider will secure it for you. Is Capital One at fault for a configuration error affecting its AWS systems, or is Amazon?

For its part, Amazon saw this conflict coming long ago. So as the cloud industry expanded into the behemoth it is today, experts and service providers gradually put together what’s now referred to as the “Shared Responsibility Model.”

Under this model, cloud providers and their customers split the job of securing cloud systems. Providers protect the underlying infrastructure—the hardware, software, and networking technologies needed to provide the service, including physical security for server farms—and their customer takes care of the rest—access management, encryption, and whatever other layers and configurations might be needed to prevent incidents.

It’s easy enough to follow along. And yet, even with this picture in mind, cloud complexity continues to confound.

What Happened at Ticketmaster

Ticketmaster’s 8-K form, filed with the Securities and Exchange Commission (SEC) on March 20, indicated that it had been breached through its cloud storage and analytics provider, Snowflake.

The damage was severe (according to the hackers), including 560 million lost records containing various customer financial and personal information. And, it turned out, this was just the beginning. Around 165 Snowflake customers had been hit, including other well-known companies like Santander and Auto Zone.

Surely, then, the blame for all this fell on the common denominator: Snowflake.

Not necessarily. Nearly a month after the 8-K, the hackers revealed to Wired magazine that they’d pulled off a supply-chain breach. The information necessary to infiltrate at least some of the customer accounts was obtained by phishing an employee at EPAM Systems, a managed service provider that helps companies with their Snowflake environments.

Where does a third-party vendor fit into our responsibility model?

Should Cloud Security be Stricter?

Shared Responsibility divides a complex attack surface into easily understood chunks. As has been the case since the cloud was invented, the model succeeds at simplifying but fails at capturing reality terribly well.

Back in 2019, Gartner made a startling assessment: that approximately 99% of all cloud security failures through 2025 would be the fault of the customer. This huge disparity obviously indicates that customers are more liable to make security oversights and errors, but there’s a second important takeaway: customers face more threats. Much of that is simply because there are more cloud customers than cloud providers. It’s also because attacking a customer’s network with a vulnerability or a phishing email is easier than attacking a cloud provider at the infrastructure level.

Thus, though a diagram of the Shared Responsibility Model with its half blue, half gray matrix seems to suggest that cloud security is split down the middle, it is, in fact, burdened disproportionately to one side. It’s easy to miss this, though, because the relationships between customers, providers, and third-party managed services can mask just how much onus falls on which parties.

While customers are almost always at fault for cloud breaches, cloud providers are in prime position to help. They can extend past these lines we’ve drawn to offer robust monitoring, detection, and other security services, and invest in educating customers to common misconfigurations. Easiest of all: they can make optional security features like device encryption, HTTPS, and multi-factor authentication (MFA) mandatory, to save customers from themselves.

By reweighting the Shared Responsibility Model—by blurring the lines, encouraging more collaboration and overlap—the next potential victim of a breach might avoid a correctable vulnerability, and we can all, collectively, spend less time and energy trying to discern blame in an environment as fuzzy as the cloud.