Service

Google Common Controls

Secure Cloud Business Applications (SCuBA)

Description

Secure Cloud Business Applications Minimum Viable Secure Configuration Baselines

CISA Google Workspace Security Configuration Baseline for Common Controls

The Google Workspace (GWS) Admin console is the primary configuration hub for configuring and setting up the subscription. The scope of this document is to provide recommendations for setting up the subscription's security controls. This Secure Configuration Baseline (SCB) provides specific policies to strengthen the security of a GWS tenant.

The Secure Cloud Business Applications (SCuBA) project provides guidance and capabilities to secure agencies' cloud business application environments and protect federal information that is created, accessed, shared, and stored in those environments. The SCuBA Secure Configuration Baselines (SCB) for Google Workspace (GWS) will help secure federal civilian executive branch (FCEB) information assets stored within GWS cloud environments through consistent, effective, modern, and manageable security configurations.

The CISA SCuBA SCBs for GWS help secure federal information assets stored within GWS cloud business application environments through consistent, effective, and manageable security configurations. CISA created baselines tailored to the federal government's threats and risk tolerance with the knowledge that every organization has different threat models and risk tolerance. Non-governmental organizations may also find value in applying these baselines to reduce risks.

The information in this document is being provided "as is" for INFORMATIONAL PURPOSES ONLY. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial entities or commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoritism by CISA.

This baseline is based on Google documentation and addresses the following:

Phishing-Resistant Multi-Factor Authentication
Context Aware Access
Login Challenges
User Session Duration
Secure Passwords
Highly Privileged Accounts
Conflicting Account Management
Catastrophic Recovery Options
GWS Advanced Protection Program
App Access to Google APIs
Authorized Marketplace Apps
Google Takeout Service
System-Defined Rules
Google Workspace Logs
Data Regions
Additional Google Services
Multi-Party Approvals

Assumptions

This document assumes the organization is using GWS Enterprise Plus. The Google Workspace (GWS) Common Controls Secure Configuration Baseline is unique among the GWS configuration baseline documents released by CISA in that it does not align to one specific GWS app. Implementers should be aware of this when cross-referencing the baseline statements to the live GWS admin console. Therefore, this document serves an enterprise-level compendium of implementable and testable configuration settings across the entire GWS admin console. The configurations specified herein correlate to the Security, Account, Directory, Rules, and Marketplace apps sections of the GWS admin console.

This document does not address, ensure compliance with, or supersede any law, regulation, or other authority. Entities are responsible for complying with any recordkeeping, privacy, and other laws that may apply to the use of technology. This document is not intended to, and does not, create any right or benefit for anyone against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.

This Common Controls baseline document:

Assumes users are familiar with overarching Federal cyber guidance and cloud security fundamentals such as the shared responsibility model;
Accounts for recent direction from Executive Order 14028, the Federal Zero Trust Strategy (published as Office of Management & Budget Memo M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles), CISA's Zero Trust Maturity Model, and the Federal Cloud Security Technical Reference Architecture;
Observes industry guidance such as the Center for Internet Security's Google Workspace Foundations benchmark and Google official documentation and white papers; and
Was developed with input from both the Office of Management & Budget (OMB) and Google product managers and security engineers.

Key Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Baseline Policies

1. Phishing-Resistant Multi-Factor Authentication

Multi-factor authentication (MFA), particularly phishing-resistant MFA, is a critical security control against attacks such as password spraying, password theft, and phishing. Adopting phishing-resistant MFA may take time, especially on mobile devices. Organizations must upgrade to a phishing-resistant MFA method as soon as possible to be compliant with OMB M-22-09 and this policy to address the critical security threat posed by modern phishing attacks. In the intermediate period before phishing-resistant MFA is fully adopted, organizations should adopt an MFA method from the list in GWS.COMMONCONTROLS.1.4v0.2 below.

This control recognizes federation as a viable option for phishing-resistant MFA and includes architectural considerations around on-premises and cloud-native identity federation in established Federal Civilian Executive Branch (FCEB) environments. Federation for GWS can be implemented via a cloud-native identity provider (IdP). Google's documentation acknowledges that on-premises Active Directory implementations may be predominant in environments that adopt GWS and provides guidance on the use of Google Cloud Directory Sync (GCDS) to synchronize Google Account data with an established Microsoft Active Directory or LDAP server.

The following graphic illustrates the spectrum of MFA options and their relative strength, with phishing resistant MFA (per OMB Memo 22-09) being the mandated method. Please note there is a distinction between Google 2 Step Verification (2SV) and MFA as a general term. While FIDO Security Key and Phone as a Security Key are acceptable forms of Phishing-Resistant MFA which rely on Google 2SV as the underlying mechanism, the other forms listed in the "strongest" column do not use Google 2SV but are still acceptable forms of Phishing-Resistant MFA.

Policies

GWS.COMMONCONTROLS.1.1v0.3

Phishing-Resistant MFA SHALL be required for all users.

> Phishing-resistant methods: - FIDO2 Security Key (directly in Google Workspace) - Phone as Security Key - FIDO2 Security Key (Federated from Identity Provider) - Federal Personal Identity Verification (PIV) card (Federated from agency Active Directory or other identity provider). - Google Passkeys

