Who's responsible in the Snowflake breaches?

It's tricky to split a shared responsibility

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

Photo by Klara Kulikova on Unsplash

Over the past week, multiple large companies, such as Ticketmaster, Satander, and Advanced Auto Parts, reported data breaches linked to their Snowflake accounts. However, as far as we can tell, Snowflake itself wasn’t directly breached. Initial investigations show that hackers used malware to obtain the Snowflake credentials of the company's employees. Sure, the malware likely obtained other credentials, but why is Snowflake getting all the attention?

One major reason is that Snowflake itself is a “high-value” target because many customers store sensitive data, so obtaining credentials to that has a higher blast radius compared to another SaaS application like Asana or Datadog.

Another reason is that it seems that Snowflake allowed customers the option not to enforce multi-factor authentication (MFA) by default. Usually, obtaining credentials alone isn’t enough to access a high-value corporate application because integration with Okta or another SSO provider enforces MFA, or the application itself enforces MFA, especially since Snowflake is a highly sensitive application. This brings up the question: why didn’t Snowflake force MFA, and do they really need to?

How does Snowflake MFA work?

Before we answer the question above, it’s worth diving into the details of how Snowflake sets up its authentication and the product security experience. The reason is that every application has a different way of setting up its authentication. This is an amazingly frustrating experience and a huge pain point that SaaS needs to address. It creates huge operational burdens on both IT and security because they have to read the documentation for every single SaaS application to figure out how to set up authentication securely. It’s interesting because we have standards for authentication, such as SAML and FIDO2, etc., which govern how authentication should happen securely, but we don’t have standards for authentication setup. If you set up authentication for three SaaS applications, they will follow three different sets of instructions. Talking about this frustration further is likely the topic of another newsletter.

In Snowflake, there are two main ways to set up MFA. The users themselves set up MFA, or you can integrate with a SAML/SSO provider like Okta that enforces MFA. This seems pretty straightforward, but implementing MFA is never the hard part. The hard part is enforcing MFA.