Thought Leadership

An Avalanche of News About Snowflake Security

Written By
Jonathan Sander
Published On
Jun 17, 2024

If you’re at all connected to the Snowflake ecosystem (or maybe even if you’re just keeping up with tech news), you’ve seen the news about Snowflake. Right away, let’s put the two right things in front of you: 

  1. The official Snowflake statement about this on the Snowflake Community site.
  2. Mandiant’s (IMHO excellent) summary of the RCA for this attack.

If you’ve heard nothing about all this and you read those two things, then you may not need to finish this article. If you don’t want to read all that (but you really should) and you need a summary, you can hardly do better than Mandiant’s diagram about the attack path: 

Figure 1: Mandiant’s Attack Path Diagram about the UNC5537 attack on Snowflake (source: https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion)

However, it’s likely you’ve seen a few other articles out there. Many of these are not as well anchored in the facts and findings of the investigations. I won’t be giving you links to those types of articles. Suffice to say that the maxim “if it bleeds it leads” is strongly ruling the narratives of many of the pieces being written about this. This is not only creating a lot of useless noise, it’s also clouding the process of getting Snowflake customers the help they need. Of course, the bad guys really don’t care about that last part. 

What we’re going to focus on here is one of the most sensationalized parts of this. Much was made of the fact that one credential in the ocean of stolen credentials happened to belong to an ex-Snowflake employee. The stories tried to make it seem like that specific credential led to accessing some internal systems that were the key to breaking into the rest. That is not what’s reported as the attack path. The Mandiant piece will hopefully put that to rest completely. However, there was one important thing that got lost in the talking points. They had a complete set of user credentials which included access to internal Snowflake business systems, but ultimately they couldn't get into any of the Snowflake systems where those credentials had access. Why is that? 

You should have two important hints about why Snowflake systems were so well protected. First, this piece is appearing on the Beyond Identity blog! Second, it’s being written by the guy who made the first introduction for Beyond Identity and Snowflake 5 years ago. Protecting identities is foundational to protecting data. Snowflake has been using device trust as part of their secure identity healthy breakfast in production for over 3 and a half years. From the start, Snowflake knew it was going to have to hold itself to a different standard. You can see that in the always encrypted by default storage and transmission of data and other security related pieces built into the architecture of the product since day one. But they also knew it meant operating the systems in a security forward way, too. That’s why it was clear that a partnership with the then bleeding edge device trust from Beyond Identity was a clear fit. It wasn’t enough to have a strong credential and MFA. Snowflake needed more, and Beyond Identity gave them a key component (pun intended) of the defenses that kept that sensationalized stolen employee password storyline from having a tragic ending.

At the time of this writing, there is still more coming to light about the impacts of the UNC5537 attack. You will hear more from the good guys now as they have more facts from the investigation to share that are verified and helpful. You will also hear more from folks whose job it is to bait clicks and feed drama. If you’re a Snowflake customer, you should take the actions directed by the official Snowflake guidance as soon as you possibly can. At Snowflake Summit last week, Seth Youssef (Global Field CTO @ Snowflake for Data Security, Privacy, & Governance) said “passwords are bad!” on stage no less than 50 times. He and the rest of my old teammates are very happy to help make all the guidance clear and actionable if you need - just ask your Snowflake rep to put you in touch with your friendly, neighborhood security architect. (A team with skills that not many vendors even invest in having, and Snowflake has been offering to customers for free since 2018.) Remember that the worst thing you can do when skiing in an avalanche is panic. There are people at Snowflake who want to help you keep going smoothly and safely. And who knows, if they advise you to look into better ways to protect your identities, maybe you can look into the tricks they use themselves and give Beyond Identity a call. They’re happy to help you, too.

Get started with Device360 today
Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.

An Avalanche of News About Snowflake Security

Download

If you’re at all connected to the Snowflake ecosystem (or maybe even if you’re just keeping up with tech news), you’ve seen the news about Snowflake. Right away, let’s put the two right things in front of you: 

  1. The official Snowflake statement about this on the Snowflake Community site.
  2. Mandiant’s (IMHO excellent) summary of the RCA for this attack.

If you’ve heard nothing about all this and you read those two things, then you may not need to finish this article. If you don’t want to read all that (but you really should) and you need a summary, you can hardly do better than Mandiant’s diagram about the attack path: 

Figure 1: Mandiant’s Attack Path Diagram about the UNC5537 attack on Snowflake (source: https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion)

However, it’s likely you’ve seen a few other articles out there. Many of these are not as well anchored in the facts and findings of the investigations. I won’t be giving you links to those types of articles. Suffice to say that the maxim “if it bleeds it leads” is strongly ruling the narratives of many of the pieces being written about this. This is not only creating a lot of useless noise, it’s also clouding the process of getting Snowflake customers the help they need. Of course, the bad guys really don’t care about that last part. 

