Third-Party App Access Is the New Executable File

Actions that a user takes from creating an email to updating a contact in the CRM system can result in several other automatic actions and notifications in the connected platforms. However, this SaaS-to-SaaS communication and supply chain is an emerging threat in the corporate cybersecurity landscape.

It bears repeating: Third-party app access is the new executable file. An innocuous process much like clicking on an email attachment, people don’t think twice when connecting an app they need with their Google Workspace or Microsoft 365 environment. These third-party apps can boost productivity, enable remote and hybrid work, and are overall essential in building and scaling a company’s work processes.

The OAuth mechanism makes it extremely easy to interconnect apps, and many users simply click “accept” without considering what permissions these apps are asking for — or what the possible ramifications could be. By providing these apps and other add-ons for SaaS platforms with permissions’ access, businesses are presenting more opportunities for bad actors to gain access to a company’s data. This puts companies at risk for supply chain access attacks, API takeovers, and malicious third-party apps. Once a bad actor is able to infiltrate one platform, they potentially have access to all of the users’ connected SaaS apps.

Nowadays, when it comes to local machines and executable files, organizations already have control built in that enables security teams to block problematic programs and files. It needs to be the same when it comes to SaaS apps.

We conducted field research from within our customers’ environments to identify just how many third-party apps were connected to their instances of Google Workspace, M365, and Salesforce. On average, there were approximately 150 SaaS apps connected to these business-critical apps, unbeknownst to the security team.

OAuth 2.0 has greatly simplified authentication and authorization, and offers a fine-grained delegation of access rights. Represented in the form of scopes, an application asks for the user’s authorization for specific permissions. An app can request one or more scopes. Through approval of the scopes, the user grants these apps permissions to execute code to perform logic behind the scenes within their environment. These apps can be harmless or as threatening as an executable file.

Third-party app access is just one component of the SaaS security posture management picture. Recent surveys have shown that an enterprise with 1,000 or more employees is likely to use more than 150 SaaS apps to run the business. While each individual SaaS app comes with built-in native security controls, it is up to the organization to ensure that all the configurations and user permissions are correct.

Further complicating matters is the fact that no two apps are the same — each has unique terminology, environment, and organization of their security configurations. Understanding every app’s “language” and managing the complex, ever-changing environment, now with the additional third-party app access risk, opens organizations up to even more exposure and vulnerability.

**Best Practices to Mitigate Third-Party App Access Risk
**To secure a company’s SaaS stack, the security team needs to be able to identify and monitor all that happens within their SaaS ecosystem. Here’s what a security team can share with employees and handle themselves to mitigate third-party app access risk.

**Educate Employees
**The first step in cybersecurity always comes back to raising awareness. Once employees become more aware of the risks and dangers that these OAuth mechanisms present, they will be more hesitant to use them. Organizations should also create a policy that requires employees to submit requests for third-party apps.

**Get Visibility Into Third-Party Access for All Business-Critical Apps
**Security teams should gain visibility into every business-critical app and review all the different third-party apps that have been integrated with their business-critical SaaS apps — across all tenets. One of the first steps when shrinking the threat surface is gaining an understanding of the full environment.

**Map Permissions and Access Levels Requested by Connected Third-Party Apps
**Once the security team knows which third party apps are connected, it should map the permissions and the types of access that each third-party app has been given. From there, it will be able to see which third-party app presents a higher risk. Being able to differentiate between an app that can read versus an app that can write will help the security team prioritize which needs to be handled first.

In addition, the security team should map which users granted these permissions. For example, a high-privileged user, someone who has sensitive documents in their workspace, who grants access to a third-party app can present a high risk to the company, and this needs to be remediated immediately.

These best practices are just the start for a cybersecurity department to better ensure its organization’s SaaS security hygiene remains intact.