3 ways to defend against attacks on Snowflake

More than a month after a series of data breaches from Snowflake environments, the full extent of the incident has become clearer: at least 165 likely victims, more than 500 stolen credentials, and suspicious activity related to known malware from nearly 300 IP addresses.

In June, the cloud data service provider washed its hands of the incident, pointing to the cybersecurity investigation report published by its incident response providers Google Mandiant and CrowdStrike, which found that 165 Snowflake customers were potentially affected by credentials stolen by information-stealing malware. In a June 2 update, Snowflake confirmed that it had found no evidence that a security vulnerability, misconfiguration, breach, or stolen employee credentials led to the data leaks.

“(E)very incident Mandiant responded to in connection with this campaign could be traced back to compromised customer credentials,” Google Mandiant said.

Snowflake urged its customers to ensure that all accounts are running multi-factor authentication (MFA), create network policy rules that restrict IP addresses to known, trusted locations, and reset Snowflake credentials.

These measures are not enoughsay experts. Companies need to be aware of how their SaaS resources are being used and not rely on users choosing security over usability.

“If you build a system that relies on humans never failing, you’ve built a really bad system,” says Glenn Chisholm, co-founder and chief product officer at SaaS security provider Obsidian Security. “Good engineers build systems that anticipate human failure.”

Here are some additional defenses security teams should consider to detect vulnerabilities in their Snowflake and other SaaS cloud services.

1. Collect account data and analyze it regularly

Security teams must first understand their SaaS environment and monitor it for changes. In the case of Snowflake, the Snowsight web client can be used to collect data about user accounts and other entities – such as applications and roles – as well as information about the permissions granted to those entities.

The picture that emerges can quickly become complex. Snowflake, for example, has five different management roles that customers can deploy, according to SpecterOps. analyzed potential attack paths in Snowflake.

The Snowflake access graph can get complex very quickly. Source: SpecterOps

And because companies tend to over-provision roles, an attacker can gain additional capabilities through non-administrative roles, says Jared Atkinson, chief strategist at SpecterOps.

“Administrators tend to grant access to resources more easily, or they grant a little more access than the user needs – think admin access rather than write access,” he says. “For a user with one resource, this may not be a big problem, but over time, as the company grows, it can become a massive burden.”

Queries for Users for whom a password has been set – as opposed to setting the password value to “False”, which prevents password-based authentication – and looking at the login history that used authentication factors are possible methods for detecting suspicious or risky user accounts.

2. Provide user accounts through an ID provider

As modern enterprise infrastructures increasingly reside in the cloud, organizations must integrate at least one single sign-on provider for each employee to manage identities and access to cloud providers. Without this level of control – the ability to quickly assign and remove employees – organizations will continue to be plagued by legacy attack surfaces, says Obsidian’s Chisholm.

In addition, companies need to ensure their SSO is set up correctly to establish a secure connection via strong authentication mechanisms and, just as importantly, switch off older methods, while applications that have been granted third-party access should at least be monitored, he says.

“Attackers can add a username and password to a credential, add the credential through a service account, and allow you to log into that service account, and nobody was monitoring that,” Chisholm says. “Nobody was monitoring those third-party access accounts, those third-party connections… but all of those connections, plus all of the ones that developers have created, become this incredible attack surface through which you get scammed.”

Snowflake supports the system for Cross-Domain Identity Management (SCIM) to enable SSO services and software – the company specifically mentions Okta SCIM and Azure AD SCIM – to manage Snowflake accounts and roles.

3. Find ways to limit the blast radius of a break-in

The data leaks enabled by Snowflake’s complex security configurations could eventually surpass or even exceed previous breaches. At least one report discovered up to 500 legitimate credentials for the Snowflake service online. Restricting or preventing access from unknown Internet addresses, for example, can limit the impact of a stolen credential or session key. In its latest update on June 11, Snowflake lists 296 suspicious IP addresses linked to information-stealing malware.

The key is to find other ways to limit the attack path to sensitive data, says SpecterOps’ Atkinson.

“We know from experience and the details of this particular incident – the credentials were likely stolen from a contractor’s system and access to that system was able to bypass all of Snowflake’s recommendations – that you can only reduce the attack surface so much,” he says. “Some of the attackers will still make it through. Managing the attack path will greatly limit an attacker’s ability to access resources and execute effects against them once they have access.”

Network policies can be used to allow known IPs to connect to a Snowflake account while blocking unknown Internet addresses. Snowflake Documentation.