What we’re going to focus on here is one of the most sensationalized parts of this. Much was made of the fact that one credential in the ocean of stolen credentials happened to belong to an ex-Snowflake employee. The stories tried to make it seem like that specific credential led to accessing some internal systems that were the key to breaking into the rest. That is not what’s reported as the attack path. The Mandiant piece will hopefully put that to rest completely. However, there was one important thing that got lost in the talking points. They had a complete set of user credentials which included access to internal Snowflake business systems, but ultimately they couldn't get into any of the Snowflake systems where those credentials had access. Why is that? 

You should have two important hints about why Snowflake systems were so well protected. First, this piece is appearing on the Beyond Identity blog! Second, it’s being written by the guy who made the first introduction for Beyond Identity and Snowflake 5 years ago. Protecting identities is foundational to protecting data. Snowflake has been using device trust as part of their secure identity healthy breakfast in production for over 3 and a half years. From the start, Snowflake knew it was going to have to hold itself to a different standard. You can see that in the always encrypted by default storage and transmission of data and other security related pieces built into the architecture of the product since day one. But they also knew it meant operating the systems in a security forward way, too. That’s why it was clear that a partnership with the then bleeding edge device trust from Beyond Identity was a clear fit. It wasn’t enough to have a strong credential and MFA. Snowflake needed more, and Beyond Identity gave them a key component (pun intended) of the defenses that kept that sensationalized stolen employee password storyline from having a tragic ending.

At the time of this writing, there is still more coming to light about the impacts of the UNC5537 attack. You will hear more from the good guys now as they have more facts from the investigation to share that are verified and helpful. You will also hear more from folks whose job it is to bait clicks and feed drama. If you’re a Snowflake customer, you should take the actions directed by the official Snowflake guidance as soon as you possibly can. At Snowflake Summit last week, Seth Youssef (Global Field CTO @ Snowflake for Data Security, Privacy, & Governance) said “passwords are bad!” on stage no less than 50 times. He and the rest of my old teammates are very happy to help make all the guidance clear and actionable if you need - just ask your Snowflake rep to put you in touch with your friendly, neighborhood security architect. (A team with skills that not many vendors even invest in having, and Snowflake has been offering to customers for free since 2018.) Remember that the worst thing you can do when skiing in an avalanche is panic. There are people at Snowflake who want to help you keep going smoothly and safely. And who knows, if they advise you to look into better ways to protect your identities, maybe you can look into the tricks they use themselves and give Beyond Identity a call. They’re happy to help you, too.

An Avalanche of News About Snowflake Security

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

If you’re at all connected to the Snowflake ecosystem (or maybe even if you’re just keeping up with tech news), you’ve seen the news about Snowflake. Right away, let’s put the two right things in front of you: 

  1. The official Snowflake statement about this on the Snowflake Community site.
  2. Mandiant’s (IMHO excellent) summary of the RCA for this attack.

If you’ve heard nothing about all this and you read those two things, then you may not need to finish this article. If you don’t want to read all that (but you really should) and you need a summary, you can hardly do better than Mandiant’s diagram about the attack path: 

Figure 1: Mandiant’s Attack Path Diagram about the UNC5537 attack on Snowflake (source: https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion)

However, it’s likely you’ve seen a few other articles out there. Many of these are not as well anchored in the facts and findings of the investigations. I won’t be giving you links to those types of articles. Suffice to say that the maxim “if it bleeds it leads” is strongly ruling the narratives of many of the pieces being written about this. This is not only creating a lot of useless noise, it’s also clouding the process of getting Snowflake customers the help they need. Of course, the bad guys really don’t care about that last part. 

What we’re going to focus on here is one of the most sensationalized parts of this. Much was made of the fact that one credential in the ocean of stolen credentials happened to belong to an ex-Snowflake employee. The stories tried to make it seem like that specific credential led to accessing some internal systems that were the key to breaking into the rest. That is not what’s reported as the attack path. The Mandiant piece will hopefully put that to rest completely. However, there was one important thing that got lost in the talking points. They had a complete set of user credentials which included access to internal Snowflake business systems, but ultimately they couldn't get into any of the Snowflake systems where those credentials had access. Why is that? 

You should have two important hints about why Snowflake systems were so well protected. First, this piece is appearing on the Beyond Identity blog! Second, it’s being written by the guy who made the first introduction for Beyond Identity and Snowflake 5 years ago. Protecting identities is foundational to protecting data. Snowflake has been using device trust as part of their secure identity healthy breakfast in production for over 3 and a half years. From the start, Snowflake knew it was going to have to hold itself to a different standard. You can see that in the always encrypted by default storage and transmission of data and other security related pieces built into the architecture of the product since day one. But they also knew it meant operating the systems in a security forward way, too. That’s why it was clear that a partnership with the then bleeding edge device trust from Beyond Identity was a clear fit. It wasn’t enough to have a strong credential and MFA. Snowflake needed more, and Beyond Identity gave them a key component (pun intended) of the defenses that kept that sensationalized stolen employee password storyline from having a tragic ending.

