Consider evaluating additional privileged roles in AAD

[tkol2022]

💡 Summary

Microsoft recently updated their official list of Azure AD built-in roles and some of their administration pages with information about what they consider "privileged" roles and permissions. Currently ScubaGear and the AAD baseline consider 8 built in roles as having the highest privileges (e.g. Global Administrator, User Administrator, Privileged Role Administrator). The scope of this issue is to determine if there is value in expanding our checks to include additional built in roles since that might help provider increased risk coverage versus what we have today.

Below are some ideas of potential improvements to ScubaGear (these are not mutually exclusive):

• Allow the user to add additional roles to the evaluation checks by passing role identifiers in the config file. The benefit of this is that it lets the user customize the functionality to their own needs. This is probably only useful to "power users" (i.e. users that have a lot of experience with AAD).
• Add a command line switch "-AllAADRoles true" that will tell ScubaGear to perform the evaluation checks for all privileged roles considered privileged by Microsoft. By default, we would only check the 8 highly privileged roles as we do today, but if the user passes this new switch, we would check additional roles. Microsoft currently designates 23 roles are privileged, so we would need to warn the user that running the AAD evaluations with that many roles could add significant time to the execution.

Screenshots

The following screenshots show changes to the Microsoft built in roles page and various admin pages in the AAD portal.

Acceptance criteria

How do we know when this work is done?

• [ ] The idea has been discussed with CISA and a decision has been made regarding whether any new functionality will be added to AAD.
• [ ] The results of the analysis have been documented in this issue.
• [ ] New issues have been created that described the scope of the source code changes.

[tkol2022]

Work completed thus far

This captures some of the salient work that has been performed so far on this issue.

• Met with Microsoft in January to discuss their criteria for designating privileged roles.
• Performed a review of Microsoft's criteria.
• @ssatyapal123 created a spreadsheet that contains all of the current AAD privileged roles and their associated privileged actions from Microsoft's Entra ID build-in roles web page so that we can consider this information in our analysis.
• Conducted an initial meeting with CISA to discuss the role criteria and what is important for Scuba
• Conducted discussion Microsoft to continue iterating on how we might change the baseline and the impacts of said changes.

[tkol2022]

@schrolla We won't make be making any decisions on baseline changes to roles in time for this release so I recommend we move this into Halibut.

[tkol2022]

July update

• Drafted a new set of criteria to determine which roles warrant inclusion as "privileged" in Scuba
• Drafted initial set of 12 Scuba privileged roles based on the draft criteria (note: this was an initial draft and updates are pending discussion and further analysis)
• Updated the master spreadsheet of 25 roles designated as privileged by Microsoft
• Created hands-on prototyping branch to test the impacts of adding roles on the performance of ScubaGear.

[tkol2022]

Policy ID	Policy	How adding new roles might impact organizations implementing Scuba policies
MS.AAD.7.1v1	A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role.	No impact because this policy is specific to the Global Admin role.
MS.AAD.7.2v1	Privileged users SHALL be provisioned with finer-grained roles instead of Global Administrator.	Will increase the value of Scuba's score generated for this policy because the score would be computed by examining a broader set of roles making the score more accurate. Practically speaking organizations are going to be assigning users to a broader set of privileged roles than just the set of 8 currently in ScubaGear.
MS.AAD.7.3v1	Privileged users SHALL be provisioned cloud-only accounts separate from an on-premises directory or other federated identity providers.	By expanding the roles Scuba would improve its risk surface detection coverage associated with non could-only privileged accounts (such as on-prem AD federated admin accounts).
MS.AAD.7.4v1	Permanent active role assignments SHALL NOT be allowed for highly privileged roles.	There would be an improvement in risk detection coverage of long-standing privileges.
MS.AAD.7.5v1	Provisioning users to highly privileged roles SHALL NOT occur outside of a PAM system.	There would be an improvement in risk detection coverage of cases where the privileged access management system is being bypassed when assigning permissions to users.
MS.AAD.7.6v1	Activation of the Global Administrator role SHALL require approval.	No impact because this policy is specific to the Global Admin role.
MS.AAD.7.7v1	Eligible and Active highly privileged role assignments SHALL trigger an alert.	There would be in increase in visibility of risky permissions assignments (i.e. when users are assigned to highly privileged roles).
MS.AAD.7.8v1	User activation of the Global Administrator role SHALL trigger an alert.	No impact because this policy is specific to the Global Admin role.
MS.AAD.7.9v1	User activation of other highly privileged roles SHOULD trigger an alert.	There would be in increase in visibility of when users are about to actively use their risky permissions.

