Azure AD Baseline Feedback
Overview
From an analysis of the Azure AD baseline that is part of SCuBA, I would like to provide feedback from the perspective of someone who has worked in a consultative role in the space of Azure AD with a variety of organizations.
It's understandable that the government provide guidance for agencies when implementing M365 and subsequently Azure AD tenants that are providing the identity layer to those services.
There are areas that are of somewhat concern, with public consumption of the guidance and the potential for adoption of such guidance without proper understanding, in particular in the commercial space. While it's understandable that the primary directive of this guidance is not to strengthen security of commercial organizations, it's likely that those organizations may attempt to consume this guidance as written to the letter. Considering how easy it is to run the ScubaGear tooling, one can see organizations easily adopting this tooling for baselining their environments, yet not necessarily understanding the ramifications behind adopting certain guidelines, especially those that tend to be more security-heavy or do not align with Microsoft recommendations. Along similar lines, there are other security recommendations for properly securing an Azure AD tenant that are not covered within here, and it may be helpful to note that this is not a comprehensive security baseline for all aspects of Azure AD.
The submission of this relates to my recent blog post in which I analyze the results, but I want to speak a bit further to some of them within here. You can find that post here, https://ericonidentity.com/2022/10/26/cisa-scuba-diving-into-the-azure-ad-baseline.
Perhaps it's simply a matter of CISA acknowledging within the guidance that if the public decides to consume it, that it may or may not cover all aspects of identity security in Azure AD, and that the recommendations may or may not align to any particular business model.
General Areas of Concern
SHALL v SHOULD
It could be presumed that SHALL v SHOULD align to NIST definitions, but it is not apparent within the guidance itself. While these terms perhaps are clear in the federal space, outside of that it may help from an open-source perspective to include the definitions within the guidance.
2.2 and 2.3 - Implementation Gap
For AAD tenants that have Azure AD Identity Protection available to them (AAD P2 or M365 E/G5), it has always been somewhat a bit misunderstood as far as whether to choose Conditional Access v AAD Identity Protection as far as the place to implement such policies. It's understandable to design to implement with CA, considering that you can only have one policy for user risk and sign-in risk defined within AAD Identity Protection.
There is one gap though when not defining these policies within Identity Protection. As CA policies are only ever evaluated in the resource tenant, if the users account is at risk or the sign-in is risky, the CA policy defined in the home tenant will not be evaluated when the user authenticates to the resource tenant. This primarily is a driver why baseline Identity Protection policies to the "majority" user base are still enabled, and then you can build from there with CAP.
2.9 and 2.10 - Usability Issues
It can be presumed that the recommendations here are to align to NIST 800-63B 4.2.3 or 4.3.3 for reauthentication and 7.3 for secret retention/session persistence.
It's understandable that CISA guidance would align to NIST, but from a usability perspective it's highly likely to become problematic, especially on mobile devices. Again, perhaps without insight into the user personas within federal agencies, this may or may not be an issue. But this area in particular is one that consumers outside of the federal space, who want to apply CISA guidance, should be warned that usability is at risk.
A 12-hour time window will generally cause little interference with a "normal desk job" worker, who likely locks their Windows device when away, or the device locks itself on idle, as unlock will cause reauthentication to take place. Therefore, a policy as such could be applied and not interfere with devices under control of the organization.
Mobile devices though can suffer from these settings, as they can interfere with client applications. A common example is session expiration in the Outlook application, and then users not realizing that they have not been receiving email, as the client will not alert the user that reauthentication is necessary.
2.14 - Lack of Break-glass accounts
The general recommendation on break-glass accounts is missing, which perhaps CISA and the federal space account for the inherent risk, but organizations that do accidently lock themselves out of their tenant have to go through a decent process to gain access to their tenant. Hence the need for break-glass accounts.
While there may also be the possibility that the federal space has different mechanisms for tenant recovery, commercial organizations that do not account for break-glass, regardless of their size, will spend days locked out of their tenant from a management perspective, which depending on the severity of what was implemented, could be highly impactful to the entire organization.
Likewise, in the case that there are issues with the Azure MFA services or Azure AD PIM role assignment, recommendation from Microsoft is that at least one break-glass account is without MFA, and that it is permanently assigned Global Administrator. Again, CISA guidance may align to federal requirements and recommendations, but this advice may not necessarily translate well beyond those walls.
2.14 and 2.15 - Implementation Gap
Out of the box all role assignments in Azure AD PIM provide an 8-hour role elevation lifetime. Perhaps covered in other federal recommendations outside of this guidance, but for roles such as Global Administrator, Microsoft recommends that activation should be limited to an hour. General identity security guidance would align in that a highly privileged role should be limited to the minimal viable window - it's unlikely a Global Administrator requires activated privileges for an entire 8 hours. Alternatively, recommendation should indicate that roles should be deactivated through Azure AD PIM once the usage of the role for the required work is complete.