Securing G Suite

Shortly after publishing Part 1 of my G Suite DFIR blog series, I gave a talk on the topic at BSides SATX. The talk had a super engaged audience and based on a few of the questions I received it became very clear that I needed to take a step back and first tell people how to secure their environment. This post aims to provide readers with a good baseline for a secure G Suite configuration and some recommendations related to preparing for worst case scenario.

Two Factor Authentication

Do it. Don’t question it. Just do it. Like right now. There is a reason this is the first section in this post. With G Suite, your users are not authenticating against an internal server that is invisible to the outside world. Anyone can access https://accounts.google.com/Login. And good chance that even with all the security awareness training in the world, you have at least one user who is using an easily brute-forced password or who will fall for a phishing email. When an attacker has those creds and your organization is not leveraging two factor-authentication (2FA), they are in. There is no firewall preventing them from accessing your mail server, there is no VPN access required to reach the login page.

By implementing 2FA in G Suite, you’ve exponentially reduced the chance of someone gaining access to any user accounts. If you are going to make one change to your G Suite configuration based on this blog post, this is the one to make. However, if the business is pushing back, there are several other things that you can do to prepare for the brute-forceable password or the phishing-susceptible employee.

Backing Up Logs

Depending on what tier of G Suite you subscribe to, there are going to be limits in place on how long your logs stick around. G Suite audit logs will be queriable for up to 6 months which is a pretty reasonable amount of time. However, email traffic logs will only stay around for 30 days in G Suite’s lowest subscription tier. In order to preserve the logs in case of the need for investigation during DFIR, it is best to offload these logs to a SIEM or log aggregation point. If an attacker has been in the organization’s G Suite for longer than the log storage periods, it is ideal to have back ups so that you still have the whole picture when the incident is detected.

Sadly, G Suite does not have a “Forward Logs” option so in order to do this, you would have to develop a program using Google’s API to ship the logs yourself. Not a flip switch, but if you have the capability it is worth considering implementing.

Securing Gmail

This section has a bullet point list of some recommended settings and the justification for each setting. All these settings are associated with the email functions of G Suite.

1. Set up DKIM/SPF - all around good practice for ensuring that your email is digitally signed so that the ability to successfully spoof your organization’s email is reduced.
2. Enable Early Phishing Detection - This setting provides more indepth scanning of inbound emails to improve detection of phishing & malicious emails.
3. Disable Mail Delegation - Mail delegation allows other users to respond on an accounts behalf. While sometimes handy, it can also lead to an extended impact if an attacker gets into an account that also has delegated access to other accounts.
4. Disable Automatic Forwarding - Automatic forwarding can be leveraged by an attacker as a persistence mechanism. If they get access to an account that allows automatic forwarding, they can send the email received by the compromised account to any outside email account they wish.
5. Disable per-user outbound gateways - This setting, if enabled, would allow a user account to by pass Google’s mail servers or the organization’s outbound gateway. This could be leveraged by an attacker as a way to send out malicious emails from a compromised account without being detected/stopped by Google or the organization.
6. Enable unintended external reply warning - External reply warnings provide awareness to the user about who they are sending their emails to in order to assist them in making sure that they don’t accidently email internal information to external entities.

Securing Google Drive

This section has a bullet point list of some additional recommended settings and the justification for each setting. All these settings are associated with the document editing and storage functions of G Suite.

1. Team Drives (Only for Business and Enterprise accounts) - Team Drives can be used to compartmentalize data so that all files adhere to least privelege. It is similar to shared folders but more manageable and uniform. It can ensure that if an account is compromised, they do not get ahold of more data than was required by the user they compromised.
2. Reduce Data Exposure - Though we’ve mentioned compromising accounts a lot in this article, there is a risk present even if an attacker can’t get into your organization. Namely, there is a lot of capabilities to allow data to be accessed publically or by outside entities. All your data should be locked down to only internal users or trusted third parties in order to assure that there is no accidental data leakage. Unless there is a use case that justifies it in your organization, you should disable the ability to share files publically.

Securing Everything Else

Gmail and Google Drive are the most commonly used (and arguably the highest risk) features in G Suite, which is why they had their own dedicated sections. However, they are just a drop in the bucket when it comes to capabilities included in a G Suite. Below are some additional settings that can improve the security posture of your G Suite account.

1. Enable out-of-domain warnings on Google Hangouts - Similar to the external reply warning, this setting informs users who are about to add external users to a Google Meet/Hangout call.
2. Limit Google Groups Access - Similar to Google Drive sharing, Google Groups can be a useful feature but can also lead to unintentional sharing of private information on a public forum. Settings for Google Groups allow a lot of granularity so leverage that to ensure only what is needed is enabled.
3. Restrict external calendar - Google Calendar is yet another feature that can lead to internal information being displayed publically. Details of calendar events are often not required for external entities not invited to the event so the ability to share all calendar events and details (as opposed to just a free/busy status) with outside entities should be disabled.
4. Whitelist marketplace apps - On top of G Suite’s built in features, there is a marketplace that allows for additional capabilities and applications to be used by your organization’s members. However, in order to avoid a user accidently installing a malicious app that made it into the marketplace or giving permissions to an app that might reveal private information to outside entities, it is best to whitelist the apps you are okay with users installing and blacklist all others.
5. Disable contact sharing - It is often the case that a company’s clientelle list is confidential information that should not be known by the public. For this reason, it is likely a good idea to disable contact sharing so that the list of clients and their contact details cannot accidently (or intentionally) easily fall into the hands of external parties.

Conclusion

Any one of the above settings can reduce the impact of data leakage, a compromise, or the impact that a compromise can cause. They should be implemented where possible in your organization to get your G Suite account in the best possible security posture. With any luck, these settings can prevent an incident in your orgnazation. However, the 3-part G Suite DFIR series will be resumed to assist with arming security teams to respond in the case that an attacker still finds their way into you account.