Snowflake customers' misperceptions on who owns identity security in the cloud

Details are continuing to emerge daily on the hacking of Snowflake customers who have had their data stolen in what is shaping up to be one of the most significant attacks in years. So far, at least 165 of Snowflake’s customers, including household names like Ticketmaster, Santander Bank, and Advanced Auto Parts, have been identified as having their data impacted in this incident. 

While initial reports indicated that Snowflake itself had been hacked, with some evidence pointing to a former employee’s demo account having been compromised, this attack was actually far more interesting because of what it tells us about the current state of security in the cloud.

In the post below, we cover what we know so far, explore some misconceptions about cloud security, and offer a couple of useful tips for how to reduce your risk moving forward.

Mandiant’s Initial Findings

On June 10, the investigators over at the top-tier incident response outfit Mandiant released their initial report, bringing some much-needed clarity to what has been a whirlwind of rumors up until this point. 

In mid April, the first indications that Snowflake’s customers’ instances were being compromised started popping up. However, contrary to some of the initial reports, the instances were not being hacked because of any misconfigurations or vulnerabilities in Snowflake itself.

The attackers were simply using compromised credentials to log into their targets’ accounts in Snowflake. 

These credentials appear to have been collected by a combination of use of infostealer malware installed on victims’ devices and just combing the dark web forums for exposed credentials.

Perhaps unsurprisingly, according to analysis by Mandiant and Snowflake, at least 79.7 percent of the credentials that were used in this case had previously been exposed. 

So by the looks of Mandiant’s report, this was less of a ninja commando op leveraging 3l33t TTPs as it were, and more like the security guard getting run over by a steamroller in the first Austin Powers movie.  

It also says more about how many appear to have missed some of the fine print on their cloud transformation path and where we have some serious gaps to close on the way to using them securely. 

Who Owns Security in the Cloud?

Chances are that the team at Snowflake is right and that their product was just working as intended. 

With the right set of credentials and associated access privileges, anyone can access sensitive resources in the cloud. That’s what makes the cloud so great for productivity and flexibility.

It’s also what makes it so difficult and risky to manage.

In the cloud, customers are responsible for managing their identities and access. The cloud service providers play little to no role in ensuring that your resources are secure. Basically what they provide is the framework and tools to help your team secure your resources. 

This is where it starts to get challenging because in the cloud:

• You are using multiple service providers, each with their own Identity and Access Management (IAM) system that has its own specific terminology and specificities
• The number of identities across all your cloud services is constantly growing, becoming impossible to manage manually
• Understanding who has access to which resource and what their privileges are can feel like staring into a black box

AWS, MongoDB, Snowflake, GitHub, and others frankly do not know who in your organization needs access to what, for how long, if they should be an admin, or one of the many other parameters that need to be set by your team. 

They intentionally, and perhaps correctly, leave it up to you to manage. 

The Problem with Standing Privileges

Beyond the use of credentials in this incident, the other detail that everyone seems to have glommed onto is that the attackers took their list of credentials and then found the accounts in Snowflake that only had single-factor authentication, ie. no MFA enabled.  

Snowflake is going to have to answer the growing clamor around why it allows customers to open up accounts on their service that hold sensitive data without requiring MFA.

But the real question to be asking here is why was there open-ended access to all this sensitive customer PII?

It would make sense that low-risk resources that do not contain PII and are needed with great frequency can be accessible around the clock to an authenticated user. But shouldn’t we be managing more sensitive data with greater care? Granting access only for specific time periods and scope that fit our risk model?

Standing privileges should be treated as a risk, with each one carefully evaluated to understand if the juice is worth the squeeze. Or at least won’t get too messy if it pops.

The challenge for many organizations is they assume that they face a choice between productivity (ie. having quick access to a resource) and security (blocking access to said resource).

Thankfully, this is actually mostly a misconception.

Automate Secure Access with Just-in-Time and Just-Enough Privilege Provisioning

It is true that manually granting access privileges to resources is time-consuming and a stumbling block to productivity. 

