The Domino Effect: A Look at Recent SaaS Breaches
It's tempting to think that when you entrust your data to a multi-billion dollar SaaS provider, the security burden is entirely on them. We pay for the service, and in our minds, they take care of everything. The reality, however, is a much more complex and, frankly, a more uncomfortable truth. Recent events have shown that a compromise in one SaaS application can trigger a supply chain attack, creating a domino effect that impacts hundreds of unsuspecting organizations.
The Salesloft Drift & Salesforce Supply Chain Attack
This incident is a prime example of a supply chain attack that exploited a trusted third-party integration. Between August 8 and August 18, 2025, a threat actor tracked by Google as UNC6395 gained unauthorized access to hundreds of customer instances on Salesforce. The attackers didn't exploit a vulnerability in Salesforce itself, but rather leveraged compromised OAuth tokens from the Salesloft Drift third-party application. These tokens, which grant trusted access to customer systems, were used to bypass traditional authentication.
Who was affected? The attack spree impacted over 700 organizations, including major cybersecurity and technology firms such as Cloudflare, Zscaler, Palo Alto Networks, and PagerDuty. This was not a small-scale phishing campaign but a widespread, systematic data theft operation.
What was compromised? The threat actor methodically ran queries to exfiltrate large volumes of data from various Salesforce objects, including Accounts, Contacts, Cases, and Opportunities. Their primary goal was to harvest credentials, such as AWS access keys, passwords, and Snowflake-related access tokens, that had been inadvertently stored within support cases or other records. For example, Cloudflare confirmed that 104 internal tokens were exposed through support case notes, which the attackers exfiltrated in a matter of minutes.
The Snowflake Data Breaches
In mid-2024, a series of data breaches affected over 160 customers of Snowflake, a popular cloud data platform. The attack, attributed to a financially motivated group known as UNC5537, was not the result of a vulnerability in Snowflake's core system. Instead, the attackers used credentials stolen via infostealer malware from third-party systems to log into customer accounts directly.
Who was affected? The list of victims reads like a who's who of global business, including Ticketmaster, Santander Bank, AT&T, and Advance Auto Parts.
What was compromised? The breaches led to the theft of millions of records, including personally identifiable information (PII) like names, addresses, and credit card information. The root cause in many of these cases was a critical security misconfiguration: a lack of multi-factor authentication (MFA) on the compromised accounts.
Other Notable Incidents
The trend of SaaS breaches extends beyond these two high-profile cases. In April 2024, the Dropbox Sign service was breached, with a threat actor accessing customer data including email addresses, usernames, and hashed passwords. The attacker gained access through a compromised service account with elevated privileges, highlighting the risks of poor privilege management. Similarly, in December 2024, a compromised API key for BeyondTrust's Remote Support SaaS product was used to reset local application passwords and gain access to certain customer instances.
The Local Context: SaaS Breaches in Southeast Asia
The problem isn't confined to a global stage; it is happening right here in our backyard, impacting our own digital ecosystem. According to an analysis by Positive Technologies, Southeast Asia experienced twice as many cyberattacks in 2024 as in the previous year. The rapid pace of digital transformation, coupled with a booming digital economy, has made the ASEAN region a prime target for cybercriminals.
-
The Indonesia National Data Center Ransomware Attack: In June 2024, Indonesia's National Data Center was hit by a sophisticated ransomware attack that used the Brain Cipher variant of LockBit 3.0. This wasn't a SaaS app in the traditional sense, but a government-run data center providing services to over 230 public agencies. The attack brought critical government services, including airport immigration processes, to a standstill and resulted in the loss of data for some agencies that had not backed up their information.
-
The Singapore Malware Surge: The Cyber Security Agency of Singapore (CSA) reported a 67% spike in malware infections in 2024, with most incidents linked to users failing to patch vulnerable software. While this is a broader cyber threat, it is a significant factor, as compromised endpoints are a common entry point to access sensitive SaaS applications.
-
Widespread Ransomware: Beyond specific incidents, the sheer volume of attacks is concerning. In 2024, businesses in Southeast Asia faced an average of 400 attempted ransomware attacks every single day. Indonesia, Vietnam, and the Philippines were among the most targeted countries, with a significant number of these attacks aimed at manufacturing companies, government institutions, and financial organizations.
These regional events serve as a potent reminder that our digital advancements must be matched by a corresponding investment in security. The data is clear: the threat landscape is not abstract; it is a tangible and growing risk to our regional economy and national security. The next section will dive deeper into the myths and misconceptions that continue to fuel this vulnerability.
Debunking the Myths: SaaS Security vs. Shared Responsibility
The common narrative that SaaS applications are "inherently secure" because they are managed by tech giants is, at best, a dangerous oversimplification and, at worst, a complete fabrication. The recent breaches prove this. What many organizations fail to grasp is the shared responsibility model, a fundamental concept in cloud computing that defines a clear line of demarcation between the provider's duties and the customer's. While the provider secures of the cloud, the customer is responsible for security in the cloud. Let’s break down the most persistent myths.
Myth 1: My SaaS Provider Secures Everything.
This is perhaps the most damaging misconception. Businesses assume that by moving to a SaaS solution, they are offloading the entire security burden. They are not. The SaaS provider's responsibility is to secure the underlying infrastructure, including the physical data centers, the servers, and the application's core code. However, as the customer, you are solely responsible for securing your data, configuring access controls, and managing user identities.
Reality: The provider ensures the software is running and patched, but you are responsible for how you use and configure it. For instance, a misconfigured sharing setting in a Google Drive folder can expose thousands of sensitive documents, and that is a failure on the customer's side, not Google's.
Myth 2: Compliance Certificates (e.g., SOC 2, ISO 27001) Equal Total Security.
Many organizations feel a false sense of security when their SaaS provider boasts a SOC 2 or ISO 27001 certification. It's an important baseline, but it is not a shield against all threats.
Reality: Certifications are a snapshot in time; they verify that the provider's processes and controls meet certain standards during an audit. They do not guarantee continuous security against a constantly evolving threat landscape, nor do they cover every possible attack vector like zero-day vulnerabilities or sophisticated phishing campaigns. A compliant system can still be breached if the customer fails to manage user permissions or secure third-party integrations, as seen in the Salesloft Drift incident.
Myth 3: Misconfigurations are Minor Issues.
Many see misconfigurations as small, technical glitches rather than critical security flaws. The reality is they are the low-hanging fruit for attackers and are often a primary cause of data breaches.
Reality: A simple misconfiguration, such as a publicly accessible API key or an overly permissive user account, can be the very first step in a catastrophic breach. These errors often occur because of "fragmented ownership and administration by business units" within a company, leaving security gaps that attackers can exploit.
This shared responsibility model is not a new concept; it has been a core principle of cloud security from the beginning. The recent breaches simply serve as a painful, public lesson in what happens when we ignore it. The next section will focus on what this all means from a practical standpoint, providing actionable recommendations to move your organization from a state of vulnerability to a state of resilience.
From a Practical Standpoint: Actionable Recommendations for a Stronger Posture
Understanding the myths is one thing; acting on the reality is another. In today's digital landscape, a passive security stance is a recipe for disaster. It is crucial to understand that your security posture is not just about the tools you buy but the processes you implement and the culture you build. What this means in practice is moving from a reactive to a proactive security model.
1.Embrace a Zero Trust Architecture (ZTA)
The old model of "trust, but verify" is dead. A Zero Trust framework operates on a "never trust, always verify" principle. This means that every user, device, and application attempting to access a resource—whether they are inside or outside your network—must be continuously verified.
How it applies to SaaS: In a ZTA, you don't trust an identity just because it's on your network. Instead, you verify the user, the device, and the context of the access request before granting access to a SaaS application. This minimizes the blast radius of a breach by preventing an attacker from moving laterally between systems, even if they've compromised one account.
2.Govern All Identities—Especially Non-Human Ones
The Salesloft Drift and Snowflake breaches were not caused by compromised human passwords. They were the result of a failure to secure non-human identities like OAuth tokens and API keys. These "machine identities" are used by applications and services to interact with each other, often holding more privilege than a typical human user and operating without oversight.
What you should do: You need a process for discovering and managing these non-human identities. Implement a lifecycle for them, from provisioning with the principle of least privilege to regular rotation of credentials and decommissioning when they are no longer needed. A key step is to assign ownership for every non-human identity, ensuring clear accountability.
3.Implement SaaS Security Posture Management (SSPM)
Manual audits and checks are no longer scalable. You can't manually review every single configuration and permission across dozens of SaaS applications. This is where a dedicated SSPM solution comes in.
SSPM, or SaaS Security Posture Management, is a category of automated security tools designed to provide continuous visibility into the security of your SaaS applications. It operates on the principle that manual, periodic checks of security settings across a growing number of SaaS apps are simply not scalable or effective. An SSPM platform works by connecting to your sanctioned SaaS applications via APIs to continuously scan for misconfigurations, excessive user privileges, and potential compliance gaps. The goal is to identify and remediate security issues before they can be exploited by an attacker, offering a single, centralized view of your entire SaaS ecosystem. For example, an SSPM tool can automatically flag a misconfiguration in Salesforce where an external-facing portal is publicly accessible, or in Google Workspace where a sensitive folder is shared with an external party. They can also detect "Shadow IT" (unauthorized apps) and assess their risk to your organization. The most advanced SSPM solutions can even offer automated remediation, such as deactivating a risky third-party integration or changing a user's permissions, ensuring that security issues are addressed promptly and efficiently.
4.Strengthen Third-Party Integration Security
The Salesloft Drift attack highlighted the danger of SaaS-to-SaaS integrations. A single compromised API key or OAuth token from an integrated application can provide an attacker with a backdoor into your sensitive data.
A simple approach: Before integrating any third-party application, conduct a thorough security review. Once integrated, enforce strict access controls and continuously monitor the application's behavior for any suspicious activity.
The Inevitable Reality: Building a Data Breach Readiness Plan
In today's threat landscape, a proactive defense is non-negotiable, but so is a robust incident response plan. Having a well-defined process can significantly reduce the financial and reputational damage of a breach. A prepared response can save millions of dollars in total data breach costs and restore trust with customers and stakeholders. This is particularly critical in Malaysia, where the Personal Data Protection Act (PDPA) 2010 now mandates data breach notification to the Commissioner and affected individuals within a strict timeframe if the breach is likely to cause significant harm.
1.The Immediate Response: Containment and Assessment
The moment a breach is suspected, the clock starts ticking. The first goal is immediate containment to stop the bleeding. This means isolating affected systems, disabling compromised accounts, and taking necessary equipment offline to prevent further data loss. However, it is paramount that you do not destroy any evidence in the process.
The Who: You need a designated Incident Response Team (IRT) with clearly defined roles and responsibilities. This team should include not just technical experts from IT and security, but also representatives from legal, HR, and communications. For many small to medium enterprises, it is advisable to have a pre-arranged partnership with an external cybersecurity firm that can provide digital forensics expertise.
The What: Your initial analysis must answer critical questions: What kind of information was compromised? How many individuals were affected? And what is the potential for harm?
2.Digital Forensics: The Post-Breach Stocktake
Once the immediate threat is contained, the real investigation begins. This is where digital forensics comes in. Think of it as a digital crime scene investigation to determine the timeline and scope of the breach.
Collecting Evidence: Forensic investigators will meticulously collect and preserve digital evidence from endpoints, servers, and network traffic. They create bit-for-bit copies of hard drives and capture memory snapshots to ensure the integrity of the evidence for both internal analysis and potential legal proceedings.
Reconstructing the Timeline: By analyzing log files, system snapshots, and user activity, investigators can piece together a precise timeline of the attack, from the initial point of entry to how the attacker moved laterally and what data they exfiltrated. This process is crucial for understanding the root cause—whether it was an unpatched vulnerability, a phishing attack, or a misconfigured firewall—so you can fix it for good.
3.Notification and Communication
For a breach that affects personal data, the legal and ethical obligation to notify is paramount, especially in Malaysia under the PDPA 2010.
Timeliness is Key: In Malaysia, data controllers must notify the Personal Data Protection Commissioner as soon as practicable, and within 72 hours of becoming aware of the breach if it is likely to cause significant harm to individuals. The notification must include key details such as the date and time of the breach, the nature of the breach, and the type of data involved.
Communicating with the Public: You must also notify affected individuals without undue delay, and no later than seven days after the initial report to the Commissioner. The communication should be transparent and provide clear information about the breach, its likely consequences, and the steps individuals can take to protect themselves.
Ultimately, breach readiness is not about fearing the worst; it's about preparing for it. It's about accepting that vulnerabilities exist and having a clear, actionable plan to respond when they are exploited.
Conclusion: The Path Ahead
The recent string of high-profile SaaS breaches, both globally and right here in Southeast Asia, should be seen as a wake-up call, not a cause for panic. The problem is not with the cloud itself but with our collective reliance on outdated security models. We must abandon the dangerous myth of the "impenetrable cloud" and fully embrace the shared responsibility model. The bottom line is that while your SaaS provider secures the infrastructure, the ultimate security of your data is firmly in your hands.
Moving forward, the path ahead requires a paradigm shift. It's no longer enough to react to a breach after it happens; we must assume the worst and prepare for it. This means adopting a Zero Trust architecture that verifies every interaction, implementing an SSPM solution for continuous monitoring, and meticulously managing every single identity—human or machine.
For Malaysian organizations, the urgency is even greater. The Personal Data Protection Act (PDPA) 2010 now comes with teeth, and a failure to demonstrate due diligence and prompt action can result in significant penalties and irreparable damage to your reputation. As we navigate this evolving landscape, the conversation must shift from "if a breach happens" to "when a breach happens."
The most resilient organizations in the future will be those that have not only invested in the right technology but have also cultivated a culture of continuous learning and preparedness. They will be the ones that see cybersecurity not as a cost center, but as a fundamental business enabler. The time to act is now.
This article is also available on Linkedin at https://www.linkedin.com/pulse/saas-security-myth-vs-reality-ts-dr-suresh-v3uac
Author: ORCID ID - Suresh Ramasamy: 0000-0003-4562-037X