Recent data breaches across CircleCI, LastPass, and Okta underscore a common theme: The enterprise SaaS stacks connected to these industry-leading apps can be at serious risk for compromise.

CircleCI, for example, plays an integral, SaaS-to-SaaS role for SaaS app development. Similarly, tens of thousands of organizations rely on Okta and LastPass security roles for SaaS identity and access management. Enterprise and niche SaaS apps alike have effectively introduced multitudes of unmonitored endpoints into organizations of all sizes.

While spending for SaaS security is trending up, it lags behind categories such as cloud infrastructure protection and network security. According to Statista, the average organization employs 100+ SaaS apps, many of which are unsanctioned by IT, creating a glaring gap in SaaS security.

Why Users Flock to SaaS Apps — And Often Bypass IT in the Process

As productivity tools for tasks such as marketing automation, document signature, and sales forecasting have shifted from installed software to SaaS, so have the behaviors of end-users. Employees find SaaS solutions to help them accomplish more in less time, especially with the increasing decentralization of the IT function.

Employees will always seek ways to increase their productivity with tools of their choice. This behavior is nothing novel or in and of itself malicious, but it poses significant security risks. In the era of installed software, organizations added endpoint security to work machines and devices to ensure their employees couldn’t download harmful software or fall victim to malware-based attacks. This approach remains a key facet of overall endpoint security, but it doesn’t reflect the evolution of the way people are now working: outside the purview of corporate networks, and often on personal devices.

Rather than approaching Security or IT to understand policies for onboarding new SaaS solutions — and facing the likelihood of red tape, delays, or denial for their requests — they break out the credit card or opt for a 30-day free trial of the SaaS apps. Workers rarely consider the security implications of the shadow IT they’ve introduced into the ecosystem as they authorize connecting their new apps to enterprise SaaS systems such as Microsoft 365, Salesforce, Workday, or ServiceNow.

These connections, coupled with the users’ inherited permission settings, could touch the organization’s most sensitive data, with no ability to monitor or control this attack surface risk. And it happens every day.

How SaaS Apps Inherit Permissions via OAuth Tokens

In many organizations, SaaS apps (and SaaS-to-SaaS connections) capitalize on OAuth access tokens both at the point of initial connection and throughout their lifecycle. The process typically follows these steps:

  • A user has been authenticated into an enterprise SaaS app, whether via simple authentication or strong zero trust authentication. They’re now in the SaaS cloud.
  • That user wants to save time toggling between their project management tool and documents, spreadsheets, and emails. Accordingly, they search for ways to streamline their work. That search leads to a popular project management SaaS plug-in, perhaps with a free trial, and the user decides to try it.
  • The user begins the installation and clicks on “Yes” to a prompt authorizing read-write access to data in a major SaaS platform like an office productivity suite, and the data associated with it. There are no tiers of different permission rights for the user to select.
  • An OAuth token is created by the office productivity suite. This token allows the project management app and office productivity suite to maintain API-based cloud-to-cloud communication without the user having to log in and authenticate regularly.

From this point forward, the project management app is continually connected after the initial strong authentication. CASBs and SWGs will not detect this SaaS-to-SaaS connectivity.

SaaS Apps
Figure 1: A breakdown of how a SaaS-to-SaaS connection interacts with an OAuth token.

These application tokens are valuable because they make the project management app easily accessible for the user. Unfortunately, they’re equally, if not more, valuable for attackers seeking an easily exploitable entry point into an enterprise SaaS system.

The Reach — and Risk — SaaS Apps and SaaS-to-SaaS Connections Present

If threat actors can successfully hijack OAuth tokens, they can gain entry into CRMs, code repos, and more. One compromised SaaS-to-SaaS connection can provide valid, authorized API access into a multiplicity of different production SaaS environments and data.

Security and IT teams are overburdened with monitoring and maintaining the configuration settings and growth of their enterprise SaaS platforms, let alone unauthorized SaaS apps. Without any security review, SaaS-to-SaaS connections create potentially vulnerable endpoints.

The prevalence of these SaaS-to-SaaS connections is substantial and frequently underestimated by IT organizations. According to SaaS security provider AppOmni:

  • The average enterprise organization has more than 42 distinct SaaS-to-SaaS apps connected into live SaaS environments within an enterprise. Nearly 50 percent of these apps were connected directly by end-users, not by IT teams.
  • Roughly half of these 42 connected apps have not been used in the last six months. Whether active or dormant, connected SaaS-to-SaaS apps retain their data access rights.
  • Many of these organizations have reached a total of nearly 900 user-to-application connections.
SaaS Apps
Figure 2: SaaS environments contain many entry points outside traditional network and CASB protection.

As this research demonstrates, the number of “authorized” apps in contact with potentially sensitive data is infeasible to assess and monitor without the correct SaaS security tooling.

Practical Steps for Monitoring and Securing SaaS Connections

Most Security teams lack the proper tooling to gain visibility into SaaS connectivity and the associated user activity. SaaS Security Posture Management (SSPM) solutions address these concerns by bringing visibility and control over the SaaS estate.

A Security or IT professional can, for instance, utilize SSPM to discover everything running in Salesforce, along with the SaaS apps connected to it. The same is true for numerous other SaaS applications used by the organization.

This added visibility and control in ongoing monitoring of SaaS apps and SaaS-to-SaaS connections reduces attack surface risk and enables proactive security control. If a vulnerability is discovered, the Security team can take action, such as pinpointing unsanctioned, unsecure, and over-permissioned SaaS apps.

Thanks to an SSPM solution’s continuous monitoring capabilities, the Security team is able to determine a baseline of SaaS activity to use as a time-in-point frame of reference. While the potential for a SaaS-related breach can never be fully eliminated, utilizing SSPM drives down that risk considerably.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

Leave a Reply

Your email address will not be published. Required fields are marked *