Conditional access guidance

The following guidance is based on various sources including Microsoft documentation and attempts to provide the information in a condensed form. The Conditional Access as Code policy sets try to follow this guidance as far as possible and provide an extremely fast and practical implementation of the guidance.

The guidance is intended for all conditional access implementations, not only for the solution offered by this repository.

The guidance is divided into different levels, as conditional access implementations are very individual, this individuality is primarily reflected in the third level which deals with decision details. Any conditional access implementation should be able to be reviewed very quickly through guidance levels one and two.

It is crucial NOT to get distracted by the many details of the third level and lose focus. Initially the focus should always be on disabling legacy authentication and establishing strong authentication, especially for privileged access.

Level 1

1. Follow zero trust principals
2. Plan for disruption
3. Build a governance model
4. Establish quality assurance processes
5. Structure policies on the basis of a framework

Level 2

1. Ensure you protect every user and app
2. Block legacy authentication
3. Require strong authentication (This does not have to mean always requesting MFA)
4. Require trusted devices (This does not have to mean always requesting a trusted device)
5. Respond to potentially compromised accounts
6. Respond to suspicious sign-ins
7. Limit your strong credential registration
8. Protect privileged users in all M365 RBAC systems
9. Protect privileged systems (e.g. Azure Management, AWS, GCP, ...)
10. Your policies are a piece of the puzzle for your data loss prevention concept
11. The framework you choose to structure your policies should balance between the least amount of policies and an efficient way to get policies enabled.
12. Ensure polices get enabled by utilizing report-only mode and if needed the ring framework described below
13. Minimize the use of policies blocking access, think of this as "secure by default" not "block by default"
14. Establish a naming convention for your policies
15. Utilize and protect groups for exclusions
16. Conditional access is a crucial part of your security posture, hence it should be integrated in your security operation processes

Level 3

1. Depending on your Identity Proofing process decide how you can limit your strong auth credential registration. You have the following options that you could also combine:
   1. Require a trusted device
   2. Require a trusted location
   3. Require strong auth (This will require prestaging MFA information)
2. Depending on your risk tolerance, decide whether you want to request a secure password change for low/medium/high user risk. Prior to blocking on user risk, strongly consider reacting to low user risk instead to avoid dead ends for your users. The policy framework described below can enable you to perform different risk decisions for specific personas and categories.
3. Depending on your risk tolerance, decide whether you want to require MFA for low/medium/high risk sign-ins. Prior to blocking on sign-in risk, strongly consider reacting to low sign-in risk instead to avoid dead ends for your users. The policy framework described below can enable you to perform different risk decisions for specific personas and categories.
4. Always requiring MFA will increase MFA fatigue, the above mentioned risk based protection is very good and better than causing MFA fatigue. However, if your users are mostly accessing apps from devices with strong authentication (WHFB or FIDO2) you can consider a "always MFA" policy because the strong device based SSO will prevent the MFA fatigue.
5. Depending on your device journey maturity you can require compliant devices (Intune compliance) or hybrid joined devices (trust in on-prem config) Establishing device trust in most cases is preferred, however you may have some use-cases on untrusted devices that can but must not have session or app protection controls.
6. Decide how you can protect privileged users, access and systems, at a minimum you should require MFA but additional protection with privileged access devices is recommended. Limitation to a trusted location shall be considered.
7. The framework you choose to structure your policies can include the following elements, depending your organizational complexity only a subset of these may be required:
   1. Personas (e.g. Internals (Employees), Externals (with Corp identity), Guests, Admins, External Admins (with Corp identity), Guest Admins, Service Accounts, General or catch the rest)
   2. Categories (e.g. Base protection, Attack surface reduction, Data protection and application protection that may be sub-categorised in sensitivity, Compliance, Admin protection)
   3. Rings (e.g. Pilot group 1, Pilot group 2, ...)
8. Your naming convention should fit to the framework you choose to structure your policies. The most complex could look like this: (Unique Number) - (Persona) - (Category) - (Ring) - (Cloud apps or actions): (Control) For (Users and groups) When (Condition)
9. A policy targeted to a large amount of users can create false impression of security if a large amount of users is excluded. You should establish an attestation process on your exclusion groups. You can consider using temporary (e.g. user with issue) and permanent (e.g. service account) exclusion groups for every policy
10. Target and exclusion groups can be abused to "deactivate" conditional access policies, hence you should understand who can update the membership of these groups. Consider protecting them with the assignableToRoles flag, not assigning roles that can update memberships of normal groups on the tenant level can also help.
11. Ensure your emergency access accounts are excluded from all policies
12. Ensure the Azure AD Connect service accounts are excluded from policies that would prevent it from synchronization
13. You should integrate alerts for the following events in your security operation processes:
    1. Creation
    2. Deletion
    3. State change (Deactivated, Report-only, Activated)
    4. Significant member changes to your target and exclusion groups
    5. Deletion of target or exclusion groups
14. Consider splitting your policy to block legacy authentication in "Other clients" and "Exchange ActiveSync clients", it will potentially allow you to already block one of the two while working on the other. Additionally you can consider limiting legacy authentication to a trusted location.
15. Conditional access offers different controls that can be utilized to prevent data loss. Based on your risk tolerance there are different approaches to DLP with Conditional Access, however you do not have to decide exclusively on one of the following approaches, you can utilize the framework described above to differentiate for personas and categories or even risk for more granular decisions:
    1. Disallowing access from untrusted devices (Trusted device only)
    2. Limiting access from untrusted devices with session controls, app enforced restrictions and app protection policies
    3. Allowing access from untrusted devices without additional controls
    4. Relying on the protection applied to the data
16. DLP controls often introduce granular controls based on device platform, you should ensure you have policies in place for all device platforms include the ones you cannot target with Conditional Access (e.g. Linux)

Controversial / Topics to be discussed

1. Inclusion of the Enterprise Access Model of the Priv Access Guidance, seems like a "side mention" in the framework section would not be enough?
2. More details on "Plan for disruption"
3. Usage of "All cloud apps" vs. targeting all cloud apps by explicitly selecting them
4. Block sign-in from which you never expect a sign-in
5. Prevent persistent browser sessions on untrusted devices
6. Apply a short sign-in frequency on untrusted devices
7. Block of company "disallowed apps"