Uncovering (and Understanding) the Hidden Risks of SaaS Applications
Recent data breaches at CircleCI, LastPass, and Okta underscore a common theme: Enterprise SaaS stacks connected to these industry-leading applications can be at serious risk of being compromised.
CircleCI, for example, plays an integral SaaS-to-SaaS role for SaaS application development. Likewise, tens of thousands of organizations rely on Okta and LastPass security roles for SaaS identity and access management. Enterprise and niche SaaS applications alike have effectively introduced many unmonitored endpoints into organizations of all sizes.
When spending on SaaS security being trending, it lags behind categories like cloud infrastructure protection and network security. According to Statista, the average organization deploys 100+ SaaS applications, many of which are not approved by IT, creating a glaring gap in SaaS security.
Why Users Are Flocking To SaaS Applications — And Often Cutting IT In The Process
As productivity tools for tasks such as marketing automation, document signatures, and sales forecasting have shifted from installed software to SaaS, so has end user behavior. Employees are finding SaaS solutions to help them get more done in less time, especially with the increasing decentralization of IT functions.
Employees will always be looking for ways to increase their productivity with the tools of their choice. This behavior is neither new nor dangerous in itself, but poses a significant security risk. In the installed software era, organizations are adding endpoint security to work machines and devices to ensure their employees cannot download malicious software or fall victim to malware-based attacks. This approach remains a key aspect of overall endpoint security, but it doesn’t reflect the evolution of how people work today: outside the realm of enterprise networks, and often on personal devices.
Instead of approaching Security or IT to understand the policies for deploying a new SaaS solution — and facing possible bureaucracy, delays, or rejection of their requests — they issue a credit card or opt for a 30-day free trial of a SaaS application. Workers rarely consider the security implications of that shadow they have introduced into the ecosystem as they allow connecting their new applications to enterprise SaaS systems such as Microsoft 365, Salesforce, Workday or ServiceNow.
This connection, coupled with the user’s inherited permission settings, can touch an organization’s most sensitive data, without the ability to monitor or control this attack surface risk. And it happens every day.
How SaaS Applications Inherit Permissions through OAuth Tokens
In many organizations, SaaS applications (and SaaS-to-SaaS connections) take advantage OAuth access tokens both at the initial connection point and throughout their lifecycle. The process usually follows these steps:
- A user has been authenticated into an enterprise SaaS application, either through simple authentication or strong zero trust authentication. They are now in the SaaS cloud.
- These users want to save time switching between project management tools and documents, spreadsheets, and email. Therefore, they are looking for ways to streamline their work. That search led to a popular project management SaaS plug-in, perhaps with a free trial, and the user decided to give it a try.
- The user starts the installation and clicks “Yes” to request read-write access permissions to data on major SaaS platforms such as office productivity suites, and the data associated with them. There are no different permission levels for users to choose from.
- OAuth tokens are created by office productivity suites. This token allows project management applications and office productivity suites to maintain API-based cloud-to-cloud communications without users having to log in and authenticate regularly.
From now on, the project management app continues to connect after the initial strong authentication. CASB and SWG will do No detect this SaaS-to-SaaS connectivity.
|Figure 1: A breakdown of how a SaaS-to-SaaS connection interacts with an OAuth token.|
These application tokens are valuable because they make project management applications easily accessible to users. Unfortunately, they are just as, if not more, valuable to attackers looking for easy exploitable entry points into enterprise SaaS systems.
Reach — and Risk — of SaaS Application Arrivals and SaaS-to-SaaS Connections
If a threat actor manages to hijack the OAuth token, they can get into CRM, code repos, and more. A single compromised SaaS-to-SaaS connection can provide valid, authorized API access to different production SaaS environments and data.
Security and IT teams are burdened with monitoring and maintaining configuration settings and growth of their enterprise SaaS platforms, let alone unauthorized SaaS applications. Without any security review, SaaS-to-SaaS connections create potentially vulnerable endpoints.
The prevalence of these SaaS-to-SaaS connections is enormous and is often underestimated by IT organizations. According to the SaaS security provider AppOmni:
- The average corporate organization has more than 42 different SaaS-to-SaaS applications connected to a live SaaS environment within an enterprise. Nearly 50 percent of these applications are 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 enabled or disabled, connected SaaS-to-SaaS applications retain their data access rights.
- Many of these organizations have achieved a total of nearly 900 user connections to the app.
|Figure 2: A SaaS environment contains multiple entry points beyond traditional network and CASB protection.|
As this research shows, the number of “official” applications that deal with potentially sensitive data cannot be assessed and monitored without proper SaaS security tools.
Practical Steps to Monitor and Secure SaaS Connections
Most Security teams don’t have the proper tools to gain visibility into SaaS connectivity and related user activity. SaaS Security Posture Management (SSPM) solution addresses this problem by providing visibility and control over real SaaS.
A Security or IT professional could, for example, use SSPM to discover everything running on Salesforce, along with the SaaS applications connected to it. The same goes for many of the other SaaS applications used by organizations.
This additional visibility and control in continuous monitoring of SaaS applications and SaaS-to-SaaS connections reduces the risk of attack surfaces and enables proactive security controls. If vulnerabilities are found, the Security team can take action, such as defining disallowed, insecure, and over-allowed SaaS applications.
Thanks to the SSPM solution’s continuous monitoring capabilities, Security teams can define a baseline of SaaS activity to use as a point-in-time frame of reference. While the potential for SaaS-related breaches can never be completely eliminated, the use of SSPM significantly reduces that risk.