At ISC2 Congress in October 2025 Vishal Chawla, CISSP, Founder and CEO of BluOcean Cyber, talked about the Snowflake data breach of the previous year and asked: was it really a vendor failure?
In the session Beyond the Snowflake Breach: Why Scattered Spider Loves Your Broken TPRM for SaaS applications (And How to Break Their Grip), Chawla posed this question. And the answer – on the surface at least – was that, yes, it was.
Digging a little deeper, though, it became clear that as with any cloud product or service – in this case a SaaS-based data warehouse platform, the service provider’s security arrangements are only a part of the story.
How It Happened
Chawla took the audience through how the attack was executed, though the answer was entirely predictable: insert some information-stealing malware, find client areas with no multi-factor authentication (MFA), scan for interesting (critical or sensitive) data and then exfiltrate it. The alarm bell here, of course, is the part about client areas without MFA: why would any of the clients whose data was stolen – many of which were big multi-nationals with good-size internal cyber teams – have a SaaS service but not defend it with the most fundamental component of cybersecurity?
The answer: what Chawla called “the shared responsibility blind spot” – namely that although many third-party risk management (TPRM) regimes are thorough and are done well, TPRM only looks at the vendor. The SaaS provider takes care of everything functional – keeping hardware running, ensuring the operating system is patched and updated, fixing application issues and upgrading to new versions – but it is up to the client to do the configuration of the components they control. If the client doesn’t employ MFA, or does not de-provision users when they leave, the vendor can hardly be blamed for data theft.
Machine-to-Machine Risk
The discussion then moved a step further into the SaaS world, to look at instances where SaaS services connect to other SaaS services – particularly where one SaaS service depends on another. The example explored by Chawla was the August 2028 Salesloft Drift attack, in which a trusted platform (Salesloft Drift) that enables integration with Salesforce installations was compromised and used to penetrate a variety of large global organizations. It is easy to set up such connectivity and then simply let it run with no further review. In fact, a live poll of session attendees at Congress revealed that, when it comes to monitoring the growth of connectivity among SaaS systems 58% of those in the room who responded said their organizations had no real visibility; 17% had standard operating procedures and/or continuous monitoring for connections; 8% said they had visibility but didn’t conduct reviews, and none at all said they did quarterly reviews.
Mitigating Risk
Moving on, the question moved to: what shall we do to avoid being victims of SaaS attacks? Chawla began by pointing out a long list of simple actions that would have entirely prevented the Snowflake attack: using good logging to improve log analytics and monitor user behaviors; alerting for mass data uploads; modelling data access; enforcing MFA on all accounts and disabling any mechanism that might enable MFA to be bypassed.
Next was the necessity for the security and application management teams to collaborate more, to provide security expertise to help the application team run their systems more securely.
Control of “SaaS sprawl” was next on the list – that is, accepting that the difficulty of securely managing SaaS implementations grows faster than the actual number of such installations, and so proper governance is required to do it properly. An uncontrolled, poorly managed growth in SaaS in organizations is an impending disaster given that 65% of such solutions are thought to be so-called Shadow SaaS implementations. There is a widespread lack of single sign-on (SSO) in SaaS implementations and a sprawling growth in SaaS sign-ups brings a support skillset requirement that none of us can keep up with. The answer: a proper governance model that begins with a proper strategy, introduces a governance model, deploys tools to help us control everything, deploys new items a few at a time and then wraps everything in a sustainment plan to maintain security over time.
The following item may seem obvious, but in reality, is often forgotten: having a proper, proactive SaaS security architecture. The application itself is just a tiny part of the overall architecture, which also includes fundamental items like privileged access management (PAM), key management, security information and event management (SIEM), security orchestration, automation and response (SOAR), data leakage prevention, and SaaS security posture management (SSPM). The latter is less well-known than the other concepts and is all about continuously monitoring configurations and user activity to ensure it complies with internal policies and industry standards.
Chawla concluded with three key points about the security of SaaS services:
- Traditional TPRM is fundamentally broken for SaaS
- The SaaS risk gap is in our configuration and if we do that poorly then we are asking for trouble
- Continuous monitoring beats annual questionnaires
The results of one of the other interactive polls conducted during the session made for interesting reading. It asked: “If a SaaS breach occurs in your organization, who actually gets blamed?” Nobody said Procurement. 2% had no opinion and another 2% pointed the finger at the Chief Risk Officer. Business Leaders and the TPRM team scored 5% each. In a landslide “victory” that has been an ongoing concern for many years for those in the cybersecurity team: 86% of respondents were of the view that, in their organizations, the blame lies with the CISO.
