Updated: November 29th, 2022
CISA recently released baseline guidance for cloud application security, dubbed SCuBA, or Secure Cloud Business Applications. Within this guidance they cover the M365 and Google Workspace stacks, and they have also released the ScubaGear tool, which you can find here, cisagov/ScubaGear: Automation to assess the state of your M365 tenant against CISA’s baselines (github.com). The ScubaGear tool provides the ability to run an assessment against a targeted M365 environment against baselines. I’ve tested the ScubaGear tool against the Azure AD baseline, and it works well enough, but for the purposes of this post I’m targeting the baseline itself.
When released, there is the natural curiosity to see where things intersect with CISA recommendations, Microsoft recommendations, and what actually works out in the real world. I saw some folks on Twitter commenting that this could be potentially a great tool for analysis for all sorts of commercial and public organizations, big and small. But do the recommendations from, and for, the Federal Government align to what most organizations really need?
I’ll be taking a look at each baseline policy as defined and providing analysis on it specific to the context of its applicability outside of government scenarios. I’ll be going through in order as written, and then providing a final take. Note that for ease the header numbering aligns to the baseline.
If you’re curious to obtain the baseline, CISA has it available as a PDF found here, Microsoft Azure Active Directory PDF. There is also a markdown version on Github that is easier to consume, found here, ScubaGear/aad.md at main · cisagov/ScubaGear (github.com). As I’m only providing reference to the policy itself, I’ll point out that the CISA documents in either format also provide useful license requirement information and details on implementation, which are mostly links to Microsoft Docs Learn articles.
Content between policy definition header and analysis is provided from CISA recommendations. Content after colored Analysis header to next recommendation is my analysis.
Terminology
One component of the CISA guidance is the lack of reference to the differentiation between the terminology SHALL vs SHOULD. If aligned to NIST definitions, taken from NIST publications:
SHALL – “indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted“
SHOULD – “indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited“
Azure AD Baseline
2.1 Legacy Authentication SHALL Be Blocked
Block legacy authentication protocols using a conditional access policy. Legacy authentication does not support multifactor authentication (MFA), which is required to minimize the impact of user credential theft.
2.1.1 Policy
- Legacy authentication SHALL be blocked
2.1 Analysis | Agree
A straightforward recommendation, which is much easier now that Microsoft has disabled basic authentication as of October 1st, 2022 (Microsoft retires Basic Authentication in Exchange Online | Microsoft 365 Blog).
The one area that tends to get sticky is in the realm of SMTP, used primarily by customers for things like multi-function devices, as well as for applications sending email. To a lesser extent, some Service Desk applications and other ITSM platforms use IMAP for receiving email inbound.
While Microsoft has implemented modern authentication for POP, IMAP, and SMTP, Authenticate an IMAP, POP or SMTP connection using OAuth | Microsoft Learn, most services leveraging basic authentication are likely far behind.
To the recommendation from CISA, organizations can use systems like SendGrid for outbound mail.
If organizations must continue to use basic authentication, I would recommend that a conditional access policy is used to block access to those accounts outside of the corporate network boundaries.
2.2 High Risk Users SHALL Be Blocked
Azure AD Identity Protection uses various signals to detect the risk level for each user and determine if an account has likely been compromised. Users who are determined to be high risk are to be blocked from accessing the system via Conditional Access until an administrator remediates their account. Once a respective conditional access policy with a block is implemented, if a high-risk user attempts to login, the user will receive an error message with instructions to contact the administrator to re-enable their access.
2.2.1 Policy
- Users detected as high risk SHALL be blocked.
- A notification SHOULD be sent to the administrator when high-risk users are detected.
2.2 Analysis | Partially Agree | Recommendation Missing Components, May Not Align To All Organizations
The recommendation takes a harder stance than Microsoft, which by default recommends requiring a password change after sufficient proofing of the user, instead of a block.
Blocking access is the more secure route, but the policy may not apply to all organizations in all situations. Additionally, if the case is likely that the user account has been breached, it limits the ability for user self-remediation. I would agree that alerts should be configured, but likely rolling up alerts through a SIEM than emails directly from Identity Protection. Of course, for the paranoid, having both configured will provide layers of notification.
For organizations that do take this route, the other issue is CISA configuring the block as a conditional access policy. Conditional access policies only apply within the resource tenant, so if the user is an outbound guest accessing resources in another tenant, a CAP will not apply. It would be recommended to configure this in a multi-layered approach, with Azure AD Identity Protection also configured with a user risk policy to block authentication. Likewise, if organizations pivot from blocking to requiring a password change, the policy should still be applied as an AAD Identity Protection policy, to ensure that users are covered even when they are guests in another tenant.
2.3 High Risk Sign-ins SHALL Be Blocked
Azure AD Identity Protection uses various signals to detect the risk level for each user sign-in. Sign-ins detected as high risk are to be blocked via Conditional Access.
2.3.1 Policy
- Sign-ins detected as high risk SHALL be blocked.
2.3 Analysis | Agree | Recommendation Missing Components, May Not Align To All Organizations
Like user risk policy, this takes a stronger stance, but also leaves some gaps from Microsoft recommendations, which are to require MFA for all medium or higher sign-in risks, instead of a block. The thought process behind the Microsoft recommendation is that if the user is able to sufficiently proof themselves through MFA, even if Conditional Access is not requiring such, will verify the user. I would suspect the CISA stance could be based on the thought that MFA is currently highly phishable in certain forms, even though they recommend only using phishing-resistant MFA.
This area tends to be something that varies among organizations depending on the type of organization and their primary user personas. The CISA recommendation does not cover medium risk sign-ins, which could have a potential malicious aspect to them as well. A strategy here may be to configure the Azure AD Identity Protection sign-in risk policy as a medium or higher to require MFA, to ensure that outbound guests access resources in another tenant are still protected. While there is some presumption that across agencies this would be less of an issue as the resource tenant would have similar CAP, in the commercial space that is likely not going to be the case. At the same time, continuing to keep the high blocking policy.
For some organizations such as higher education, it is likely that even blocking instead of requiring MFA will be too disruptive to a widely dispersed and mobile user base, which has a bundle of complexities with even phishing-resistant MFA.
2.4 Phishing-Resistant Multifactor Authentication SHALL Be Required for All Users
Phishing-resistant multifactor authentication protects against sophisticated phishing attacks. Recognizing the significant risk these attack present, the Office of Management and Budget (OMB), requires federal agencies to implement phishing-resistant authentication.
However, phishing-resistant MFA may not always be immediately available, especially on mobile devices. Where phishing-resistant MFA is not yet available, organization should adopt an MFA method from the list below. Organizations must upgrade to a phishing-resistant MFA method as soon as possible to become compliant with this policy and address the critical security threat posed by modern phishing attacks.
2.4.1 Policy
- MFA SHALL be required for all users.
- Phishing-resistant MFA SHALL be used for all users.
- Phishing-resistant methods:
- Federal PIV card (Azure AD Certificate-Based authentication [CBA])
- FIDO2 Security Key
- Windows Hello for Business
- Federal Personal Identity Verification (PIV) card (Federated from agency Active Directory or other identity provider)
- Phishing-resistant methods:
- If phishing-resistant MFA cannot be used, an MFA method from the list below SHALL be used in the interim:
- Microsoft Authenticator (Push Notifications)
- Microsoft Authenticator (Phone Sign-in) (Also referred to as Passwordless Sign-in)
- When using Microsoft Authenticator:
- Number Matching SHALL be enabled.
- Additional Context SHALL be enabled.
- When using Microsoft Authenticator:
- Software Tokens One-Time Password (OTP) – This option is commonly implemented using mobile phone authenticator apps
- Hardware tokens OTP
- SMS or Voice as the MFA method SHALL NOT be used.
2.4 Analysis | Agree | May Not Align To All Organizations
It cannot be stressed enough to organizations that can implement phishing-resistant MFA, to do such. Windows Hello for Business and FIDO2 security keys are easier than ever to rollout and can be rolled out in a staged fashion. What becomes a wall for many organizations is the realization that their applications are holding back a full passwordless implementation. I discuss this more in this post, An Agile Refresh of the Passwordless Strategy – Eric on Identity.
At the very least, organizations should enable the Authenticator App for passwordless (phone sign-in) and/or Authenticator App for MFA. If corporate issued devices are involved, there should be no choices provided for anything weaker from an MFA stance at this point.
As with 2.3, for some organizations, especially in primary and higher education, as well as non-profits, it may be a difficult posture to take with the varied user personas and the unique challenges in each organization. Even for those corporations who do not issue corporate phones, globally there are varying personal stances and even laws regarding use of personal devices for corporate use. If organizations have a difficult time enforcing usage of the Authenticator App, they should coordinate to use things like TAP to bootstrap WHfB, and require Authenticator App usage as a trade-off if the user is not required to access corporate resources from their personal device.
2.5 Azure AD Logs SHALL Be Collected
Configure Azure AD to send critical logs to the agency’s centralized SIEM and to CISA’s central analysis system so that they can be audited and queried. Configure Azure AD to send logs to a storage account and retain them for when incident response is needed.
2.5.1 Policy
- The following critical logs SHALL be sent at a minimum: AuditLogs, SignInLogs, RiskyUsers, UserRiskEvents, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ADFSSignInLogs, RiskyServicePrincipals, ServicePrincipalRiskEvents.
- If managed identities are used for Azure resources, also include the ManagedIdentitySignInLogs log type.
- If the Azure AD Provisioning Service is used to provision users to SaaS apps or other systems, also include the ProvisioningLogs log type.
- The logs SHALL be sent to the agency’s SOC for monitoring.
2.5 Analysis | Agree
Recommendation is straightforward. Too many organizations still do not send Azure AD logs to a SIEM or at the very least something like Log Analytics, which can become a liability in the event of a breach.
2.6 Only Administrators SHALL Be Allowed to Register Third-Party Applications
Ensure that only administrators can register third-party applications that can access the tenant.
2.6.1 Policy
- Only administrators SHALL be allowed to register third-party applications.
2.6 Analysis | Agree | Recommendation Is Misleading, May Not Align To All Organizations
The ability to register applications in a tenant is one that comes up often, and there are nuances within it. By default, Microsoft allows for app registration for all users within an Azure AD tenant, but as CISA points out in the 2.6.4 implementation, you can disable this setting tenant-wide.
Where the recommendation in the title is a bit misleading, is that App Registration is not specific to third-party applications. Organizations developing applications in-house, either single or multi-tenant apps, are going to need to register applications with Azure AD.
Having worked with some federal government agencies in designing plans for this in the past, this becomes a very business process heavy scenario. From the security lens, the organization should provide a lower environment Azure AD tenant, which may though have a bit of a cascading impact. Within there, developers may be allowed to register applications, and that is also the tenant in which the applications go through any security testing processes. When it comes time to promote the application to production, a privileged administrator works with the developers to create the App Registration in the prod Azure AD tenant.
In commercial spaces of all shapes and sizes, most do not choose to build out the lower environments and may either leave this open in the name of usability, or find middle-ground by disabling this, but then providing some users the Application Developer role to be able to register applications. Alternatively, a privileged user may create the app registration and then assign an owner to it, allowing the owner to further manage it.
2.7 Non-admin Users SHALL Be Prevented from Providing Consent to Third-Party Applications
Ensure that only administrators can consent to third-party applications and only administrators can control which permissions are granted. An admin consent workflow can be configured in Azure AD, otherwise users will be blocked when they try to access an application that requires permissions to access organizational data. Develop a process for approving and managing third-party applications.
2.7.1 Policy
- Only administrators SHALL be allowed to consent to third-party applications.
- An admin consent workflow SHALL be configured.
- Group owners SHALL NOT be allowed to consent to third-party applications.
2.7 Analysis | Agree
By default, Microsoft used to allow for users to consent to all applications, even though I believe recently things have changed in newly minted tenants, which set application consent to verified publishers for “low impact” permissions.
Whenever approaching Azure AD tenants that have been around for a while, this always becomes a topic, both in the analysis and cleanup of existing applications, but then also how to tune things more towards the security end of things, without interfering with the user experience too much. Afterall, completely disrupting the ability for users to leverage their work account is a process that leads to shadow IT and accounts being created external to the organization within those applications.
Jeffrey Appel (@JeffreyAppel7) has an excellent article that dives into why third-party application consent should be restricted, as well as how to manage it. I suggest you check it out here, Protect against AzureAD OAuth Consent phishing attempts (Illicit consent attack) (jeffreyappel.nl).
2.8 Passwords SHALL NOT Expire
Ensure that user passwords do not expire. Both the National Institute of Standards and Technology (NIST) and Microsoft emphasize MFA because they indicate that mandated password changes make user accounts less secure.
2.8.1 Policy
- User passwords SHALL NOT expire.
2.8 Analysis | Partially Agree
In the security and identity communities this is a rather polarizing recommendation.
For organizations that in particular are on the passwordless journey, requiring users to still have to manage a password for the sake of rotation places a burden on users and gives a perception that passwordless will never come to reality.
On the other side, organizations such as Trimarc Security and KnowBe4 continue to stress that passwords should be rotated:
The recommendation also comes down to user personas, and within the CISA recommendations, those are lacking. Organizations should take the time to understand their user base, and while leaning towards security, ensure that they don’t implement a password expiration policy that will provide a high degree of interference for end users.
2.9 Session Length SHALL Be Limited
To reduce the risk of credential theft during user sessions, configure the sign-in frequency to a limited period of time. (Defined as 12 hours in 2.9.4 Implementation)
2.9.1 Policy
- Sign-in frequency SHALL be configured to 12 hours.
2.9 Analysis | Disagree | Recommendation Not Suitable For Most Organizations
Sign-in frequency is the most problematic session policy within Conditional Access. I’ve encountered several organizations who take the approach that flipping the most switches equals the most security at the complete demise of the user experience. If you hate your users, this is the policy to enable.
Ultimately sign-in frequency does have its use cases, but they are usually specific, targeting sensitive applications or privileged users, or users coming from personal devices.
It would seem from analysis that CISA is aligning to NIST 800-63B 4.2.3 (AAL2) or 4.3.3 (AAL3), which indicates that reauthentication should occur every 12 hours. This makes sense for one government agency to align with another, but there are usability ramifications that organizations outside of those mandated to use these settings should consider here.
Enabling this policy will result in users seeing messages such as the following in Windows after 12 hours without re-authentication:
Which again, these may be mitigated based on typical user behavior and ensuring that users are using passwordless to satisfy MFA expiration requirements within this CAP session control.
Mobile devices won’t be able to easily avoid this, and you’ll end up leaving your users on a daily basis with this experience:
With the lack of any definition of user personas within NIST guidance, it’s a rather heavy-handed approach to security. Of all the recommendations, this is one that commercial organizations should really investigate before consuming the advice of CISA.
2.10 Browser Sessions SHALL NOT Be Persistent
To reduce the risk of credential theft during user sessions, disallow persistent browser sessions.
2.10.1 Policy
- Browser sessions SHALL not be persistent.
2.10 Analysis | Disagree | Recommendation Not Suitable For Most Organizations
Browser session policy, or the Keep Me Signed In (KMSI) experience, is what allows a user to close their browser window and then open it again without having to reauthenticate. It’s a great control for securing access on highly privileged users, and for external access on personal devices that are not MDM or MAM controlled, and for guest users.
With a bit of a deeper analysis, it could be presumed that CISA is aligning to NIST 8006-3B 7.2, which states “session secrets SHALL be non-persistent“.
In the commercial space of Zero Trust, the general though process in that the device is the security boundary, and if the device is secure, then what happens on the device should be considered under the same security context, is why browser session policy interferes with corporate devices and may actually move away from a Zero Trust design. However, it’s a bit of a polarizing debate.
If a device is compliant and corporate managed, and the user is using a strong means of authentication such as Windows Hello for Business or a FIDO2 security key, then as long as the user remains within the same security context (which from a privileged access standpoint they should irrespective of this setting), it’s a bit of a pointless mechanism. If the user does succumb to something like malware, it’s a relative shot in the dark as to whether they have browsers on their corporate device open or closed and it’s ultimately using complete randomness as a security measure.
Save this one for the use cases outside the corporate confines, and perhaps for the limited privileged users we want to be extra paranoid about.
2.11 The Number of Users with the Highest Privilege Roles SHALL Be Limited
Global Administrator is the highest privileged role in Azure AD because it provides unfettered access to the tenant. Therefore, if a user’s credential with these permissions were to be compromised, it would present grave risks to the security of the tenant. Limit the number of users that are assigned the role of Global Administrator. Assign users to finer-grained administrative roles that they need to perform their duties instead of being assigned the Global Administrator role.
2.11.1 Policy
- A minimum of two users and a maximum of four users SHALL be provisioned with the Global Administrator role.
2.11 Analysis | Agree
Another hot topic when working with organizations, which usually will have more than four Global Admins. Microsoft recommendation is no more than five Global Admins, and if two of them are break-glass accounts, that leaves you three usable under Microsoft recommendation.
CISA makes no mention of break-glass accounts, so it’s hard to determine if they include them within this, which would leave two usable Global Admins, or not, and you in theory then have six total.
Regardless, there are a few truths within here:
- Most organizations have too many Global Admins and should use this recommendation as a benchmark to push to reduce the number.
- Without specifics on break-glass accounts, it’s difficult to gauge the actual total.
- As such, that total number, even with great reduction, is likely to vary by an account or two.
Global Administrators need zero rights on Azure subscriptions.
M365 and Intune both offer delegation models managed outside of Azure AD for further permission refinement.
2.12 Highly Privileged User Accounts SHALL Be Cloud-Only
Assign users that need to perform highly privileged tasks to cloud-only Azure AD accounts to minimize the collateral damage of an on-premises identity compromise.
2.12.1 Policy
- Users that need to be assigned to highly privileged Azure AD roles SHALL be provisioned cloud-only accounts that are separate from the on-premises directory or other federated identity providers.
- The following built-in Azure AD roles are considered highly privileged at a minimum. Additional built-in roles that are considered highly privileged in the agency’s environment can be added to this list:
- Global Administrator
- Privileged Role Administrator
- User Administrator
- SharePoint Administrator
- Exchange Administrator
- Hybrid Identity Administrator
- Application Administrator
- Cloud Application Administrator
2.12 Analysis | Agree
This recommendation is straightforward and I would use this for all organizations that are assigning highly privileged roles to daily driver user accounts, as well as those who have assigned privileges to separate accounts that are still sourced from Active Directory.
Not only does cloud-only insulate you from configuration issues with hybrid identity, but it also ensures that a breach of Active Directory does not result in a breach of Azure AD.
One piece that CISA is missing in the recommendation, those Global Administrator accounts should retain the UPN suffix for the default tenant.onmicrosoft.com domain, in the case that a misconfiguration issue arises with the custom domain.
2.13 Multifactor Authentication SHALL Be Required for Highly Privileged Roles
Require users to perform MFA to access highly privileged roles. This configuration provides a backup policy to enforce MFA for highly privileged users in case the main conditional access policy—which requires MFA for all users—is disabled or misconfigured.
2.13.1 Policy
- MFA SHALL be required for user access to highly privileged roles.
- Refer to the baseline statement [Highly Privileged User Accounts SHALL be Cloud-Only](#2.12.1 Policy) for a recommended minimum list of Azure AD built-in roles that are considered highly privileged. It is also possible to designate additional built-in roles that are considered highly privileged in the agency’s environment based on its risk tolerance.
2.13 Analysis | Agree
Another straightforward recommendation that also aligns with Microsoft. Having a privileged role specific Conditional Access policy for MFA should exist in every tenant. If you don’t have one, makes plans to add one.
2.14 Users Assigned to Highly Privileged Roles SHALL NOT Have Permanent Permissions
Do not assign users to highly privileged roles using permanent active role assignments. Instead, assign users to eligible role assignments in a PAM system and provide an expiration period for active assignments requiring privileged users to reactivate their highly privileged roles upon expiration.
Note: Although Azure AD PIM is referenced in the implementation instructions, an equivalent third-party PAM service may be used instead.
2.14.1 Policy
- Permanent active role assignments SHALL NOT be allowed for highly privileged roles. Active assignments SHALL have an expiration period.
- Refer to the baseline statement, Highly Privileged User Accounts SHALL be Cloud-Only, for a recommended minimum list of Azure AD built-in roles that are considered highly privileged. It is also possible to designate additional built-in roles that are considered highly privileged in the agency’s environment based on its risk tolerance.
- Provisioning of users to highly privileged roles SHALL NOT occur outside of a PAM system, such as the Azure AD PIM service, because this bypasses the controls the PAM system provides.
2.14 Analysis | Agree | Recommendation Missing Components
The recommendation is solid, however, in lack of a reference to break-glass accounts, it does not cover that those accounts should have permanent assignment per Microsoft. At the very least the one “backup” break-glass account should have permanent assignment.
In reality too many organizations are relaxed on their use of PIM, and this CISA recommendation overall should be taken as solid advice.
2.15 Activation of Highly Privileged Roles SHOULD Require Approval
Require approval for a user to activate a highly privileged role, such as Global Administrator. This makes it more challenging for an attacker to leverage the stolen credentials of highly privileged users and ensures that privileged access is monitored closely.
Note: Although Azure AD PIM is referenced in the implementation instructions, an equivalent third-party PAM service may be used instead.
2.15.1 Policy
- Activation of highly privileged roles SHOULD require approval
- Refer to the baseline statement Highly Privileged User Accounts SHALL be Cloud-Only for a list of Azure AD built-in roles that are considered highly privileged. It is also possible to configure additional built-in roles that are considered highly privileged in the agency’s environment based on its risk tolerance.
2.15 Analysis | Agree | May Not Align To All Organizations
The theory that Global Administrator requires approval is a tough pill for many organizations to swallow. And the majority of them don’t. There are arguments around both the technological aspects as well as the business aspects for those that hold Global Administrator:
- This inhibits work while I wait for approval
- What happens if nobody is around to approve and it’s an emergency but doesn’t warrant break-glass
- My employer doesn’t trust that I’ll do the right thing
Ultimately, unless there are compliance requirements in play, most organizations make internal decisions regarding approval for privileged roles. The risk trade-off usually is not wholeheartedly analyzed, but in selecting a priority, it would be more critical for organizations to reduce the number of Global Admins before implementing approval.
2.16 Highly Privileged Role Assignment and Activation SHALL Be Monitored
Since many cyber attacks leverage privileged access, it is imperative to closely monitor the assignment and activation of the highest privileged roles for signs of compromise. Create alerts to trigger when a highly privileged role is assigned to a user and when a user activates a highly privileged role.
Note: Although Azure AD PIM is referenced in the implementation instructions, an equivalent third-party PAM service may be used instead.
2.16.1 Policy
- Eligible and Active highly privileged role assignments SHALL trigger an alert.
- Refer to the baseline statement Highly Privileged User Accounts SHALL be Cloud-Only for a recommended minimum list of Azure AD built-in roles that are considered highly privileged. It is also possible to designate additional built-in roles that are considered highly privileged in the agency’s environment based on its risk tolerance.
- User activation of the Global Administrator role SHALL trigger an alert.
- User activation of other highly privileged roles SHOULD trigger an alert.
- Note: Alerts can be configured for user activation of other highly privileged roles as well but note that if users activate these other roles frequently, it can prompt a significant number of alerts. Therefore, for those other roles, it might be prudent to set up a separate monitoring mailbox from the one configured for the alerts associated with the Global Administrator role. This separate mailbox would be designed to store alerts for “review as necessary” purposes versus the mailbox configured for the Global Administrator role, which should be monitored closely since that role is sensitive.
2.16 Analysis | Agree
It’s hard to argue against this recommendation. While the email alerts are what CISA highlights here, organizations may find it beneficial to send alerts such as this to their SIEM, not necessarily as an incident or an alert to be acted upon, but to bring that data into a centralized location. That being said, similar to alerts for Azure AD Identity Protection, a layered approach would also send email from within PIM itself.
2.17 Managed Devices SHOULD Be Required for Authentication
Require that users connect to M365 from a device that is managed using conditional access. Agencies that are implementing a hybrid Azure AD environment will likely use the conditional access control option named Hybrid Azure AD joined, whereas agencies that are using devices that connect directly to the cloud and do not join an on-premises AD will use the conditional access control option named, Require device to be marked as compliant.
Guest user access note: This conditional access policy will impact guest access to the tenant because guest users will be required to authenticate from a managed device similar to regular Azure AD users. For guest users, the organization that manages their home tenant is responsible for managing their devices and the resource tenant must be configured to trust the device claims from the home tenant, otherwise guest users will be blocked by the policy. This link describes the detailed authentication flow for guest users and how conditional access related to devices is applied. The implementation section describes the cross-tenant settings that must be configured in both the home and the resource tenants to facilitate guest access with managed devices.
2.17.1 Policy
- Managed devices SHOULD be required for authentication.
2.17 Analysis | Agree | May Not Align To All Organizations
Perhaps somewhere in the depths of some government documents it’s indicated what the difference between SHALL and SHOULD are, but my perception is that SHOULD holds a somewhat lower bar of requirement than SHALL.
The recommendation for managed devices required is solid, but it’s a wide target that varies greatly based on user personas and the type of organization. Back to the higher education example, it’s unlikely to have students Azure AD Join their devices, and for many universities it’s not wanted.
Organizations should strive to AADJ or HAADJ devices to be able to obtain compliance, and whether using Intune or a supported 3rd party MDM, ensure that compliance is a factor as great as possible in building a strong model for authentication. MAM is a suitable alternative to MDM management for mobile devices, and organizations should ensure that they work with their users instead of against them, even if it means a combination of various means of MDM and MAM, a combination of AADJ and HAADJ.
2.18 Guest User Access SHOULD Be Restricted
Ensure that only users with specific privileges can invite guest users to the tenant and that invites can only be sent to specific external domains. Also ensure that guest users have limited access to Azure AD directory objects.
2.18.1 Policy
- Only users with the Guest Inviter role SHOULD be able to invite guest users.
- Guest invites SHOULD only be allowed to specific external domains that have been authorized by the agency for legitimate business purposes.
- Guest users SHOULD have limited access to Azure AD directory objects.
2.18 Analysis | Agree | May Not Align To All Organizations
Guest user access is yet another place that varies greatly depending on the users and the organization. Overly restrictive guest access can at times create scenarios where user will attempt to share data out-of-band to get around restrictions.
It is up to most organizations to determine their guest stance. If your organization heavily works with several clients who may or may be greatly varied, such as a consulting firm, you may find that guest access has to be left pretty open. If it’s a regulated industry organization, you’ll tend to find buttoning up of guest access happening more.
With the recent GA of cross-tenant access settings, luckily Microsoft has made it quite easy to configure guest restrictions across tenants.
End of the day, organizations have to determine where they want to sit on the usability vs security spectrum when it comes to guest accounts, and it’s very much not a one-size-fits-all process to implement.
Additional Thoughts
What Works
I love seeing a policy like this come from a federal agency, as it helps reinforce recommendations from Microsoft as well as what is seen in the field, in many of these scenarios. While not directly tied to NIST recommendations, it’s somewhat of an affirmation from the government as far as what would likely fit into other guidelines – many times organizations find it difficult to translate guidelines into technical settings for something like Azure AD.
As it is a Creative Commons Zero license, there is the ability to clone the repo and alter things – I’ve started to examine the templates used for generating the baseline analysis, and I’m curious as to how flexible it is.
What Needs Improvement
CISA acknowledges that there is other work still going on to cover hybrid identity, which is mostly missing within the recommendations.
A few of the recommendations have what I would consider small technical gaps as noted.
There are also some gaps from an architecture perspective that are not covered at all, such as recommendations on PIM lifetime – Microsoft recommendation is to turn down the activation duration on Global Administrators to one hour. Likewise, the lack of break-glass accounts within the recommendation leaves one curious as to what the stance is there. If the recommendation is to have no break-glass accounts, the process to recover access to a tenant can be a very drawn out one.
It would be great to see the tool eventually analyze Enterprise Application permissions, but as the recommendations are very binary, it likely would be difficult to create any baseline policy as to what is or is not permissible with how varied application requirements can be.
The lack of user personas, while perhaps satisfactory for implementation within the Federal Government and to align with NIST, does not translate well to most businesses outside of that realm. And this is what creates the biggest deficiency in being able to leverage this tool for purposes externally. End of the day these recommendations all lean heavily towards security over usability. Recommendations such as 2.9 and 2.10 will cause the greatest detriment to the user experience.
Final Take
It’s great to see the government putting out these sorts of actionable standards for agencies, even if it’s also making the government a shill for M365 E5 or AAD P2 licensing. I’m curious to see how these baselines evolve, as it’s only in Version 0.1 Draft at the time of writing this.
About this posts featured image
The chosen photo is the work of Paxton Tomko, used under the Unsplash license.
