Tag Archives: Security and Compliance

See which apps are Google verified in the Admin console

Quick launch summary 

With this launch, we’ll show whether apps are Google verified in the Admin console on the app details page and the App Access Control summary page. We hope this visibility will make it easier to make informed decisions about access to G Suite data within your organization. 

Apps often require access to G Suite data to help your users get work done. Google works with app developers to make sure that third-party apps comply with Google privacy and security requirements. 

If apps meet certain verification requirements, they are considered “Google verified”. If they don’t complete the verification process, they are considered “unverified” and might be subject to restrictions. You can control which apps can access sensitive G Suite data via App access control, and choose to authorize unverified apps if you want. 


Getting started 


Rollout pace 

Availability 

  • Available to all G Suite and Cloud Identity customers 

Resources 

New APIs to sign out users and control 2-Step Verification

Quick launch summary 

We’re adding two new APIs to the Admin SDK Directory API: 


Sign user out of all sessions 
This new endpoint allows an admin to programmatically sign a user out of all web and device sessions. This can help manage account access when users leave an organization, if a device is lost or misplaced, or if a user forgot to sign out of a shared device. We do not recommend using this to sign users out and force a sign-in periodically; you can explore the Google web session control feature for that use case. 


Turn off 2-Step Verification 
This new endpoint allows an admin to turn 2-Step Verification (2SV) off programmatically. This action also removes all 2SV methods on the account. Note that in some cases, 2SV cannot be turned off for a user due to other policies that may be in effect. For example, a user may be enrolled in the Advanced Protection Program, or “2SV enforced” is turned on; in such cases the API will fail with an appropriate error code and message. 

Note that both of these actions can already be performed via the Admin console. The current launch makes them accessible via API as well so they can be integrated into automated offboarding workflows. 


Getting started 

  • Admins and developers: This feature will be available via the Admin SDK Directory API. Use the API documentation to learn more about the new endpoints to sign users out or turn off 2-Step Verification. 
  • End users: There is no end user setting for this feature. 

Rollout pace  

Availability 

  • Available to all G Suite customers 

Resources 

Filter audit logs and usage reports by groups

Quick launch summary 

You can now filter audit logs and usage reports by specific groups. When you add a new or existing group to an allow list, you can then filter to see log events or usage reports by that specific group. 

This can make it more efficient to find log entries, and allow you to more quickly and easily focus in on a specific target audience to better understand user account information, apps usage, and security. 


Getting started 


Rollout pace 

Availability 

  • Available to all G Suite customers

Resources 

Filter audit logs and usage reports by groups

Quick launch summary 

You can now filter audit logs and usage reports by specific groups. When you add a new or existing group to an allow list, you can then filter to see log events or usage reports by that specific group. 

This can make it more efficient to find log entries, and allow you to more quickly and easily focus in on a specific target audience to better understand user account information, apps usage, and security. 


Getting started 


Rollout pace 

Availability 

  • Available to all G Suite customers

Resources 

Security groups help manage groups used for security and access control

What’s changing 

We’re making security groups available in beta. Security groups help you easily regulate, audit, and monitor groups used for permission and access control purposes. They enable admins to: 
  • Apply a label to any existing Google Group to distinguish it from email-list groups. 
  • Provide strong guarantees that: 
    • External groups (owned outside your organization) and non-security groups cannot be added as a member of a security group. 
    • Security labels, once assigned to a group, cannot be removed. 
Soon, you’ll be able to use more granular admin roles to separate administration of security and non-security groups. Keep an eye on the G Suite Updates blog for an announcement when that rolls out. 


Who’s impacted 

Admins and developers 


Why you’d use it 

Groups are used in a variety of ways. This can include groups that help teams communicate and collaborate, as well as groups that control access to important apps and resources. Security groups can help customers manage these categories of groups differently to increase their overall security posture. 

For example, if you have compliance or regulatory requirements for managing access control, you may have set up naming conventions to keep track of which groups were used for this purpose. With security groups, you can now assign a security label to these groups and more easily manage them without having to use workarounds like naming conventions. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to all G Suite customers 

Resources 

New beta adds IRM controls for DLP to help protect sensitive content in documents

What’s changing 

