Skip to content

Latest commit

 

History

History
1184 lines (843 loc) · 73.8 KB

commoncontrols.md

File metadata and controls

1184 lines (843 loc) · 73.8 KB
Raw

CISA Google Workspace Secure 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 secure configurations.

The CISA SCuBA SCBs for GWS help secure federal information assets stored within GWS cloud business application environments through consistent, effective, and manageable secure 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:

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.3 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

GWS.COMMONCONTROLS.1.2v0.3

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

GWS.COMMONCONTROLS.1.3v0.3

Allow users to trust the device SHALL be disabled.

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

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

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

GWS.COMMONCONTROLS.1.1v0.3 Instructions

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

GWS.COMMONCONTROLS.1.2v0.3 Instructions

  1. Set New user enrollment period to 1 Week.
  2. Select Save

GWS.COMMONCONTROLS.1.3v0.3 Instructions

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

GWS.COMMONCONTROLS.1.4v0.3 Instructions

If using security keys:

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

If security keys are not yet available for your organization:

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

If using Passkeys, use the Google Workspace Admin Console:

  1. Sign in to Google Admin console as an administrator.
  2. Select Security -> Authentication -> Passwordless.
  3. Select Skip passwords.
  4. Select the Allow users to skip passwords at sign-in by using passkeys box.
  5. 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

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:

  1. Access the Google Admin console.
  2. From the menu, go to Security -> Access and data control -> Context-Aware Access.
  3. Verify Context-Aware Access is ON for everyone. If not, click Turn On.
  4. Select Access Level and select Create Access Level and determine the conditions of the rule per agency needs.
  5. 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

Login Challenges SHALL be enabled when third party SAML SSO is in use.

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

  1. Sign in to Google Admin console as an administrator.
  2. Select Security->Authentication->Login challenges.
  3. Under Organizational units, ensure that the name for the entire organization is selected.
  4. 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.
  5. Optionally, if employee IDs are known to agency employees (or accessible to the employee outside of Google Workspace), they may be used.
  6. Click Login challenges.
  7. Select the Use employee ID to keep my users more secure checkbox.
  8. 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.

Resources

Prerequisites

  • None

Implementation

GWS.COMMONCONTROLS.4.1v0.3 Instructions

To configure Google session control:

  1. Sign in to the Google Admin console as an administrator.
  2. Select Security.
  3. Select Access and data control -> Google session control.
  4. Look for the Web session duration heading.
  5. 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.

GWS.COMMONCONTROLS.5.2v0.3

User password length SHALL be at least 12 characters.

GWS.COMMONCONTROLS.5.3v0.3

Password policy SHALL be enforced at next sign-in.

GWS.COMMONCONTROLS.5.4v0.3

User passwords SHALL NOT be reused.

GWS.COMMONCONTROLS.5.5v0.3

User passwords SHALL NOT expire.

Resources

Prerequisites

  • None

Implementation

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

Policy Group 5 common Instructions

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

GWS.COMMONCONTROLS.5.1v0.3 Instructions

  1. Under Strength, select the Enforce strong password checkbox.

GWS.COMMONCONTROLS.5.2v0.3 Instructions

  1. Under Length, set Minimum Length to 12+.

GWS.COMMONCONTROLS.5.3v0.3 Instructions

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

GWS.COMMONCONTROLS.5.4v0.3 Instructions

  1. Under Reuse, deselect the Allow password reuse checkbox.

GWS.COMMONCONTROLS.5.5v0.3 Instructions

  1. 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.

GWS.COMMONCONTROLS.6.2v0.3

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

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

  1. The implementation process for this can be located here.

GWS.COMMONCONTROLS.6.2v0.3 Instructions

To obtain a list of all GWS Super Admins:

  1. Sign in to the Google Admin console as an administrator.
  2. Navigate to Account -> Admin Roles.
  3. Click the Super Admin role in the list of roles
  4. 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.

Resources

Prerequisites

  • Super Admin privileges

Implementation

GWS.COMMONCONTROLS.7.1v0.3 Instructions

To configure account conflict management per the policy:

  1. Sign in to the Google Admin console as an administrator.
  2. Navigate to Account -> Account settings.
  3. Click the Conflicting accounts management card.
  4. Select the radio button option: "Replace conflicting unmanaged accounts with managed ones."
  5. 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

Resources

Prerequisites

  • None

Implementation

GWS.COMMONCONTROLS.8.1v0.3 Instructions

