G Suite, the collection of business collaboration tools from Google has been growing in adoption over the past decade, reaching over 5 million business customers who use tools like Gmail, Google Drive, and Google Docs to work more efficiently. Firms like ATB Financial have reimagined the way they work by using Google Docs as a collaborative tool, doubling the speed of their strategic planning and reporting1.
Part of the G Suite experience for end users is the flexibility to augment tools like Google Drive with apps from the G Suite Marketplace, or home-built custom applications that developers have scripted themselves to integrate with G Suite.
Take for example an end user working for a healthcare company that needs to edit and sign a PDF in Google Drive. They can go to G Suite Marketplace, find and install a PDF editing tool, and complete their task efficiently. But, during installation, the app requests access to the user’s data in Google Drive. As a security professional in a regulated industry, you may not be able to allow any third party to access your company’s data. While the third-party may not present any malicious threat, your ability to demonstrate compliance could be at risk.
McAfee MVISION Cloud, a Cloud Access Security Broker (CASB) integrates with G Suite to give you visibility and control over applications that have access to data in resources like Google Drive. We call this feature “Connected Apps”. Let’s look at the top 5 G Suite security use cases you can implement for third-party apps:
1. Discover which third-party apps are connected to your G Suite Environment.
As a security team, your first step in addressing the risk of third-party apps is assessing how broadly they are used by your organization, and how often they are added. You may have power users that consider G Suite Marketplace a key part of their workflow and add new apps regularly. Within MVISION Cloud, you can view every app connected to G Suite, when they were added, who is using them, what they can access in G Suite (i.e. Google Drive), and the status of the application. It is simple to identify the apps in your G Suite environment and monitor new apps as they are added.
Connected Apps analytics in MVISION Cloud, showing recently added apps.
2. Allow your own internally developed apps by default.
Not all apps that connect to G Suite come from the G Suite Marketplace. Your internal teams may be augmenting G Suite with their own scripted apps, which enables greater control over your data. Take for example a retail chain (ACME) that built an app to run analytics on purchase data they store in Google Drive. The developers are in-house, and the data in Google Drive remains under their control. With MVISION Cloud, you can whitelist any internal app that follows a standardized naming scheme, while blocking other third-party apps. In this example, any app name that begins with “ACME_” will be allowed in your environment. Now all of your developer apps are allowed by default, streamlining their access to G Suite.
Connected Apps policy in MVISION Cloud, showing a policy for whitelisting internal apps
3. Block apps from G Suite Marketplace until you audit and approve them.
Companies facing strict regulations for data protection may want to take a restrictive approach, allowing third-party apps to be installed into G Suite, only after they have been audited by their security team. For example, a financial services company may sanction an app like Smartsheet for their entire organization, including as an add-in application to G Suite. For any other applications, the security team is required to audit the scope of permissions accessed by the app first, and then either explicitly allow or block the apps. With MVISION Cloud, you can automatically revoke access to all third-party apps that have an “unassigned” status (i.e. have not yet been reviewed by the audit team), and put them in Under Audit status until your company decides to allow or block the app.
Connected Apps policy in MVISION Cloud, showing a policy to block all un-reviewed apps, and allowing access to those already reviewed and approved.
4. Block certain user groups from installing apps
You may have specific user groups within your organization that require tighter control, since they have access to more confidential data. For example, researchers in a pharma company hold valuable IP that if exposed, could significantly damage the business. For the research group, you can apply a policy that blocks installing all new apps into G Suite, and then build out allowed and blocked lists for that team specifically.
Connected Apps policy in MVISION Cloud, showing a policy that blocks all new apps for a specific user group.
5. Block access to specific resources in G Suite
You can also set your policy to control what resources in G Suite, third-party apps can access. For example, as a healthcare company, you may know that third-party access to your Google Drive is against your internal policy, so you want to block any apps that require that access. With MVISION Cloud, you can define your policy based on what resources the apps request access to, allowing you to focus on scope of app access first, and then the individual apps later. Access to G Suite resources is handled by OAuth Scopes, which you can find here, and are easily added as a dictionary that can be used in your policy.
Connected Apps policy in MVISION Cloud, showing a policy blocking any app that requires access to Google Drive
In each of these use cases, you have the ability to automatically notify your end users and coach them on your policies for installing apps into G Suite.
Check out an in-depth demo of Connected Apps here:
About the Author
Categories: Cloud Security