Reevaluate the benefits of Groups 7.1

[buidav]

💡 Summary

In the instructions for 7.1 we're asking that groups be initially created with access type of restricted. This seems like a best practice and can easily just easily be bypassed by changing the access type right after creation.

The rego itself checks if all groups are always of access type restricted permissions.

Due to the organizational needs I'm not sure it's viable for us to have a policy that says groups must always disable that anyone in the organization can.

• view post
• post to
• view members of a group.

I think we should delete 7.1 altogether but I'm open to other suggestions.

Motivation and context

Streamlining the ease of use of the SCuBA baselines.

Implementation notes

• Either delete or rewrite the instructions for Groups 7.1

Acceptance criteria

• Groups 7.1 has a clearer purpose or is deleted.

[LaurenBassett]

The other thing I think worth mentioning, is that the baseline currently appears to be checking for ALL existing groups and whether or not they are restricted. It does not address the actual core of the baseline, which is that NEW groups should be restricted.

[mdueltgen]

We have decided to remove Groups 7.1 for clarity.