You can now automatically restrict the ability to download, print, and copy sensitive documents through data loss prevention (DLP) rules. These new DLP-driven information rights management (IRM) controls, currently available in beta, will make it more difficult for users to make copies of documents that might expose sensitive content. 

G Suite DLP rules already enabled admins to limit the sharing of documents directly. However, users could make copies of documents by printing it, copying it to unmanaged locations, or downloading it to physical media. These copies were not subject to the same sharing controls, increasing the risk of that content being exposed. 

There are already controls so that document owners and editors can manually prevent viewers and commenters from printing, copying, or downloading their files. However, this placed the responsibility of selecting the correct restriction on a file on end users. 


Who’s impacted 

Admins and end users 


Why it’s important 

The new IRM controls will help ensure that only a single version of sensitive documents exists, and therefore that company DLP policies will help protect it. This could help reduce the potential for accidental or intentional exposure of sensitive content in documents. It also reduces the need for end-users to recognize and manually adjust the IRM settings for files, creating a more scalable and automated process to protect your organization’s content. 


Additional details 

Admin setting for IRM in the DLP rule creation workflow 
When you’re creating or editing a DLP rule, there will be a new option: “Beta: Disable download, print, and copy for commenters and viewers.” If selected, this will prevent downloading, printing, and copying of the document unless the user has editor or owner permissions. Note that this is only available as part of our new Drive DLP system. 
Admins can add IRM controls to DLP rules 


Users will see new notifications on affected files 
Document editors and owners will see a new note when in the settings section of the sharing screen, as pictured below. Users with view or comment access will not be able to download, copy, or print the document—these options will be greyed out for them. Note that this only places limits on “viewer” or “commenter” roles within Drive. 
Document owners and editors will see a new note when they try to share the document 
Document viewers and commenters will have print, download, and copy options greyed out 


Getting started 

  • Admins: This feature will be OFF by default and can be enabled as part of new and existing DLP rules. Visit the Help Center to learn more about how to create new DLP rules and see FAQs about the Drive DLP IRM beta. 
  • End users: There is no end user setting for this feature. 

Rollout pace 

  • This feature is available now for all users. 

Availability 

  • Available to G Suite Enterprise, G Suite Enterprise for Education, G Suite for Education, and G Suite Enterprise Essentials customers 
  • Not available to G Suite Basic, G Suite Business, and G Suite for Nonprofits, and G Suite Essentials customers 

Resources 

Roadmap 

Block apps from accessing G Suite data with app access control

What’s changing 

Last year, we launched app access control to help all G Suite and Cloud Identity customers control access to G Suite data via OAuth 2.0 by third-party and domain-owned apps. Now, we're improving it by allowing admins to block apps from accessing any OAuth 2.0 scopes. This makes it easy for customers to quickly restrict apps that are deemed to be high-risk or compromised. 

If an app is blocked, it will not be able to access any data from Google services. It will be blocked whether the app is on iOS, Android, or the web. If users try to authorize the app, they’ll see an authorization error message. Admins can customize this error message if they choose. 


Who’s impacted 

Admins 


Why you’d use it 


G Suite has a robust developer ecosystem, with thousands of apps available via the G Suite Marketplace and directly to customers, and a rich API framework enabling customers to develop custom apps. Not all apps, however, conform to every enterprise customer’s security policy, so our customers and partners value controls to manage third-party apps accessing G Suite data. 

Previously, admins could trust or limit access by specific apps. Now, we’re streamlining this to make it easier to manage potentially thousands of apps, and to help you to more quickly block apps when needed. By adding an option to block an app, you can quickly and efficiently protect data when an app is compromised or high-risk.
You can now block app access to OAuth 2.0 scopes via the Admin console. 

Apps can now be trusted, limited, or blocked. 


Getting started 

Rollout pace 

Availability 

  • Available to G Suite Basic, G Suite Business, G Suite Enterprise, G Suite for Education, G Suite Enterprise for Education, and G Suite for Nonprofits customers
  • Not available to G Suite Essentials and G Suite Enterprise Essentials customers

Resources 

Push device updates and settings to managed Windows 10 devices more quickly

Quick launch summary 

In April, we launched enhanced security for Windows. It allows admins to push device configuration updates, device settings, and more to Windows 10 devices remotely, without any specific network requirements. 

