By Stephan Schulze
In November 2006, Twitter developer Blaine Cook was on the hunt for a solution to a very specific problem. He wanted to grant external access to Twitter’s functionality in a standardized and transparent way. This would make it possible to let another app, such as Hootsuite, use your Twitter account and publish a tweet. Developers at other companies wanted to do similar things, so some of them joined forces.
The birth of OAuth
The hunt for an open-source solution evolved into a fully-fledged standard called OAuth, which was first published in 2010. OAuth 2.0 followed in 2012 with further security improvements and better support for mobile and desktop applications.
Today, many popular SaaS applications, such as G Suite, use OAuth. And there are hundreds of third-party apps that integrate with G Suite. If you want the Zoom conferencing app to read your Google Calendar and create meetings, you can say, “Yes, I’ll let the app do these things on my behalf — no need to ask me each time”.
But there’s one big problem…
Too many apps and too many permissions
The number of third-party apps has increased exponentially since 2006. It’s easy for the number of apps to spiral out of control. When installing these apps, employees are not always entirely aware of what these apps can do on their behalf. This month, our system administrators did a tally of all the third-party apps that were authorized for our company’s G Suite instance and analyzed what permission scopes were granted. There were a lot.
Here’s a little animated GIF of them scrolling through the report.
The results were eye-opening. Our employees had collectively installed around 380 apps with access to a wide range of G Suite features.
OK, but what’s the problem exactly?
If you’re asking this question, you’ve probably never had to audit the permissions that people have granted to their user accounts. The more apps you have, the more nebulous the permissions can get. Again let’s take G Suite as an example. The G Suite APIs let app developers access hundreds of fine-grained permission scopes. And here lies the problem:
Apps with “aggressive” permissions can slip under the radar
One day, during an online conference call in the Zoom Meetings app, someone noticed that there was an “app” participating in the call. It was an app called “Fireflies.ai”. It’s a perfectly fine app, and I don’t mean to dismiss it in any way. But it requires some aggressive permissions to do its job.
For example, it needs permission to identify call participants, record the audio from the call, transcribe the audio, and automatically create tasks based on what was said. This is actually a pretty cool functionality and can save a tremendous amount of time. But it can be more challenging to ensure confidentiality if you’re not completely aware of the permissions that you’re granting.
Of course, there are many apps that require extensive permissions — this isn’t a problem in itself. It’s more that people don’t pay enough attention when they grant them.
The problem of “permission blindness”
Many people are so accustomed to clicking “Sign in with…” buttons that they’ve developed a kind of “permission blindness”. They hurriedly click through the various dialogs until they get to where they want to go.
Signing in with Google is super convenient, but it’s not the same as granting extensive app permissions to your Google account. It doesn’t help that both types of dialog have the same header, “Sign in with Google”. This is because authenticating (identity) and authorizing (permissions) are often handled in the same seamless UI flow.
Have a look at the following screenshots. The content is different enough, but they’re visually still quite similar (bonus task: see if you can spot the fake permissions I made up for dramatic effect).
The first step is to encourage your employees to be conscious of what app permissions they are granting. This shouldn’t be an alien concept. After all, the same problem exists for smartphone apps. At the start of this year, a report by the International Computer Science Institute (ICSI) drew more public attention to the nefarious ways in which mobile apps can track our behavior without our consent. In short, data protection is every citizen’s responsibility. You just need to remind employees that this responsibility includes their employer’s data as well as their personal information.
A compromised app can jeopardize your entire User Account
Again, this point is best illustrated with a concrete example. At Project A, some of us work with Lumin PDF. It’s a very popular app that lets you view and edit PDFs without downloading them. But in April this year, Lumin PDF got hacked.
An attacker managed to infiltrate their user database and extract the user records for all Lumin PDF users (24,386,039 in total) into a gigantic CSV file that they posted online. Most of the user records contain a Google Access token that was used to authenticate the app in G Suite. Once an access token is out in the wild, anyone can potentially impersonate a trusted user.
The unfortunate thing was that Lumin PDF didn’t immediately notify its users about the breach. The CEO of Lumin PDF issued a public statement refuting any claims that the leaked tokens were still usable, but we had to be sure. Our system administrators checked the validity of the tokens, and they had indeed been invalidated.
Of course, it’s harder to take these kinds of proactive steps if you’re not aware that employees are using the app in the first place.
Why not just have a stricter IT Policy?
Well, first off, if you’ve already got into the state where you have 380 apps to review, it might take you a while to figure out which apps you need to whitelist.
Also, if you start off too strict, you run the risk of slowing down productivity and forcing employees to contrive hidden workarounds.
However, if you still want to harden your app security, most enterprise systems provide a variety of options to control what apps users can install and to restrict the scope of what apps can do.
For example, some G Suite administrators prefer to maintain a whitelist of approved apps and limit the access scope that apps have to certain API operations.
But before you go all out with a strict new app security policy, consider a more nuanced approach.
No need to enforce, just monitor and crowdsource
Instead of trying to review each and every app yourself, try to build awareness of app security in your organization and “crowdsource” the review process — let your employees share some of the workload of checking app permissions.
For example, at Project A, we’re taking the following steps:
Ask employees to take responsibility for their own app usage
Make an announcement or presentation and ask everyone to have a look at their own app usage. Ask employees to get rid of any apps that they aren’t really using, and double-check the permissions of the apps that they want to keep.
Ask team leaders to reinforce the message
Approach team leaders about their team’s app usage and get them to raise any issues with their team members. After the first phase, track how many people uninstall apps in response to your announcement in the first phase. Look for teams that use a lot of apps but haven’t uninstalled many apps after the first phase, and approach those team leaders first.
Expect a bit of pushback from some team leaders. Some people just want a list of what is officially endorsed and would prefer not to dig into the details. But honestly, your head of finance is probably in a better position to know if “ERPAG” is really a must-have app for their team.
Monitor app usage more precisely
As an alternative to applying “hard” permissions restrictions to your IT policy, you can also use monitoring to maintain an overview of your app landscape.
For example, you can use G Suite API to pull custom reports about new app installations, permissions, and app usage. If you use Slack, you can also add a bot to a Slack channel that notifies you whenever someone installs a new app. That way, you’re not blocking people from trying out new tools, but you can act immediately if the app looks suspicious or if the app has a known security vulnerability.
Also, you can prevent app duplication and advise employees that they don’t need to install yet another app when a perfectly viable option is already installed for your organization.
Know your employee’s usage patterns before you resort to a whitelist
If you monitor rather than enforce, you also have the benefit of understanding why people install the apps they do.
Remember the case of “fireflies.ai”? Sure, it could access sensitive data, but it was good to know that someone thinks it’s necessary to get meetings automatically transcribed. As it happened, we realized that the Zoom app can also transcribe meetings, and we pointed people to a Zoom transcription feature that they weren’t aware of.
This requirement might have gone unnoticed under a more rigorous security policy. If you stop employees from installing apps on their own, many people won’t have the patience to request permission from an administrator. And some administrators like this way. But if you let employees install apps on their own, you can still talk to the person and discuss other technical solutions without blocking and frustrating them.
However, your company might grow to the extent that you can no longer keep up with the volume of app installs. When this happens, you can look at more targeted solutions, such as restricting feature scopes for certain apps. For example, you can restrict users from installing Gmail apps that can read their emails while allowing more liberal access to apps for Google Slides.
So get an overview of your company’s app usage but don’t go overboard with your security policy. Make sure it matches the size and culture of your company.
We have over a hundred employees at Project A, so this “soft” approach is easy to try. What about your company? Are you paying any attention to third-party app integrations for SaaS systems such as Slack, G Suite, or Salesforce? Did you start with an allowlist from the beginning, or are you thinking of implementing one? Hit us up in the comments.