About a month ago, Snowflake was in the news for a purported “breach” — a term I believe is misused in this context. Snowflake did nothing fundamentally wrong, and the exfiltration of data did not happen because of vulnerabilities or issues in Snowflake’s enterprise environment. What it looks like is a good old-fashioned credential-based attack. And it happens to be that lots of companies have sensitive data in Snowflake—so, it mattered.
How it happened
Here’s the gist of the attack:
- Customers sign up for and use Snowflake
- Many of those accounts do not set up MFA
- Tools exist within Snowflake to secure the instances, but those are not always used by customers
- Attackers have lots of ways to get credentials— in this case, from pre-existing breaches and through endpoint keystroke logging malware
- Attackers ran a password stuffing attack to pop Snowflake accounts
What’s wild about this incident is that you could quite literally upsert any SaaS provider name into the story of the attack and it would read exactly the same. As outlined in the Mandiant report, this was not a highly targeted breach using sophisticated techniques compromising infrastructure with zero day blah blah. It was a credential-based attack. Furthermore, according to Mandiant, about 80% of the credentials used to compromise accounts were pre-known as compromised. That’s not to say that 80% of the success of those breaches was from those creds—but surely they played a part. When people reuse passwords and MFA is not on an account, that’s extra bad. This was an old-fashioned password stuffing attack on poorly secured environments. A tale as old as time.
What we’ve learned
There’s a lot that’s already been said that’s not worth repeating. To be additive, I think there are a few additional takeaways that are worth talking about:
1 - The shared responsibility model of security seems… broken.
Elements of this attack strike right at the heart of the shared responsibility model between vendors and customers. If a vendor provides the tools to properly secure accounts but those tools are not used, who’s responsible? The truth is that it’s gray today and it will be gray tomorrow. Arguably every vendor does have a responsibility to provide some basic level of security protections. *Minimally* that includes MFA and SSO support (yes, the SSO tax is truly an antipattern in this context). These are table stakes for a modern SaaS vendor.
In the case of Snowflake, they have a solid write-up on the best practices for any customer using their instance. This comes with a set of recommendations such as locking down accounts with MFA, implementing SSO and SCIM, and defining roles with the right level of access.
The challenge with all of these (or any) best practices is the time and energy required to implement them. MFA and SSO are no-brainers because they’re high ROI—easy to implement and significantly improve security. On the other hand, the recommendation of network and IP restrictions is great, but can be impractical. Many companies have remote employees. Unless users are VPN-ing back in using a traditional VPN or modern access gateway, chances are this won’t be an effective control for you. Other best practices such as monitoring and advanced detection can take significant effort to implement. When everything is said and done, beyond a basic set of quick wins, it can be difficult as a customer to figure out if the juice is worth the squeeze on certain recommendations and whether others will be practical.
Additionally…
2 - Access governance and JIT should be a standard recommendation.
[Disclaimer—this is the ConductorOne product. Yes, you can disregard it if you want, but I firmly believe in this recommendation.]
We frequently talk about SSO and MFA and SCIM, but way less frequently do we talk about just-in-time access, “use-it-or-lose-it” access, and local account visibility as key least privilege approaches to securing access. However, it’s obvious that reducing standing privileges to sensitive data and infrastructure dramatically reduces the risk of a breach. Today, there’s too much of a focus on the front door—trying to secure who gets in—and not nearly enough on whether someone should have access in the first place. If you reduce standing access by 75%, you’ve reduced the surface area of your attack by 75%. That’s huge.
3 - Usernames and domain names are not secrets.
We MUST stop treating username and domain names as secrets. I can’t say for certain that this played into the Snowflake attack, but too often folks treat information like usernames and tenant names as secrets that offer some layer of protection. They’re not and they don’t. You should assume every attacker on the planet knows your tenant name(s) and usernames for all of your users. Again, not suggesting this played a major or even minor role in this attack, but it’s about the *mindset*. Security through obfuscation does not work. And, when combined with the next takeaway, the rest of the recommendations make even more sense.
4 - And also… passwords are no longer secrets.
Here’s my spicy take. We should just flat out stop treating passwords like they’re a secret. They’re probably not. Fifteen years ago they were, and then internet-scale breaches started happening, and now every single variation of your “g1fthorse123!” root password is on the internet somewhere associated with your name and email address. It’s nearly impossible to prevent end-user password reuse. Chances are that your employees and contractors have the credentials they’re using for sensitive environments floating around somewhere on the web as you read this. Furthermore, internet-scale phishing attacks mean that compromising passwords is a matter of when, not if.
5 - Contractors are an underappreciated risk to your business.
This was an interesting insight from the Mandiant report: contractors likely played a nontrivial role in the attacks by having creds compromised on nonwork machines. I’ve seen that contractors will frequently have fewer security requirements than full-time employees do. This is *risky*. Contractors need to be properly offboarded. Unused contractor access needs to be removed. We need to be methodical and religious about contractor access management. They frequently have the exact same access to critical business software and systems as your employees do.
Conclusion
It would be a shame for someone to read about the Snowflake attacks and think: “MFA… got it. Let’s get that implemented and call it a day.” It would appear that at least 20% of compromised Snowflake accounts came from stealing credentials using endpoint malware. If an attacker can grab credentials from an endpoint, they can grab OAuth and bearer tokens as well. MFA helps to secure the front door from credential-based attacks, but it’s no longer sufficient to secure your environment. You have to contain the blast radius of potential attacks. That’s about improving visibility, streamlining access governance, managing contractors more effectively, and pushing toward least privilege access control.
To learn how ConductorOne can help you improve the security posture at your organization, take a product tour or chat with us!
