Code Monkey home page Code Monkey logo

cisagov / scubagoggles Goto Github PK

View Code? Open in Web Editor NEW
135.0 9.0 14.0 3.2 MB

SCuBA Security Configuration Baselines and assessment tool for Google Workspace

Home Page: https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project

License: Creative Commons Zero v1.0 Universal

Open Policy Agent 85.54% Python 5.86% HTML 8.18% JavaScript 0.13% CSS 0.21% Shell 0.09%
cisa cybersecurity google-workspace opa open-policy-agent python google gws open-source security

scubagoggles's Introduction

    ScubaGoggles

GWS Secure Configuration Baseline Assessment Tool

Developed by CISA, ScubaGoggles is an assessment tool that verifies a Google Workspace (GWS) organization's configuration conforms to the policies described in the Secure Cloud Business Applications (SCuBA) Security Configuration Baseline documents.

For the Microsoft 365 (M365) rendition of this tool, see ScubaGear.

Warning

This tool is in an alpha state and in active development. At this time, outputs could be incorrect and should be reviewed carefully.

Table of Contents

Limitations of the tool

The majority of the conformance checks done by ScubaGoggles rely on GWS Admin log events. If there is no log event corresponding to a SCuBA baseline policy, ScubaGoggles will indicate that the setting currently can not be checked on its HTML report output. In this situation, we recommend you manually review your GWS security configurations with the SCuBA security baselines.

Additionally, some events will not be visible due to data retention time limits, as the admin logs are only retained for 6 months (see Data retention and lag times). However, if you wish to generate a log event for testing ScubaGoggles' capabilities, follow the implementation instructions in the SCuBA GWS baseline documents to change your GWS configuration settings. Toggling certain settings, off and on will be enough to generate a log event. Other settings will require implementing more substantive configuration changes.

Many of the these controls can be scoped down to the organizational unit level. We recommend creating a new organization unit and applying these controls just to that new organizational unit for testing. Rerun ScubaGoggles after you've saved your configuration changes to see if the policy requirement is met.

Getting started

Important

Use of this tool requires access to an internet browser for initial setup and to view the html report output.

Downloading the Latest Release

To download ScubaGoggles:

  1. Click here to see the latest release.
  2. Click scubagoggles-[latest-version].zip to download the release.
  3. Extract the folder in the zip file.

Install Python dependencies

Minimum required Python version to run the tool is 3.7.16.

Installing in a Virtual Environment

The following commands are used to set up a python virtual environment (venv) to install the needed python dependencies. Inside the release or repo folder, open up a terminal and run the following commands based on your OS.

Windows

pip3 install virtualenv
python -m venv .venv
.venv\Scripts\activate

macOS

pip3 install virtualenv
virtualenv -p python3 .venv
source .venv/bin/activate

Users can run the tool via the scuba.py script as a developer or by installing the scubagoggles package in a python venv. Choose either of these next steps to install the needed python dependencies in the venv.

Installing dependencies for running scubagoggles directly

In the root directory of the release/repo, install the scubagoggles package and dependencies with the following command.

python3 -m pip install .

Installing dependencies for running via scuba.py script

In the root directory of the release/repo, install the the required dependencies with the following command.

pip3 install -r requirements.txt

Important

Users will need to rerun the activate script from the OS specific directions above in each new terminal session to reactivate the venv containing the dependencies.

Download the OPA executable

The tool makes use of Open Policy Agent's Rego Policy language. An OPA executable is required to execute this tool and can be downloaded using our download_opa.py script.

python download_opa.py --help
usage: download_opa.py [-h] [-v] [-os]

Download executable the OPA executable file required to run this SCuBA tool.

options:
  -h, --help            show this help message and exit
  -v {0.45.0,0.46.3,0.47.4,0.48.0,0.49.2,0.50.2,0.51.0,0.52.0,0.53.1,0.54.0,0.55.0,0.56.0,0.57.1,0.58.0,0.59.0,0.60.0}
                        What version of OPA to download: Default version: 0.59.0
  -os {windows,macos,linux}
                        Operating system version of OPA to download. Default os: windows
  --disablessl          If there are proxy errors, try adding this switch to disable ssl verification
