Every spring, as the flowers begin to bloom and the days grow longer, a new group of interns joins our office. And each year, without fail, I assign them a seemingly straightforward subproject: to develop a Conditional Access baseline.
You might think that after all these years, I’d have heard it all, but no—these bright young minds always manage to surprise me with fresh twists on what many might consider a dull subject. It’s like asking someone to reinvent the wheel and then watching them transform it into a hoverboard.
However, this summer, I decided to take on the challenge myself, starting from scratch with a new baseline, hence this post.
Key principles
Now, let’s get down to business. The term ‘baseline’ might evoke the image of a starting point, and that’s precisely what it is—a foundation upon which we can build a more secure environment. But don’t be misled, even though it’s a ‘baseline,’ it’s far from basic. Here are some of the key principles that should be included in a robust Conditional Access baseline:
- Mandatory Multi-Factor Authentication (MFA) for All Users: This is the cornerstone of any good security policy. Like the reliable lock on your front door, MFA adds that extra layer of security, ensuring that even if credentials are compromised, there remains a formidable barrier in place.
- Enhanced MFA for Administrative Roles: Admin accounts are akin to the keys to the kingdom; they should not only be protected with MFA but also with additional settings that provide tighter control and monitoring. Think of it as having a security camera on top of that reliable lock.
- Blocking Legacy Authentication: In the world of security, old is rarely gold. Legacy authentication protocols often don’t support modern security practices, making them the weak link in the chain. Blocking these is like upgrading from a wooden club to a smart lock.
- Managing Safe Locations and Risky Users: Not all users and locations are created equal. Some might be as secure as a bank vault, while others are as risky as a cardboard box in the rain. Identifying and handling these appropriately ensures that trust is given where it’s earned and withheld where it’s dubious.
“there’s no such thing as a ‘perfect’ baseline”
Now these are just key principles. Following this, we will discuss the draft baseline that I made. Remember, there’s no such thing as a ‘perfect’ baseline. It’s a living, breathing set of guidelines that should evolve as new threats emerge and old ones fade away. It’s about finding the right balance between security and usability, ensuring that while the doors are locked, they can still be opened by the right people.
My Conditional Access Baseline: A Strategic Approach
In the next section, I’ll walk you through my own draft for a Conditional Access baseline. This draft outlines key principles and strategies that have proven effective in creating a strong security posture. Here are the core components that should be included in any robust Conditional Access baseline.
For a detailed overview, download the CA baseline XLSX file.
- 01-MFA-RequireMFA-AllUsers
We force MFA for all users, exclude CaExclusionGroup (almost on every CA) & Compliant network locations - 02-MFA-RequireMFA-PrivilegedPersistence
All privileged accounts must use multi-factor authentication (MFA) with restrictions on session persistence and have resilience defaults disabled. - 03-MFA-RequireMFA-ExternalUsers
We block guest access using this Conditional Access (CA) policy, except for the Office 365 application. With the previous CA policy, we enforce Multi-Factor Authentication (MFA). - 04-MFA-ServicesAccounts-TrustedLocations
We block access for service accounts except for selected trusted locations. This policy ensures that service accounts are protected and only accessible from secure, trusted locations. - 05-BLOCK-LegacyAuth-AllUsers
Legacy authentication is blocked for all users to prevent the use of outdated protocols that don’t support modern security measures. The CaExclusionGroup is excluded from this policy. - 06-BLOCK-RiskyLocations-AllUsers
Access is blocked from risky locations for all users, excluding CaExclusionGroup and CaUserVacationGroup. This helps mitigate potential threats from high-risk regions. We need to specify which locations (countries) are risky, but let’s not dive into that political minefield here! 😉 - 07-BLOCK-HighRiskUsers
High-risk users are blocked from accessing any cloud apps to prevent security breaches. This policy applies to all users except those in the CaExclusionGroup. - 08-BLOCK-SuspiciousBrowserSessions
Suspicious browser sessions are blocked, especially when a high sign-in risk is detected. This policy applies to all users, with CaExclusionGroup excluded. - 09-BLOCK-NonCompliantDevices
Non-compliant devices are blocked from accessing all cloud apps to ensure that only devices meeting security standards can access corporate resources. The policy excludes CaExclusionGroup and CaAllowedOutsideLogin. - 10-BLOCK-RequireMFA-RegisterSecurityInfo
We block access except from trusted locations if users haven’t completed their MFA registration. This is crucial because if a hacker knows the password, they could register their own MFA device and gain full access to the account. And we definitely don’t want that, do we? - 11-DEVICE-Registration
All users are required to use MFA when registering or joining a device. It is also possible to change this to BLOCK instead of Grant, to ensure devices can only be registered from allowed locations. - 12-APP-MobileDeviceAccess-CompliantDevice
We allow access to mobile devices (only iOS and Android) for all apps, except Intune. This policy ensures that mobile devices adhere to company security standards. It applies to mobile apps and desktop clients, and requires the use of approved client apps. The CaExclusionGroup is excluded, and Microsoft Intune is used for compliance checks. - 13-SESSION-RequireTermsofUse-SensitiveApps
All users must accept the Terms of Use before accessing sensitive apps like SharePoint Online and Teams. This policy ensures that users are aware of and agree to the company’s terms before accessing critical resources. YBefore using this setting, make sure to establish a Terms of Use in Entra. - 14-SESSION-BlockFileDownloads-UnmanagedDevices
File downloads from Office 365 SharePoint Online are blocked on unmanaged devices to protect company data from being accessed or saved on non-compliant devices. The CaExclusionGroup is excluded from this policy.
Conclusion
Creating a conditional access baseline is a critical step in securing your digital environment. By following the principles outlined in this draft, you can build a robust security framework that protects your assets while maintaining usability.
P.S. Don’t forget to publish new CA policies as report-only for the first week and monitor the logs to ensure you don’t create unwanted effects in your environment.