Marcel Levy
March 4, 2025
Snowflake, one of the world’s larger cloud data storage providers, announced in January that it would be taking a more proactive approach to securing customer access. Snowflake calls it the “Shared Destiny” model, to contrast with the “Shared Responsibility” model that Snowflake, and other cloud providers, have long used.
Snowflake changed its approach because they, and their customers, learned the hard way in 2024 that cloud security is a team sport. A massive data breach hit Snowflake’s customers – household names like AT&T, Nieman Marcus, and Ticketmaster. The attackers behind the breach accessed this data using legitimate credentials that they had stolen using malicious software.
Stolen credentials are a perennial risk. That’s why multi-factor authentication (MFA) has long been part of the standard security advice. Set up the authenticator app on your phone, type in the code during your login, and now the attacker needs more than just the stolen credentials. The attackers behind the Colonial Pipeline ransomware incident in 2021 accessed the company’s network via a retired employee’s VPN account. MFA would have prevented it.
So the story has a simple moral: Just enable MFA everywhere, right?
Not so fast. H.L. Mencken said it best more than a century ago: “There is always a well-known solution to every human problem — neat, plausible, and wrong.”
Real-world systems are far more complex than our diagrams make them out to be. It’s not that these companies didn’t know about MFA, or decided to tackle them “later.” Our MFA systems are designed for people to use, and not programmatic access.
There’s a lot of excitement about AI “agents.” Well, we already have agents. We call them by a lot of names: Applications, programs, services, or “the computer.” The term “workloads” is gaining in popularity. And these workloads have identities, which give them permissions just like people. Historically we’ve called these workload identities “service accounts.” These service accounts have passwords, or secret keys that look like passwords.
Passwords are an old technique, and there are plenty of useful programs that can log in using a password, but don’t support MFA. Legacy systems and service accounts tend to go hand in hand. Enterprises are time travelers, in a way. Kubernetes applications run side-by-side with mainframes running business-critical COBOL applications. Critical systems were designed and built during every decade in between.
These passwords are one flavor of the overall problem of “secrets.” These are bits of data that applications need to run and solve problems on our behalf. Those problems could be data analysis (Snowflake), shipping us the pants we ordered (Walmart), or keeping gasoline coming to the pumps (Colonial Pipeline). The older and more important the application, the more secrets it tends to gather to itself.
Each one of these secrets is both an asset and a liability. They’re essential to the business when kept in the right place, but devastating to the business when they’re not. For example, Cloudflare experienced a breach in November 2023 that started with compromised service accounts.
How do we get out of this? Whenever we get stuck, it’s helpful to shift our focus. Snowflake realized that customer security is a shared outcome – not a shared problem that can be cleanly divided in two. SPIRL and others realized that the secrets an application touches are not the same as the application’s identity. After all, we’re most interested in what applications are allowed to do, and that first means giving each application a unique “name,” just like everyone else on the team. Once you do that, you can assign permissions to the application, instead of a secret.
SPIRL uses the open standard SPIFFE to assign workloads on the network an identity, a name, that can be used to grant permissions to those workloads. No more secrets that can be stolen – MFA or no MFA.
Find out more about SPIRL’s product here.
References:
.png)
.png)
.png)