# example
python download_opa.py -v 0.60.0 -os macos
  1. If the above script can not execute for any reason or you would prefer to download OPA manually, go to the Open Policy Agent website
  2. Check the website for a compatible OPA version (Currently v0.45.0 and above) for ScubaGoggles and select the corresponding version on top left of the website
  3. Navigate to the menu on left side of the screen: Introduction -> Running OPA -> Download OPA
  4. Follow the instructions for downloading the respective OPA executable for your OS.

Note

The following notes apply only for MAC and Linux users.

  • By default on MAC and Linux systems the OPA executable will be run with sudo.
  • Use the scubagoggles gws --omitsudo flag to omit running the executable with sudo.
  • MAC and Linux OS users should have their OPA executables named opa_darwin_amd64 or opa_linux_amd64_static respectively for scubagoggles execution.
  • The OPA executable must also be given execute permissions
chmod +x opa_darwin_amd64 # give the opa executable execute permissions

Permissions

OAuth API Scopes

The tool uses the following OAUTH API scopes.

  • https://www.googleapis.com/auth/admin.reports.audit.readonly
  • https://www.googleapis.com/auth/admin.directory.domain.readonly
  • https://www.googleapis.com/auth/admin.directory.group.readonly
  • https://www.googleapis.com/auth/admin.directory.orgunit.readonly
  • https://www.googleapis.com/auth/admin.directory.user.readonly
  • https://www.googleapis.com/auth/apps.groups.settings

When running ScubaGoggles for the first time you will be prompted to consent to these API scopes. Users with the Super Admin role automatically have the privilege to consent to these scopes. A custom admin role can also be made with the minimum permissions to consent to these scopes. See this Google Admin SDK Prerequisites guide for more information.

Create a project

  1. If you already have a Google Cloud Project that you want to utilize skip to Authentication
  2. Otherwise start by signing into http://console.cloud.google.com/.
  3. Follow the directions outlined in this guide to create a project

Authentication

ScubaGoggles supports both OAuth and Service Accounts for authorization/authentication. OAuth requires regular user consent while using a service account allows for more automation. Follow the instructions below for the authentication method of your choice.

Create an OAuth credential

  1. Be signed into http://console.cloud.google.com/.
  2. From the hamburger menu on the left, select APIs & Services -> OAuth consent screen
  3. Select Internal for User Type
  4. Click Create
  5. Fill in your App name and User support email
  6. Scroll down to the Authorized Domains section
  7. Under Authorized domains, add the primary domain of your GWS organization.
  8. Add another email address for Developer contact information
  9. Click SAVE AND CONTINUE
  10. Do nothing on the Scopes screen, just click SAVE AND CONTINUE
  11. Review summary, then click BACK TO DASHBOARD
  12. Click Credentials from the menu on the left
  13. Click CREATE CREDENTIALS
  14. Select Oauth client ID
  15. Select Web application for Application type
  16. Give name as appropriate
  17. Under Authorized redirect URIs, click "ADD URI." Add http://localhost and http://localhost:8080/
  18. Click CREATE
  19. Click DOWNLOAD JSON from the resulting OAuth client created page
  20. Click OK
  21. Move the downloaded file (begins with client_secret*.json) to the root directory folder of this repo, rename to credentials.json
  22. Go back the menu on the left and click Enabled API Services
  23. In the center screen click Enable APIS AND Services
  24. Search for and enable the Admin SDK API
  25. Search for and enable the Groups Settings API
  26. During the first run of this tool your default web browser will open up a page to consent to the API scopes needed to run this tool. Sign in with an account with the necessary privileges and click allow.
Add the Oauth App to the allowlist

If you've limited application access to Google's APIs in your organization, the Common Controls: App Access to Google APIs baseline covers this topic, follow the directions below to allowlist the OAuth app.

  1. Login to https://console.cloud.google.com
  2. Navigate to the appropriate project
  3. Select API's & Services from the top left hamburger icon
  4. Select Credentials
  5. Copy your client ID under OAuth 2.0 Client IDs
  6. Now login to admin.google.com and navigate to Security -> Access and Data Control -> API Controls -> Manage Third-Party App Access
  7. Select Add App -> Oauth App Name or Client ID
  8. Search by your OAuth client ID
  9. Select the App
  10. Select your root organization as the domain
  11. Select Trusted

