How the Shared Responsibility Model Contributed to the AT&T Breach

Customers of Snowflake, a U.S. cloud service that offers data storage and analytics, recently suffered a massive and highly public data breach that some say could be the largest in history. The breach affected nearly 170 organizations—including “nearly all” of wireless carrier AT&T’s customers, along with customers of other companies such as Ticketmaster and LendingTree.

But the breach isn’t just devastating for the affected customers and companies. It’s also an excellent example of what can happen when the cloud shared responsibility model breaks down. Let’s explore how.

• What’s the Shared Responsibility Model?
• The AT&T Data Breach: How Did It Happen?
• Who’s At Fault When There’s Shared Responsibility?
• Lessons for Companies (and Users) in the Cloud
• MASV: A Layered Security Approach

What’s the Shared Responsibility Model?

Let’s first define what we’re talking about here: The shared responsibility model, or shared security responsibility model, is a security framework used by many public cloud providers, including Snowflake, that divides data security responsibilities between the provider and its end users.

Vendor responsibility combined with customer responsibility. Sounds simple enough, right?

The problem, however, is when users assume their cloud provider will take care of a data security responsibility that’s actually not the provider’s responsibility—or don’t take advantage of the tools offered by the provider (like enforcement of multi-factor authentication (MFA), for example).

When that happens, the shared security responsibility model breaks down. And the chances of a data breach go way, way up.

The AT&T Data Breach: How Did It Happen?

This data breach seems to be a direct result of this kind of breakdown of the cloud shared responsibility model.

In keeping with this model, and like many cloud services, Snowflake has traditionally provided cybersecurity tools and capabilities but allowed users to manage their security posture on their own. For example, Snowflake provided access management tools such as MFA but previously did not require its users to enforce them.

SOURCE: Verdict.co.uk

A brief statement released by the cloud service provider acknowledged that the breach was a “targeted campaign directed at users with single-factor authentication (SFA),” adding that passwords to Snowflake accounts with SFA were either “previously purchased or obtained using info-stealing malware.”

Translation: Keystroke logging (or similar) malware harvested user passwords, which were then used to break into insecure Snowflake accounts and (predictably) wreak havoc on the data within. But the sad fact is that if admins of the breached Snowflake accounts had enforced MFA access control among their users—a relatively simple requirement—this breach almost certainly would not have happened.

(TechCrunch has recently reported that it has seen “hundreds” of alleged Snowflake customer credentials, like what was used in this attack, still available online).

Unsurprisingly, since the breach was made public, Snowflake has announced a new authentication policy that allows admins to force all Snowflake users to use MFA.

Who’s At Fault When There’s Shared Responsibility?

In this scenario, is Snowflake really responsible for this data breach?

• Snowflake recommended that account admins enforce strong passwords on sign up.
• Snowflake offered optional MFA access management to further secure their users’ accounts, but some account admins chose not to set it up.
• Snowflake didn’t allow tools for admins to enforce MFA prior to the breach.

While the latter is definitely on Snowflake, the first two could be perceived either as a failure either on the cloud service provider or the user’s end. In reality, it’s probably a bit of both (shared responsibility also means sharing responsibility when things go wrong, too).

The incident has illustrated in sharp relief one of the major vulnerabilities of the shared responsibility model.

From our observations, and maybe unsurprisingly, industry sentiment is slowly shifting towards vendors implementing more strict security controls to prohibit customers from shooting themselves in the foot (like in this situation): A shared responsibility model, just with a bit more vulnerability management responsibility on the vendor than the user.

Lessons for Companies (and Users) in the Cloud

It’s important for all of us to learn from our mistakes, and public cloud services and users are no different.

Along with vendors allowing admins to enforce sensible cybersecurity measures like MFA, there are other valuable data protection lessons that can be learned from this incident:

Enforce MFA/2FA and other sensible security defaults

Data breaches have now become so commonplace that even most everyday business users are aware of the importance of access control with MFA or two-factor authentication (2FA). Admins should always enforce it and cloud providers should always provide this option.

Even though MFA causes some employee friction—I recently switched computers and had to deal with around 100 MFA verifications in a couple of hours while setting things up—it is able to stop many cyberattacks in their tracks. That’s reason alone for it to be non-negotiable. 

A cloud service should also provide education and assistance for clients who enable MFA on legacy accounts that are connected to automated processes, because the MFA step will likely break those processes if the migration isn’t handled carefully.

Other security defaults, such as automatically configuring all new resources (such as storage buckets, databases, or virtual machines) to block all public access (instead of being open to the public by default), should also be implemented by cloud providers.

While these kinds of measures add a little bit of friction to the end user, they also force them towards a path to more security—rather than the other way around.

Gather open threat intelligence (OSINT)

Continuously monitor threats on the dark web and regular internet on behalf of customers and react to any indicators of a potential breach. It’s become a bit of a tradition for careless users to accidentally expose API keys on open code repositories, for example, like when this user posted their Stripe API key on GitHub (oops).

Cloud companies should monitor open source code repositories for key leaks and reach out to affected clients if they discover them. Providers can use automated tools such as CrowdStrike for this.

Offer Tooling To Stay On Top of Potential Threats

Cloud providers should also offer tooling and integration with leading cybersecurity platforms to assess DevSecOps teams, stay on top of potential threats, and give users more flexibility to follow cybersecurity best practices. If cloud providers don’t provide such security controls, admins should search out these tools anyway.

• Case in point: Services like Splunk or Wiz can perform passive monitoring of all actions within a cloud infrastructure, automatically spotting usage anomalies that can be a dead giveaway to a breach—but otherwise may go undetected.
• Another example: API key rotation. If a user wants to change up their API key every three months, for example, the provider should provide a mechanism for them to do that without incurring significant system downtime. That means providing the capability of generating multiple API keys at the same time.

Don’t take things for granted

Finally, especially as a customer, never take the shared responsibility model for granted or become complacent. It’s sometimes easy to fall into a mindset of “it’s the other company’s responsibility,” or assume that if a security tool isn’t mandatory, it’s not important.

Cloud providers should provide as much education and documentation as possible to guide users toward a responsible security posture, while also educating their own employees on the latest security threats and best practices.

And as a user you should always follow best practices, read the documentation, and never assume your cloud infrastructure provider is going to take care of something until you see it in writing.

MASV: A Layered Security Approach

Along with being built on AWS security with strong TLS 1.2 and AES-256-based encryption and strict access controls, MASV keeps all stored and transferred data safe through a layered security approach that include:

• Employee security awareness training and strong internal password generators.
• Product security including regular code scanning and automated alerts for admin logins.
• Customer protections such as the mandatory enforcement of strong passwords, and the encouragement of mandatory MFA and password generator usage.
• Validation through third-party cybersecurity audits and regulatory compliance.

Sign up for MASV and start for free today.