What We Can Learn from the Snowflake Breach
On May 31st, news broke of two major breaches affecting almost 600 million people. Ticketing giant Ticketmaster and the bank Santander both disclosed they had been victims of large scale breaches, affecting 560 million and 30 million users respectively. Since then, we have learned that threat actors ran targeted attacks on these victims, finding their way in through Ticketmaster and Santander’s third-party SaaS cloud storage provider, Snowflake.
These latest breaches are particularly interesting for many reasons, including:
- The scale of the attacks and the number of innocent people affected
- They demonstrate the complexity of our environments and the difficulty even teams at multi billion-dollar corporations face securing them
- The handling/fallout of these events by the various parties involves post-breach
What we know about the Snowflake breach
Specifics about this series of breaches are still murky, but what we know so far is this:
- A threat actor group targeted these organizations to find weaknesses they could exploit in their complex environments.
- The threat actors found that Ticketmaster and Santander were customers of the third-party cloud database, Snowflake.
- Ticketmaster and Santander had configured their connections to their Snowflake instances without MFA, meaning that the only thing between a third-party application with access to hundreds of millions of records with personal information and a threat actor was a stolen password from someone with access to that Snowflake instance.
- Threat actors obtained a stolen password on these Snowflake accounts or credential-stuffed their way in, and proceeded to exfiltrate massive amounts of sensitive data without these companies realizing what had happened until it was far too late.
The aftermath - what can we learn?
After news broke of the breaches, the corporate finger pointing began. Ticketmaster and Santander tried to point the finger at Snowflake, claiming it was Snowflake’s weak security that allowed the breach, not their own systems. Snowflake then lobbed back, revealing that Ticketmaster and Santander had configured their databases without the precautions of MFA, placing the blame back on Ticketmaster and Santander and their lax security practices.
It got even juicier when HudsonRock published a postmortem highlighting Snowflake– and Snowflake appears to have muscled them into taking down the article. But the SEC 8-k filings identify a “third party cloud database environment” as the source (recall that since Dec 18, 2023, companies under SEC jurisdiction are required to file an 8-k if there is cyber incident that they reasonably believe may be material).
MFA is table stakes–every CISO knows that. So why are we still seeing these attacks? Because it’s hard to implement across a sprawl of applications–some of which the CISO may not even know about. And it’s hard to continuously implement policies like MFA and prune permissioning if you can’t monitor them continuously.
Threat actors are specifically targeting systems that are configured without MFA because it’s easy for them to get in. Way cheaper than burning a 0-day or using an expensive vulnerability. So here we are: a couple days later, Advanced Auto Parts just announced it was hit in the exact same way, which is to say, through Snowflake (no MFA configured on their cloud storage instance that housed 380 million customer records). I anticipate more to come, because Snowflake is such a prolific vendor that’s providing unsexy background stuff like data lakes, which tons of entities use.
Snowflake is doing what vendors do–they point to the shared responsibility model which states that it’s up to individual customers of the cloud services to adopt best security practices, including MFA. Having come recently from AWS, this is familiar–and to some extent, it will remain true that vendors can’t be responsible for their customers’ security behaviors.
In this case, it will be interesting to see if Snowflake starts to implement different baseline requirements like MFA for their customers. This kind of action would align with CISA’s Secure By Design initiative, which urges vendors and providers to take on some security best practices themselves. In other words, we want to see entities creating more requirements or better default behaviors for customers, even if it creates some degree of friction for their customers.
At the end of the day, there will always be some security responsibilities on the customer side to configure. It’s a reason why I came to work at Reco, because I empathize with the challenges a CISO faces trying to get to “good behaviors,” even ones like MFA that feel like table stakes.
How Reco can help
Every CISO knows you should implement MFA across the board. So why isn’t it in place? As businesses adopt more and more SaaS applications—many of which might be sprawl that the CISO isn’t even aware of—they create complex environments with multiple applications requiring permissioning and monitoring that threat actors can exploit if you aren’t right all the time. And who gets it right all the time without some automation enforcing it?
Reco can proactively secure SaaS environments like Snowflake because we would have both alarmed on the lack of MFA, and noticed the weird data behaviors of the breach exploiting it.
Reco not only monitors for unusual activity through critical posture checks around MFA, SSO/SAML, and IP restrictions, but identifies where those weak points are, helping CISOs answer that nagging, “What don’t I know?”
Our platform helps strengthen Snowflake deployments by ensuring continuous compliance with the CIS Snowflake Foundations Benchmark best practices and security configurations (and alerts you should you fall out of compliance).
Reco also monitors events in Snowflake by running queries on new IP logins and data exfiltration activities in log files. Reco detects threats and anomalies, and will send a prioritized alert to your SIEM or SOAR in near real-time.
Dark Reading highlighted recently that this type of visibility and monitoring into your SaaS environment is one of the most important security tools, and one that is foundational.
Reco is offering complimentary Snowflake and ServiceNow security assessments. Our Snowflake and ServiceNow security assessment will uncover everything you need to know to secure Snowflake and ServiceNow in your environment:
- Discover all Snowflake and ServiceNow usage
- Identify accounts where MFA/SSO is not enabled
- Ensure IP restrictions are enabled
- Run a full posture check (w/ over 100 checks), identify misconfigurations, and recommend changes
- Detect threats and any unusual activity related to MFA, SSO/SAML IP restrictions and where those weak points are located
We connect to your SaaS environment via API within minutes and your security assessment results will be ready within 1 day.
If you’d like to learn more about securing your SaaS environment, please reach out.
ABOUT THE AUTHOR
Merritt Baer
Merritt is the CISO at Reco and Advisor to a small handful of young companies including expanso, Andesite, and LISN. Previously, Merritt served in the Office of the CISO at Amazon Web Services for over five years–a Deputy CISO to help to secure AWS infrastructure, at a vast scale. She has also worked in security in all three branches of the US government and the private sector, including the Federal Communications Commission, the US Department of Homeland Security, the Office of US Senator Michael Bennet, and the US Court of Appeals for the Armed Forces.
Merritt is the CISO at Reco and Advisor to a small handful of young companies including expanso, Andesite, and LISN. Previously, Merritt served in the Office of the CISO at Amazon Web Services for over five years–a Deputy CISO to help to secure AWS infrastructure, at a vast scale. She has also worked in security in all three branches of the US government and the private sector, including the Federal Communications Commission, the US Department of Homeland Security, the Office of US Senator Michael Bennet, and the US Court of Appeals for the Armed Forces.
