G Suite Security Controls

Overview

Securing a G Suite domain, as with any security process, should be based on a balance of risks with benefits. It should be a “living process” that evolves based on new threats, capabilities, and business needs. To help customers implement the appropriate balance for their needs, Google provides numerous administrative and security controls to configure their G Suite domain.

We will check how Google secures users and their data.

User credentials

Usernames and passwords combination is the primary method by which any user can access data within G Suite; therefore, an understanding of the configuration options available and the implications of those options are critical. There are two ways to manage passwords, either directly within G Suite or using a Security Assertion Markup Language 2.0 (SAML 2.0)–compliant Single Sign-On (SSO) system. Additionally, beyond the programmatic controls presented here, it’s critical to understand how your business policies (for example, password rotation requirements) may impact username and password security.

A Google password refers to a password stored within Google’s infrastructure, and is the primary mechanism used for signing in to G Suite when SSO is not enabled. A Google password is also required for signing in to services that don’t support SSO, and always for super administrator accounts.

For example, Google Sync doesn’t support SSO authentication and requires a Google password. Most Internet Message Access Protocol (IMAP) and Simple Mail Transfer Protocol (SMTP) clients also don’t support SSO authentication and require a Google password.

A Google password can contain any combination of ASCII characters and must contain between 8 and 100 characters. Within G Suite, you can specify the minimum and a maximum number of characters, within the specified guidelines, and monitor the length and relative strength of your users’ passwords.

SAML SSO

G Suite supports SAML 2.0-compliant SSO systems for organizations that want to apply additional controls around user authentication or integrate a single authentication system with other cloud-based or on-premise applications.

In this configuration, Google operates as the Service Provider (SP) and the customer's SSO system operates as the identity provider (IdP). If an SSO system is configured in G Suite, any non-super administrators will be redirected to the SSO system when attempting to authenticate.

2 Step Verification

Multifactor verification is one of the most effective mechanisms to protect against account compromise due to phishing or password reuse. While complex passwords and other security mechanisms mitigate the risk of an attacker guessing a user's password, these protections do nothing to mitigate against compromise from reused passwords or phishing attacks. To mitigate the risk posed by compromised passwords, Google implemented 2 step verification in the year 2011. By requiring a username, password, and a unique 6-digit passcode (regenerated every 30 seconds), the ability for an attacker to compromise an account (even if they know the username and password) is substantially minimized.

Apps Password

As with SAML SSO, certain protocols don’t support 2SV, for example, Google Sync on iOS and certain IMAP clients. When 2SV is enabled on an account, G Suite provides a mechanism called App passwords (previously Application Specific Passwords [ASPs]) that generates random, 16-character passwords for use with a G Suite account. These passwords are intended to be used only once, to set up an application or device, and can be monitored or revoked via the Google Admin console.

In Transit

Google uses Transport Layer Security (TLS) to provide encryption for data in transit between the browser and Google services. In 2011, Google enables forward secrecy (FS) to provide additional protection against retrospective decryption. To take full advantage of Google's encryption, it’s critical to use a modern browser and OS.

Google also supports advanced TLS for email when it’s sent or received, which means Google tries to communicate using encrypted means if the other server supports it; however, Google reverts back to unencrypted communication if required. Gmail can also be configured to enforce TLS when sending or receiving email with specific domains; if an encrypted connection can’t be established, it results in an error and the messages aren’t sent or received.

Email Security

G Suite Email Security is an extensive set of controls around spam, compliance, and routing. While many of these settings are global settings, there are several best practices to consider when securing a G Suite domain.

• Spam — Minimize the use of email whitelists and approved senders. If senders’ messages are quarantined as spam, work with the sender to properly configure their email system and message content.

• Inbound gateway — Use only an inbound mail gateway if required. If used, ensure it’s configured properly for Sender Policy Framework (SPF) and to allow G Suite to perform additional spam and phishing protection.

• Compliance — Require TLS when communicating with partner domains that support TLS.

• Routing — Minimize routing complexity to allow for easier troubleshooting.

• Forwarding — Disable automatic forwarding for the domain to prevent users from forwarding emails to other email accounts.

• Comprehensive mail storage — Enable this setting to ensure that all emails sent from other services like Drive and Calendar are logged in the user’s mailbox.

DNS settings

Sender Policy Framework (SPF) provides a mechanism to help ensure that only approved mail servers are used to send mail on your domain’s behalf. This is a key component in preventing external malicious actors from spoofing your domain (a common tactic used for spam and phishing). To set up SPF with G Suite, ensure that “include:_spf.google.com” is added to your SPF record. Additionally, after you have verified that all servers (that may send mail on your behalf) are included in your SPF record, we recommend setting a hard fail (-all).

DomainKeys Identified Mail (DKIM) is a complementary technology that cryptographically signs a message to verify that the message came from your domain and that it hasn’t been changed along the way. If you use an outbound gateway, ensure that it doesn’t modify the message in any way to avoid “breaking” DKIM.

Domain-based Message Authentication, Reporting and Conformance (DMARC) provides a method for senders to recommend how recipients treat messages purporting to come from their domain and a way for recipients to report back on authentication failures. DMARC can be configured in “reporting only” mode initially and then deployed slowly.