Determining the Potential Data Attack Surface and Reducing the Blast Radius in Light of the Snowflake News

Earlier this week, the industry learned of the recent increase in attacks against customers of the DBaaS platform Snowflake.

In a community post issued by Snowflake on Monday, the company stated that they “believe this is the result of ongoing industry-wide, identity-based attacks with the intent to obtain customer data. Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity.”

Threat actors appear to be targeting Snowflake users with a specific security posture. Those who do NOT have multi-factor authentication turned on. This was confirmed by Mandiant CTO Charles Carmakal as well.

"Threat actors are actively compromising organizations' Snowflake customer tenants by using stolen credentials obtained by infostealing malware and logging into databases that are configured with single-factor authentication," Mandiant CTO Charles Carmakal said in a post on LinkedIn.

Snowflake is investigating activities from a list of IP addresses at this time - that list can be found here. Below are Snowflake’s recommendations following the news of their customers being under siege:

1. Enforce Multi-Factor Authentication on all accounts
2. Set up Network Policy Rules to only allow authorized users or only allow traffic from trusted locations (VPN, Cloud workload NAT, etc.); and
3. Impacted organizations should reset and rotate Snowflake credentials.

Reducing the data attack surface is the real mission

Enterprises using Snowflake, or any other SaaS service for that matter, must be able to focus their security efforts on the greatest potential areas of risk.  In cases such as this, the goal should be not only to determine which users have MFA turned on, but also to understand what sensitive data those specific users currently have access to. We refer to this correlation as the data attack surface. Discovering the data attack surface is also what we are actively helping our customers do today.

Cyera classifies data within IaaS, SaaS, DBaaS, and on-premises datastores. Snowflake is one of the platforms we support. Based on our classification of data within Snowflake, and our analysis of Snowflake’s Access Control configurations, we can provide our customers with an actionable report of Snowflake users with access to sensitive data, along with their MFA status and last active date. Our customers can then use this information to enable MFA for their users with access to Restricted and Confidential data, as well as disable stale users who have been inactive for a long time.

These insights are critical for every organization, so that it can proactively prevent unnecessary exposure, and react swiftly in the event of a potential data security incident.

Therefore our recommendation is for Snowflake customers who already have Cyera to do the following:

• Use Cyera to quickly identify Snowflake users with access to sensitive data that have multi-factor authentication turned off
• Prioritize users with access to sensitive data vs. users who do not have access to focus your security efforts
• Identify inactive users with access to sensitive data - and reduce their data access permissions  or disable such users to minimize the potential blast radius

Threat actors will continue to target users, services, and servers (the industry witnessed this with the Change Healthcare breach) that do not enforce MFA. But beyond turning on MFA, which every organization should do, I also urge security leaders to have a solution in place that can accurately determine their data attack surface, and work towards reducing the potential blast radius. After all, data is what most threat actors are after anyway.

If you would like to learn more about how we can help reduce the data attack surface in your environment, let us know. We are always happy to help.