Third-Party App Integration Permissions: What You Need to Know

On average, enterprise organizations have more than 300 third-party applications integrated into their cloud environment, according to our Knowledge Base data. It isn’t surprising either as there are apps for every imaginable business need from collaboration to communication to instrumentation to coagulation. Okay, maybe not that last one, but the point stands that organizations are using a ton of apps.

Of course, the more technology an organization uses, the more attackers will attempt to find ways to compromise those technologies. Exploiting app integrations and permissions is proving an effective tactic for two reasons:

• Email platforms give applications some truly concerning permissions

• Security teams often lack visibility into when these permissions change, leading to blindspots and gaps

Knowing this, what are some of those permissions? What are the risks? And how can you mitigate those risks? Let’s dive in.

As I’m sure you are aware, every time an application is installed or integrated, users are asked to allow that application certain permissions. In the case of cloud email, you are most likely familiar with read or write permissions, wherein an application gains the ability to create an event on a user’s calendar, create an email message, or read from the calendar or inbox.

But there are thousands of permissions that can be configured for a given application, and while we will talk about the risks of vanilla read and write access, it is worth noting some of the more bizarre abilities an app can be granted.

Did you know that, on Microsoft 365, an integrated application can be granted the ability to respond as a particular user through chat apps? Essentially, an application can masquerade as any user and go send chat messages to any other user. Similarly, there are permissions allowing apps to join video conferences as individual users.

Now, both of these permissions have perfectly benign reasons to exist, allowing IT ticketing systems to respond as a helpdesk employee or allowing a notetaker app to join a video chat on behalf of its owner.

The issue, though, is what happens when these permissions are not allowed by organizational policy? What happens when a compromised user or malicious insider gains access to these over-permissioned apps? What happens when security can’t see that an app with these permissions was integrated or an existing app had its permissions changed to allow some of these functions?

The core risk around third-party app integration is that an over-permissioned app could allow malicious actors to gain access to sensitive data. But there are a few ways that this can happen that are all worth noting. App attacks can be the primary threat vector or an accidental side door into the cloud email platform.

Consent phishing, as an example, is a type of payloadless phishing attack, which serves a user a link that by all accounts is legitimate, taking the user to a permissions page for an app from a verified publisher. Of course, this app is not from a verified publisher and is instead attacker-owned. Once permissions are granted for that app, the threat actors behind it have access to the victim’s corporate account and can begin to exfiltrate data.

On the other side of the fence, for applications already integrated into the cloud email platform, there is an entirely different risk. As mentioned earlier, security teams often lack visibility into app permission changes. In fact, roughly one-third of security practitioners report being unable to see SaaS app security settings.

Considering the powers an app can be granted, this is a significant issue. Not every application a user installs is legitimate, and many of those applications request unnecessarily broad data access. Even if the endpoint isn’t a threat actor compromising the data in the application, there may be compliance and privacy implications that could cause reputational damage rather than financial (although the two are firmly intertwined).

While determining app permissions is often on the shoulders of IT or the line of business owner for a given application, security needs to have a hand on the steering wheel—or at least be in the passenger seat with a hand on the emergency brake.

To stretch that contrived car metaphor a bit further, security teams should really be the ones determining whether the car is worth purchasing at all. In other words, each new app integration should be subject to review and be in line with stringent policies.

Often, though, even with the best of intentions and strongest of policies, users find ways to integrate apps. And then those users accidentally grant those apps evermore access. The solution is proactive posture management specifically for the apps integrated across the cloud email platform. Abnormal supports this solution on two fronts: AppBase and Security Posture Management.

With AppBase, a detailed profile is built for every application currently integrated into customer environments–from the install date to the app permissions. The Security Posture Management add-on then operationalizes that data, surfacing new integrations and high-impact changes to permissions. Security teams can then take immediate action by referencing contextual insights, supporting documentation, and next step guides, and exporting each change to the SIEM for further remediation, if necessary.

This comprehensive toolset makes it easier for companies to protect their information from threat actors who may attempt to integrate malicious applications or exploit existing integrations.

Abnormal offers the resources needed to effectively and securely integrate third-party apps into your existing infrastructure. With Abnormal’s platform as part of your security infrastructure, you can rest assured that your business is safeguarded from any threats posed by unsecured third-party applications.

See for yourself how Abnormal improves the risk posture of cloud email environments. Schedule your personalized demo today.