Rationale: Weaker forms of MFA do not protect against more sophisticated phishing attacks. Enforcing methods resistant to phishing reduces those risks. Additionally, phishing-resistant MFA is required for agency staff, contractors, and partners, by Office of Management and Budget Memo M-22-09.
Last modified: August 17, 2023
Note: Policy 1.1 applies if Phishing-Resistant MFA is available. Otherwise, Policy 1.4 applies.
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.1.2v0.3

Google 2SV new user enrollment period SHALL be set to 1 week.

Rationale: Enrollment must be enforced within a reasonable timeframe. 1 week balances the need for allowing new personnel time to set up their authentication methods and reducing the risks inherent to not enforcing MFA immediately.
Last modified: August 17, 2023
Note: This setting and policy only applies when the means of Phishing-Resistant MFA in use relies on Google 2SV.
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.1.3v0.3

Allow users to trust the device SHALL be disabled.

Rationale: Trusting the device allows users to bypass 2-Step Verification for future logins on that device. Disabling device trusting makes it possible for future logins on the same device to be protected by MFA.
Last modified: August 17, 2023
Note: This setting and policy only applies when the means of Phishing-Resistant MFA in use relies on Google 2SV.
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.1.4v0.3

If phishing-resistant MFA is not yet tenable, an MFA method from the following list SHALL be used in the interim

Google prompt

Google Authenticator

Backup Codes

Software Tokens One-Time Password (OTP): This option is commonly implemented using mobile phone authenticator apps

Hardware Tokens OTP

Rationale: This is a stopgap security policy to help protect the organization if phishing-resistant MFA has not been enforced. This policy requires MFA enforcement, thus reducing single-form authentication risk. Additionally, this list excludes SMS and voice call, the weakest authentication methods, forcing users to use stronger MFA methods.
Last modified: August 17, 2023
Note: ONLY to be enforced if Policy 1.1 is not possible for the agency. SMS or Voice as the MFA method SHALL NOT be used.
MITRE ATT&CK TTP Mapping

Resources

Prerequisites

FIDO2-compliant security keys

Implementation

Note: If using a third-party IdP with GWS, refer to Google documentation on setting up third-party single sign-on (SSO). If using GWS as the IdP, refer to Google documentation on setting up SSO.

To enforce Phishing-Resistant 2-Step Verification (MFA) for all users, use the Google Workspace Admin Console:

Policy 1 common Instructions

Sign in to Google Admin console as an administrator.
Select Security -> Authentication.
Select 2-Step Verification.

GWS.COMMONCONTROLS.1.1v0.3 Instructions

Under Authentication, ensure that Allow users to turn on 2-Step Verification is checked.
Set Enforcement to On.
Under Methods select Only security key.
Under Security codes select Don't allow users to select security codes.
Select Save

GWS.COMMONCONTROLS.1.2v0.3 Instructions

Set New user enrollment period to 1 Week.
Select Save

GWS.COMMONCONTROLS.1.3v0.3 Instructions

Under Frequency, deselect the Allow user to trust device checkbox.
Select Save

GWS.COMMONCONTROLS.1.4v0.3 Instructions

If using security keys:

Under Methods, select Only security Key. Next, select Don't allow users to select security codes.
Select Save

If security keys are not yet available for your organization:

Under Methods, select Any except verification codes via text, phone call.
Select Save

If using Passkeys, use the Google Workspace Admin Console:

Sign in to Google Admin console as an administrator.
Select Security -> Authentication -> Passwordless.
Select Skip passwords.
Select the Allow users to skip passwords at sign-in by using passkeys box.
Select Save

2. Context-aware Access

Device-based context-aware access provides access control policies based on device disposition attributes such as compliance with organizational secure configuration policies for devices (e.g., managed by Unified Endpoint Management). GWS also provides other context-aware access policies based on authentication and network information. These can be used to implement more targeted access policies. For advanced use cases, custom context aware access rules can be authored using the Common Expressions Language (CEL).

Device-based context-aware access can be used in several ways depending on agency business requirements. The following options are all acceptable approaches:

Properties of the device as reported by Google (encryption, screen lock, OS version, etc.)
Device inventory status (corporate-issued versus BYOD)
Use of Managed Chrome Browser
Data based on integration with certain third-party device management tools

It is extremely important to know how context-aware access policies affect one another, for example:

At a given scope (e.g., Organizational Unit [OU] or Group), each context aware access rule is evaluated separately. If any rule grants access, then access is allowed to the given application.
If rules are applied to OUs and Groups, which allow an action that may be denied after evaluating a policy at a higher level, then access will be allowed.

To enforce a device policy that requires company-owned devices, Google needs a list of serial numbers for company-owned devices.

Policies

GWS.COMMONCONTROLS.2.1v0.3

Policies restricting access to GWS based on signals about enterprise devices SHOULD be implemented.

Rationale: Granular device access control afforded by context-aware access is in alignment with Federal zero trust strategy and principles. Context-aware access can help to increase the security of your GWS data by allowing you to restrict access to certain applications or services based on user/device attributes.
Last modified: July 10, 2023
Note: More granular controls may be used if the agency needs it.
MITRE ATT&CK TTP Mapping
- T1098: Account Manipulation
  - T1098:005: Account Manipulation: Device Registration