[tkol2022]

Impact Analysis

The previous table describes my personal analysis of the impacts of adding new roles to Scuba, by policy. This section summarizes my thoughts.

• Overall there seems to be a clear benefit because if new privileged roles are added, ScubaGear would then examine more privileged access in the tenant than it does currently (i.e. more roles = more users with risky permissions). Also in practice, organizations are using more privileged roles than just the 8 roles that are currently in Scuba. So when ScubaGear executes today, there is a blind spot in the report because the additional roles that are used in practice (and the users assigned to them) aren't being audited.

• One of the potential administrative burdens that could be caused by adding more roles is that the sys admins that manage the tenant might have more work to do if there are more users considered privileged by Scuba, however this concern may be localized to a small handful of section 7 policies (about 5 policies). Each of those impacted policies must be analyzed in its own right and we might be able to tweak the policies to reduce any potential burdens or we might determine that the concern is not warranted due to various factors.

• I was initially concerned that by adding more roles, that policy 7.7 would trigger too many alerts which would eventually get ignored by security operations. After pondering this however, I am wagering that assigning users to highly privileged role assignments doesn't happen all that often even in larger organizations and should be audited.

• This leaves policy 7.9 which is the only concern. This policy generates an alert every time that a privileged user activates their role. Depending on how many users have privileged roles and how often they activate them, this could potentially generate an unmanageable number of alerts to monitor, especially if we were to expand the set of roles. This specific policy needs further discussion. We also should examine feedback we have received on this policy via the agency pilots to determine its feasibility in the baseline - examination of this policy may require additional work and discussion beyond this specific GitHub issue because it is centered on the general feasibility of the policy versus expanding the current number of privileged roles in Scuba.

• Of all the section 7 policies affected by expanding the privileged roles, there would be an unknown amount of manual labor for a sys admin to implement policies 7.7 and 7.9 because those require updating the configurations associated with each role in Entra ID and with each role PIM for Groups (if it is being used). Luckily this is a one time exercise and we could offer a utility script that sys admins could run in Powershell to perform the configurations that would automate the process.

What does this look like in practice?

I provided a screenshot below where I ran ScubaGear against 26 roles which closely matches what Microsoft currently has on their Entra Id roles page. This is what the section 7 policies would look like.

[tkol2022]

Performance Impact

Thanks to @crutchfield I was able to easily add a set of new privileged roles to ScubaGear and test to see how it would handle the increase from the existing 8 roles. He had programmed a DefaultPrivilegedRoles variable in ScubaConfig.psm1 which makes it easy to dynamically add more roles to the tool.

I ran a limited execution test and timed how long it took ScubaGear to run with three different sets of roles.

• ScubaGear with 8 roles (as it is today)
• ScubaGear with 14 roles (if we were to add 6 roles)
• ScubaGear with 26 roles (matching Microsoft's current privileged role list)

Surprisingly there was no noticeable difference in performance. Intuitively I thought ScubaGear would run at least a little slower with more roles, but that was not the case when I tested it. In order to ensure that many of the new roles that I added would be "picked up" by ScubaGear code I performed assignments of users and groups to the new roles.

Examine the screenshot below that shows the execution times in seconds. I ran each configuration 10 times and took and average. I ran using a service principal to minimize variances associated with user interactive authentication where you have to click the screen during authentication prompts. You can see from the data that all three configurations (8 roles, 14 roles and 26 roles) all executed within the same ballpark w/r/t time.

[tkol2022]

Closing this issue because the requisite work has been completed and discussed with CISA. Issue #1230 has been created to perform some testing with federal agencies and then we can analyze their feedback.