GWS Policy API Updates for Common Controls and Gmail

[rlxdev]

🗣 Description

Google released more settings in the Policy API subsequent to the initial PR for the ScubaGoggles Policy API integration. The settings have allowed the following policies to be implemented as part of this PR:

• Common Controls 1.1: Phishing-Resistant MFA SHALL be required for all users
• Common Controls 1.2: Google 2SV new user enrollment period SHALL be set to 1 week
• Common Controls 1.3: Allow users to trust the device SHALL be disabled
• Common Controls 16.2: User access to Early Access Apps SHOULD be disabled
• Gmail 1.1: Mail Delegation SHOULD be disabled
• Gmail 8.1: User email uploads SHALL be disabled to protect against unauthorized files being introduced into the secured environment
• Gmail 9.1: 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
• Gmail 10.1: Google Workspace Sync SHOULD be disabled
• Gmail 12.1: Using a per-user outbound gateway that is a mail server other than the Google Workspace mail servers SHALL be disabled

Closes #519

🧪 Testing

Rego tests were added for the new implementations detailed above. They all include testing for the
compliant and non-compliant cases. The following test files have been added:

commoncontrols_api01_test.rego
commoncontrols_api04_test.rego
commoncontrols_api16_test.rego
gmail_api01_test.rego
gmail_api08_test.rego
gmail_api09_test.rego
gmail_api10_test.rego
gmail_api12_test.rego

In addition to these tests, testing was done on each affected baseline using the scubagws Admin UI .

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
• The relevant issues PR resolves are linked preferably via closing keywords.
• All relevant type-of-change labels have been added.
• I have read and agree to the CONTRIBUTING.md document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• Tests have been added and/or modified to cover the changes in this PR.
• All new and existing tests pass.

✅ Pre-merge Checklist

• This PR has been smoke tested to ensure main is in a functional state when this PR is merged.
• Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge Checklist

• Delete the branch to clean up.
• Close issues resolved by this PR if the closing keywords did not activate.

[adhilto]

@rlxdev Why isn't Common Controls 1.4 included in this? I'm all for splitting big updates into multiple PRs, but it doesn't look like we have a separate issue for that. The policy API does support checking it, the logic is the same as what you have for 1.1, just trading line 289 with enforceMethod != "ALL".

[adhilto]

Tested and works as expected. My only ask is that you open up an issue to track updating 1.4 since it's ready to be updated.

[rlxdev]

If I understand the Common Controls 1.4 baseline correctly, the criterion for meeting the requirement is to allow users to turn on 2-step verification with security key only or non-telephony OR passwordless authentication. Google has not provided the passwordless authentication setting in the Policy API yet, so the baseline can only be partially implemented. This is one of the baselines in the Policy API tracker for Google. I didn’t change the Rego code for this reason, deciding to wait for Google until they provide the passwordless authentication settings in the API results.

[adhilto]

If I understand the Common Controls 1.4 baseline correctly, the criterion for meeting the requirement is to allow users to turn on 2-step verification with security key only or non-telephony OR passwordless authentication. Google has not provided the passwordless authentication setting in the Policy API yet, so the baseline can only be partially implemented. This is one of the baselines in the Policy API tracker for Google. I didn’t change the Rego code for this reason, deciding to wait for Google until they provide the passwordless authentication settings in the API results.

This looks like a conversation we'll want to queue up for later to clarify the baseline, my understanding is that 1.4 just boiled down to "don't use SMS or voice as a second factor." That's certainly all that the Rego is currently checking and is consistent with the equivalent M365 control. But after reviewing the implementation steps, I can see where you're coming from.

[snarve]

Tested and works as expected, only recommendation is the naming convention and function names - follow standard naming methodology.
Approving the PR as the functionality works as expected, recommend the naming targeted in the upcoming updates.

[mitchelbaker-cisa]

Created new report, checked each policy with updated api setting result in details section. Ran all unit tests with no issue.