More Tips for Securing Your G Suite
Many startups, organisations, and larger enterprises today use the G Suite for their business productivity. The G Suite offers email services, calendars, collaborative document creation, file sharing, video conferencing and more. G Suite can also help manage the business IT infrastructure with MDM and SAML support. It puts much of the business activity in the cloud and makes it all available through the web browser.
As with most business Apps, there are some security risks, so Google takes security seriously and has been steadily improving the security features and APIs available for administrators to manage their data. In fact, the security features are a main product differentiator across the G Suite product tiers. This can be frustrating at times especially when looking at security gaps and how attackers compromise the G Suite. We believe that just as the G Suite has built better defences, attackers have also learned a few tricks of their own that every IT operations and security team should be aware of to better protect their organisation.
In this guide we cover some of the most important issues and actionable steps organisations should take to lock down their G Suite. If you have feedback, more tips, or suggestions we’d be happy to hear from you.
Trail of Bits wrote a very similar guide some time back and we’d like to kindly thank Dan Guido for sharing this with us. The tips there are solid and we’ve integrated them into our list below.
Update: May 4th, 2017. Due to the Google Phishing Worm going around we updated the OAuth sections to describe the Third Party Apps DLP feature in Beta for Google Enterprise customers
G Suite Best Practices
#1. Enforce Multifactor Authentication to Protect from Phishing
We covered this in our previous post on the topic. In summary, phishing and weak passwords are the largest vulnerability when it comes to the G Suite and multifactor is the strongest defence. We recommend U2F, Google Prompt, TOTP in that order and recommend enforcing multifactor unconditionally on your domain. For the details and some discussion to help you decide on a multifactor strategy check out the previous post.
Resources
#2. Understand and Backup Audit Reports
Another important aspect of securing your G Suite is getting visibility into how your data is being used and access in G Suite. Google Reports covers a number of areas and various third party products exist to help you analyze this information as as well.
In Reports some of the features include
- Alerting for Security Critical Events
- Aggregate reports of data sharing, security settings
- Near real-time audit logs
The audit logs cover:
- Login attempts
- Admin Activity
- SAML
- Tokens (for 3-legged OAuth logs)
- Drive activity
- Calendar activity
- Google Groups
This information is critical for investigations in case there is an incident, as well as for active threat monitoring for an organisation. It’s possible to find unauthorised data access and other malicious activity. Some of the information, such as IP addresses, can also be correlated with threat feeds.
Alerts
By default, not all of the available security alerts are enabled. It’s a good idea to turn them on for improved visibility. Alerts can be sent to a custom group and/or all superadmins. The alerts can show when new users gain privileges for example, and would detect lateral movement attempts inside of G Suite if a privileged user is compromised. It’s also possible to make custom alerts from audit log searches.
Make Backups
The audit log retention covers 180 days of activity. Though this may sound like a long time period, since most incidents actually take about 200 days or longer to discover according to some estimates, this data must be backed up for longer (we recommend 2 years) otherwise when it’s gone, it’s gone. This can be put into GCS itself or preferably another non-google storage mechanism.
For organisations with managed security services or an incident response/security devops team, this data is also great to put into centralised security metric stores for correlation and your team is probably already collecting it.
The Google Admin SDK provides API access for extracting the data. Be mindful to reduce the scopes to just the reporting APIs for these keys.
Resources
#3. Manage OAuth For Your Domain
For 3-legged OAuth users are susceptible to Phishing Attacks. Third party software such as Bettercloud can help manage this. Also if you’re a G Suite Enterprise customer ask your customer representative about getting the Third-Party Apps DLP/Data Leakage permission feature enabled. It’s currently in Beta and allows whitelisting OAuth usage.
Besides 3-legged OAuth, the G Suite API’s also work with 2-legged OAuth. Services working with 2-legged OAuth are given domain-wide access to user information without any user authorization. Many G Suite integrations and third party add ons which need the domain level access require this authorisation.
From the admin console, under Security→ Advanced Settings → Authentication you can manage API Client Access for 2-legged OAuth. The API Scopes should be as restrictive as possible as they limit the capabilities of that 2-legged OAuth. For example a directory services application shouldn’t need full access for creating new users or viewing emails. If there are tokens you do not recognise you should work to delete them and check audit logs to understand how they are being used, as the authentication logs will show up in the admin audit logs.
With the Admin SDK it is currently possible for a privileged service to impersonate other users and administrators. The APIs provides for an ‘ADMIN_EMAIL’ to be specified for SDK calls. Unfortunately, the audit logs do not record this impersonation and the records will show the actions as if they were performed as that user. The audit logs will show the API authentication at least. We’ve filed a feature request with Google for cleaning this issue up.
Because of this an organisation needs to guard their privileged service accounts very carefully and discourage privilege scopes. By turning on alerting for OAuth events it’s possible to get a heads up when new service accounts are approved for 2-legged OAuth. Being aware of these would mitigate lateral movement with new keys, but unfortunately it’s difficult to understand if an existing service key is being misused.
Resources
Manage 2-legged OAuth under Security→ Advanced Settings → Authentication
#4. Enable Email Security Features
Google already provides their own AV scanning of emails and makes it easy to report phishing and spam attempts. There’s an additional set of measures to take.
Stop Spoofing with DMARC, SPF, & DKIM
In addition to that, it’s important to lock down your domain further with DMARC, SPF, and DKIM to prevent spoofing with your domain names. Strong email DNS settings will also prevent emails from your organisations being marked as spam.
Keeping secure DNS settings for your domain protects both your customers from phishing attacks and also your employees themselves when they receive that office-printer@yourcompany.com email.
E-mail Encryption
Google does provide a hosted S/MIME feature for G Suite Enterprise customers for encrypting and signing e-mails. This can enforce email encryption for all outbound emails and could be useful for compliance. The encryption happens on the server side rather than client-side though, which may not be ideal depending on your organisation’s threat model.
If your organisation relies upon client-side S/MIME or PGP and wants to avoid any plaintext e-mail data from being stored with Google Mail, one critical thing to keep in mind is that many mail clients today will auto-save drafts on Google Mail by default. This may need to be disabled for sensitive work.
Limit Exposure to Email Data Leaks
These tips comes from the TOB guide. Disable read receipts, mail delegation, emailing profiles, automatic forwarding, and outbound gateways.
Resources
#4. Handle a Compromised Account Safely
In case a user has been compromised, Google provides a detailed checklist of steps to take to investigate and restore an account. Along with instructions on how to revoke tokens, and investigate unauthorised activity, there are some instructions on how to also check security critical email settings such as e-mail forwarding and mail filters which an attacker may have tampered with.
#5. Be Aware of Which Documents are Shared Publicly and on the Web
By default, documents which are shared publicly will not be indexed and available. However, if a link is shared on a web-page, or the document is published to the web, then the document could be indexed and generally available.
Set Sane Default Sharing Settings
The default settings may be okay for some organisations, but Google allows setting even stricter permissions for Drive & Docs sharing. If you want to avoid employees accidentally making a document public, we do recommend the following action. Set the Access checker prompt to only suggest recipients get a document (rather than the general public). Users can still share a document publicly unless you’ve also disabled that.
#6. Use Team Drive to Compartmentalise Information
For Business and Enterprise users, Google Drive supports teams for automatically delegating permissions to a group. This reduces the overhead of setting up document sharing within a team and simplifies onboarding when new members join a team. You can read more about Team Drive from Google.
#7. Keep Few Super-Admins, but consider at least three
As a best practice, delegate G Suite privileges on a need-to-have basis. Rather than creating dozens of super-admins, it’s best to create groups with only the specific privileges that they absolutely need, and keep super-admins to a very small number of accounts that are not used regularly. An account that is used for e-mail should not be a superadmin, instead special accounts should be created purely for administration.
This tip comes from Jon Oberheide. Once an organisation has at least three super-admins or more than 500 users, G Suite disables account self-recovery for admins. So if your organisation has fewer users, consider creating at least three dummy superadmin accounts to disable account self-recovery to add some friction to potential social engineering attacks.
#7. Audit Group Settings
Another great tip from Jon. G Suite makes it easy for users to accidentally create groups where the email archives are shared across the whole organisation. Regularly audit group settings to make sure groups that need to be confidential are configured correctly. In case a random employee is compromised they won’t be able to access highly privileged and confidential groups.
Manage Group Permissions
By default, the settings for a new group are not particularly secure and need to be locked down.
Manage Group Sharing Settings
Apps → G Suite → Settings for Groups & Business → Advanced Settings
#8. Disable Contact Sharing
From the TOB Guide, contact sharing lets internal users figure out who interacts with who. Additionally you can disable sharing domain profiles and contacts with external apps.
#9. Whitelist Marketplace Apps
And one more from the TOB Guide, it is possible to whitelist marketplace apps that users install. By default, the settings allow users to install any application.
Apps → Marketplace → Settings for Marketplace Apps
#10. Lock Down Google Talk/Hangouts
Apps → G Suite → Settings for Google Talk/Hangouts
A Note on Products
Be aware that Google differentiates their G Suite Security Features based on product level.
Common Security Pitfalls
Two-factor Authentication Must be Enforced to be Effective
Unless two-factor is enforced and enabled for users it won’t be effective. Simple, but true. Two factor should be mandatory by policy and taught on day one of on-boarding for new members to an organisation. Along with this, IT Admins need to think of and follow a policy for how to handle remote employee password resets and scratch codes. It’s often a great idea to include the team leader or hiring manager in the conversation to mitigate phishing against admins.
Three-Legged OAuth is a Potential Risk for Phishing
To grant an application access to their G Suite information, users can go through a 1-click dialogue that shows the scopes they are authorising an application. We think three-legged OAuth is particularly risky for phishing since as of today, G Suite itself does not provide any mechanism for Administrators to automatically disable and prevent the usage of 3-legged OAuth applications.
Many system administrators were surprised to see the number of corporate emails authorising Pokémon Go, for example. On the bright, abusing OAuth does leave a clear trail of OAuth token logs, creates a point source for Google to block if a malicious attack happens, and it also lets administrators revoke the tokens once issued.
As a security team it’s a good idea to regularly audit which applications and scopes are being authorised inside your organisation. The Admin SDK provides for enumerating and revoking tokens from users once they have authorised applications. Products such as Bettercloud also provide for management of Third-Party Apps and can do whitelisting and blacklisting. It’s likely they use the token revocation API to enforce policies, and if someone has more details we’d be happy to know, since we wonder about possible race conditions between authorisation and enforcement.
If you’re a G Suite Enterprise customer, ask your account representative about Third-Party Apps DLP which lets you whitelist OAuth usage.
Guard Two-Legged OAuth Keys Carefully
Because Two-Legged OAuth keys can provide domain-wide access to data they are highly interesting to attackers. One other thing to be especially aware of is user impersonation with the current Admin SDK APIs. Currently, audit logs fail to make it clear when impersonation happens, making the data potentially harder to comb through in case there’s been a serious incident since a lifted service key could have been used to impersonate a legitimate administrator. We’ve filed a feature request with Google to clean this up.
Failure to Follow Secure Account Cleanup
In case there’s been a real compromise, the checklist Google provides for handling a compromised account has important steps. It is important to go through all of them to build an accurate picture of any malicious activity that has occurred. We do not recommend skipping any of the revocation steps or skipping combing through mail filters, since attackers are well aware of abusing G Suite features for persistence inside of an organisation. The Admin SDK can be used to regularly monitor for suspicious mail forwarding and filter rules.
Hangouts Leaks Directory Information
Along with sources such as LinkedIn, Facebook, Github, and Twitter, adversaries are increasingly sourcing information about their targets from the online services that they may use. The G Suite is no exception in this regard.
If an attacker correctly guesses an email address, hangouts will verify that email address as accurate, provide full name information, and potentially a profile picture. In effect this makes your organisation’s google directory semi searchable by adversaries.
You can restrict hangouts to keeping them within your organisation only, but this may limit your ability to do video conferencing outside of your organisation effectively.
Apps → G Suite → Settings for Google Talk/Hangouts
Special Thanks for Feedback
We appreciate your feedback and hope this document is useful to you. We’d like to extend our thanks to Josef Rudenlöf for helpful ideas, Dan Guido for the Trail of Bits guide from 2015 , and Jon Oberheide for some more tips on disabling account self-recovery as well as Google Groups security.
Have More Tips?
We want to know if there’s something here that’s not quite right, or if there’s something that needs more details. Leave a comment or shoot us an email at tips+gsuite@longterm.io. We’re happy to learn more about G Suite
Resources
G Suite Security Best Practices
