Header photo by Kaffeebart on Unsplash
On May 31, 2024, Ticketmaster confirmed a data breach that resulted in the loss of personal information for numerous customers.
Fingers pointing at Snowflake
According to a report by TechRadar, the breach was attributed to a sophisticated cyberattack that targeted Snowflake, a prominent data warehousing company.
Rumors underlined how the attackers exploited vulnerabilities within Snowflake’s systems to gain unauthorized access to sensitive data, leading to significant concerns about data security and privacy.
The involvement of Snowflake in the breach has been a focal point of the investigation. As a major cloud data platform, Snowflake’s security measures are critical to protecting the vast amounts of data it manages for clients like Ticketmaster.
The breach has raised questions about the efficacy of Snowflake’s security protocols and their responsibility in safeguarding customer data.
Snowflake’s response:
Snowflake took the matter seriously, and issued a joint statement with cybersecurity giants CrowdStrike and Mandiant to clarify its position.
A LinkedIn post from the official Snowflake page underlines how the issue was not caused by defects in the Snowflake platform:
Snowflake LinkedIn post about the data breach. Click on the image to join the conversation.
The post links to the official statement by Brad Jones, Snowflake’s Chief Information Security Officer, detailing the preliminary findings from the joint investigation.
Building an armor against data breaches: how we do it at Nimbus Intelligence
At Nimbus Intelligence, we prioritize your data security and implement the recommended best practices to ensure the highest level of protection.
Just as medieval locksmiths forged armor to shield against powerful blows, we use our expertise in Snowflake’s security best practices to safeguard your data from cyber threats and unauthorized access.
Multi-Factor Authentication (MFA):
MFA for users in the account with the ACCOUNTADMIN role adds an extra layer of security beyond just a username and a password.
Snowflake currently supports MFA with the Duo Push app (not to be confused with the green owl from Duolingo), via phone call or via passcode.
This diagram illustrates the overall login flow for a user enrolled in MFA, regardless of the interface used to connect. Click on the image to navigate to the Snowflake Documentation.
Network Policies
We set up network policies to control inbound access to the Snowflake service and internal stage. By blacklisting/whitelisting IP addresses, we can make sure that only allowed users access our client’s Snowflake account.
In his blog, my colleague Feruz explains how to handle common errors related to network policies in the Snowflake account
Network Rules
We utilize network rules as schema-level objects that group network identifiers into logical units.
Snowflake features that restrict network traffic can reference these network rules, which simplifies the management process by avoiding the need to define network identifiers directly within each feature.
A network rule itself does not dictate whether its identifiers should be allowed or blocked; instead, the Snowflake feature that uses the network rule specifies whether the identifiers are permitted or prohibited.
Key-Pair authentication and rotation
To enhance authentication security, we use key-pair authentication as an alternative to basic methods like username and password.
Some supported Snowflake clients allow the use of encrypted private keys for connecting to Snowflake.
We assign the public key to the Snowflake user, enabling secure connections and authentication via the Snowflake client. Additionally, we regularly rotate public keys to meet robust security and governance standards.
Session policies
The default idle timeout value of a session in Snowflake is 4 hours. When this timer expires, the user needs to log in again.
Recognizing that a lot can happen in 4 hours, we reduce this timeout value according to the specific needs and processes of our clients.
The minimum timeout value is 5 minutes, which adds security but can be frustrating due to frequent logins. Striking a good balance between security and usability is key here.
User-level security considerations
Granular role-based access involves creating roles that are specific to business functions (for example, ANALYST). Each of these roles must have the appropriate privileges on the objects they need to use. For example, we would grant SELECT privileges on the marts tables/views to the ANALYST role.
One of the most important considerations is to avoid the use of broad privilege grants. Typing “GRANT ALL PRIVILEGES” is certainly easier than selecting specific privileges in detail. However, it is less secure in terms of controlling access to data. We do not want all users to be capable of seeing all data stored in Snowflake.
Row access policies
In some cases, access to specific rows of data must be restricted based on user roles or attributes. This can include sensitive information like financial records or healthcare data that should only be visible to certain users.
For this reason, we implement row access policies to control which rows of data are accessible to each user. This allows us to ensure that only authorized users can view sensitive information while others can access the data they need without seeing restricted details. For example, a policy might allow only finance team members to access financial records, while other departments see aggregated data instead.
Column-level security: Dynamic data masking
In some cases, the developers themselves are not allowed to see certain data. This could include names, email addresses, home addresses, or other highly sensitive information. Despite that, they may need to include the fields for a user that can access personal data.
For this reason, we implement data masking before querying the data. This allows us to access the necessary data to perform our job without viewing information that our clients do not want us to see.
Hire an Analytics Engineer
Nimbus Intelligence offers the option to engage our Analytics Engineers, expediting access to pertinent data for your business intelligence needs. Our services encompass both remote and on-site collaborations.
Presently, we have offices in Amsterdam, Milan and Madrid. Connect with us to know more.
