Changes to Common Controls Baseline

[jkaufman-mitre]

🗣 Description

The following changes were made within the common controls baseline:

• Policy 2.2 was removed
• Policy 10.1 was removed
• Policy Group 16, Additional Google Services, was created
• Policy group 17, Multi-Party Approval, was created
• Policy 14.1 implementation was updated.
• Change 11.1 to SHALL

💭 Motivation and context

Fixes #240
Fixes #252
Fixes #274
Fixes #276

🧪 Testing

✅ 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]

GWS.COMMONCONTROLS.2.1v0.2 still needs more work.

The note, "granular controls may be used if the agency needs it," is misleading because it kind of implies that specifying what controls you want context aware access to apply is optional. It's not. Simply doing what is currently the implementation for 2.1 doesn't do anything. The full instructions need to include the following elements:

1. Turn on context aware access (as instructed in the current implementation, see screenshot)
   

2. Create one or more access levels, as needed
   
   

3. Determine the conditions of the rule, per agency discretion.
   

4. Assign the access levels
   

Finally, there are still a lot of open questions left.

• What should the conditions of the access levels be? Entirely up to agency discretion?
• Which apps should be assigned to those levels? All? Just the admin center? Agency discretion?
• Which users should be assigned to those levels? They can be assigned at the OU and or group level. All? Or agency discretion?
• What mode should those assignments be in? Just monitor? Or active? Left to agency discretion?

Recommendations:

• Clarify that "Note:" for 2.1. Maybe: "Note: the implementation details of context-aware access use cases will vary per agency. Refer to Google's documentation on implementing context-aware access for your specific use cases."
• Augment the implementation steps to include all that I detailed above.
• Delete the implementation steps for 2.2 (they're still there).
• Address the open questions listed above.

[adhilto]

Feedback for GWS.COMMONCONTROLS.16.1

[jkaufman-mitre]

Removed Policy 10.1 because there is no implementation for the policy. Agencies will be evaluated on their in-house procedures for items such as this as part of their NIST 800-53 control assessments. The technical implementation steps are already covered within this policy group.

[jkaufman-mitre]

Moved 11.2 to Policy Group 10 (#318)

[adhilto]

Moved 11.2 to Policy Group 10 (#318)

Looks like this change might not have been pushed yet?

[jkaufman-mitre]

Made Common Controls 11.1 a SHALL.

[jkaufman-mitre]

TTP Mappings have been added.

[jkaufman-mitre]

@adhilto @buidav Can you review this. This one is ready for review again.

[mdueltgen]

As discussed, removed Issue 290 for 2.2. Context Aware Access revamp will happen in the next release after Coast.

@adhilto Please review the 2.1 section for Coast release including changes to the implementation steps.

OOO and don't want this PR to block on me

[snarve]

11.2 is unchanged as @adhilto mentioned in the email thread. Since there is a separate issue for this( #318 ), recommend to create a separate branch for this and commit separately as this PR tackles multiple issues already. Having a separate branch and PR (per issue) would ease the tracking and updates.
@jkaufman-mitre @mdueltgen @adhilto @buidav any thoughts on this

[adhilto]

11.2 is unchanged as @adhilto mentioned in the email thread. Since there is a separate issue for this( #318 ), recommend to create a separate branch for this and commit separately as this PR tackles multiple issues already. Having a separate branch and PR (per issue) would ease the tracking and updates. @jkaufman-mitre @mdueltgen @adhilto @buidav any thoughts on this

I agree, that's the right call (with the caveat that branch be made after this one is merged in to ease merge conflicts). I just edited the description of this PR to remove that issue so it's accurate and so that that issue won't auto-close once this PR is merged.

[mdueltgen]

11.2 is unchanged as @adhilto mentioned in the email thread. Since there is a separate issue for this( #318 ), recommend to create a separate branch for this and commit separately as this PR tackles multiple issues already. Having a separate branch and PR (per issue) would ease the tracking and updates. @jkaufman-mitre @mdueltgen @adhilto @buidav any thoughts on this

I agree, that's the right call (with the caveat that branch be made after this one is merged in to ease merge conflicts). I just edited the description of this PR to remove that issue so it's accurate and so that that issue won't auto-close once this PR is merged.

Sounds good I will make sure #318 and #290 are in different branches for the next release. I think now that those two have been removed from the description of this PR, I think we should be good to do review of PR as is and merge for Coast.

[adhilto]

Baseline looks good, and Rego changes are complete. @snarve did half yesterday, I did the last half today.

[mdueltgen]

Rev

[snarve]

Looks good