Code Monkey home page Code Monkey logo

cisagov / scubagoggles Goto Github PK

View Code? Open in Web Editor NEW
141.0 9.0 17.0 4.38 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.52% Python 5.85% HTML 8.19% JavaScript 0.12% CSS 0.23% Shell 0.09%
cisa cybersecurity google-workspace opa open-policy-agent python google gws open-source security

scubagoggles's Issues

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.

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

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

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

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

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

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. :)

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

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

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.

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

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

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

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.

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.

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

See Common Controls Rego for an example

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'

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

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

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.