More than a month has passed since the spate of data thefts from Snowflake environments, and the full scope of the incident is becoming clearer, with at least 165 victims, over 500 stolen credentials, and suspicious activity linked to known malware from nearly 300 IP addresses.
In June, the cloud data services provider backed away from the incident, pointing to a cybersecurity investigation report published by incident response providers Google Mandiant and CrowdStrike. 165 Snowflake customers They may have been affected by credentials stolen by information-stealing malware. In a June 2 update, Snowflake confirmed that it had found no evidence that vulnerabilities, misconfigurations, breaches, or stolen employee credentials led to the data breach.
“[E]”All incidents responded to by Mandiant related to this campaign were traced back to compromised customer credentials,” Google Mandiant said.
Snowflake urged customers to ensure multi-factor authentication (MFA) is in place on all accounts, to create network policy rules to limit IP addresses to known and trusted locations, and to reset their Snowflake credentials.
However, these measures Not EnoughExperts say: Companies need to be aware of how their SaaS resources are being used and not rely on users choosing security over convenience.
“When you build a system that assumes humans will never fail, it’s a really bad system,” says Glenn Chisholm, co-founder and chief product officer at SaaS security provider Obsidian Security. “Good engineers design systems that assume humans will fail.”
Here are some additional defenses that security teams should consider to detect security failures in Snowflake and other SaaS cloud services.
1. Collect account data and analyze it regularly
Security teams must first understand their SaaS environment and monitor changes in that environment. In the case of Snowflake, the Snowsight web client can be used to gather data about user accounts and other entities (such as applications and roles) and the permissions granted to those entities.
Deployment situations can quickly become complicated. For example, Snowflake has five different administrative roles that customers can provision, according to SpecterOps: Analyzing Snowflake’s Potential Attack Vectors.
Snowflake’s access graph can become complex quickly. Source: SpecterOps
And because companies tend to over-provision roles, attackers can gain capabilities through non-admin roles, said Jared Atkinson, chief strategist at SpecterOps.
“Administrators tend to grant access to resources more easily or give users a little more access than they need — think admin access instead of write access,” he says. “This might not be a big issue for one user and one resource, but over time as your business scales, it can become a big burden.”
Query User with password set By reviewing the login history where an authentication factor was used — rather than preventing password-based authentication by setting the Password value to False — you may be able to detect suspicious or risky user accounts.
2. Provision user accounts through your identity provider
Because modern business infrastructure is increasingly based in the cloud, companies must, at a minimum, integrate a single sign-on provider for all employees to manage identity and access to cloud providers. Without that level of control — being able to quickly provision and deprovision employees — the traditional attack surface will continue to plague companies, says Obsidian’s Chisholm.
Additionally, companies need to ensure that SSO is properly configured to allow secure connections through strong authentication mechanisms, and just as importantly, older methods should be disabled and any applications that allow third-party access should at least be monitored, he says.
“An attacker could add a username and password to the credentials, add credentials through a service account, and then be able to log into that service account, and nobody was monitoring that,” Chisholm said. “Nobody was monitoring the third-party access accounts, the third-party connections… But all of these interconnections, plus all of the connections that developers make, add up to an incredible surface area that can be breached.”
Snowflake Supports Cross-Domain Identity Management Systems (SCIM) Allows SSO services and software — The company Specifically, Okta SCIM and Azure AD SCIM are mentioned. — Manage Snowflake accounts and roles.
3. Find a way to limit the explosion radius when invading
The data breach caused by Snowflake’s complex security configuration could ultimately rival or even surpass past breaches. At least one report has said: 500 legitimate credentials found Taking measures such as limiting or preventing access from unknown Internet addresses to Snowflake’s online services can help limit the impact of stolen credentials and session keys. In its latest update on June 11, Snowflake 296 suspicious IP addresses associated with information stealing malware.
SpecterOps’ Atkinson says it’s important to find other ways to limit attack vectors to sensitive data.
“We know from experience and the details of this incident that there is limited ability to reduce the attack surface, as credentials were likely stolen from a contractor’s system and access to that system could circumvent all of Snowflake’s recommendations,” he said. “Some attackers will still get through. Attack path controls significantly limit an attacker’s ability to access and have an effect on resources.”
Network policies allow you to block unknown internet addresses while allowing known IP addresses to connect to your Snowflake account. Snowflake Documentation.