The delta between the time it takes from requesting access to the time it is granted can quickly grow to a very expensive and unappealing option for security teams to come to their leadership with since it means that less is getting produced. 

Then there is the challenge of remembering to revoke said privilege at the end of the desired period, which is also a real risk and pain to be reckoned with.

However, by adding smart automation to the process, shifting over to a Just-in-Time (JIT) approach can be part of the solution. 

The idea here falls under the Least Privilege Principle that calls for only granting users the access privileges they need to get the job done and for the length of time that they actually need it.

For example, a developer may only need access to production for an hour or two a few times a month. 

So the JIT approach would call for removing the developer’s standing access privileges to production (which I hope are not currently available), and creating a predefined policy based on user and resource contexts that allows that dev scoped access upon request for the allotted time. 

This approach gives the developer the access he or she needs while cutting down the standing access from 730 hours a month on average to maybe 10. Thus reducing the opportunities for abuse.

The second part comes to reducing what the developer can do with their access by implementing a Just-Enough Privilege approach. 

This starts with understanding: 

• What does a user actually needs to get their work done?
• How are they using their access privileges?
• What is the potential risk from giving a user privileges? 

Once we have the proper context in hand, we can start to make decisions like if can they make changes with an edit privilege or should simply being able to have read access privileges that are less risky.

The key is that JIT and JEP are two sides of the same coin, with both relying on relevant context to drive appropriate access privilege provisioning. They also go hand-in-hand with each other as part of privileged access management strategy, closing security gaps 

And in order for this all to be an efficient process that powers the business instead of tholding it back, we need to manage it all automatically.  

By automating the process, we are able to: 

• Save the time that the developer would have had to wait for the access request to be approved and manually provisioned
• Provision tightly scoped access privileges according user and resource context, avoiding blindly excessive privileges
• Ensure that the access is revoked at the end of the approved use, reducing sprawl and lowering risk from a privilege remaining open-ended
• Reduce the risk that a malicious actor (or insider threat) could abuse standing privileges if the developer’s credentials are compromised
• Remove human approver interaction for the vast majority of lower risk requests, allowing managers to focus on approvals to crown jewel resources that require their attention

With the benefits of automating JIT and JEP being fairly clear, we also need to change our perception of how we go about defining what needs to be secured and how.

Tips for Securing Cloud Resources

Clever attackers can often find a way around decent protections. But there are still plenty of ways that we can deny them an easy win.

Here are a few tips on how to become a harder nut to crack.

Enable MFA Everywhere -- This is becoming a bit harder in the world of non-human identities, but start with getting this right for your users with a pulse and you can cause many attackers to look for greener pastures.

Reduce Your Access Risk -- Remove standing privileges to resources that you would have a bad day if they were compromised. Think PII, source code, production, etc. Implement JIT and look to see where you can also reduce privileges via JEP so that the blast radius of compromised credentials can be minimized.

Audit and Alert on Suspicious Access -- As cliche as it may sound, identity and access are the new perimeter. So it is worth specifically keeping track of access requests and what users are doing with said access. This monitoring can pay dividends when you have to respond to an incident. Additionally, monitor for suspicious access requests that don’t fit your expected contexts as they may be a malicious actor snooping around and attempting to reach something sensitive.

Looking to a Future Without Credentials

While many are awaiting a passwordless future, the best practice calls for rotating credentials somewhat regularly so that old ones compromised in the past cannot be used in attacks moving forward. However, rotating say quarterly can still leave open challenges both from a usability side with your users and leave open a months-long window that compromised credentials can be abused.

For the nearer term, we need to consider ephemeral credentials that are tied to the identity of the user but last for only as long as the JIT access is granted. Think of it like the one time password (OTP), but far more dynamic and secure since it evaporates after use.

So long as there are credentials to be used for accessing resources, hackers are going to abuse them. It is up to us to take away the low hanging fruit that can make their path to our data too easy.

Rom Carmel is Co-Founder and CEO, Apono.