The modern kill chain is eluding enterprises because they aren’t protecting the infrastructure of modern business: SaaS.
SaaS continues to dominate software adoption, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven’t revised their security programs or adopted security tooling built for SaaS.
The mature security controls CISOs and their teams depended on in the age of on-prem dominance have vanished. Firewalls now protect a small perimeter, visibility is limited, and even if SaaS vendors offer logs, security teams need homegrown middleware to digest them and push into their SIEM.
SaaS vendors do have well-defined security scopes for their products, but their customers must manage SaaS compliance and data governance, identity and access management (IAM), and application controls — the areas where most incidents occur. While this SaaS shared responsibility model is universal among SaaS apps, no two SaaS applications have identical security settings.
Figure 1. In the context of SaaS security concerns, the application provider is responsible for all physical infrastructure, as well as the network, OS, and application. The customer is responsible for data security and identity management. The SaaS shared responsibility model requires SaaS customers to assume ownership of components that threat actors attack most often. Illustration courtesy of AppOmni.
> AppOmni research reports that on average, a single instance of SaaS has 256 SaaS-to-SaaS connections, many of which are no longer in use, but still have excessive permissions into core business apps such as Salesforce, Okta, and GitHub, among others.
Between the multitude of different SaaS security settings and constant updates that alter them, security teams can’t effectively monitor these connections. The number of entry points multiplies exponentially when employees enable SaaS-to-SaaS (also called “third party” or “machine”) connections. Machine identities can use API keys, secrets, sessions, digital certificates, cloud access keys, and other credentials to enable machines to communicate with one another.
As the attack surface migrated outside the network perimeter, so did the kill chain — the way in which threat actors orchestrate the various phases of their attacks.
SaaS is the new cybersecurity battleground. See AppOmni’s security experts break down real-world examples of the modern SaaS kill chain and common TTPs — and show you how to reduce the likelihood of threat actor success.
The modern SaaS kill chain usually involves:
Figure 2. Successful SaaS kill chains typically involve four overarching steps: initial access, reconnaissance, lateral movement and persistence, and ransomware execution and security evasion. Illustration courtesy of AppOmni.
SaaS security leader AppOmni’s latest threat intelligence briefing webinar delineated the kill chain of the Scattered Spider/Starfraud threat actor groups’ (affiliates of ALPHV) successful attack on an undisclosed target in September 2023:
Figure 3. The kill chain used by the Scattered Spider/Starfraud threat actor groups. Illustration courtesy of AppOmni.
Scattered Spider/Starfraud likely accomplished this series of events over several days. When SaaS serves as the entry point, a serious attack can include the corporate network and infrastructure. This SaaS/on-prem connectivity is common in today’s enterprise attack surfaces.
Most SaaS breaches aren’t dominating headlines, but the consequences are significant. IBM reports that data breaches in 2023 averaged $4.45 million per instance, representing a 15% increase over three years.
Threat actors are continually relying on the same TTPs and playbook of the Scattered Spider/Starfraud kill chain to gain unauthorized access and scan SaaS tenants, including Salesforce and M365 where configuration issues might be manipulated to provide access later.
Other attackers gain initial access with session hijacking and impossible travel. Once they’ve transferred the hijacked session to a different host, their lateral movement often involves communications platforms such as SharePoint, JIRA, DocuSign, and Slack, as well as document repositories like Confluence. If they can access GitHub or other source code repositories, threat actors will pull down that source code and analyze it for vulnerabilities within a target app. They’ll attempt to exploit these vulnerabilities to exfiltrate the target app’s data.
The AppOmni threat intelligence briefing also reports that data exfiltration via permission sharing remains a serious SaaS security concern. This occurs, for example, in Google Workspace when the unauthorized user changes directories to a very open level of permissions. The attacker may share them with another external entity via email forwarding, or changing conditional rules so attackers are included as BCC recipients in a distribution list.
Establish a SaaS intake and review process to determine what SaaS you’ll allow in your company. This process should require answers to security questions such as:
Ensure you can detect Shadow IT SaaS (or unsanctioned SaaS apps) and have a response program so alerts aren’t created in vain.
If you’re not monitoring your SaaS tenants and ingesting all of the logs from them in some unified method, you’ll never be able to detect suspicious behaviors and receive alerts based on them.
> Threat actors target machine identities for their privileged access and lax authentication standards, often rarely requiring MFA.
In 2023, threat actors successfully targeted and breached major CI/CD tools Travis CI, CircleCI, and Heroku, stealing OAuth tokens for all of these providers’ customers. The blast radius expands considerably in these situations.
With the average enterprise containing 256 machine identities, hygiene is often lacking. Many of them are used once or twice and then remain stagnant for years.
Inventory all of your machine identities and triage these critical risks. Once you’ve mitigated these, create policies that prescribe:
Zero Trust architecture builds on the principle of least privilege (PLP) with a “never trust, always verify” approach. While Zero Trust has been established in traditional networks, it’s rarely achieved in SaaS environments.
Zero Trust Network Access (ZTNA)'s network-centric approach cannot detect misconfigurations, machine integrations, or unwanted user access entitlements within and to SaaS platforms, which can have thousands or even millions of external users accessing data.
Zero Trust Posture Management (ZTPM), an emerging SaaS security tool, extends Zero Trust to your SaaS estate. It bridges the SaaS security gap that SASE creates by:
With SSPM, ZTPM, and a SaaS security program in place, your team will gain the visibility and intelligence it needs to identify intruders in the low-risk stages of your kill chain — and stop them before a breach becomes devastating.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.