Resources

Prerequisites

One or more of the following user roles should have been configured to set context-aware policies:

> Super admin > Delegated admin with each of these privileges: - Data Security -\> Access level management - Data Security -\> Rule management - Admin API Privileges -\> Groups\>Read - Admin API Privileges -\> Users\>Read
Serial numbers may be required to enforce a policy for company-owned devices. Refer to Google documentation on device management for additional guidance.

Implementation

GWS.COMMONCONTROLS.2.1v0.3 Instructions

To turn on Context-Aware Access:

Access the Google Admin console.
From the menu, go to Security -> Access and data control -> Context-Aware Access.
Verify Context-Aware Access is ON for everyone. If not, click Turn On.
Select Access Level and select Create Access Level and determine the conditions of the rule per agency needs.
Select Assign access levels to apps and select Apps to apply the rule onto.

Note that the implementation details of context-aware access use cases will vary per agency. Refer to Google's documentation on implementing context-aware access for your specific use cases. Common use cases include:

Require company-owned on desktop but not on mobile device
Require basic device security
Allow access to contractors only through the corporate network
Block access from known hijacker IP addresses
Allow or disallow access from specific locations
Use nested access levels instead of selecting multiple access levels during assignment

3. Login Challenges

Login challenges are additional security measures used to verify a user's identity. For example, Google might ask the user to confirm their recovery email before logging in as part of a challenge.

Policies

GWS.COMMONCONTROLS.3.1v0.3

Rationale: Without enabling Post-SSO verification, any Google 2-Step Verification (2SV) configuration is ignored for third-party SSO users. Enabling Post-SSO verification will apply 2SV verification policies.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

Resources

Prerequisites

When using Employee ID challenge, the Employee ID must be uploaded to Google Workspace through the Agency's Identity Management infrastructure (e.g., via GCDS).

Implementation

GWS.COMMONCONTROLS.3.1v0.3 Instructions

Sign in to Google Admin console as an administrator.
Select Security->Authentication->Login challenges.
Under Organizational units, ensure that the name for the entire organization is selected.
Click Post-SSO verification, then select Ask users for additional verifications from Google if a sign-in looks suspicious, and always apply 2-Step Verification policies (if configured). Click SAVE.
Optionally, if employee IDs are known to agency employees (or accessible to the employee outside of Google Workspace), they may be used.
Click Login challenges.
Select the Use employee ID to keep my users more secure checkbox.
Click SAVE.

4. User Session Duration

This control allows configuring of limits on how long a GWS session can be active before being prompted for authentication credentials.

Note: If using a third-party IdP, and agency-set web session lengths for its users, then there will be a need to set the IdP session length parameter to expire before the Google session expires to ensure users are forced to sign in again. See GWS documentation for additional details.

Policies

GWS.COMMONCONTROLS.4.1v0.3

Users SHALL be forced to re-authenticate after an established 12-hour GWS login session has expired.

Rationale: Allowing sessions to persist indefinitely allows users to bypass 2-Step Verification for future activity on that device. Limiting sessions to 12 hours may reduce the impact of session hijacking attacks and prevent users from inadvertently remaining logged in on unattended devices.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1550: Use Alternate Authentication Material
  - T1550:004: Use Alternate Authentication Material: Web Session Cookie
- T1078: Valid Accounts
  - T1078:004: Valid Accounts: Cloud Accounts

Resources

GWS Admin Help | Set session length for Google services

Prerequisites

None

Implementation

GWS.COMMONCONTROLS.4.1v0.3 Instructions

To configure Google session control:

Sign in to the Google Admin console as an administrator.
Select Security.
Select Access and data control -> Google session control.
Look for the Web session duration heading.
Set the duration to 12 hours.

5. Secure Passwords

Per NIST 800-63 and OMB M-22-09, ensure that user passwords do not expire and that long passwords are chosen. Research indicates that frequent password rotation breeds poor password choice and encourages password reuse. Ensure that passwords are strong to defend against brute-force attacks. Ensure that passwords are not reused to defend against credential theft.

Policies

GWS.COMMONCONTROLS.5.1v0.3

User password strength SHALL be enforced.

Rationale: Weak passwords increase the risk of account compromise. Enforcing password strength adds an additional layer of defense, reducing the risk of account compromise. Strong password policies protect an organization by prohibiting the use of weak passwords.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

GWS.COMMONCONTROLS.5.2v0.3

User password length SHALL be at least 12 characters.

Rationale: The National Institute of Standards and Technology (NIST) has published guidance indicating that password length is a primary factor in characterizing password strength (NIST SP 800-63B). Longer passwords tend to be more resistant to brute force and dictionary-based attacks.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

GWS.COMMONCONTROLS.5.3v0.3

Password policy SHALL be enforced at next sign-in.

Rationale: Unless the password policy is enforced at next login, a user could potentially operate indefinitely using a weak password. Enforcing the policy at next login helps ensure that all active user passwords meet current requirements.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

GWS.COMMONCONTROLS.5.4v0.3

User passwords SHALL NOT be reused.

Rationale: Password reuse represents a significant security risk. Preventing password reuse when possible limits the scope of a compromised password.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

