Stay up to date with Pomerium news and announcements.
Everyone’s taking the wrong lessons from the Snowflake breach. Adding multi-factor authentication helps, but that’s just the tip of the iceberg. It’s somewhat similar to saying “let’s not light a match around those oil spills” without anyone asking “so why are there so many oil spills?”
Or what a hacker’s takeaway was: even well-known companies have internal systems vulnerable to stolen credentials!
What happened?
Before we jump into the takeaways, let’s quickly summarize what happened.
In late May 2024, a cyberattack on Snowflake, a cloud data warehousing platform, compromised the sensitive customer data of several of its clients. This exposed over 165 companies, resulting in several high-profile hacks traced back to the incident: AT&T’s massive data breach, Ticketmaster, Santander, and more companies have publicly confirmed their own data breaches as a result of the Snowflake incident.
The threat actor, UNC5537, advertised the data for sale in a cybercrime forum, claiming to have breached Snowflake. Investigations revealed that the breach was likely facilitated by a compromised machine used by a Snowflake sales engineer. The hackers exploited unencrypted usernames and passwords stored on the machine and in a project management tool called JIRA. They then used these stolen credentials in a credential-stuffing attack to gain access to customer databases. None of the affected accounts had multi-factor authentication (MFA) enabled, making it easier for the hackers to infiltrate.
SourceDiagram from Mandiant: https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
More importantly, Snowflake breach has exposed multiple problems beyond the basic requirement of adding multi-factor authentication (MFA) to everything.
Lack of context-aware access: Correct user credentials alone shouldn’t have given such a degree of access, particularly since the access should have been flagged as anomalous and risky.
The Perimeter Problem: Compromised credentials allowed for a breach in customer networks, but the attack vector shouldn’t have been utilized for such a degree of lateral movement.
Third-party and beyond breaches: We are reminded yet again that third-party vendor breaches can result in spillover effects putting organizations at risk.
“Add MFA to everything!” as a takeaway doesn’t go far enough to address the fundamental cause of the breach. The breaching of over 165 companies from mere credential stuffing attacks showcases how modern networking infrastructure is unprepared for the current threat landscape.
Identity without context is meaningless
Identity-only access is unreliable. Context is everything.
According to Google’s Threat Horizons Report, weak or no credentials made up almost half of initial access vectors for the first half of 2024.
SourceSource: Google Cloud’s Threat Horizons Report
The National Institute of Standards and Technology's (NIST) Zero Trust Architecture (SP 800-207) emphasizes the importance of context to achieve zero trust architecture with granular access control security policies for apps based on attributes such as user identity, location, device security status, and IP address. Even if zero trust architecture isn’t the goal, companies should leverage contextual data in their access control decisions.
Modern security systems must go beyond simply verifying credentials; they should evaluate the context in which access is requested. This includes factors like the user’s location, the device being used, and the typical behavior patterns of the user. Even trusted internal users can do irreparable damage when their incentives become misaligned with the company’s goals.
Even if Snowflake hadn’t been breached, these companies were still at risk given the ease of which the hackers exfiltrated data. The cause for compromised credentials just happened to be Snowflake this time, but the true root problem lays in how each of these companies set up their network infrastructure.
Plus, “the compromised accounts did not have network allow-lists in place” so these companies were completely blind to the fact that the compromised credentials were logging in from untrusted networks. If a privileged account suddenly exhibits contextual anomalies when logging in — such as accessing from North Korea — shouldn’t the system have questions?
"It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted.”
The Snowflake incident underscores the inherent weakness of perimeter-based security models: once attackers bypass the perimeter defenses, they often find it relatively easy to move laterally within the network. In the case of the 165 companies affected by this breach, it's only logical to believe that many of them are still at risk. If they didn't have the Perimeter Problem, a compromised credential would have gone nowhere in their systems.
This problem will persist for some time because companies have yet to adapt an application-centric security model from their existing network-centric models.
Network segmentation is a Sisyphean task better replaced with mutual authentication and application-centric security approach.
The network-centric approach is similar to building paved roads for all vehicles to drive on, whereas the application-centric approach is applying armor to each of your services so they are safe anywhere, even in exposed environments.
Ideally, utilize both network-centric and application-centric approaches. If resources are limited, you are better off with just application-centric approaches.
Third-party and beyond breaches
We are reminded yet again that hosted vendor solutions are an easy target, resulting in large data breaches with spillover effects putting organizations at risk. For Snowflake, the breach happened because a third-party contractor’s access was compromised. For the compromised parties, the backstory to this saga is un-nerving because it was caused by a third-party vendor working for their contracted third-party vendor (in this case, Snowflake).
Our take is that companies don’t talk about the unnecessary expansion of data boundaries. Snowflake’s breach has brought this problem back into the limelight: you can’t control what other companies are doing when connecting your infrastructure and hosting your company's treasures on their servers. When you hitch your wagons together so closely, your most closely guarded data is at risk.
This is why cybersecurity companies like ExtraHop use Pomerium:
As a plus, it’s self-hosted so the Pomerium team cannot mess with your instance. SaaS-based Zero trust services must by design decrypt your traffic to provide functionality, meaning you are trusting them as a MITM. We want our traffic, our secrets, our authentication cookies to be protected even from our vendors. Our security is in our hands, using a reliable product.
Bri Hatch, Senior Director of IT Operations at ExtraHop
As a result, many companies have approached Pomerium to explore how Pomerium can insulate them from similar breaches. As a self-hosted reverse proxy, Pomerium is purpose-built for context-aware access without compromise, being the only solution on the market capable of the factors discussed above.
Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result is:
Easier with clientless access.
Faster by being tunnel-free and deployed where your apps and services are.
Safer because every single action is verified before allowed to execute.
Tailored to your organization’s needs by integrating all data for context-aware access.
