Google Common Controls
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.2
-
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.2
-
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.2
-
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.2
-
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
- GWS Admin Help | Set up 2-Step Verification (Deploy)
- GWS Admin Help | Set up 2-Step Verification (Protect your business)
- GWS Admin Help | Set up SSO via a third-party Identity provider
- Google Cloud Architecture Center | Federating Google Cloud with Active Directory
- Google Cloud Architecture Center | Federating Google Cloud with Azure Active Directory
- Google Workspace Updates /| Simplify and Strengthen Sign-In by Enabling Passkeys for Your Users
- Google Security Blog /| So Long Passwords, Thanks for all the Phish
- Allow Users to Skip Passwords at Sign-In (Beta)
- CIS Google Workspace Foundations Benchmark
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.2 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.2 Instructions
-
- Set New user enrollment period to 1 Week.
- Select Save
- GWS.COMMONCONTROLS.1.3v0.2 Instructions
-
- Under Frequency, deselect the Allow user to trust device checkbox.
- Select Save
- GWS.COMMONCONTROLS.1.4v0.2 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.2
-
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
Resources
- GWS Admin Help | Context-Aware Access overview
- GWS Admin Help | Context-Aware Access examples for Basic mode
- GWS Admin Help | Context-Aware Access examples for Advanced mode
- GWS Admin Help | Device management security checklist
- GWS Admin Help | Set up guide: Deploy company-owned devices in Google endpoint management
- GWS Admin Help | Turn endpoint verification on or off
- GWS Admin Help | Set up guide: Deploy company-owned devices in Google endpoint management—Steps 1 and 2
- GitHub | Google | Google Common Expressions Language (CEL)
- Google Cloud Access Context Manager | Macros for CEL expressions
- Google Cloud Access Context Manager | Custom access level specification
- GWS Blog | Enable advanced context-aware access to Google Workspace in the Admin console
- GWS Admin Help | Google Workspace Device management security checklist
- GWS Admin Help | Deploy Context-Aware Access
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.2 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.2
-
Login Challenges SHALL be enabled when third party SAML SSO is in use.
- 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
Resources
- GWS Admin Help | Protect Google Workspace accounts with security challenges
- CIS Google Workspace Foundations Benchmark
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.2 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.2
-
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
Resources
Prerequisites
- None
Implementation
- GWS.COMMONCONTROLS.4.1v0.2 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.2
-
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
- GWS.COMMONCONTROLS.5.2v0.2
-
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
- GWS.COMMONCONTROLS.5.3v0.2
-
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
- GWS.COMMONCONTROLS.5.4v0.2
-
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
- GWS.COMMONCONTROLS.5.5v0.2
-
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
Resources
- GWS Admin Help | Enforce and monitor password requirements for users
- CIS Google Workspace Foundations Benchmark
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.2 Instructions
-
- Under Strength, select the Enforce strong password checkbox.
- GWS.COMMONCONTROLS.5.2v0.2 Instructions
-
- Under Length, set Minimum Length to 12+.
- GWS.COMMONCONTROLS.5.3v0.2 Instructions
-
- Under Strength and Length enforcement, select the Enforce password policy at next sign-in checkbox.
- GWS.COMMONCONTROLS.5.4v0.2 Instructions
-
- Under Reuse, deselect the Allow password reuse checkbox.
- GWS.COMMONCONTROLS.5.5v0.2 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.2
-
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
- GWS.COMMONCONTROLS.6.2v0.2
-
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
Resources
- Google Cloud Architecture Center | Best practices for planning accounts and organizations
- GWS Admin Help | Create, edit, and delete custom admin roles
- GWA Admin Help | Assign Specific Admin Roles
- GWA Admin Help | Pre-Built Admin Roles
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.2 Instructions
-
- The implementation process for this can be located here.
- GWS.COMMONCONTROLS.6.2v0.2 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.2
-
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
- GWS Admin Help | Use the transfer tool to migrate unmanaged users
- GWS Admin Help | Find and add unmanaged users
- Google Workspace Updates Blog | Resolve conflict accounts faster with the new Conflict Accounts Management tool
- Google Cloud Architecture Center | Migrating consumer accounts
- Google Cloud Architecture Center | Best practices for planning accounts and organizations
- How a conflicting account is created
Prerequisites
- Super Admin privileges
Implementation
- GWS.COMMONCONTROLS.7.1v0.2 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.2
-
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
Resources
- GWS Admin Help | Allow super administrators to recover their password
- GWS Admin Help | Recover an account protected by 2-Step Verification
Prerequisites
- None
Implementation
- GWS.COMMONCONTROLS.8.1v0.2 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.2
-
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
- GWS.COMMONCONTROLS.9.2v0.2
-
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
Resources
- GWS Admin Help | Protect users with the Advanced Protection Program
- GWS Admin Help | Advanced Protection Program FAQ
- CIS Google Workspace Foundations Benchmark
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.2
-
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.2
-
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.2
-
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.2
-
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
- RFC 6819
- RFC 6749
- OMB M-22-09
- GWS Admin Help | Control which third-party & internal apps access GWS data
- CIS Google Workspace Foundations Benchmark
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.2 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.2 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.2 Instructions
-
- Select Settings.
- Select Internal apps and uncheck the box next to Trust internal apps.
- Select SAVE.
- GWS.COMMONCONTROLS.10.4v0.2 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.2
-
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
- GWS.COMMONCONTROLS.11.2v0.2
-
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
Resources
- GWS Admin Help | Manage Google Workspace Marketplace apps on your allowlist
- CIS Google Workspace Foundations Benchmark
- GWS Admin Help | Control access to less secure apps
Prerequisites
- None
Implementation
- GWS.COMMONCONTROLS.11.1v0.2 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.2 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.2
-
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
Resources
- GWS Admin Help | Security checklist for medium and large businesses
- GWS Admin Help | Allow or block Google Takeout
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.2 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.2
-
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
Resources
- GWS Admin Help | Data sources for the security investigation tool
- GWS Admin Help | View and edit system-defined rules
Prerequisites
- None
Implementation
- GWS.COMMONCONTROLS.13.1v0.2 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.2
-
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
- GWS.COMMONCONTROLS.14.2v0.2
-
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
Resources
- GWS Admin Help | Share data with Google Cloud Platform services
- Google Cloud Operations Suite | Audit logs for Google Workspace
- Google Cloud Operations Suite | View and manage audit logs for Google Workspace
- Google Cloud Operations Suite | Aggregate and store your organization's logs
- Google Cloud Architecture Center | Google Logging export scenarios
- GWS Admin Help | Data sources for GWS Audit and investigation page
- Google Cloud Operations Suite | Configure and Manage sinks – Google Cloud
- OMB M-21-31 | Office of Management and Budget
Prerequisites
- None
Implementation
- GWS.COMMONCONTROLS.14.1v0.2 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.2 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.2
-
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.2
-
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
Resources
- GWS Admin Help | Data regions: Choose a geographic location for your data
- GWS Admin Help | What data is covered by a data region policy?
Prerequisites
- Super Admin role
Implementation
- GWS.COMMONCONTROLS.15.1v0.2 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.2 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.2
-
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
Prerequisites
- Super Admin role
Implementation
- GWS.COMMONCONTROLS.16.1v0.2 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.2
-
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
Prerequisites
- Super Admin role
Implementation
- GWS.COMMONCONTROLS.17.1v0.2 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.