The Hidden Threats of Non-Human Identities: Lessons from Snowflake's Attack

What Happened

At the end of May 2024, Snowflake disclosed a potential compromise of its production environment. According to Mandiant’s blog post uncovering the attack, a threat actor used a service account’s credentials which were exposed via different infostealer malwares¹.

Snowflake stated that the attack was not caused by a vulnerability, misconfiguration or a breach of the Snowflake product. Still, it is estimated that 165 different organizations were victims of this attack exposing sensitive data of millions of customers. The attackers claim that around 30 million Santander Bank clients’ bank details were exposed along with the information of millions of Ticketmaster users. The list of those affected also included AT&T, the Neiman Marcus Group and many more. These organizations didn’t exercise poor security practices like exposing tokens via public repos or having services open publicly, they were just not protected enough to deal with this Snowflake-oriented attack.

Using Best Practices to Reduce Blast Radius

Knowing that the attack was not performed using extreme measures but only exposed credentials is rather bittersweet. Though it’s comforting that attackers were not exploiting sophisticated vulnerabilities, sensitive customer and company data still managed to be compromised, affecting finances, trust and reputation of high-profile companies.

Every organization uses third-party services. and chances are that one day or another they will be the target of an attack. Using best practices can reduce potential damage of any incoming cyber disaster:

• Multi-Factor Authentication - MFA prevents threat actors from accessing sensitive environments using only a username and password. After the attack, Snowflake issued a new security capability for admins to enforce MFA for all users in their environment making it easier to prevent these types of attacks. A strong best practice to implement is to ensure all users authenticate via the company IDP, allowing the ability to monitor and provision all users while avoiding using passwords.
• Network Policy - Network policies also minimize the attack surface since access is only possible through designated IP ranges, possibly only IP addresses belonging to your company.
• Rotate Credentials - Do this at least every 6 months. Out of the 165 estimated victims to the Snowflake-focused attack, the earliest exposed credentials used were over 4 years old. As a rule of thumb, rotating passwords and access tokens can also lower the chances of falling victim to a broad attack in the future.
• Monitor Outside Contractors - Most services offer many tools to monitor users inside the organization, while it is much easier to forget about outside contractors. Many times less policies are enforced on contractors but they can inflict the same amount of damage as internal collaboration tools. Perform a quarterly assessment for your outside contractors - are these users still necessary? Do they all follow all policies?

Snowflake Service Accounts

Services often offer more than one identity type in their environment's identity management. Up until recently, Snowflake had only one identity type: User. A User can have attached roles that grant access to different resources.

Below is an example of a Snowflake RBAC model:

Snowflake allows multiple possible authentication methods: Password, RSA key and a MFA for a second method (using DUO app). It’s also possible to integrate an external IDP to authenticate.

Snowflake’s recent update introduced a new property for the Snowflake identity:
‍type = PERSON | SERVICE | LEGACY_SERVICE | NULL

The main addition of this update is the SERVICE type. This property was created to differentiate between human users and service accounts and allow admins easier visibility and management of their environment. Identities with the type set to SERVICE can only authenticate using an RSA Key, as recommended according to Snowflake’s best practices.

Although this update focuses on improving security and visibility, it’s an inadequate solution for two reasons:

1. The update doesn’t apply to existing users. All existing users received the NULL value for the type property. In case you want to improve your security posture after this update, you still need to do it by yourself, the same way as before, but this time with tagging.
2. Since the addition of the TYPE property is optional, the process of creating a new user didn’t change dramatically and there is still no way to tell apart all human and NHI users.

At the end of the day there may still be many service accounts without a specified type, that are still using passwords (which are brute-forceable and easier to steal than RSA keys) without an MFA, which is irrelevant for machine access anyway.

To treat service accounts and enforce policies appropriately, it is essential to first distinguish between users and service accounts. This can be achieved by utilizing data from an IDP, detecting authentication methods from logs, and analyzing usernames and email addresses.

Snowflake Recursive Permissions Structure

The main object in Snowflake is the Role. Through privileges, roles are linked to all other objects such as databases and warehouses. Roles can also be attached to other roles recursively. This adds complexity to determine the privileges for a single user.

SELECT PRIVILEGE, GRANTED_ON, NAME, GRANTEE_NAME
FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
WHERE DELETED_ON IS NULL
   AND GRANTED_ON = 'ROLE'

Here is a simple query for determining the direct linked Roles granted to every role in a Snowflake environment. From there, it is possible to know every role and user’s direct and indirect privileges by using this query recursively.

‍
The NHI Expert’s Top Challenges

In the era of the cloud services boom, organizations are managing thousands of identities and credentials. Every single one of them, should they fall into the wrong hands, can expose sensitive company and/or customer data.

It’s hard to govern all of the identities wandering in the wide planes of cyber space, whether it’s human identities, which are easier to affiliate, or non-human identities that require an extra layer of expertise. Here are some of the top challenges when it comes to managing NHIs:

Crossing all identity sources

Even for advanced and sophisticated cloud services, it’s hard to identify issues outside of the service’s context.

Identifying off-boarded employees

Off-boarded employees with access to organizational resources are a major security threat. Finding these users and understanding which resources are available to them requires a deep understanding of different services and how to put all data together.

Identifying poorly installed integrations

Many services offer SAML SSO integrations with identity providers. When poorly configured, however, such services can cause rouge identities that are seemingly safe to become potential security threats as they are not properly provisioned.

Dealing with complex identity architectures

Some services suggest challenging identity structures without a way to distinguish between human users and service accounts. Yet the need for programatic access still exists. This access results in many “service accounts” with high privileges using weak authentication methods.

Ownership, usage and dependencies

The hardest part of monitoring NHIs is not knowing who is in charge of those entities.

1. Who created them - the answer is usually pretty straight forward.
2. Who maintains them - the creator of a specific resource is not necessarily the person who maintains ownership over the identity, it is harder to determine who is the right human to contact in case of trouble.
3. Operations that depend on them - even after mapping all identities, it’s hard to understand the chain effect that an action could have on the rest of an environment.

Identify risky configurations / not using best practices

As mentioned before, there were many ways to prevent the Snowflake attack. A single platform that centralizes and prioritizes all identity issues helps dealing with this problem.

• According to our customers data, over 90% of service accounts don’t use an RSA key and are de facto users with no MFA or any other authentication factor.
• Even for organizations that enforce network policies for specific users, over 50% of users aren’t covered. Enforcing an account network policy  or making sure that admin privileged users are covered helps minimize the attack surface significantly.

The Need for a NHI Security Solution

Current solutions are insufficient - lacking full visibility, human ownership and identity usage.

With Token Security you can ensure your human and non-human Snowflake identities are properly managed and well aligned with security best practices, while eliminating the risk of compromised identities and ensuring coverage against any data leakage risk.

Here’s how Token secures non-human identities:

• Full Identity Visibility - Automatically discover all human and non-human identities, differentiate between human users and service accounts, and identify the authentication methods they use. Understand the ownership and maintenance of each identity, and gain insights into the permissions associated with each identity to assess risks and determine their usage purposes. This information helps in mapping and prioritizing potentially risky identities.
• Security Posture - Consistently apply best practices by highlighting users who can bypass the IDP, identifying users without network restrictions or MFA, and detecting inactive users.
• Lifecycle Management - De-provision outdated identities, rotate long-standing credentials, manage keys for identities created by former employees, ensure proper permission assignments, and safeguard critical data, including PII.

‍