GWS.COMMONCONTROLS.5.5v0.3

User passwords SHALL NOT expire.

Rationale: The National Institute of Standards and Technology (NIST), OMB, and Microsoft have published guidance indicating mandated periodic password changes make user accounts less secure. For example, OMB M-22-09 states, "Password policies must not require use of special characters or regular rotation."
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force

Resources

Prerequisites

None

Implementation

To configure a strong password policy is configured, use the Google Workspace Admin Console:

Policy Group 5 common Instructions

Sign in to the Google Admin console as an administrator.
Select Security -> Authentication.
Locate Password management.
Follow implementation for each individual policy.
Select Save.

GWS.COMMONCONTROLS.5.1v0.3 Instructions

Under Strength, select the Enforce strong password checkbox.

GWS.COMMONCONTROLS.5.2v0.3 Instructions

Under Length, set Minimum Length to 12+.

GWS.COMMONCONTROLS.5.3v0.3 Instructions

Under Strength and Length enforcement, select the Enforce password policy at next sign-in checkbox.

GWS.COMMONCONTROLS.5.4v0.3 Instructions

Under Reuse, deselect the Allow password reuse checkbox.

GWS.COMMONCONTROLS.5.5v0.3 Instructions

Under Expiration, select Never Expires.

6. Highly Privileged Accounts

Highly privileged accounts represent significant risk to an agency if compromised or if insiders use them in an unauthorized way. Highly privileged accounts share the same risk factors related to the catastrophic impacts on GWS services, user community and agency data, if compromised. This section supports the definition of highly privileged accounts and the controls necessary to protect them.

Pre-Built GWS Admin Roles considered highly privileged:

Super Admin: This role possesses critical control over the entire GWS structure. It has access to all features in the Admin Console and Admin API and can manage every aspect of agency GWS accounts.
User Management Admin: This account has rights to add, remove, and delete normal users in addition to managing all user passwords, security settings, and other management tasks that make it potentially crucial if compromised.
Services Admin: This admin has full rights to turn on or off GWS services and security settings for these services (Gmail, Drive, Voice, etc.). Given that most GWS features are premised on these services being secure, compromise of this account would be critical.
Mobile Admin: This admin has full rights to manage all the agency mobile devices including authorizing their use and controlling the apps that can be downloaded and used on them. This admin can also set the security policies on all agency mobile devices connected to GWS.
Groups Admin: This admin has full rights to view profiles in the organizational and OU structures and can manage all rights for those members in the group.

Policies

GWS.COMMONCONTROLS.6.1v0.3

All highly privileged accounts SHALL leverage Google Account authentication with phishing-resistant MFA and not the agency's authoritative on-premises or federated identity system.

Rationale: Leveraging Google Account authentication with phishing resistant MFA for highly privileged accounts reduces the risks associated with a compromise of on-premises federation infrastructure. This makes it more challenging for an adversary to pivot from a compromised on-premises environment to the cloud with privileged access.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force
- T1556: Modifying Authentication Process
  - T1556:006: Modifying Authentication Process: Multi-Factor Authentication

GWS.COMMONCONTROLS.6.2v0.3

A minimum of two and maximum of eight separate and distinct super admin users SHALL be configured.

Rationale: The super admin role provides unfettered access to the workspace. Properly managing the number of users with this level of access makes workspace compromise more challenging. However, having too few accounts can be problematic as it increases the risk of losing admin access entirely (e.g., if a super admin forgets their password); having between 2 and 4 balances these two concerns.
Last modified: July 10, 2023
Note: Admin count does not include "break-glass" super admin accounts.
MITRE ATT&CK TTP Mapping
- T1136: Create Account
  - T1136:003: Create Account: Cloud Account
- T1098: Account Manipulation
  - T1098:003: Account Manipulation: Additional Cloud Roles

Resources

Prerequisites

Super admin users cannot log in to admin.google.com with a third-party IdP when using super admin level accounts—they must use Google Login as the authentication mechanism. This policy extends this rule to other admin types.
Delegated accounts, including the ones defined as highly privileged above, can by default, use a third-party IdP to access admin.google.com: however, this policy prohibits that practice. All highly privileged accounts must use phishing resistant Google Authentication.

Implementation

GWS.COMMONCONTROLS.6.1v0.3 Instructions

The implementation process for this can be located here.

GWS.COMMONCONTROLS.6.2v0.3 Instructions

To obtain a list of all GWS Super Admins:

Sign in to the Google Admin console as an administrator.
Navigate to Account -> Admin Roles.
Click the Super Admin role in the list of roles
The subsequent dialog provides a list of Super Admins.

7. Conflicting Account Management

It is possible for employees of an organization to create conflicting, unmanaged accounts that are unmanaged by an enterprise's Google Workspace tenant. Unmanaged accounts are defined as users who independently created a Google account using the organization's domain. For example, a user with an enterprise/corporate email of user@company.com could create a personal, unmanaged Google account using that email address. This would create an account conflict in a GWS tenant licensed to company.com since email addresses are unique.

