On June 10, 2024, cybersecurity research and response firm Mandiant published its findings on the ongoing security investigation of stolen customer data.  This news was first broken to the public about Ticketmaster and Santander Bank on May 31, 2024.

Mandiant reports, “Mandiant’s investigation has not found any evidence to suggest that unauthorized access to Snowflake customer accounts stemmed from a breach of Snowflake's enterprise environment. Instead, every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials.”

If there is any relief for Snowflake customers, it’s that Snowflake’s platform itself had not been compromised - which could have led to the exposure of more than 9,000+ customer data sets. Instead, Mandiant is reporting that 165 potential companies were exposed. Why is this good news? This means Snowflake is a safe platform to store and use your data. Like any other cloud-based service, you must take steps to protect your data beyond what the vendor does for you. Understanding what you can do to strengthen your defenses is crucial.

There are many ways to understand how to approach data security in cloud-based SaaS systems. We’ll borrow Gartner’s. The above diagram breaks down the responsibilities of the customer and vendor for IaaS, PaaS and SaaS. Snowflake fits best in the SaaS pilar, and Snowflake’s nine security responsibilities for data and systems are shown in green, indicating they are unaffected by this incident. The two responsibilities in blue, People and Data, remain under the control of Snowflake’s Customers.

Customers are responsible for what data they put in Snowflake, which users they allow access to this data, and how that access is controlled. But Snowflake does not entirely leave the People and Data responsibilities squarely on their customers. They recognize the importance of keeping data safe and have built industry-leading security and governance capabilities that they provide to customers of all sizes. From role-based access controls (RBAC) to dynamic data masking, network access restrictions, and more, Snowflake helps customers with the remaining two security responsibilities of People and Data.

So why did this data exposure happen if Snowflake is fulfilling its responsibilities and assisting customers with theirs?  Managing People, Data, and security is challenging regardless of an organization’s size or maturity. This is where ALTR comes in.

About ALTR

ALTR is a Data Security Platform specifically designed to help customers with their two data security responsibilities. ALTR does two things to help customers manage their People and Data: automate and scale the powerful Snowflake-provided native security and governance capabilities mentioned above and extend Snowflake’s security capabilities with Active Security measures.

‍

For the first part, ALTR can connect to your Snowflake, leverage data classification or Snowflake Object Tagging, and ensure that only authorized users can access data according to company policy. All this happens without writing a single line of code. Your data people don’t have to become security experts, and your security people don’t have to learn SQL. This does not replace the built-in Snowflake capabilities –it depends on them. Snowflake’s enforcement layer is still the engine for applying the advanced ALTR capabilities. This includes RBAC, dynamic data masking and row-access policies, to name a few.

ALTR also provides detailed information and reporting for data and infosec teams to prove they follow data access compliance rules and deliver that reporting in near real-time.

ALTR’s Active Security capabilities are used by Snowflake’s most sensitive and regulated business to ensure Snowflake is safe for PII, PHI,  and PCI information. However, these capabilities are not limited to only large or mature businesses. Active Security can help a small or young company secure one row of customer data in Snowflake.

Active Security includes Database Activity Monitoring, Data Access Rate Limiting (Thresholding), and cell-level data protection in the form of encryption or tokenization.

Database Activity Monitoring

Database Activity Monitoring adds near-real-time logging and alerting capabilities to Snowflake, where Snowflake logging can be delayed as much as four hours after access. ALTR can send data access logs in seconds to security teams for analysis and processing. This dramatic reduction of time is difficult to do at the scale of Snowflake but is necessary to keep the most sensitive data in Snowflake. Customers can be alerted in near-real-time, within seconds of access, to check if these accesses are valid or seem suspicious.

Data Access Rate Limiting, or Thresholding

Data Access Rate Limiting, or Thresholding, is a patent-issued feature exclusive to ALTR which can stop data access in real-time, even with valid credentials. Customers can set a policy indicating how much data a particular user can consume in a period. Once a user reaches their limit, their access to that data is blocked.

No other data access is limited for that user, and no other users are impacted by a single user reaching their limit. Users can log in to Snowflake, but if the limit has been met for the day, no more data will flow to that user. When combined with ALTR’s Database Activity Monitoring, customers can be alerted instantly when a user has reached their limit and decide what to do with that user.

Cell-level Data Protection

Cell-level data protection takes the same type of on-disk data protection that Snowflake provides with Tri-Secret-Secure (TSS) and extends it deeper into the data. The purpose of cell-level protection with encryption or tokenization is to remove the single-party risk of Snowflake holding the data and encryption keys by adding a second (or even third) party to the equation. In this way, compromising a Snowflake user account does not necessarily mean the data can be compromised, making Snowflake safer.

With ALTR’s tokenization or Format-Preserving Encryption Native App, the data or the keys to decrypt the data are stored outside of Snowflake. When authorized users request access to the plain text, Snowflake and ALTR interact in real-time to provide the plain text data. This operates at the scale of Snowflake and uses ALTR’s SaaS platform in the mix.

How Could ALTR Have Prevented Customer Data Exposure?

Customers should follow all recommended Snowflake security best practices for user accounts, such as multifactor authentication and network access limitations for user accounts. But sometimes that’s not enough.

In this case, we have a simple answer to the above question of how ALTR could have helped stop or limit the exposure.

1. Security teams were unable to see the data exfiltration in near real-time. They were limited to the default delays of up to four hours after the data had been stolen. Installing ALTR’s Database Activity Monitor into your Snowflake account and hooking up the output of ALTR’s real-time logs to your email, chat system or SIEM tool would have notified the business to investigate the user accounts immediately. “Why would someone from outside the country be accessing all our customer data at this time of night? We should investigate right away.”

2. Cell-level protection, like ALTR’s FPE Native App, would have rendered the data access useless as the accounts likely would not have been given access to the decryption keys. ALTR’s FPE Native app is format-preserving and deploys determinism – meaning an email will still look like an email, and the protected values remain operational downstream without your users needing to decrypt and see them in plaintext. This means as the bad actors ran SELECT statements over the data, they would have received encrypted data back without receiving the encryption key. This makes data exfiltration useless and is why having a two-party system of data security is so widely used because it's effective.

3. In the case the impacted user accounts did have access to the decryption key by compromising an elevated permission user, ALTR’s Thresholds could have been configured to do two things: alert in real-time when more than 100,000 rows have been accessed by a single user in 1hr for example, and then cut off access to that same data after 500,000 rows of data were accessed by a single user. The user would be authenticated to Snowflake and allowed to access the table, but no data would come out. That impacted user would then be in the ‘penalty box’ without the ability to decrypt information further.

Active Security is the best way to ensure sensitive data is safe in Snowflake no matter what happens. Active Security can detect and stop a breach, not just notify you. All three Active Security features are in GA and running in production across many Snowflake user accounts today. Our product and team focus on one thing only: safeguarding sensitive data.