Investigate use of SecureScore to satisfy AAD 7.2

[ssatyapal123]

💡 Summary

Currently, policy MS.AAD.7.2v1 is a manual check for ensuring that the tenant is using fine grained administrative roles.

• Assign users to finer-grained administrative roles that they need to perform their duties instead of being assigned the Global Administrator role.

The purpose of this issue is to determine the best way to implement this policy check in ScubaGear.

Update 12/20/2023

Since creating this issue, we determined that Identity Secure Score is not feasible for ScubaGear. Instead we designed our own calculation to determine least privilege which is documented in this issue.

Old notes

Only tenants that have Secure Score for Identity Category implemented, ScubaGear can check the status of the Identity Secure Score for the Control Name: "RoleOverlap" to see if it is "100%". This option was considered but may not be ideal for the following reasons:

1. The GCC High environment does not implement the Identity Category
2. A lot of users have complained about making changes to their tenant after reviewing their secure score, and then finding out that the score doesn’t reflect the changes when they view it in the portal
3. We also don’t really know the formula that Microsoft uses to compute the specific secure score item that we are referencing for AAD 7.2 so if an agency were to fail that policy, we could give them some guidance on what to do, but we can’t be 100% sure that it would affect their secure score.

Some alternative ideas for the future that are not mutually exclusive:

1. Secure Score is a useful feature and instead of referencing just a policy check from the Identity category of the Secure Score (which is what we are tried for policy AAD 7.2). it makes more sense to add a section to the top of the AAD baseline, or in the appendix that says something like “try running the Identity Secure Score that Microsoft has to help you further improve your posture beyond the policies in this baseline.” This way the user can get the benefit of additional policy checks (i.e. things ScubaGear does not cover) from Identity Secure Score.
2. Brainstorm and develop a custom-made alternative mathematical formula that we can use for AAD policy 7.2 instead of secure score. Maybe a simple ratio might be good enough. However, if we are going to do bullet 1 above, then a check for policy 7.2 might not be necessary since Microsoft already covers it in secure score.

• This issue was previously examined in Emerald under issue Implement MS.AAD.7.2v1 Policy to check Secure Score #453

Acceptance criteria

How do we know when this work is done?

• CISA concurs on the new formula we proposed.
• Separate coding issue created.

[ssatyapal123]

After further investigation into this issue, the current thinking is to proceed with a custom-made mathematical formula to replace the Identity Secure Score check for the Control Name: RoleOverlap for the following reasons:

• Without insight into the Secure Score formula, ScubaGear results may not be easily defensible
• Creating a formula allows ScubaGear to control the pass/fail behavior

The following procedure was used to come up with a meaningful formula

Step 1. Come up with a few least privilege score formulas using simple ratios to start
Step 2. Run calculations on the test tenants using these formulas

Step 1: Formulas considered:
(Notes:

• All are ratios of numbers of users assigned to the roles specified
• If a user is assigned to Global Admin and another privileged/highly privileged role, they are only counted once for Global Admin as they don't need to have the other role to perform the function
• To easily find the numerator and denominator, you can run ScubaGear against each tenant and review the Provider Export JSON for the section named privileged_users to find all users with the Global Admin role and all those assigned to highly privileged roles but not to Global Admin)

1. Global Admins/ScubaGear Highly Privileged Roles
2. Global Admins/ScubaGear Highly Privileged Roles excluding Global Admins (selected this one, see below)
3. Global Admins/Total Privileged Roles*
4. Global Admins/Total Privilege Roles* excluding Global Admins

*Total Privileged Roles refers to Microsoft's recently updated official list of Azure AD built-in roles. Total Privileged Roles is the union of Microsoft's privileged roles and ScubaGear highly privileged roles. Note that ScubaGear includes two highly privileged roles that are not part of Microsoft's privileged roles set: Exchange and SharePoint Admins

After reviewing the different formulas, formula (2) seems to apply best for these reasons:

1. Focusing on ScubaGear Highly Privileged Roles vs Microsoft's recently introduced list is more relevant to ScubaGear
2. Excluding the Global Admins in the denominator helps highlight the impact of having too many Global Admins as compared to other privileged roles, for example, assuming there are 8 Global Admins:

• 8/(10-8) = 4 -> means that there are 4 times as many Global Admins as other highly privileged roles put together
• 8/(16-8) = 1 -> means there are as many Global Admins as other highly privileged roles put together
• 8/(24-8) = 0.5 -> means there are half as many Global Admins as other highly privileged roles put together

Initially, the threshold can be set at 1 as there should likely not be as many Global Admins as there are users assigned to other roles. However, for small tenants, it may be necessary to reduce the threshold to less than 1 as the ratio doesn't include insight into the total Global Admins (ScubaGear recommends no more than 8.) For small tenants, this number may be more important to check (e.g., even a ratio of 7/8 may not be advisable for small tenants as 7 Global Admins may be too many.)

Below is the calculations for formula 2 against the E5, G5, and E3 tenants:

- E5: Global Admins/ScubaGear Highly Privileged Roles excluding Global Admins: 6/11
- G5: Global Admins/ScubaGear Highly Privileged Roles excluding Global Admins: 12/21
- E3: Global Admins/ScubaGear Highly Privileged Roles excluding Global Admins: 8/11

Note that this formula only looks at the sum of highly privileged roles and not the distribution or roles. Another formula iteration could include information on the number of roles with at least one user provisioned.

CAVEAT: This issue has a dependency on issue #376 because of the fact that the privileged_users array will need to include roles assigned using PIM for Groups. Currently, privileged_users only includes users assigned directly to a highly privileged role.

[tkol2022]

Next step is to get concurrence from CISA on the new formula. Follow up via email.

[ssatyapal123]

Issue can be closed as effort is now in the coding issue #760.