3 Ways to Chill Attacks on Snowflake

More than a month after a spate of data theft of Snowflake environments, the full scope of the incident has become more clear: at least 165 likely victims, more than 500 stolen credentials, and suspicious activity connected 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 had potentially been impacted by credentials stolen through information-stealing malware. In a June 2 update, Snowflake confirmed that it found no evidence that a vulnerability, misconfiguration, breach, or stolen employee credential had led to the data leaks.

"[E]very incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials," Google Mandiant stated.

Snowflake urged its customers to ensure multifactor authentication (MFA) is running on all accounts; to create network policy rules that limit IP addresses to known, trusted locations; and to reset Snowflake credentials.

Those measures, however, are not enough, say experts. Companies need to be aware of how their SaaS resources are being used and not rely on users choosing security over convenience.

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

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

1. Collect Data on Accounts and Regularly Analyze It

Security teams first need to understand their SaaS environment and monitor that environment for changes. In the case of Snowflake, the Snowsight web client can be used to collect data on user accounts and other entities — such as applications and roles — as well as information the privileges granted to those entities.

The picture that develops can quickly grow complex. Snowflake, for example, has five different administrative roles that customers can provision, according to SpecterOps, which analyzed potential attack paths in Snowflake.

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

And, because companies tend to overprovision roles, an attacker can gain capabilities through nonadministrative roles, says SpecterOps chief strategist Jared Atkinson.

"Administrators tend to more easily grant access to resources, or they grant slightly more access than the user needs — think admin access instead of write access," he says. "This might not be a huge problem for one user with one resource, but over time, as the business grows, it can become a massive liability."

Querying for users who have a password set — as opposed to the password value set to False, which prevents password-based authentication — and looking at login history for which authentication factors have been used are possible ways to detect suspicious or risky user accounts.

2. Provision Users Accounts Through an ID Provider

With modern business infrastructure increasingly based in the cloud, companies need to integrate a single sign-on provider for every employee as the bare minimum to manage identity and access to cloud providers. Without that level of control — being able to provision and de-provision employees quickly — legacy attack surface area will continue to haunt companies, says Obsidian's Chisholm.

In addition, companies need to make sure that their SSO is properly set up to securely connect through strong authentication mechanisms, and just as importantly, older methods need to be turned off, while applications that have been granted third-party access should at least be monitored, he says.

"Attackers are able to 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 no one was monitoring this," Chisholm says. "No one was monitoring those third-party access accounts, those third party connections ... but all those interconnections, plus all the ones that developers have created, become this incredible surface area that you get screwed through."

Snowflake supports the System for Cross-domain Identity Management (SCIM) to allow SSO services and software — the company specifically names Okta SCIM and Azure AD SCIM — to manage Snowflake accounts and roles.

3. Find Ways to Limit the Blast Radius of a Breach

The data leaks facilitated by Snowflake's complex security configurations may eventually rival, or even surpass, previous breaches. At least one report discovered as many as 500 legitimate credentials for the Snowflake service online. Limiting 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 connected with information-stealing malware.

Finding other ways to limit the attack path to sensitive data is key, says SpecterOps' Atkinson.

"We know from experience and the details of this particular incident — the creds were likely stolen from a contractor’s system and access to that system could bypass all of Snowflake’s recommendations — that one can only reduce the attack surface so much," he says. "A subset of attackers will still make it through. Attack-path management will severely limit an attacker’s ability to access and carry out effects against resources once they have access."

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