Using a Service Account

Important

ScubaGoggles requires the service account to have domain-wide delegation of authority to function.

  1. Login to https://console.cloud.google.com and navigate to your GCP project.
  2. From the hamburger menu, select IAM & Admin -> Service Accounts
  3. Select CREATE SERVICE ACCOUNT. Fill out the id field and then select DONE
  4. Click on the newly created service account then click KEYS -> ADD KEY -> Create new key -> JSON -> CREATE
  5. Move the downloaded file (begins with <service account>*.json) to the root directory folder of this repo, rename to credentials.json
  6. Now login to admin.google.com and navigate to Security -> Access and data control -> API controls
  7. Select MANAGE DOMAIN WIDE DELEGATION
  8. Select Add new
  9. Enter the client_id from the downloaded credentials (also visible after clicking on the created Service account under Details -> Unique ID)
  10. Enter each OAuth scope as listed in OAuth API Scopes
  11. Select AUTHORIZE
  12. Finally, run ScubaGoggles with the --subjectemail option set to the email of an admin with necessary permissions to run ScubaGoggles.

Note

ScubaGoggles can be run using a service account in a different organization. To do so, specify the --customerid argument with the customer ID of the target organization (found in admin.google.com under Account -> Account settings)

Usage

Execute the ScubaGoggles tool using the scubagoggles command. For GWS, all commands will be under the gws subparser.

scubagoggles gws -h
usage: scubagoggles gws [-h] [-b  [...]] [-o] [-c] [--subjectemail] [--customerid] [--opapath] [--regopath] [--documentpath]
                    [--runcached] [--skipexport] [--outputfoldername] [--outputproviderfilename]
                    [--outputregofilename] [--outputreportfilename] [--omitsudo] [--quiet] [--debug]

optional arguments:
  -h, --help            show this help message and exit
  -b  [ ...], --baselines  [ ...]
                        A list of one or more abbreviated GWS baseline names that the tool will assess. Defaults to
                        all baselines. Choices: gmail, calendar, groups, chat, drive, meet, sites, commoncontrols,
                        rules, classroom
  -o , --outputpath     The folder path where both the output JSON & HTML report will be created. Defaults to "./" The
                        current directory.
  -c , --credentials    The relative path and name of the OAuth / service account credentials json file. Defaults to
                        "./credentials.json" which means the tool will look for the file named credentials.json in the
                        current directory.
  --outjsonfilename     The name of the file that encapsulates all assessment output. Defaults to ScubaResults.
  --subjectemail        Only applicable when using a service account. The email address of a user the service account
                        should act on behalf of. This user must have the necessary privileges to run scubagoggles.
  --customerid          The customer ID the tool should run on. Defaults to "my_customer" which will be the domain of 
                        the user / service account authenticating.
  --opapath             The relative path to the directory containing the OPA executable. Defaults to "./" the current
                        executing directory.
  --regopath            The relative path to the directory contain the folder containing the rego files. Defaults to
                        "./rego" the "rego" folder inside the current executing directory.
  --documentpath        The relative path to the directory containing the SCuBA baseline documents. Defaults to
                        "./baselines" the "baselines" folder inside the current executing directory.
  --runcached           This switch when added will run in the tool in "RunCached mode". When combined with -sa allows
                        to the user to skip authentication and provider export.
  --skipexport          This switch when added will skip the provider export.To be used in conjunction with
                        --runcached.
  --outputfoldername    The name of the folder created in --outputpath where both the output JSON and the HTML report
                        will be created. Defaults to GWSBaselineConformance. The client's local timestamp will be
                        appended to this name.
  --outputproviderfilename 
                        The name of the Provider output json in --outputpath. Defaults to ProviderSettingsExport.
  --outputregofilename 
                        The name of the Rego output json in --outputpath. Defaults to TestResults.
  --outputreportfilename 
                        The name of the main html file homepage created in --outputpath. Defaults to BaselineReports.
  --omitsudo            This switch prevents running the OPA executable with sudo.
  --quiet               This switch suppresses automatically launching a web browser to open the html report output
                        and the loading bar output.
  --debug               This switch is used to print debugging information for OPA.