Now, it will be quicker for applied settings to take effect on managed devices faster. Previously, it could take up to six hours for settings to change on a device. With this update, they will take effect in a few minutes in most cases, as long as the device is connected to the internet. This will help ensure devices are updated and in compliance faster and that critical security updates are applied quickly. 


Getting started 

Rollout pace 

Availability 

  • Available to G Suite Enterprise, G Suite Enterprise for Education, G Suite Enterprise Essentials, and Cloud Identity Premium customers 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits, and G Suite Essentials customers 

Resources 

Updates to Admin console security settings section, new location for password policy reporting

What’s changing 

We’ve streamlined the security settings section of the Admin console. Specifically you may notice: 
  • Interface and content updates to Admin console > Security 
  • A new location for password policy reporting at Admin console > Reports 
See more details below. 


Who’s impacted 

Admins 


Why it matters 

This is the latest in a series of updates we’ve made in the last few months to improve the Admin console. These updates will make your security settings easier to see, and help you find important settings which can help you maintain a strong security posture for your organization. 


Additional details 

Interface and content updates to Admin console > Security 
  • An updated and reorganized interface for the main security settings section at Admin Console > Security. 
  • A new banner to the top of the Admin Console > Security page, which has links to learn more about security and privacy in Google Cloud. Previously this information was in a dedicated section (at Admin console > Security > Security and privacy resources) which has now been removed. 
  • The removal of password policy reporting from this section. It’s now been moved to the Reports section (see more below). 

A new location for password policy reporting at Admin console > Reports 
Data on user password policy compliance has been moved to the Reports section of the Admin console. Now you can find information such as password strength and length requirements at Admin Console > Reports > Accounts, and Admin Console > Reports > User reports > Security. Previously, this was at Admin console > Security > Password monitoring. 

By adding this data to the reports section, you can now use filters, view by OU, view historical values, and download reports features that were not available in the previous location. 

In addition, when reporting on password policy compliance, we now simply show whether or not a user’s password length is in compliance with the configured policy. Previously, we stated the specific length of the password. 


New password compliance information in the Admin console > Reports section 

You can now use filters, view by OU, view historical values, and download reports for password compliance data 

The new interface for the Security section of the Admin console 


Getting started 

Rollout pace 

Availability 

  • Available to all G Suite customers

Resources 

Strengthening 2-Step Verification by showing phone prompts to more users

What’s changing 

Starting on July 7, 2020, we will make phone verification prompts the primary 2-Step Verification (2SV) method for all eligible users, unless they are already using security keys as their 2SV method of choice. This means that if you sign in to your Google account and are also signed in on a smartphone, you will be asked to follow phone prompts to verify the login attempt. This will help increase account security while making it easier to sign in.

This won’t apply if you use a security key to protect your account. You’ll also still be able to use other methods (such as a code received by text) by selecting a different method during the phone prompt verification steps.
Phone prompts verify your sign-in attempt via your smartphone 


Who’s impacted 

End users

Why it’s important 

Phone prompts, also known as “on-device prompts,” are more secure than text or voice codes as a form of 2-Step Verification. They’re also easier to use, as they avoid requiring users to manually enter a code received on another device. By making prompts the primary method for more users, we hope to help them take advantage of the additional security without having to manually change settings—though they can still use other methods of 2-Step Verification if they prefer.


Additional details 

How phone prompts work 
After you enter your password to sign in to your Google Account, Google sends a "Trying to sign in?" prompt to every eligible mobile device where you’re signed in. This prompt tells you when and where your password was entered, and then asks you to confirm or block the sign-in attempt by simply tapping your mobile device. You can still select a different verification method during sign-in if one is available on your account. You’ll also stop receiving prompts on a phone if you sign out of that phone. Learn more about phone prompts.

Users with security keys are excluded from this change 
Users will not have prompts as their primary 2SV method in two situations:

  • If an organization enforces the “Only security key” 2-Step Verification option for a user, there will be no change and the user will continue to be required to use security keys. 
  • If a user currently has, or at any point in the future adds, a security key on their account, the security key verification will be presented as the primary method. 

Additionally, if a user doesn’t have 2-Step Verification turned on, this will not apply.


Getting started 



Rollout pace 



Availability 


  • Available to all G Suite customers and users with personal accounts. 

Resources