At the time of this writing, there is still more coming to light about the impacts of the UNC5537 attack. You will hear more from the good guys now as they have more facts from the investigation to share that are verified and helpful. You will also hear more from folks whose job it is to bait clicks and feed drama. If you’re a Snowflake customer, you should take the actions directed by the official Snowflake guidance as soon as you possibly can. At Snowflake Summit last week, Seth Youssef (Global Field CTO @ Snowflake for Data Security, Privacy, & Governance) said “passwords are bad!” on stage no less than 50 times. He and the rest of my old teammates are very happy to help make all the guidance clear and actionable if you need - just ask your Snowflake rep to put you in touch with your friendly, neighborhood security architect. (A team with skills that not many vendors even invest in having, and Snowflake has been offering to customers for free since 2018.) Remember that the worst thing you can do when skiing in an avalanche is panic. There are people at Snowflake who want to help you keep going smoothly and safely. And who knows, if they advise you to look into better ways to protect your identities, maybe you can look into the tricks they use themselves and give Beyond Identity a call. They’re happy to help you, too.

An Avalanche of News About Snowflake Security

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

If you’re at all connected to the Snowflake ecosystem (or maybe even if you’re just keeping up with tech news), you’ve seen the news about Snowflake. Right away, let’s put the two right things in front of you: 

  1. The official Snowflake statement about this on the Snowflake Community site.
  2. Mandiant’s (IMHO excellent) summary of the RCA for this attack.

If you’ve heard nothing about all this and you read those two things, then you may not need to finish this article. If you don’t want to read all that (but you really should) and you need a summary, you can hardly do better than Mandiant’s diagram about the attack path: 

Figure 1: Mandiant’s Attack Path Diagram about the UNC5537 attack on Snowflake (source: https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion)

However, it’s likely you’ve seen a few other articles out there. Many of these are not as well anchored in the facts and findings of the investigations. I won’t be giving you links to those types of articles. Suffice to say that the maxim “if it bleeds it leads” is strongly ruling the narratives of many of the pieces being written about this. This is not only creating a lot of useless noise, it’s also clouding the process of getting Snowflake customers the help they need. Of course, the bad guys really don’t care about that last part. 

What we’re going to focus on here is one of the most sensationalized parts of this. Much was made of the fact that one credential in the ocean of stolen credentials happened to belong to an ex-Snowflake employee. The stories tried to make it seem like that specific credential led to accessing some internal systems that were the key to breaking into the rest. That is not what’s reported as the attack path. The Mandiant piece will hopefully put that to rest completely. However, there was one important thing that got lost in the talking points. They had a complete set of user credentials which included access to internal Snowflake business systems, but ultimately they couldn't get into any of the Snowflake systems where those credentials had access. Why is that? 

You should have two important hints about why Snowflake systems were so well protected. First, this piece is appearing on the Beyond Identity blog! Second, it’s being written by the guy who made the first introduction for Beyond Identity and Snowflake 5 years ago. Protecting identities is foundational to protecting data. Snowflake has been using device trust as part of their secure identity healthy breakfast in production for over 3 and a half years. From the start, Snowflake knew it was going to have to hold itself to a different standard. You can see that in the always encrypted by default storage and transmission of data and other security related pieces built into the architecture of the product since day one. But they also knew it meant operating the systems in a security forward way, too. That’s why it was clear that a partnership with the then bleeding edge device trust from Beyond Identity was a clear fit. It wasn’t enough to have a strong credential and MFA. Snowflake needed more, and Beyond Identity gave them a key component (pun intended) of the defenses that kept that sensationalized stolen employee password storyline from having a tragic ending.

At the time of this writing, there is still more coming to light about the impacts of the UNC5537 attack. You will hear more from the good guys now as they have more facts from the investigation to share that are verified and helpful. You will also hear more from folks whose job it is to bait clicks and feed drama. If you’re a Snowflake customer, you should take the actions directed by the official Snowflake guidance as soon as you possibly can. At Snowflake Summit last week, Seth Youssef (Global Field CTO @ Snowflake for Data Security, Privacy, & Governance) said “passwords are bad!” on stage no less than 50 times. He and the rest of my old teammates are very happy to help make all the guidance clear and actionable if you need - just ask your Snowflake rep to put you in touch with your friendly, neighborhood security architect. (A team with skills that not many vendors even invest in having, and Snowflake has been offering to customers for free since 2018.) Remember that the worst thing you can do when skiing in an avalanche is panic. There are people at Snowflake who want to help you keep going smoothly and safely. And who knows, if they advise you to look into better ways to protect your identities, maybe you can look into the tricks they use themselves and give Beyond Identity a call. They’re happy to help you, too.

Book

An Avalanche of News About Snowflake Security

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Download the book

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.