Gmail is the Google Workspace offering for sending and receiving email. Users can upload attachments to emails and send them to a given email address. Additional Gmail features include integrating with other Google applications, such as Meet and Chat. This Secure Configuration Baseline (SCB) provides specific policies to strengthen Gmail security.
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 available at the Gmail Google Workspace Admin Help Center and addresses the following:.
- Mail Delegation
- Domain Keys Identified Mail
- Sender Policy Framework
- Domain Based Message Authentication, Reporting, and Conformance
- Attachment Protections
- Links and External Images Protections
- Spoofing and Authentication Protection
- User Email Uploads
- POP and IMAP Access
- Workspace Sync
- Automatic Forwarding
- Per User Outbound Gateways
- Unintended External Reply Warning
- Email Allowlist
- Enhanced Pre-Delivery Message Scanning
- Security Sandbox
- Comprehensive Mail Storage
- Content Compliance Filtering
- Spam Filtering
Within Google Workspace, settings can be assigned to users through organizational units, configuration groups, or individually. Before changing a setting, the user can select the organizational unit, configuration group, or individual users to which they want to apply changes.
This document assumes the organization is using GWS Enterprise Plus.
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.
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.
This section determines whether users can delegate access to their mailbox to others within the same domain. This delegation includes access to read, send, and delete messages on the account owner's behalf. This delegation can be done via a command line tool (GAM) if enabled in the admin console.
Mail Delegation SHOULD be disabled.
-
Rationale: Granting mail delegation can inadvertently lead to disclosure of sensitive information, impersonation of delegated accounts, or malicious alteration or deletion of emails. By controlling mail delegation, these risks can be significantly reduced, improving the security and integrity of email communications.
-
Last modified: October 4, 2023
-
Note: Exceptions should be limited to individuals authorized by existing Agency policy, such as SES or Politically Appointed staff. Other considerations include ensuring that delegated accounts require Phishing-Resistant Multi-Factor Authentication (MFA), limiting delegated account permissions (ex. allowing view/reply but not delete), monitoring delegated accounts regularly, and disabling them if no longer required.
-
MITRE ATT&CK TTP Mapping
- Google Workspace Admin Help: Turn Gmail delegation on or off
- GAM: Example Email Settings - Creating a Gmail delegate
- CIS Google Workspace Foundations Benchmark
- None
To configure the settings for Mail Delegation:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select User Settings -> Mail delegation.
- Ensure that the Let users delegate access to their mailbox to other users in the domain checkbox is unchecked.
- Select Save.
This section enables DomainKeys Identified Mail (DKIM) to help prevent spoofing on outgoing messages sent from a specific domain. DKIM allows digital signatures to be added to email messages in the message header, providing a layer of both authenticity and integrity to emails. Without DKIM, messages that are sent from a specific domain are more likely to be marked as spam by receiving mail servers. DKIM relies on Domain Name System (DNS) records, thus, its deployment depends on how an agency manages its DNS.
DKIM SHOULD be enabled for all domains.
-
Rationale: Enabling DKIM for all domains can help prevent email spoofing and phishing attacks. Without DKIM, adversaries could manipulate email headers to appear as if they're from a legitimate source, potentially leading to the disclosure of sensitive information. By enabling DKIM, the authenticity of emails can be verified, reducing this risk.
-
Last modified: November 13, 2023
-
MITRE ATT&CK TTP Mapping
- Binding Operational Directive 18-01 - Enhance Email and Web Security | DHS
- Trustworthy Email | NIST 800-177 Rev. 1
- Google Workspace Admin Help: Help prevent spoofing and spam with DKIM
- CIS Google Workspace Foundations Benchmark
- None
To configure the settings for DKIM:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Authenticate email -> DKIM authentication.
- Select a domain listed in the Selected domain drop-down menu.
- Select START AUTHENTICATION.
- Select Save.
- Add the DNS TXT record listed in Admin Console to the domain, via the domain provider's DNS settings page. Note that it can take up to 48 hours for DNS changes to fully propagate.
Note that step 7 requires action taken outside of the Google Admin Console, dependent on the agency's domain provider. Thus, the exact final step needed to set up DKIM varies from agency to agency. See Turn on DKIM for your domain for more details.
To test your DKIM configuration, consider using a web-based tool, such as the Google Admin Toolbox.
The Sender Policy Framework (SPF) is a mechanism that allows administrators to specify which IP addresses are explicitly approved to send email on behalf of the domain, facilitating detection of spoofed emails. SPF isn't configured through the Google Admin Console, but rather via DNS records hosted by the agency's domain. Thus, the exact steps needed to set up SPF varies from agency to agency, but Google's documentation provides some helpful starting points.
An SPF policy SHALL be published for each domain that fails all non-approved senders.
-
Rationale: Adversaries could potentially manipulate the 'FROM' field in an email to appear as a legitimate sender, increasing the risk of phishing attacks. By publishing an SPF policy for each domain that fails all non-approved senders, this risk can be reduced as it provides a means to detect and block such deceptive emails. Additionally, SPF is required for federal, executive branch, departments and agencies by Binding Operational Directive 18-01, "Enhance Email and Web Security."
-
Last modified: February 14, 2024
-
Note: SPF defines two different "fail" mechanisms: fail (indicated by
-, sometimes referred to as hardfail) and softail (indicated by~). Fail, as used in this baseline policy, refers to hardfail (i.e.,-). -
MITRE ATT&CK TTP Mapping
- Binding Operational Directive 18-01 - Enhance Email and Web Security | DHS
- Trustworthy Email | NIST 800-177 Rev. 1
- Google Workspace Admin Help: Help prevent spoofing and spam with SPF
- A list of approved IP addresses for sending mail must be maintained. Failing to maintain an accurate list of authorized IP addresses may result in spoofed email messages or failure to deliver legitimate messages when SPF is enabled. Maintaining such a list helps ensure that unauthorized servers sending spoofed messages can be detected, and permits message delivery from legitimate senders.
First, identify any approved senders specific to your agency (see Identify all email senders for your organization for tips). SPF allows you to indicate approved senders by IP address or CIDR range. However, note that SPF allows you to include the IP addresses indicated by a separate SPF policy, refered to by domain name. See Define your SPF record—Basic setup for inclusions required for Google to send email on behalf of your domain.
SPF is not configured through the Google Workspace admin center, but rather via DNS records hosted by the agency's domain. Thus, the exact steps needed to set up SPF varies from agency to agency. See Add your SPF record at your domain provider for more details.
To test your SPF configuration, consider using a web-based tool, such as the Google Admin Toolbox. Additionally, SPF records can be requested using the command line tool dig. For example:
dig example.com txt
If SPF is configured, a response resembling v=spf1 include:_spf.google.com -all will be returned; though by necessity, the contents of the SPF policy may vary by agency. In this example, the SPF policy indicates the IP addresses listed by the policy for "_spf.google.com" are the only approved senders for "example.com." These IPs can be determined via additional SPF lookups, starting with "_spf.google.com."
Ensure the IP addresses listed as approved senders for your domains are correct. Additionally, ensure that each policy either ends in -all or redirects to one that does; this directive indicates that all IPs that don't match the policy should fail. See Define your SPF record—Advanced setup for a more in-depth discussion of SPF record syntax.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with SPF and DKIM to authenticate mail senders and ensure that destination email systems can validate messages sent from your domain. DMARC helps receiving mail systems determine what to do with messages sent from your domain that fail SPF or DKIM checks.
A DMARC policy SHALL be published for every second-level domain.
-
Rationale: Without proper authentication and a DMARC policy available for each domain, recipients may improperly handle SPF and DKIM failures, possibly enabling adversaries to send deceptive emails that appear to be from your domain. Publishing a DMARC policy for every second-level domain further reduces the risk posed by authentication failures.
-
Last modified: November 13, 2023
-
MITRE ATT&CK TTP Mapping
- None
The DMARC message rejection option SHALL be p=reject.
-
Rationale: Without stringent email authentication, adversaries could potentially send deceptive emails that appear to be from your domain, increasing the risk of phishing attacks. This policy reduces risk as it automatically rejects emails that fail SPF or DKIM checks, preventing potentially harmful emails from reaching recipients. Additionally, "reject" is the level of protection required by BOD 18-01, "Enhance Email and Web Security," for federal, executive branch, departments and agencies.
-
Last modified: November 13, 2023
-
MITRE ATT&CK TTP Mapping
The DMARC point of contact for aggregate reports SHALL include [email protected].
-
Rationale: Without a centralized point of contact for DMARC aggregate reports, potential email security issues may go unnoticed, increasing the risk of phishing attacks. As required by BOD 18-01 for federal, executive branch, departments and agencies, set [email protected] as the DMARC aggregate report recipient, which allows CISA to monitor and address email authentication issues.
-
Last modified: November 13, 2023
-
Note: Only federal, executive branch, departments and agencies should include this email address in their DMARC record.
-
MITRE ATT&CK TTP Mapping
- None
An agency point of contact SHOULD be included for aggregate and failure reports.
-
Rationale: Without a designated agency point of contact for DMARC aggregate and failure reports, potential email security issues may not be promptly addressed, increasing the risk of phishing attacks. By including an agency point of contact, this risk can be reduced as it facilitates a timely response to email authentication issues, enhancing overall email security.
-
Last modified: November 13, 2023
-
MITRE ATT&CK TTP Mapping
- None
- Binding Operational Directive 18-01 - Enhance Email and Web Security | DHS
- Trustworthy Email | NIST 800-177 Rev. 1
- Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC 7489
- Google Workspace Admin Help: Help prevent spoofing and spam with DMARC
- DKIM or SPF must be enabled
DMARC is not configured through the Google Admin Console, but rather via DNS records hosted by the agency's domain(s). As such, implementation varies depending on how an agency manages its DNS records. See Add your DMARC record for Google guidance.
Note, a DMARC record published at the second-level domain will protect all subdomains. In other words, a DMARC record published for example.com will protect both a.example.com and b.example.com, but a separate record would need to be published for c.example.gov.
To test your DMARC configuration, consider using one of many publicly available web-based tools, such as the Google Admin Toolbox. Additionally, DMARC records can be requested using the command line tool dig. For example:
dig _dmarc.example.com txt
If DMARC is configured, a response resembling v=DMARC1; p=reject; pct=100; rua=mailto:[email protected], mailto:[email protected]; ruf=mailto:[email protected] will be returned, though by necessity, the contents of the record will vary by agency. In this example, the policy indicates all emails failing the SPF/DKIM checks are to be rejected and aggregate reports sent to [email protected] and [email protected]. Failure reports will be sent to [email protected].
See GWS.GMAIL.4.1v0.3 instructions for an overview of how to publish and check a DMARC record. Ensure the record published includes p=reject.
See GWS.GMAIL.4.1v0.3 instructions for an overview of how to publish and check a DMARC record. Ensure the record published includes [email protected] as one of the emails for the rua field.
See GWS.GMAIL.4.1v0.3 instructions for an overview of how to publish and check a DMARC record. Ensure the record published includes a point of contact specific to your agency, in addition to [email protected], as one of the emails for the rua field and one or more agency-defined points of contact for the ruf field.
This section enables protections against suspicious attachments and scripts from untrusted senders, to include encrypted attachments, documents with malicious scripts, and attachment file types that are uncommon and/or archaic. Through these attachments malware can be spread. These messages can be kept in the inbox with a warning label (default), moved to spam, or quarantined.
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Protect against encrypted attachments from untrusted senders SHALL be enabled.
-
Rationale: Attachments from untrusted senders, especially encrypted ones, may contain malicious content that poses a security risk. By enabling protection against encrypted attachments from untrusted senders, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect against attachments with scripts from untrusted senders SHALL be enabled.
-
Rationale: Attachments with scripts from untrusted senders may contain malicious content that poses a security risk. By enabling protection against such attachments, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect against anomalous attachment types in emails SHALL be enabled.
-
Rationale: Anomalous attachment types in emails may contain malicious content that poses a security risk. By enabling protection against such attachments, this risk can be reduced, enhancing the safety and integrity of the user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Google SHOULD be allowed to automatically apply future recommended settings for attachments.
-
Rationale: By enabling this feature, the system can automatically stay updated with the latest security measures recommended by Google, reducing the risk of security breaches.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
Emails flagged by the above attachment protection controls SHALL NOT be kept in inbox.
-
Rationale: Keeping emails flagged by attachment protection controls in the inbox could potentially expose users to malicious content. Removing these emails from the inbox enhances the safety and integrity of user data and systems.
-
Last modified: September 8, 2023
-
Note: Agencies and Organizations can choose whether to send email to spam or quarantine. Applies to Policies 5.1 - 5.3.
-
MITRE ATT&CK TTP Mapping
Any third-party or outside application selected for attachment protection SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for attachment protection that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services reduces this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
- N/A
To configure the settings for Attachment Protections:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Safety -> Attachments.
- Follow implementation for each individual policy
- Select Save.
- Check the Protect against encrypted attachments from untrusted senders checkbox.
- Check the Protect against attachments with scripts from untrusted senders checkbox.
- Check the Protect against anomalous attachment types in emails checkbox.
- Check the Apply future recommended settings automatically checkbox.
- Under the setting for Policy 5.1 through Policy 5.3, ensure either "Move email to spam" or "Quarantine" is selected.
- No implementation steps for this policy
This section enables extra protections to prevent email phishing due to links and external images. Specific settings for this control include identifying hidden malicious links behind shortened URLs, scanning linked images to find hidden malicious content, showing a warning prompt when clicking links to untrusted domains, and applying future recommended settings automatically.
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Identify links behind shortened URLs SHALL be enabled.
-
Rationale: Shortened URLs can potentially hide malicious links, posing a security risk. By enabling the identification of links behind shortened URLs, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Scan linked images SHALL be enabled.
-
Rationale: Linked images in emails can potentially contain malicious content, posing a security risk. By enabling the scanning of linked images, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Show warning prompt for any click on links to untrusted domains SHALL be enabled.
-
Rationale: Clicking on links to unfamiliar domains can potentially expose users to malicious content, posing a security risk. By enabling a warning prompt for any click on such links, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Google SHALL be allowed to automatically apply future recommended settings for links and external images.
-
Rationale: By enabling this feature, the system can automatically stay updated with the latest recommended security measures from Google, reducing the risk of security breaches and enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
Any third-party or outside application selected for links and external images protection SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for links and external images protection that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services enhances the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
- Google Workspace Admin Help: Advanced phishing and malware protection
- Google Workspace Admin Help: Set up rules to detect harmful attachments
- Google Workspace Admin Help: Monitor the health of your Gmail settings
- CIS Google Workspace Foundations Benchmark
- N/A
To configure the settings for Links and External Images Protection:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Safety -> Links and external images.
- Follow implementation for each individual policy.
- Select Save
- Check the Identify links behind shortened URLs checkbox.
- Check the Scan linked images checkbox.
- Check the Show warning prompt for any click on links to untrusted domains checkbox.
- Check the Apply future recommended settings automatically checkbox.
- No implementation steps for this policy
This control enables extra protections to prevent spoofing of a domain name, employee names, email pretending to be from a specific domain, and unauthenticated email from any domain. These messages can be kept in the inbox with a warning label (default), moved to spam, or quarantined.
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Protect against domain spoofing based on similar domain names SHALL be enabled.
-
Rationale: Emails sent from domains that look similar to your domain can potentially deceive users into interacting with malicious content, posing a security risk. Enabling protection against such spoofing can reduce this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect against spoofing of employee names SHALL be enabled.
-
Rationale: Spoofing of employee identities (e.g., CEO and IT staff) can potentially deceive users into interacting with malicious content, posing a security risk. Enabling protection against such spoofing can reduce this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect against inbound emails spoofing your domain SHALL be enabled.
-
Rationale: Inbound emails appearing to come from your domain can potentially deceive users into interacting with malicious content, posing a security risk. By enabling protection against such spoofing, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect against any unauthenticated emails SHALL be enabled.
-
Rationale: Unauthenticated emails can potentially contain malicious content, posing a security risk. By enabling protection against such emails, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Protect your Groups from inbound emails spoofing your domain SHALL be enabled.
-
Rationale: Inbound emails spoofing your domain can potentially deceive users into interacting with malicious content, posing a security risk. By enabling protection against such spoofing, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Emails flagged by the above spoofing and authentication controls SHALL NOT be kept in inbox.
-
Rationale: Keeping emails flagged by spoofing and authentication controls in the inbox could potentially expose users to malicious content. Moving emails out of the inbox can reduce this risk, enhancing the safety and integrity of the user's data and systems.
-
Last modified: September 8, 2023
-
Note: Agencies and organizations can choose whether to send to spam or quarantine. This policy applies to Policy 7.1 - Policy 7.5
-
MITRE ATT&CK TTP Mapping
Google SHALL be allowed to automatically apply future recommended settings for spoofing and authentication.
-
Rationale: By enabling this feature, the system can automatically stay updated with the latest recommended security measures from Google, reducing the risk of security breaches and enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Any third-party or outside application selected for spoofing and authentication protection SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for spoofing and authentication protection that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services reduces this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for Spoofing and Authentication Protection:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Safety -> Spoofing and authentication.
- Follow steps for individual policies below.
- Select Save
- Check the Protect against domain spoofing based on similar domain names checkbox.
- Check the Protect against spoofing of employee names checkbox.
- Check the Protect against inbound emails spoofing your domain checkbox.
- Check the Protect against any unauthenticated emails checkbox.
- Check the Protect your groups from inbound emails spoofing your domain checkbox.
- Under each setting from Policy 7.1 through Policy 7.5, make sure either "Move email to spam" or "Quarantine" is selected.
- Check the Apply future recommended settings automatically checkbox.
- There is no implementation for this policy.
This section addresses a feature that enables users to import their email and contacts from non-Google webmail accounts such as Yahoo!, Hotmail, or AOL.
User email uploads SHALL be disabled to protect against unauthorized files being introduced into the secured environment.
-
Rationale: Allowing user email uploads could potentially introduce unauthorized or malicious files into the secured environment, posing a security risk. By disabling user email uploads, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- Google Workspace Admin Help: Advanced Gmail settings reference for admins
- Google Workspace Admin Help: Turn imports from webmail hosts on or off
- N/A
To configure the settings for User Email Uploads:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Setup -> User email uploads.
- Uncheck the Show users the option to import mail and contacts from Yahoo!, Hotmail, AOL, or other webmail or POP3 accounts from the Gmail settings page checkbox.
- Select Save.
This section determines whether users have POP3 and IMAP access. Doing so allows the user to access Gmail emails from outside the context of protected/hardened environments and from older versions of Gmail applications or other third-party mail applications.
POP and IMAP access SHALL be disabled to protect sensitive agency or organization emails from being accessed through legacy applications or other third-party mail clients.
-
Rationale: Enabling POP and IMAP access could potentially expose sensitive agency or organization emails to unauthorized access through legacy applications or third-party mail clients, posing a security risk. By disabling POP and IMAP access, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
Note: POP and IMAP access MAY be enabled on a per-user and per-application basis as needed.
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for POP and IMAP access:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select End User Access -> POP and IMAP access.
- Uncheck the Enable IMAP access for all users checkbox.
- Uncheck the Enable POP access for all users checkbox.
- Select Save.
This section determines whether Google Workspace Sync allows data synchronization between Google Workspace and Microsoft Outlook. The data includes email, calendar, and contacts. Data synchronizes each time users start Outlook. This is an additional plugin that must be downloaded.
Google Workspace Sync SHOULD be disabled.
-
Rationale: Enabling Google Workspace Sync could potentially expose sensitive agency or organization data to unauthorized access or loss, posing a security risk. By disabling Google Workspace Sync, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- T1048: Exfiltration Over Alternative Protocol
- T1048:001: Exfiltration Over Alternative Protocol: Exfiltration Over Symmetric Encrypted Non-C2 Protocol
- T1048:002: Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
- T1048:003: Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
- T1530: Data from Cloud Storage
- T1199: Trusted Relationship
- T1048: Exfiltration Over Alternative Protocol
Google Workspace Sync MAY be enabled on a per-user basis as needed.
-
Rationale: Enabling Google Workspace Sync indiscriminately could potentially expose sensitive agency or organization data to unauthorized access or loss, posing a security risk. By only allowing Google Workspace Sync on a per-user basis as needed, this risk can be reduced, ensuring the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- T1048: Exfiltration Over Alternative Protocol
- T1048:001: Exfiltration Over Alternative Protocol: Exfiltration Over Symmetric Encrypted Non-C2 Protocol
- T1048:002: Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
- T1048:003: Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
- T1530: Data from Cloud Storage
- T1199: Trusted Relationship
- T1048: Exfiltration Over Alternative Protocol
- N/A
To configure the settings for Google Workspace Sync:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select End User Access -> Google Workspace Sync.
- Uncheck the Enable Google Workspace Sync for Microsoft Outlook for my users checkbox.
- Select Save.
- There is no implementation steps for this policy.
- Select Save.
This section determines whether emails can be automatically forwarded from a user's inbox to another of their choosing, possibly to external domains.
Automatic forwarding SHOULD be disabled, especially to external domains.
-
Rationale: By enabling automatic forwarding, especially to external domains, adversaries could gain persistent access to a victim's email, potentially exposing sensitive agency or organization emails to unauthorized access or loss. By disabling automatic forwarding, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for Automatic Forwarding:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select End User Access -> Automatic forwarding.
- Uncheck the Allow users to automatically forward incoming email to another address checkbox.
- Select Save.
This section determines whether outgoing mail is delivered only through the Google Workspace mail servers or another specified external SMTP server. With this setting, a user can choose which email address displays in the "From" field.
Using a per-user outbound gateway that is a mail server other than the Google Workspace mail servers SHALL be disabled.
-
Rationale: Using a per-user outbound gateway that is a mail server other than the Google Workspace mail servers could potentially expose sensitive agency or organization emails to unauthorized access or loss, posing a security risk. By disabling this feature, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for Per-user Outbound Gateways:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select End User Access -> Allow per-user outbound gateways.
- Uncheck the Allow users to send mail through an external SMTP server when configuring a "from" address hosted outside your email domain checkbox.
- Select Save.
This section determines whether users are prompted with a warning for messages that include external recipients (users with emails addresses that are outside of your organization). However, the warning is not shown if the external recipient is in the organization's Directory, personal Contacts, or other Contacts; or if a secondary domain or domain alias address is used.
Unintended external reply warnings SHALL be enabled.
-
Rationale: Unintended external reply warnings can help reduce the risk of exposing sensitive information in replies to external messages. Enabling these warnings reminds users to treat external messages with caution, reducing this risk and enhancing the safety and integrity of user data and systems.
-
Last modified: June 7, 2024
-
MITRE ATT&CK TTP Mapping
- Google Workspace Admin Help: Control Gmail external recipient warnings
- Capacity Enhancement Guide Counter-Phishing Recommendations for Federal Agencies | CISA
- Actions to Counter Email-Based Attacks on Election-Related Entities | CISA
- N/A
To configure the settings to warn users of external recipients:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select End User Access -> Warn for external recipients.
- Check the Highlight any external recipients in a conversation. Warn users before they reply to email with external recipients who aren't in their contacts checkbox.
- Select Save.
This section determines whether an email allowlist allows for messages from certain IP addresses to not be marked as spam by Gmail. However, if implemented, emails from these senders will bypass important security mechanisms, such as SPF, DKIM, and DMARC.
An email allowlist SHOULD not be implemented.
-
Rationale: Implementing an email allowlist could potentially expose users to security risks as allowlisted senders bypass important security mechanisms, including spam filtering and sender authentication checks. By not implementing an allowlist, this risk can be reduced, enhancing the safety and integrity of the user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for Email Allowlists:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Spam, phishing, and malware -> Email allowlist.
- Under the Enter the IP addresses for your email allowlist field, ensure no IP addresses are listed.
- Select Save.
This section determines whether Gmail can screen and identify suspicious content that may be phishing attempts. In doing so, Google can either show a warning or move the email to Spam, but email delivery will experience a short delay due to the additional checks.
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Enhanced pre-delivery message scanning SHALL be enabled to prevent phishing.
-
Rationale: Without enhanced pre-delivery message scanning, users may be exposed to phishing attempts, posing a security risk. By enabling this feature, potential phishing emails can be identified and blocked before reaching the user, reducing this risk and enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Any third-party or outside application selected for enhanced pre-delivery message scanning SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for enhanced pre-delivery message scanning that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services reduces this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
- N/A
To configure the settings for Enhanced Pre-Delivery Message Scanning:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Spam, phishing, and malware -> Enhanced pre-delivery message scanning.
- Check the Enables improved detection of suspicious content prior to delivery checkbox.
- Select Save.
- There is no implementation steps for this policy
This section determines whether certain messages and their associated attachments are executed in a sandbox environment for protection against malware, ransomware, and zero-day threats. Malicious software may be missed by traditional antivirus programs. However, this may cause some messages to get delayed before final delivery. Some of the file types scanned include Microsoft executables, Microsoft Office, PDF, and archives (zip, rar).
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Security sandbox SHOULD be enabled to provide additional protections for their email messages.
-
Rationale: Without a security sandbox, emails with malicious content could potentially interact directly with the users' systems, posing a risk. By enabling the security sandbox, additional protections are provided for email messages, reducing this risk and enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Any third-party or outside application selected for security sandbox SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for security sandbox that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services reduces this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
- N/A
To configure the settings for Security sandbox or Security sandbox rules:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Spam, phishing, and malware -> Security sandbox.
- Check the Enable virtual execution of attachments in a sandbox environment for all the users of the Organizational Unit for protection against malware, ransomware, and zero-day threats checkbox.
- Either Security sandbox or Security sandbox rules may be enabled but enabling Security sandbox takes precedence.
- If Security sandbox rules are enabled, then the configuration needs to be completed and consists of the following fields :
- A short description.
- Email messages to affect.
- Expressions to describe the content to search for in each message.
- Action to take if expressions match.
- Select Save.
- There is no implementation steps for this policy.
This section allows for email messages sent through other Google Workspace applications, (i.e., Calendar, Drive, Docs, Sheets, Slides, Drawings, Forms, and Keep) to be stored in the associated users' Gmail mailboxes. This includes a copy of all sent or received messages within a specified domain (including messages sent or received by non-Gmail mailboxes).
Comprehensive mail storage SHOULD be enabled to allow tracking of information across applications.
-
Rationale: Without comprehensive mail storage, tracking of information across applications could be compromised, posing a potential security risk. Enabling comprehensive mail storage can reduce this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: November 14, 2023
-
MITRE ATT&CK TTP Mapping
- None
- N/A
To configure the settings for Comprehensive Mail Storage:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Compliance -> Comprehensive mail storage.
- Check the Ensure that a copy of all sent and received mail is stored in associated users' mailboxes checkbox.
- Select Save.
This section determines whether Gmail content is filtered based upon specified expressions, such as keyword, strings or patterns, and metadata. The compliance actions based upon the word lists are reject, quarantine, or deliver with modifications.
A Google Workspace solution is not strictly required to satisfy this baseline control, but the solution selected by an agency should offer services comparable to those offered by Google.
Content filtering SHOULD be enabled within Gmail messages.
-
Rationale: Without content filtering, Gmail messages could potentially contain sensitive or private content, posing a security risk. By enabling content filtering, this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
Any third-party or outside application selected for advanced email content filtering SHOULD offer services comparable to those offered by Google Workspace.
-
Rationale: Using third-party or outside applications for advanced email content filtering that do not offer services comparable to those offered by Google Workspace could potentially expose users to security risks. Using applications that offer comparable services can reduce this risk, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- None
Gmail or third-party applications SHALL be configured to protect PII and sensitive information as defined by the agency. At a minimum, credit card numbers, taxpayer Identification Numbers (TIN), and Social Security Numbers (SSN) SHALL be blocked.
-
Rationale: Without proper configuration, Gmail or third-party applications could potentially expose PII and sensitive information, posing a security risk. By configuring these applications to block at least credit card numbers, Taxpayer Identification Numbers (TIN), and Social Security Numbers (SSN), this risk can be reduced, enhancing the safety and integrity of user data and systems.
-
Last modified: July 10, 2023
-
MITRE ATT&CK TTP Mapping
- Google Workspace Admin Help: Set up rules for advanced email content filtering
- Personally identifiable information (PII) | NIST
- Sensitive information | NIST
- N/A
To configure the settings for Objectionable content:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Compliance -> Content Compliance.
- If Content compliance filtering is enabled, then the configuration needs to be completed and consists of the following fields:
- A short description.
- Email messages to affect.
- Expressions for content to search for in messages.
- Compliance action options.
- Select Save.
- There is no implementation steps for this policy.
- There is no implementation steps for this policy.
This section covers the settings relating to bypassing spam filters.
Domains SHALL NOT be added to lists that bypass spam filters.
-
Rationale: Legitimate emails may be incorrectly filtered by spam protections. Adding allowed senders is an acceptable method of combating these false positives. Allowing an entire domain, especially a common domain like office.com, however, provides for a large number of potentially unknown users to bypass spam protections.
-
Last modified: April 10, 2024
-
Note: Allowed senders MAY be added.
-
MITRE ATT&CK TTP Mapping
Domains SHALL NOT be added to lists that bypass spam filters and hide warnings.
-
Rationale: Legitimate emails may be incorrectly filtered by spam protections. Adding allowed senders is an acceptable method of combating these false positives. Allowing an entire domain, especially a common domain like office.com, however, provides for a large number of potentially unknown users to bypass spam protections.
-
Last modified: April 10, 2024
-
MITRE ATT&CK TTP Mapping
Bypass spam filters and hide warnings for all messages from internal and external senders SHALL NOT be enabled.
-
Rationale: Bypassing spam filters and hiding warning for all messages from internal and external senders creates a security risk because all messages are allowed to bypass filters. Disabling this feature mitigates the risk.
-
Last modified: April 10, 2024
-
MITRE ATT&CK TTP Mapping
- N/A
To configure the settings for spam filtering:
- Sign in to the Google Admin Console.
- Select Apps -> Google Workspace -> Gmail.
- Select Spam, Phishing, and Malware.
For each rule listed under Spam:
- Ensure that either:
- Bypass spam filters for messages from senders or domains in selected lists is not selected, or
- None of the lists shown under Bypass spam filters for messages from senders or domains in selected lists contain an entire domain. For example, the entire domain "example.com" is not acceptable, but the specific address, [email protected], would be.
- Modify the rule or lists associated with the rule as needed, then select Save.
For each rule listed under Spam:
- Ensure that either:
- Bypass spam filters and hide warnings for messages from senders or domains in selected lists is not selected, or
- None of the lists shown under Bypass spam filters and hide warnings for messages from senders or domains in selected lists contain an entire domain. For example, the entire domain "example.com" is not acceptable, but the specific address, [email protected], would be.
- Modify the rule or lists associated with the rule as needed, then select Save.
For each rule listed under Spam:
- Ensure that *Bypass spam filters and hide warnings for all messages from internal and external sender is not selected.
- Select Save.