What Happened

The Snowflake data breach was a sophisticated, multi-step campaign aimed at financially extorting customers and stealing data. The activity cluster, identified as UNC5537, utilized usernames and passwords obtained from dark web forums. These credentials were initially harvested through various malware applications infecting personal computers across numerous organizations, affecting approximately 165 Snowflake customers.

UNC5537 used these compromised logins to impersonate users, gaining access to their respective corporate Snowflake accounts. Once inside, the hackers executed a utility called FROSTBITE, which collected detailed information about the user, their corporation, roles, session IDs, and more. Armed with this data, the attackers employed a legitimate tool called DBeaver Ultimate to connect and run queries across different Snowflake instances to gain a controlling amount of data which could be used for extortion purposes.

The acquisition of credentials through malware attacks date back as far as 2020, indicating a prolonged data set of usernames and passwords.

What Snowflake Customers Could Have Done

The “good news” is that this attack was not something involving Snowflake’s own backend service. Rather, it was a brute force attack on customer credentials. So Snowflake customers can’t completely be bystanders when it comes to their corporate security just because they have an end-to-end encrypted database. The basics of security standards are still something that organizations need to pay attention to and here are some of examples:

Multi-Factored Authentication 

If only multi-factor authentication (MFA) had been in place, the Snowflake breach could have been a different story. MFA isn't just a password—it’s a password plus something else, like a mobile device or a biometric scan. So even if the hackers got their hands on usernames and passwords, they’d be stopped cold without that second factor. MFA sends notifications for login attempts, giving users a heads-up about unauthorized access. This can clue users that something nefarious might be going on.

Rotating Passwords

Another critical misstep in the Snowflake breach was the failure of customers to periodically rotate credentials. The simple act of not allowing a user to proceed without updating their password allowed credentials farmed as early as 2020 to still remain active.

Location Tracing of Log-Ins

Locations can be spoofed, so this doesn’t always work, but we’re talking about accounts that didn’t have some of the basics set up, so it’s not unimaginable that the hackers could have queried from a foreign location. Location-based login tracing can be a method of defense, especially for very unusual location-based attacks.

Audited Access Control Grants

If you are going to get hacked, it is probably best that the user’s credentials aren’t giving the keys to the kingdom. You would hope that the Administrator has better malware aversion habits, but that might be a difficult ask for from the average user. 
Having advanced RBAC implemented along with strict object naming conventions can enable the enterprise to get quite surgical about data grants, so even if a breach happens, the exposure is minimized.

What Snowflake Could Have Done and is Doing

Snowflake has the tricky job of balancing ironclad security with the flexibility for customers to decide just how locked down they want their systems to be. While offering customizable security options caters to diverse user needs, it also means Snowflake must ensure that the default security features are robust enough to fend off sophisticated threats. Snowflake has already been working through updates, and there are some additional suggestions we have.

Could Have Done

Snowflake has offered Cisco DUO to control MFA for many years now. (Even beyond the data available for this breach) However, using MFA has been an option. Snowflake strongly recommends leveraging MFA in its documentation.

Enforcement of MFA as a requirement might be seen as a heavy-handed intrusion into corporate security governance. In the case of these hacks, it would have succeeded in stopping the intrusion.

Is Doing

Being informative might be the most evenhanded way of satisfying their broad customer needs. Snowflake has a feature in Private Preview called the Trust Center. The purpose of this is to act as an information center on how secure a Snowflake account is. The Trust Center scans a wide range of recommendations based on benchmarks provided by the CIS Benchmarks which, within the Snowflake Benchmark, includes recommendations in the topics of:

• Identity and Access Management
  • Single Sign On
  • SCIM Integration
  • MFA
  • Password Strength
  • Key Pair Authentication
  • Key Rotation
  • Inactive User Deactivation
  • Idle Session Timeouts
  • Limiting Admin User Count
  • Grant Control
• Monitoring and Alerting
  • Monitoring Grants to Roles and Privileges
  • Monitoring for Sessions
• Networking
  • Trusted IP
  • Service Account Policies
• Data Protection
  • Annual Rekeying
  • AES Encryption Key Size
  • Data Retention
  • Data Staging Parameters
  • Unload Prevention
  • Tri-Secret Security
  • Data Masking
  • Row Access Policies for Sensitive Data

The CIS Benchmarks have been operationalized into the Trust Center assessment which can be executed against the Snowflake environment. This can act as a powerful assessment of the security methods being used within a Snowflake account. The high-risk items are surfaced with specific recommendations on what should be done to de-risk the vulnerabilities.

Snowflake Trust Center with a Trusted Partner

Intricity, a Ness Digital Engineering Company, is the first Snowflake partner and carries the breadth of experience to drive a security assessment to its fullest potential. The Trust Center provides a powerful assessment, and Ness has the capacity to take that assessment to full execution within your organization. Ness’s security assessment includes the implementation of the Trust Center along with the execution of the Trust Center benchmark recommendations within your organization.

Templated Guided Security Decisions

The Ness Documentable Templates allow for all the decisions around security to be documented into the architectural templates of your Snowflake instance. These templates are based in Lucid Charts, and provide an easily accessible, and sharable view into the security and design decisions which have been made by the enterprise.

The following are a small visual sample of some of the templated frameworks, built of Snowflake, which Ness leverages to document the decisions made during the security assessments. These act as living representations of the security architecture.

Engage with Ness

The Trust Center and Templated Mapping of your current governance model is a packaged offering from Ness that dives deep into the current state of your security using the Trust Center, then maps out the road ahead in documented practices which the organization can proceed with. To schedule a meeting with a Snowflake Specialist from Ness, please register HERE.