Review app access risk

Trelica assigns an "access risk" level to any application in your inventory that your users are accessing via single-sign-on (SSO) with OpenID Connect. A common example of OpenID Connect SSO is a "Sign in with Google" option, which allows users to log in to an app or website with their existing Google Workspace account. 

Access risk is just one way of looking at the risk in your SaaS inventory and can help you make decisions about the apps that Trelica is discovering. For example, an app that is predominantly for home use and that has high access risk might be something you want to address.

You can find the access risk score in the Applications view, in the Permissions risk report (available from the Reports list), and on individual application profiles.

"Sign in with Google" (or Microsoft) isn't necessarily a bad thing for staff to use on non-business related apps. The app will know their work email address, but it does mean that the user isn't potentially reusing a password. The risk is that users can inadvertently, or carelessly, grant additional access to Google Workspace resources which contain company information.

How Trelica defines risk

Trelica's access risk grading is based on OAuth Scopes. When an individual logs in to an application using OpenID Connect SSO, they are usually prompted to grant the application various permissions. These permissions are granted via OAuth scopes.  

Google and Microsoft support hundreds of OAuth Scopes, ranging from basic, low-risk permissions that grant the user access to an app, through to permissions that give a third party app complete access to a user’s email account or cloud file storage.

You can find a much more detailed review of the technology behind these OAuth Scopes in this blog post.

Google’s sensitive OAuth Scope list

Google flags 46 OAuth Scopes as being sensitive and requires vendors of apps using these scopes to undergo additional verification when registering for Google Sign-in. Our "high risk" category is based on these sensitive scopes; any app using any one of these scopes is categorised as high risk.

Occasionally an app might provide multiple routes of access via OAuth, such as a simple login alongside an add-on that integrates data from a Google Sheet. One route of access may be categorised as low risk, while the other is high risk. In this situation, if a single user has authenticated with the high risk scopes then Trelica categorises the whole app as high risk.

There isn't a direct equivalent for Microsoft's OAuth scopes. To grade access risk for Azure AD-based OAuth we've mapped Google's sensitive scopes list to Microsoft's.

Inherent vs contextual risk

The high risk category addresses the inherent risk that comes with users granting broad permissions to third party apps. Access risk doesn't address the contextual risk that comes from user behaviour within an application, such as a user uploading PII to an unmanaged app. Irrespective of the risk categorisation for that app, this user behaviour represents risk by virtue of the fact that a user is making decisions about which third parties are holding your organisation’s sensitive data.

Why don't I see an Access Risk for an application?

Trelica detects applications from multiple different sources, including:

  • Single-sign-on to applications through your Identity Provider (e.g. Google, Okta, or Azure AD).
  • Spend data from a finance or expense system.
  • Trelica Browser Extension.
  • Manually entered applications.

Access risk only applies to applications detected from your Identity Provider, and only to a very specific form of SSO called 'OpenID Connect'. OpenID Connect is most commonly seen as 'Sign in with Google' buttons on some web applications, although it's also available on some apps for Microsoft 365.

If a user is connecting to an application by clicking on an icon in a 'My apps' dashboard, or logging in without using a 'Sign in with Google' button, then they're likely connecting using SAML2 Single Sign On which doesn't represent any access risk.

Finally, if someone did log in with OpenID Connect, but a very long time ago, then the so-called "access token" that lets the application interact with your Identity Provider might have expired. Since this no longer represents an active risk, the access risk will not be shown for that user against an application.

Manage high-risk apps

We recommend that you review any non-business apps that are identified as high risk. From your App inventory, select the "Non-business" view and sort by "Access risk".

If you are concerned by the risk presented by an app, you can revoke individual users' OAuth tokens. This revokes the app's access to the user's Google Workspace account. However, it does not prevent the user from re-granting those permissions if they log in to the app using OpenID Connect SSO again in future. 

Revoke all OAuth tokens.png

To prevent users from logging back in to an app with OpenID Connect SSO and re-granting OAuth scopes, you can block the app in Google Workspace.

Block via Google Workspace.png

Was this article helpful?

1 out of 1 found this helpful

Comments

0 comments

Please sign in to leave a comment.