To disable Super Admin account self-recovery:

  1. Sign in to https://admin.google.com as an administrator.
  2. Select Security -> Authentication.
  3. Select Account Recovery.
  4. Click Super admin account recovery.
  5. To apply the setting to all your Super Admins, leave the top OU selected. Otherwise, select a child OU or a configuration group.
  6. Deselect the Allow Super Admins to recover their account checkbox.
  7. Click Save.
  8. 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.

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

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:

  1. Sign in to the Google Admin console as an administrator.
  2. Select Security -> Authentication -> Advanced Protection Program.
  3. On the right, locate the Advanced Protection header.
  4. Locate the Allow users to enroll in the Advanced Protection Program header.
  5. Select Enable user enrollment.
  6. 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.

GWS.COMMONCONTROLS.10.2v0.3

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

GWS.COMMONCONTROLS.10.3v0.3

Agencies SHALL NOT trust unconfigured internal apps.

GWS.COMMONCONTROLS.10.4v0.3

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

Resources

Prerequisites

  • None

Implementation

Policy Group 10 Instructions

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

GWS.COMMONCONTROLS.10.1v0.3 instructions:

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

GWS.COMMONCONTROLS.10.2v0.3 instructions:

  1. Select Manage Google Services.
  2. Select the Services box to check all services boxes.
  3. Once this box is selected, then the Change access link at the top of console will be available; select it.
  4. 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.
  5. Select Change then confirm if prompted.

GWS.COMMONCONTROLS.10.3v0.3 Instructions

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

GWS.COMMONCONTROLS.10.4v0.3 Instructions

  1. Select Settings.
  2. Select Unconfigured third-party apps and select Don't allow users to access any third-party apps
  3. 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.

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.

Resources

Prerequisites

  • None

Implementation

GWS.COMMONCONTROLS.11.1v0.3 Instructions

  1. Sign in to the Google Admin console as an administrator.
  2. Select Apps -> Google Workspace Marketplace apps -> Settings.
  3. Select Allow users to install and run allowlisted apps from the Marketplace.
  4. 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.
  5. Click Save.

To add an app to the allowlist:

  1. On the left-hand side above Setting, click Apps lists.

  2. Click the ALLOWLIST APP to add an app to the allow list.

    or

  3. Click Allowlisted Apps to manage the allow list.

GWS.COMMONCONTROLS.11.2v0.3 Instructions

  1. Sign in to the Google Admin console as an administrator.
  2. Select Security.
  3. Select Access and data control -> Less secure apps.
  4. Select Disable access to less secure apps (Recommended).
  5. 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

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

  1. Sign in to https://admin.google.com as an administrator.
  2. Select Account then Google Takeout.
  3. Select User access to Takeout for Google services.
  4. For services without an individual admin control, select Services without an individual admin control then Edit.
  5. Select Don't allow for everyone.
  6. Click Save.
  7. For services with an individual admin control, under apps select the checkbox next to Service name and select Don't allow.
  8. 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

Resources

Prerequisites

  • None

Implementation

GWS.COMMONCONTROLS.13.1v0.3 Instructions

  1. Sign in to Google Admin console.
  2. On the left navigation pane, click the hamburger menu above Home->Show more.
  3. Click Rules.
  4. From the Rules page, click Add a filter.
  5. From the drop-down menu, select Type.
  6. Select the System defined check box.
  7. Click Apply.
  8. 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.
  9. 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.
  10. Click Edit Rule.
  11. Click Next: View Conditions.
  12. Click Next: Add Actions.
  13. 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.
  14. Click Next: Review.
  15. 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

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

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

  1. 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.

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

Resources

Prerequisites

  • Super Admin role

Implementation

GWS.COMMONCONTROLS.15.1v0.3 Instructions

To configure Data Regions per the policy:

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

GWS.COMMONCONTROLS.15.2v0.3 Instructions

To configure Supplemental Data Storage per the policy:

  1. Sign in to the Google Admin console as an administrator.
  2. Navigate to Account -> Account settings.
  3. Click the Supplemental Data Storage card.
  4. Ensure the checkbox for "Russian Federation" is unchecked.
  5. 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.

Resources

Prerequisites

  • Super Admin role

Implementation

GWS.COMMONCONTROLS.16.1v0.3 Instructions

To configure additional services per the policy:

  1. Sign in to the Google Admin console as an administrator.
  2. Navigate to Apps -> Additional Google services.
  3. Click CHANGE at the top where it says if Access to additional services without individual control for all organizational units is On/Off.
  4. Select the option: "OFF for everyone"
  5. 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

Prerequisites

  • Super Admin role

Implementation

GWS.COMMONCONTROLS.17.1v0.3 Instructions

To configure additional services per the policy:

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