Creating a conflicting account can also happen unintentionally. After signing up for Google Cloud Identity or Google Workspace, admins might decide to set up single sign-on with an external identity provider (IdP) such as Azure Active Directory (AD) or Active Directory. When configured, the external IdP might automatically create accounts in Cloud Identity or Google Workspace for all users for which single sign-on was enabled, inadvertently creating conflicting accounts.

Unmanaged accounts carry significant risk, as they cannot be managed by admins, rendering them outside of the scope of protection admins can apply to keep work data secure. Significantly, two-step verification (2SV) cannot be enforced. Even if access is revoked, these accounts can carry a social engineering risk. Further, reconciling conflicting accounts creates churn for admins and adds to the workload of onboarding users to Google Workspace & Google Cloud.

The GWS admin console provides several administrative options for handling conflicting, unmanaged accounts:

Automatically invite users to transfer unmanaged accounts.
Replace unmanaged accounts with managed ones.
Don't create new accounts if unmanaged accounts exist.

This policy requires replacing unmanaged accounts with managed ones. When this option is configured, data owned by the account will not be imported; the user will receive a temporary account address, which they'll need to manually replace with a @gmail.com address of their choice; the user will receive an email notification of this and are informed they cannot use the original email any longer.

By changing the email address, the user resolves the conflict by ensuring that the managed account and consumer account have different identities. The result remains that they have one consumer account that has all their original data, and one managed account that doesn't have access to the original data.

Policies

GWS.COMMONCONTROLS.7.1v0.3

Account conflict management SHALL be configured to replace conflicting unmanaged accounts with managed ones.

Rationale: Unmanaged user accounts cannot be controlled or monitored by workspace admins. By resolving conflicting accounts, you ensure all users in your workspace are using managed accounts.
Last modified: September 14, 2023
MITRE ATT&CK TTP Mapping

Resources

Prerequisites

Super Admin privileges

Implementation

GWS.COMMONCONTROLS.7.1v0.3 Instructions

To configure account conflict management per the policy:

Sign in to the Google Admin console as an administrator.
Navigate to Account -> Account settings.
Click the Conflicting accounts management card.
Select the radio button option: "Replace conflicting unmanaged accounts with managed ones."
Click Save.

8. Catastrophic Recovery Options for Super Admins

This section covers the admin self-recovery setting that is in Google Admin console.

Policies

GWS.COMMONCONTROLS.8.1v0.3

Account self-recovery for Super Admins SHALL be disabled

Rationale: If enabled, an adversary could attempt to gain access to a super admin account through the account recovery method. Disabling this feature forces super admins to contact another super admin to recover their account, making it more difficult for a potential adversary to compromise their account.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1556: Modifying Authentication Process
  - T1556:006: Modifying Authentication Process: Multi-Factor Authentication

Resources

Prerequisites

None

Implementation

GWS.COMMONCONTROLS.8.1v0.3 Instructions

To disable Super Admin account self-recovery:

Sign in to https://admin.google.com as an administrator.
Select Security -> Authentication.
Select Account Recovery.
Click Super admin account recovery.
To apply the setting to all your Super Admins, leave the top OU selected. Otherwise, select a child OU or a configuration group.
Deselect the Allow Super Admins to recover their account checkbox.
Click Save.
Ask your Super Admins to set up a recovery phone number or email address for receiving password recovery instructions.

9. GWS Advanced Protection Program

This control enforces more secure protection of highly privileged, senior executive and sensitive users accounts from targeted attacks. It enforces optional GWS user security features like:

Strong authentication with security keys
Use of security codes with security keys
Restrictions on third-party access to account data
Deep Gmail scans
Google Safe Browsing protections in Chrome
Account recovery through admin

Policies

GWS.COMMONCONTROLS.9.1v0.3

Highly privileged accounts SHALL be enrolled in the GWS Advanced Protection Program.

Rationale: Sophisticated phishing tactics can trick even the most savvy users into giving their sign-in credentials to attackers. Advanced Protection requires you to use a security key, which is a hardware device or special software on your phone used to verify your identity, to sign in to your Google Account. Unauthorized users won't be able to sign in without your security key, even if they have your username and password. The Advanced Protection Program includes a curated group of high-security policies that are applied to enrolled accounts. Additional policies may be added to the Advanced Protection Program to ensure the protections are current.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force
- T1556: Modifying Authentication Process
  - T1556:006: Modifying Authentication Process: Multi-Factor Authentication

GWS.COMMONCONTROLS.9.2v0.3

All sensitive user accounts SHOULD be enrolled into the GWS Advanced Protection Program.

Rationale: Sophisticated phishing tactics can trick even the most savvy users into giving their sign-in credentials to attackers. Advanced Protection requires you to use a security key, which is a hardware device or special software on your phone used to verify your identity, to sign in to your Google Account. Unauthorized users won't be able to sign in without your security key, even if they have your username and password. The Advanced Protection Program includes a curated group of high-security policies that are applied to enrolled accounts. Additional policies may be added to the Advanced Protection Program to ensure the protections are current.
Last modified: July 10, 2023
Note: This control enforces more secure protection of sensitive user accounts from targeted attacks. Sensitive user accounts include political appointees, Senior Executive Service (SES) officials, or other senior officials whose account compromise would pose a level of risk prohibitive to agency mission fulfillment
MITRE ATT&CK TTP Mapping
- T1110: Brute Force
- T1556: Modifying Authentication Process
  - T1556:006: Modifying Authentication Process: Multi-Factor Authentication