Example 1: Run an assessment against all GWS products

scubagoggles gws

Example 2: Run an assessment against just Gmail and Google Calendar

scubagoggles gws -b gmail calendar

Example 3: Run an assessment and store the results under a folder called output

scubagoggles gws -b calendar gmail groups chat meet sites -o ./output

Example 4: Do a run cached assessment

# skip authentication and provider export stage
# used for running against a cached provider json

scubagoggles gws --runcached --skipexport

Example 5: Run with a service account on a different tenant

scubagoggles gws --customerid <customer_id> --subjectemail [email protected]

See the help options yourself

scubagoggles gws -h

The html report should open automatically. If not, navigate to the output folder and open the *.html file using a browser of your choice. The json output will also be located in this folder.

Note

If you chose not install the scubagoggles package in a venv but do have the dependencies installed from requirements.txt, you may execute the tool using the scuba.py script located in the root directory of this repository. Replace any scubagoggles directions with python scuba.py

Organization

  • The Python scripts are saved in the scubagoggles folder.
  • The rego folder holds the Rego files. Each *.rego file holds the "desired state" for each product, per the baseline policy statements.
  • Style and developer guides are located in the guides folder.

Design

We use a three-step process:

  1. Export. In this step, we primarily use the Google Admin SDK API to export and serialize all the relevant logs and settings into json. ScubaGoggles also uses various other Google APIs to grab organization metadata, user privileges etc.
  2. Verify. Compare the exported settings from the previous step with the configuration prescribed in the baselines. We do this using OPA Rego, a declarative query language for defining policy.
  3. Report. Package the data output by Rego into a human-friendly html report.

Troubleshooting

Not Authorized to Access This Resource

If an authorization error similar to the one below appears:

/Users/scubagoggles/provider.py:463: RuntimeWarning: An exception was thrown trying to get the tenant info:
<HttpError 403 when requesting https://admin.googleapis.com/admin/directory/v1/customers/my_customer?alt=json returned "Not Authorized to access this resource/api">

Ensure that you consented to the following API scopes as a user with the proper permissions to consent and have enabled the required APIs and Services.

Scubagoggles Not Found

If an error similar to the one below appears:

command not found: scubagoggles

Ensure that you have properly configured the virtual environment and have activated the virtual environment using the OS appropriate commands.

Alternatively, to run scubagoggles without installing it as a package, you can replace the scubagoggles command with python scuba.py.

Unable to view HTML report due to environment limitations

If you are unable to view the HTML report in a browser window, the results of the conformance scan can be viewed in their raw JSON format.

We recommend running the conformance report in quiet mode to stop the web browser from being opened automatically. This can be done with the --quiet command:

scubagoggles gws --quiet

Once the scan is complete, navigate to the output folder. Within the output folder, we can access the generated HTML reports, or view the results in JSON format.

To view the JSON, open the ScubaResults.json file.

Each baseline will appear in the following format:

{
    "Summary": {
      "Gmail": {
          "Manual": 26,
          "Passes": 9,
          "Errors": 0,
          "Failures": 6,
          "Warnings": 2
      },
      "Groups for Business": {
          "Manual": 0,
          "Passes": 6,
          "Errors": 0,
          "Failures": 0,
          "Warnings": 1
      }     
    },
    "Results": {
      "Gmail": [
        {
            "GroupName": "Mail Delegation",
            "GroupNumber": "1",
            "Controls": [
                {
                  "Control ID": "GWS.GMAIL.1.1v0.1",
                  "Requirement": "Mail Delegation SHOULD be disabled.",
                  "Result": "Pass",
                  "Criticality": "Should",
                  "Details": "Requirement met in all OUs and groups."
                }
                ...

Project License

Unless otherwise noted, this project is distributed under the Creative Commons Zero license. With developer approval, contributions may be submitted with an alternate compatible license. If accepted, those contributions will be listed herein with the appropriate license.

scubagoggles's People

Contributors

adhilto avatar buidav avatar chad-cisa avatar dependabot[bot] avatar jacdavi avatar jfevang avatar jkaufman-mitre avatar laurenbassett avatar mdueltgen avatar mitchelbaker-cisa avatar rgbrow1949 avatar rlxdev avatar snarve avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

scubagoggles's Issues

Functional Testing for Calendar

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Find the minimum privileges that need to be assigned to a custom admin role to run the tool

The permissions needed to access the API with the scopes that we need are a bit vague.
The reports API Google Documentation guide says that a super admin or a custom admin is needed to access the API.

Lessons learned from M365, members of the public aren't comfortable with running some random tool off the internet as the highest privileged role in their Cloud environment. For GWS, this is the super admin role.

There is no specific Google Documentation for assigning the custom admin the minimum permissions we need to access the reports and directory apis:

This issue is to find out and document the minimum privileges that need to be assigned to a custom admin to run this tool.
Then test if there are any issues running the tool as an account assigned just that custom admin role.
How to create a custom admin role.

See the README for the OAuth scopes we're currently using for Goggles

Drive/Docs Baseline Dependent Baseline Policy Issues

There's been a few issues about this, but I wanted to put everything in one place.

The baseline policies for GWS.DRIVEDOCS.1 are not contradictory, but not all are applied in every situation.

GWS.DRIVEDOCS.1.1v1 - Agencies SHOULD disable sharing outside of the organization’s domain
Determines which of the following baselines should be 'active' and being checked. In my opinion, we shouldn't have this as a pass/fail, as we recommend that it is turned off, but have baselines established when it is turned on.

if sharing outside the organization is disabled (GWS.DRIVEDOCS.1.1v1 is 'compliant')
Then, GWS.DRIVEDOCS.1.2v1 should be evaluated (If disabling sharing outside of the organization's domain, then agencies SHALL also disable users' receiving files from outside of the organization's domain.)

Additionally,
GWS.DRIVEDOCS.1.3.1v1 and GWS.DRIVEDOCS.1.4.1v1 do NOT need to be checked.

if sharing outside the organization is enabled (GWS.DRIVEDOCS.1.1v1 is 'non-compliant')
Then, GWS.DRIVEDOCS.1.2.1v1 does not need to be checked

and
GWS.DRIVEDOCS.1.3.1v1 and GWS.DRIVEDOCS.1.4.1v1 need to be checked.

Currently, all baselines are being evaluated every time, which is causing extra failures when they don't need to be.

I worry about how this would be extended to multiple OUs, but I think this is the core of where the logic inconsistencies are coming from.

Add in the Regal Linter for OPA Rego

One of the OPA maintainers came back on the M365 side and did all of the work in a PR needed to make the OPA linter work for us. This epic is to make updates to our Rego code for all products to adhere to those OPA linter rules.

  • Gmail
  • Google Calendar
  • Groups
  • Google Chat
  • Google Drive & Docs
  • Google Meet
  • Google Sites
  • Common Controls
  • Rules
  • Google Classroom

See Common Controls Rego for an example

Chat 4.2 Inheritance Issue

If 4.1 is non-compliant, then 4.2 is 'disabled' and it can't be selected. Should we change the baseline to address this?

GWS.GMAIL.12.1 has no security benefits and is a counter recommendation

GWS.12.1 recommends organizations create an allowlist/whitelist just to avoid broken links.

Not sure what the security benefits of this policy are.
This policy is recommending an image domain allowlist which is counter to policies we've had in the past which is to recommend against allowlists.
If this setting is just for fixing broken image links and does not provide a security benefit, I would recommend removal.
 
Even the Google documentation for this policy recommends users tread carefully when implementing this setting.

GWS.GMAIL.12.1v0.1

Image URL proxy whitelists SHOULD be enabled to avoid broken links to images that are dependent on internal IP addresses within an organization's domain.

Gmail 7.6 logic is incomplete

Gmail 7.6: Emails flagged by the above spoofing and authentication controls SHALL NOT be kept in inbox.

Rego logic is incomplete. When enabling settings 7.1 - 7.5. There is the default option and the option to add to spam or quarantine.
Issue is when you leave the setting the the default show warning the log event will not indicate if the setting is set to show warning or quarantine

The rego currently only can check if the setting is enabled not what value it is changed to. After the first log event however, then the setting shows up for any additional change events. Tricky situation. Will need to find a way to handle this.

Refactor rego for each baseline to include detailed message in report

As part of implementing the Multiple OU's use case for each of the baseline, the earlier implemented detailed report messages will get replaced by a more generic message on whether the baseline policy is complaint in all the OU's or not.

Since the detailed report message is similar to the report details on M365 and was added as per request (on the M365 side), this may be something we may need to revisit and implement on the GWS side as well.

To be able to re-use the existing detailed message from each baseline, this issue will serve as an epic for each of the issues/baseline.

In each of these issues, you may find the obsolete code with the detailed report messages that can be re-used whenever this feature is added to the code base.

Updated grace periods for resolving policy violations in managed iOS devices

Ensuring only managed applications can access sensitive information is vital to security. Currently, when admins make a policy change that results in an app going from unmanaged to managed, if a policy violation is detected, a 24-hour grace period is given to users to comply with the change. After this grace period, users will lose the ability to access their Google Workspace account.

Publish Date: Thursday, December 7, 2023
Update Blog Link

Functional Testing for Gmail

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Add in the Regal Linter for OPA Rego

One of the OPA maintainers came back on the M365 side and did all of the work in a PR needed to make the OPA linter work for us. This epic is to make updates to our Rego code for all products to adhere to those OPA linter rules.

  • #116
  • #117
  • Groups
  • Google Chat
  • Google Drive & Docs
  • Google Meet
  • Google Sites
  • Common Controls
  • Rules
  • Google Classroom

See Common Controls Rego for an example

Create a Redacted Sample Report

Our first public issue we had for the M365 public release were people asking for a sample report. issue

Before this repo is released we should run the tool to create a sample then redact from the JSON and the report information about our emails and the GWS org we're testing on. M365 Sample
We'd rather not members of the public try a live pen test against us. :)

Multiple OUs Edge Case

If a GWS organization only has 1 existing organizational unit (OU) but has created other organizational units in the past then we are unable to grab the root Organizational unit name/ID.

Which means the rego can't filter out deleted OUs logs because we don't have the root OU name.

I hope this is not a common occurrence among existing GWS organizations.
Simple fix is to tell the organization to create at least one OU and our current filter will work.
Unsure if there is a long term fix somewhere.

Functional Testing for Chat

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Drive/Docs Baseline Dependent Baseline Policy Issues

There's been a few issues about this, but I wanted to put everything in one place.

The baseline policies for GWS.DRIVEDOCS.1 are not contradictory, but not all are applied in every situation.

GWS.DRIVEDOCS.1.1v1 - Agencies SHOULD disable sharing outside of the organization’s domain
Determines which of the following baselines should be 'active' and being checked. In my opinion, we shouldn't have this as a pass/fail, as we recommend that it is turned off, but have baselines established when it is turned on.

if sharing outside the organization is disabled (GWS.DRIVEDOCS.1.1v1 is 'compliant')
Then, GWS.DRIVEDOCS.1.2v1 should be evaluated (If disabling sharing outside of the organization's domain, then agencies SHALL also disable users' receiving files from outside of the organization's domain.)

Additionally,
GWS.DRIVEDOCS.1.3.1v1 and GWS.DRIVEDOCS.1.4.1v1 do NOT need to be checked.

if sharing outside the organization is enabled (GWS.DRIVEDOCS.1.1v1 is 'non-compliant')
Then, GWS.DRIVEDOCS.1.2.1v1 does not need to be checked

and
GWS.DRIVEDOCS.1.3.1v1 and GWS.DRIVEDOCS.1.4.1v1 need to be checked.

Currently, all baselines are being evaluated every time, which is causing extra failures when they don't need to be.

I worry about how this would be extended to multiple OUs, but I think this is the core of where the logic inconsistencies are coming from.

Drive 1.1 policy statement is contradicting

1.2 through 1.4 refer to settings when 1.1 is set to Allow Listed Domains (second radio button option)
However, 1.1 talks about setting the option as 'ON' or 'OFF' and not the 'Allow Listed Domains'

GWS.GMAIL.23 Feedback

TLDR: I recommend cutting GWS.GMAIL.23. See below for my reasoning.

GWS.GMAIL.23.1v0.1

The policy currently reads as "Attachment compliance SHOULD be enabled to filter specific attachments within Gmail messages." However, attachment compliance is not a simple on/off setting, so saying it should be enabled doesn't really mean anything. Even after reading the implementation, it's unclear what we actually are telling the users to do. Attachment compliance allows you to construct custom rules (similar to EXO's mail flow rules). For example, you could craft a rule such as ""if you have an incoming email from an external sender, prepend 'External: ' to the subject line." Saying to enable attachment compliance without specific details about what rules to craft is meaningless. Recommend cutting this control.

GWS.GMAIL.23.2v0.1

It might be worth noting the limitations Gmail itself has with true file type detection. It can only perform this detection on a select few file types (see https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F2364580%3Fhl%3Den&assistant_id=generic-unu&product_context=2364580&product_name=UnuFlow&trigger_context=a&fragment=file-types for more info). For all others it just matches by file extension. Given these limitations, I'm not sure if this a completely fair requirement.

GWS.GMAIL.23.3v0.1

Which file types should be blocked? "Executable" files are blocked by default, and can't be unblocked (https://support.google.com/mail/answer/6590?fl=1&sjid=1223071020538845302-NC#zippy=%2Cmessages-that-have-attachments). This is not the case for M365, so I don't think this control makes as much sense here.

Record and share your name pronunciation across Google Workspace products

From your Google account settings, you can now record your name and share its pronunciation with other users. The pronunciation can be played from your profile card across various Google Workspace tools such as Gmail or Google Docs on web or mobile devices. We hope this update makes it easier for you to represent yourself and connect with colleagues in Google Workspace.

Publish Date: Monday, December 11, 2023
Update Blog Link

Triage Information:

  • This update does not apply to any of the security configuration baselines

GWS.GMAIL.15, GWS.GMAIL.18, GWS.GMAIL.19; Contradictions and Duplications

  • GMAIL.15.1 contradicts 18.1 and 18.2.
  • GMAIL.15.2 overlaps and is redundant with 19.1 which is also redundant with 19.2.

Note that addressing these issues require large changes. So, pushing this issue to the backlog for now.

Policy 15.1 says to not use email allowlists, yet 18.1 and 18.2 says that we should? Also 18.2 duplicative of 18.1 except for the caveat.

#### GWS.GMAIL.15.1v0.1
An email allowlist SHOULD not be implemented.

#### GWS.GMAIL.18.1v0.1
An Approved Senders List SHOULD be configured to keep legitimate emails out of the spam folder.

#### GWS.GMAIL.18.2v0.1
An allowed senders list MAY be added but SHOULD NOT add allowed domains.

Policies 15.2, and 19.1, and 19.2 all are saying the same thing. We should choose one then delete the others.

#### GWS.GMAIL.15.2v0.1
A connection filter policy to create a Blocked Senders list MAY be implemented.

#### GWS.GMAIL.19.1v0.1
A blocked senders list SHOULD be configured to prevent emails from known malicious sources.

#### GWS.GMAIL.19.2v0.1
Blocked senders or domains MAY be added to the blocked senders list.

Run time bug in the GetLastEvent rego function for Gmail*

If 2 logs have the same timestamp, OPA will throw an exception.
For example, in this unit test (GMAIL.17.1V1 Correctv3) the logs have the same timestamp.
OPA throws an error. Changing the timestamp even just slightly fixes the error.

The function that causes this is actually our helper function GetLastEvent.
Chances of 2 logs of the same setting with different OUs applying at the same time should be rare in the wild.
Hopefully this won't break the tool before we can find a better solution.

Functional Testing for Drive

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Manage conversations by muting notifications in Google Chat

We’re introducing a new mute/unmute option in Google Chat to assist you in prioritizing and managing your messages. This is the latest feature within the recently announced enhanced Chat experience that helps you increase concentration, eliminate distractions and ultimately focus on the most important conversations.

Publish Date: Wednesday, December 6, 2023
Update Blog Link

Chat 4.2 SCB Update

Dev team found an issue with the baseline for GWS.CHAT.4.2v0.1.

You are the TCO, however, wait until I get more details on the change from Lauren before making any changes. I will let you know once I know more.

Functional Testing - All Baselines

This epic covers the functional testing for all the baselines post the new baseline numbering format update and other revisions.

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Related issues

Better Handle Permission Consent Errors

Issue that popped up when trying to help another team troubleshoot their setup.
When the user doesn't have the proper permissions to consent to the OAuth Scopes, the OAuth authorization token (token.json) returned won't throw any errors.
The user will then run ScubaGoggles with the improper permissions leading to errors like the one below.

/Users/x/scubagoggles/provider.py:463: RuntimeWarning: An exception was thrown trying to get the tenant info: <HttpError 403 when requesting https://admin.googleapis.com/admin/directory/v1/customers/my_customer?alt=json returned "Not Authorized to access this resource/api">

Simple fix is for the user to delete the improper token and then reconsent to the OAuth scopes, when their account is granted proper permissions. Currently we state in the README that the use has to have the super admin role to consent.

 
Long term fix: This issue is to implement a mechanism to either detect these errors, have better error messages, or prevent these errors from occurring.

Work should be centered around provider.py and auth.py

Meet Add-ons SDK available in Developer Preview

Today, the Google Meet Web Add-ons SDK is available through our Developer Preview Program. Developers can use the SDK to bring their app experience right into Meet. End users can install, open, and collaborate in apps right inside a meeting, either as the meeting focal point, or in the sidebar — all without ever leaving Meet.

Publish Date: Monday, December 11, 2023
Update Blog Link

Triage Information:

  • Related to the Google Meet SCB
  • There is no configuration item for this in Google Workspace Admin Console

Huddly cameras bring continuous framing to Google Meet Series One room kits

As part of our initiative to bring adaptive framing to Google Meet meeting rooms, we’re proud to announce that you can now access Huddly’s continuous framing capability available as part of the Series One room kit hardware devices. Huddly’s new framing solution continuously adjusts to include participants coming and leaving the room. The feature can be turned on by meeting participants directly from the touch controller. Using Huddly framing helps keep those in the meeting room in view no matter where they are, so that they’re more visible to other participants in the meeting which creates a more engaging experience.

Publish Date: Monday, December 11, 2023
Update Blog Link

Triage Information:

  • This update is not relevant to any of the security configuration baselines.

Turn on snippets for additional context surrounding data loss prevention rule violations

Admins can now view “Sensitive Content Snippets” for data loss prevention (DLP) rules. This applies to DLP events for Drive, Chat, and Chrome. When turned on, snippets will log the matched content that triggered a DLP violation in the security investigation tool. Admins can use the information captured in the snippet to better identify actual security risks, determine whether a false positive was returned, and decide on an appropriate course of action.

Publish Date: Wednesday, December 6, 2023
Update Blog Link

Functional Testing Baseline: CommonControls

Key points:

  • Test all the baseline policies
  • Test different use cases and edge cases
    • For each policy verify if the output as expected when the tests pass/fail
    • For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
      dependent/independent policies are unaffected
  • Perform tests to verify multiple OU and OU inheritance settings wherever applicable
  • Perform tests to verify Group settings wherever applicable

Groups 7.1 Prerequisite Issues

there is an issue with Groups 7.1, depending on the status of 6.1

If 6.1 is disabled (compliant), then 7.1 will automatically be compliant.

If 6.1 is enabled (warning), then 7.1 must be disabled to be compliant, otherwise it is non-compliant (warning).

Easily fill in smart chips in Google Docs using placeholder chips

To build on our innovations in smart canvas that help you simplify workflows and complete common tasks with easy-to-use prompts in Google Docs, we’re introducing placeholder chips.

Publish Date: Friday, December 8, 2023
Update Blog Link

Triage Information:

  • It is related to the Drive_Docs SCB
  • There is no configuration item in the Google Workspace Admin Console.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.