How SaaS-to-SaaS Apps Can Compromise the Security of SaaS Environments

The risk of SaaS-to-SaaS connections has always been a concern for security teams. The 0ktapus phishing scam is an example of how threat actors successfully infiltrated identity access management platform Okta. Several organizations such as Klaviyo, Mailchimp, and Twilio used Okta as a SaaS-to-SaaS connection to streamline user authentication and authorization processes. But these connections served as entry points for threat actors to compromise 9,931 user credentials and 5,441 MFA codes. This incident demonstrates how SaaS-to-SaaS apps can create vulnerabilities in an otherwise secure infrastructure if left unmonitored and undetected.

AppOmni’s data shows that, on average, there are more than 256 distinct SaaS-to-SaaS apps in live SaaS environments within an enterprise. Approximately half of these applications were connected directly by end-users, not installed by IT administrators. The typical enterprise has an average of 900 user-to-application connections. This represents hundreds of “authorized” SaaS-to-SaaS connections to the data stored in the SaaS environment.

Of those 256 SaaS-to-SaaS apps, an average of 100 have not been used – yet they retain the ability to access data via these connections. These inactive applications often represent a trial usage that was abandoned by a user, or they’re applications where the business contract may have expired but the vendor access was not removed. These application connections remain authorized until that access has been revoked.

Due to the nature of these SaaS-to-SaaS connections, they are frequently approved by individual users without any security or IT oversight. While these applications may be quite useful, SaaS-to-SaaS apps are hidden pathways into an organization’s most sensitive data. These cloud-to-cloud connections exist outside the firewall and cannot be detected by traditional scanning and monitoring tools like Cloud Access Security Brokers (CASBs) or Secure Web Gateways (SWGs).

Not knowing which app is or isn’t approved, what access the app has, and who could install an app are just some of the issues that may arise with SaaS-to-SaaS connections. When a SaaS app connects to the SaaS ecosystem, it could gain access to the data stored in your enterprise SaaS platforms.

In the event of an incident, it becomes even more complicated. The incident response team will have to investigate a compromise of the app, create timelines of when and where the app was installed, what it had access to, and other worst-case scenarios.

There are a variety of ways for SaaS apps to connect to cloud services, but there are three in particular to focus on:

• Service account integration: Where a service is assigned a dedicated username + password to connect to the cloud service just like a human user.

• Administrator-installed applications: When an admin connects a SaaS app and makes it available to groups of users (or all users) of the cloud application.

• User-connected applications: When a non-admin user grants an access token to a SaaS app, granting all of their privileges or a subset of their privileges to the SaaS app — now making it a SaaS-to-SaaS app. This flow uses OAuth. If you’ve ever signed into an application with your Facebook or Google account, you are using an OAuth flow. Enterprise SaaS applications have the same functionality through OAuth.

We’ve known this is a problem for quite some time. Looking back at the Apollo Breach in 2018, we saw the compromise of a SaaS-to-SaaS app as the stepping stone to dumping 200 million contacts from a major SaaS application. Recently, several companies, including NationsBenefits and Santa Clara Health Plan (SCHP), faced security risks due to a vulnerability in their connected SaaS app Fortra’s GoAnywhere. This vulnerability was exploited to compromise the network of 130 organizations who used this SaaS app.

When thinking of your overall attack surface, SaaS apps and their SaaS-to-SaaS connections are currently one of the biggest blind spots. Existing investments in security technologies that focus on the network or the endpoint cannot help with this challenge. It’s not that our on-premise tools have failed — it’s that the data has moved where traditional tools can’t see it. Getting visibility into what SaaS apps are already connected to your cloud and SaaS applications should be one of the top priorities for security teams. Successful organizations will have a process for continuously scanning and monitoring their cloud applications, and have a review and approval program for SaaS-to-SaaS connections.

---

¹Portions of this post were previously published in:
SecurityMagazine
SiliconAngle
BankInfoSecurity

Related Resources