Resources

Prerequisites

Two security keys are required for added assurance. If one key is lost or damaged, users can use the second key to regain account access.

Implementation

Policy Group 9 Instructions

To allow all users to enroll:

Sign in to the Google Admin console as an administrator.
Select Security -> Authentication -> Advanced Protection Program.
On the right, locate the Advanced Protection header.
Locate the Allow users to enroll in the Advanced Protection Program header.
Select Enable user enrollment.
Click SAVE.

10. App Access to Google APIs

Agencies need to have a process in place to manage and control application access to GWS data. This control enables the ability to restrict access to Google Workspace APIs from other applications and is aimed at mitigating the significant cybersecurity risk posed by the potential compromise of OAuth tokens. The baseline policy statements are written to allow implementers to balance operational need with risk posed by granting app access.

Policies

GWS.COMMONCONTROLS.10.1v0.3

Agencies SHALL use GWS application access control policies to restrict access to all GWS services by third party apps.

Rationale: Third-party apps may include malicious content. Restricting app access to only apps trusted by the agency reduces the risk of allowing malicious apps to connect to the workspace.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.10.2v0.3

Agencies SHALL NOT allow users to consent to access to low-risk scopes.

Rationale: Allowing users to give access to OAuth scopes that aren't classified as high-risk could still allow for apps that are not trusted to be granted access by non-administrator personnel and without having to be allowlisted in accordance with policy 10.1.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.10.3v0.3

Agencies SHALL NOT trust unconfigured internal apps.

Rationale: Internal apps may contain vulnerabilities or even malicious content created by compromised user accounts. Restricting access to these apps reduces the risk of allowing unsafe apps to connect to the workspace.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.10.4v0.3

Agencies SHALL NOT allow users to access unconfigured third-party apps.

Rationale: External apps may contain vulnerabilities and malicious content. Restricting access to these apps reduces the risk of allowing unsafe apps to connect to the workspace.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping

Resources

Prerequisites

None

Implementation

Policy Group 10 Instructions

Sign in to Google Admin console.
Go to Security -> Access and Data Control -> API controls.

GWS.COMMONCONTROLS.10.1v0.3 instructions:

Select Manage Google Services.
Select the Services box to check all services boxes.
Once this box is selected, then the Change access link at the top of console will be available; select it.
Select Restricted: Only trusted apps can access a service.
Select Change then confirm if prompted.

GWS.COMMONCONTROLS.10.2v0.3 instructions:

Select Manage Google Services.
Select the Services box to check all services boxes.
Once this box is selected, then the Change access link at the top of console will be available; select it.
Ensure to uncheck the check box next to For apps that are not trusted, allow users to give access to OAuth scopes that aren't classified as high-risk.
Select Change then confirm if prompted.

GWS.COMMONCONTROLS.10.3v0.3 Instructions

Select Settings.
Select Internal apps and uncheck the box next to Trust internal apps.
Select SAVE.

GWS.COMMONCONTROLS.10.4v0.3 Instructions

Select Settings.
Select Unconfigured third-party apps and select Don't allow users to access any third-party apps
Select SAVE.

It should be noted that admins will have to manually approve each trusted app. The implementation steps for this activity are outlined in Google's documentation on controlling which third-party & internal apps access GWS data (also listed under Resources).

11. Authorized Google Marketplace Apps

This section enables the ability to restrict the installation of Google Workspace Marketplace apps to a defined list provided and configured in the app allowlist. This guidance includes and applies to internally developed applications. This control disables legacy authentication and requires the use of modern authentication protocols based on federation for access from applications.

Some older versions of common software may break when this control is implemented. Examples of these apps include:

Mails configured with POP3
Older versions of Outlook

Policies

GWS.COMMONCONTROLS.11.1v0.3

Only approved Google Workspace Marketplace applications SHALL be allowed for installation.

Rationale: Marketplace apps may include malicious content. Restricting app access to only apps trusted by the agency reduces the risk of allowing malicious apps to connect to the workspace.
Last modified: October 24, 2023
MITRE ATT&CK TTP Mapping
- T1195: Supply Chain Compromise
  - T1195:002: Supply Chain Compromise: Compromise Software Supply Chain

GWS.COMMONCONTROLS.11.2v0.3

Access to Google Workspace applications by less secure apps that do not meet security standards for authentication SHALL be prevented.

Rationale: Antiquated authentication methods introduce additional risk into the workspace environment. Only allowing apps that use modern authentication standards helps reduce the risk of credential compromise.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1110: Brute Force
- T1566: Phishing
  - T1566:002: Phishing: Spearphishing Link

Resources

Prerequisites

None

Implementation

GWS.COMMONCONTROLS.11.1v0.3 Instructions

Sign in to the Google Admin console as an administrator.
Select Apps -> Google Workspace Marketplace apps -> Settings.
Select Allow users to install and run allowlisted apps from the Marketplace.
Ensure that the Allow exception for internal apps. Users can install and run any internal app, even if it is not allowlisted. checkbox is unchecked.
Click Save.

To add an app to the allowlist:

On the left-hand side above Setting, click Apps lists.
Click the ALLOWLIST APP to add an app to the allow list.

or
Click Allowlisted Apps to manage the allow list.

GWS.COMMONCONTROLS.11.2v0.3 Instructions

Sign in to the Google Admin console as an administrator.
Select Security.
Select Access and data control -> Less secure apps.
Select Disable access to less secure apps (Recommended).
Click Save to commit this configuration change.

12. Google Takeout Services for Users

This section prevents users from downloading a copy of the Google Takeout service's data to their user accounts. Services include Google Blogger, Books, Maps, Pay, Photos, Play, Play Console, Location History and YouTube, among numerous others.

Policies

GWS.COMMONCONTROLS.12.1v0.3

Google Takeout services SHALL be disabled.

Rationale: Google Takeout is a service that allows you to download a copy of your data stored within 40+ Google products and services, including data from Gmail, Drive, Photos, and Calendar. While there may be a valid use case for individuals to back up their data in non-enterprise settings, this feature represents considerable attack surface as a mass data exfiltration mechanism, particularly in enterprise settings where other backup mechanisms are likely in use.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1530: Data from Cloud Storage

Resources

Prerequisites

Determine which OU or access group will be affected by this policy and confirm that the right user and system accounts are in that OU or access group.

Implementation

GWS.COMMONCONTROLS.12.1v0.3 Instructions

Sign in to https://admin.google.com as an administrator.
Select Account then Google Takeout.
Select User access to Takeout for Google services.
For services without an individual admin control, select Services without an individual admin control then Edit.
Select Don't allow for everyone.
Click Save.
For services with an individual admin control, under apps select the checkbox next to Service name and select Don't allow.
Click Save.

13. System-defined Rules

GWS includes system-defined alerting rules that provide situational awareness into risky events and actions. A security best practice is to enable the following list of rules. Please note that some, but not all, of these rules may be set to "on" by default. Rules that are not listed may be useful but not security relevant. Review all system-defined rules to implement the appropriate configuration based on individual requirements.

Google security checklist for medium and large businesses
Government-backed attacks
User-reported phishing
User's Admin privilege revoked
User suspended for spamming through relay
User suspended for spamming
User suspended due to suspicious activity
User suspended (Google identity alert)
User suspended (by admin)
User granted Admin privilege
User deleted
Suspicious programmatic login
Suspicious message reported
Suspicious login
Suspicious device activity
Suspended user made active
Spike in user-reported spam
Rate limited recipient
Phishing message detected post-delivery
Phishing in inboxes due to bad allowlist
New user added
Mobile settings changed
Malware message detected post-delivery
Leaked password
Google Operations
Gmail potential employee spoofing
Email settings changed
Drive settings changed
Domain data export initiated
Device compromised
Calendar settings changed
Account suspension warning
Client-side encryption service unavailable

Policies

GWS.COMMONCONTROLS.13.1v0.3

Required system-defined alerting rules, as listed in the Policy group description, SHALL be enabled with alerts.

Rationale: Potentially malicious or service-impacting events may go undetected. Setting up a mechanism to alert administrators to the list of events linked above draws attention to them to minimize any impact to users and the agency.
Last modified: July 10, 2023
Note: Any system-defined rules not listed are considered optional but should be reviewed and considered for activation by an administrator.
MITRE ATT&CK TTP Mapping
- T1562: Impair Defenses
  - T1562:001: Impair Defenses: Disable or Modify Tools

Resources

Prerequisites

None

Implementation

GWS.COMMONCONTROLS.13.1v0.3 Instructions

Sign in to Google Admin console.
On the left navigation pane, click the hamburger menu above Home->Show more.
Click Rules.
From the Rules page, click Add a filter.
From the drop-down menu, select Type.
Select the System defined check box.
Click Apply.
A list of system defined rules displays. Select one of the rules from the list by clicking the table row for that rule—for example, the Device compromised rule.
From the Rule details page, you can view the conditions and actions for the rule—for example, to confirm if email notifications are turned on, and to confirm the recipients for those email notifications.
Click Edit Rule.
Click Next: View Conditions.
Click Next: Add Actions.
From the Actions page, you can change the severity for the alert to High, Medium, or Low, send an alert to the alert center if the rule's conditions are met, set up admin email notifications, and specify recipients for those notifications.
Click Next: Review.
Review the updated rule details, and then click Update Rule.

14. Google Workspace Logs

Configure GWS to send critical logs to the agency's centralized Security Information and Event Management (SIEM) so that they can be audited and queried. Configure GWS to send logs to a storage account and retain them for when incident response is needed.

Policy

GWS.COMMONCONTROLS.14.1v0.3

The following critical logs SHALL be sent to the agency's centralized SIEM.

> Admin Audit logs > Enterprise Groups Audit logs > Login Audit logs > OAuth Token Audit logs > SAML Audit log > Context Aware Access logs

Rationale: This policy enhances security by centralizing critical logs in the agency's Security Information and Event Management (SIEM) system, enabling timely detection and response to potential security incidents. It also aids agency compliance with applicable law and binding policy and helps maintain the confidentiality, integrity, and availability of the agency's information systems.
Last modified: July 10, 2023
MITRE ATT&CK TTP Mapping
- T1562: Impair Defenses
  - T1562:008: Impair Defenses: Disable Cloud Logs

GWS.COMMONCONTROLS.14.2v0.3

Audit logs SHALL be maintained for at least 6 months in active storage and an additional 18 months in cold storage, as dictated by OMB M-21-31.

Rationale: Audit logs may be unavailable when needed if they are not retained for a sufficient time. Increased log retention time gives an agency the necessary visibility to investigate incidents that occurred some time ago.
Last modified: January 30, 2024
MITRE ATT&CK TTP Mapping
- T1562: Impair Defenses
  - T1562:008: Impair Defenses: Disable Cloud Logs

Resources

Prerequisites

None

Implementation

GWS.COMMONCONTROLS.14.1v0.3 Instructions

Follow the configuration instructions unique to the products and integration patterns at your organization to send the security logs to the security operations center for monitoring.

Note: Agencies can benefit from security detection capabilities offered by the CISA Cloud Log Aggregation Warehouse (CLAW) system. Agencies are urged to send the logs to CLAW. Contact CISA at [cyberliason@cisa.dhs.gov]

GWS.COMMONCONTROLS.14.2v0.3 Instructions

There is no implementation for this policy.

15. Data Regions and Storage

Google Workspace administrators can choose to store data in a specific geographic region (currently the United States or Europe) by using a data region policy. The policy can be applied to a specific organizational unit (OU) in a tenant or at the parent OU. For the interests of Federal agencies, the best practice is to restrict stored data for all users to the U.S. This means applying this setting at the parent OU. Data region storage covers the primary data-at-rest (including backups) for Google Workspace core services (see resources section for services in scope).

At the time of writing, data region policies cannot be applied to data types not specifically listed in documentation linked in the resources section. Notably, this includes logs and cached content.

Policy

GWS.COMMONCONTROLS.15.1v0.3

The data storage region SHALL be set to be the United States for all users in the agency's GWS environment.

Rationale: Without this policy, data could be stored in various regions, potentially exposing it to unauthorized entities. Implementing this policy keeps most data in the U.S., making it harder for potential foreign adversaries to compromise the data.
Last modified: October 30, 2023
MITRE ATT&CK TTP Mapping

GWS.COMMONCONTROLS.15.2v0.3

The supplemental data storage region SHALL NOT be set to 'Russian Federation'.

Rationale: This policy is aligned with the concept of sovereignty, taking into account geopolitical and USG national security concerns. Keeping data out of Russia helps prevent official data from being subject to Russian law.
Last modified: November 30, 2023
MITRE ATT&CK TTP Mapping
- T1530: Data from Cloud Storage

Resources

Prerequisites

Super Admin role

Implementation

GWS.COMMONCONTROLS.15.1v0.3 Instructions

To configure Data Regions per the policy:

Sign in to the Google Admin console as an administrator.
Navigate to Account -> Account settings.
Click the Data Regions card.
Click the Data Regions policy card.
Select the radio button option: "United States"
Click Save.

GWS.COMMONCONTROLS.15.2v0.3 Instructions

To configure Supplemental Data Storage per the policy:

Sign in to the Google Admin console as an administrator.
Navigate to Account -> Account settings.
Click the Supplemental Data Storage card.
Ensure the checkbox for "Russian Federation" is unchecked.
Click Save.

16. Additional Google Services

This section covers the Google services that do not have an individual control and whether these services are on or off.

Policy

GWS.COMMONCONTROLS.16.1v0.3

Service status for Google services that do not have an individual control SHOULD be set to OFF for everyone.

Rationale: Allowing access to additional google services without a need may create unnecessary vulnerabilities within the Google Workspace environment. By turning these services off, it mitigates the risk by not allowing access.
Last modified: June 11, 2024
MITRE ATT&CK TTP Mapping

Resources

GWS Admin Help | Turn on or off additional Google services

Prerequisites

Super Admin role

Implementation

GWS.COMMONCONTROLS.16.1v0.3 Instructions

To configure additional services per the policy:

Sign in to the Google Admin console as an administrator.
Navigate to Apps -> Additional Google services.
Click CHANGE at the top where it says if Access to additional services without individual control for all organizational units is On/Off.
Select the option: "OFF for everyone"
Click Save.

17. Multi-Party Approval

This section covers whether multiple super admins need to approve changes to specific admin console settings.

Policy

GWS.COMMONCONTROLS.17.1v0.3

Require multi party approval for sensitive admin actions SHALL be enabled.

Rationale: Changes to sensitive admin settings, such as disabling 2-step verification, could introduce serious vulnerabilities in the GWS environment. Requiring multiple super admins to approve changes to those settings mitigates the risk changing these settings pose.
Last modified: June 20, 2024
MITRE ATT&CK TTP Mapping
- No TTP Mappings

Resources

GWS Admin Help | Multi-party approval for sensitive actions

Prerequisites

Super Admin role

Implementation

GWS.COMMONCONTROLS.17.1v0.3 Instructions

To configure additional services per the policy:

Sign in to the Google Admin console as an administrator.
Navigate to Security -> Authentication -> Multi-party approval settings.
Ensure Require multi party approval for sensitive admin actions is checked.
Click Save.