Conditional Access 2: Electric Boogaloo

Now that we’ve covered the baseline essentials, it’s time to focus our Conditional Access policy deployment a bit more.

As I mentioned in the essentials post, these Conditional Access policies are based on Zero Trust principles—Assume Breach, Verify Explicitly, and Use Least-Privilege Access. All while utilizing the framework of the Enterprise Access Model.

In ye olden days, when on-premises AD DS forests were all the rage, we used the Tiering model to harden AD security.

In my opinion, on-premises AD is now a significant security risk and should have been left behind ages ago. However, I realize that’s not always realistic. If you’re still dealing with a legacy AD DS environment, it’s best to stick with the tiering model for those on-prem needs.

But in the cloud world, we’ve moved on to modern models, specifically the Enterprise Access Model. I’ll dive into this model in a future post, but for now, know that the grouping and division of policies are based on it.

Here’s the diagram Microsoft created for the model:

Used with permission from Microsoft. Source: Microsoft Learn: Enterprise Access Model

Table of content:

1. Conditional Access: Privileged Access - The why

   1. Numbers for the C-Suite

2. Conditional Access: Privileged Access - The how

3. Entra Privileged Access – Conditional Access Policies

4. Closing Time: Access Granted!

---

Conditional Access: Privileged Access - The why

Our privileged access identities—whether they’re users like IT admins, devices like Privileged Access Workstations (PAWs), or intermediaries—are the most critical identities for Conditional Access Policies (CAPs). They hold the “keys to the castle.” and as a Security Consultant, I can confidently say that these keys are often not as well-divided as they should be!

Numbers for the C-Suite

But… why is it so important to spread privileged access and not just let all IT admins (or worse, regular Joes) have Global Administrator, Azure RBAC Owner, or Enterprise Admin on permanently?

Let’s break it down with some stats:

• Compromised privileged identities accounted for 33% of security incidents in 2024, up from 28% in 2023.

• According to the Cloud Security Alliance, the #2 threat to Cloud Computing is Identity & Access Management.

• Approximately 93% of ransomware incidents were directly linked to insufficient privilege access and lateral movement controls.

• The Ponemon Institute reported that 55% of data breaches involving insiders were due to accidental behaviors, showing how even well-intentioned privileged users can cause major security incidents. These incidents had an average remediation cost of $7.2 million.

These numbers are forcing companies to reevaluate their IT landscape risks:

A survey found that over 55% of companies consider privileged users to be at the top of their insider threat risk list. The number of insider attacks has risen by 47% over the past two years, highlighting the need for organizations to manage and monitor privileged access effectively (Source: Insider Threats in 2024: 30 Eye-opening Statistics).

---

Conditional Access: Privileged Access - The how

Now that we’ve got the why, let’s dive straight into the how!

I’ll go through each CAP, explaining why it’s recommended, providing a link to the policy in JSON format, and outlining which Mitre ATT&CK technique it addresses.

Note: I’m recommending policies that require Microsoft Entra P2 licenses. These policies are highly recommended, and you should at least get P2 licenses for your admins—not just for the CAP features, but for overall security.

Picking up from where we left off in the essentials post…

For a subset of the following CAPs, there's configurations needed outside of Conditional Access.

• For the PIM policies (CA605 & CA701), you'd need to change the role settings in PIM to require Authentication Context, and point to the context that's used by the policies. - These policies can be further extended to Protected Actions by assigning the Authentication Context to the desired Protected Actions: Microsoft Learn: Add protected actions

• For the TOU policy (CA704), you'd need to create a Terms of Use and upload it to Microsoft Entra, as described here: Microsoft Learn: Create your Terms of Use

Short reminder of the naming scheme:

<CANumber>-<GrantControl>-<PolicyType>-<Persona>-<App>-<Platform>-<OptionalDescription>

---

Entra Privileged Access – Conditional Access Policies

CAP 12:

CA100-Block-AttackSurfaceReduction-Admins-O365-AnyPlatform-Block access to Office 365 v1.0

JSON | MITRE ATT&CK Technique ID: T1098

Blocking admin access to Office 365 decreases the risk of privileged access accounts being used in day-to-day actions, and therefore the possibility of phishing or otherwise manipulation, which can lead to malicious actions such as data exfiltration.

CAP 13:

CA101-Block-AttackSurfaceReduction-Admins-iOS&Android-AllApps-Block iOS & Android access v1.0

JSON | MITRE ATT&CK Technique ID: T1098

Restricting mobile device access to Admin accounts further mitigates the risks of account manipulation or unauthorized access by decreasing the day-to-day usage of the account.

CAP 14:

CA200-Block-AttackSurfaceReduction-GuestAdmins-O365-AnyPlatform-Block access to Office 365 v1.0

JSON | MITRE ATT&CK Technique ID: T1098

Preventing Guest Admin access to Office 365 minimizes the risk of attackers leveraging guest accounts for account manipulation, reducing the attack surface for critical corporate applications, and securing corporate data.

CAP 15:

CA601-MFA&PWDreset-IdentityProtection-Admins-AnyPlatform-AllApps-Require MFA & Password reset for Medium & High user-risk v1.0

JSON | MITRE ATT&CK Technique ID: T1110

Requiring MFA and password reset for Admins flagged with medium or high user risk helps mitigate brute force attacks, and enforcing account recovery.

CAP 16:

CA602-MFA-IdentityProtection-Admins-AnyPlatform-AllApps-Require MFA for Medium & High risk Sign-in v1.0

JSON | MITRE ATT&CK Technique ID: T1110

Requiring MFA for risky sign-ins helps prevent account takeover attempts, ensuring Admin accounts are only accessed by legitimate users.

CAP 17:

CA603-SessionControl-DataProtection-Admins-AnyPlatform-AllApps-Non-persistent browser session & 4h frequency v1.0

JSON | MITRE ATT&CK Technique ID: T1185

Non-persistent browser sessions and frequent re-authentication reduce the risk of attackers intercepting or hijacking active sessions, mitigating the impact of AiTM (Adversary-in-The-Middle) attacks on Admin accounts.

CAP 18:

CA604-Compliance&AuthStr-DataProtection-Admins-AdminPortals-Windows&MacOS-Require Compliant device & Phishing-resistant Auth for Admin Portals v1.0

JSON | MITRE ATT&CK Technique ID: T1651

Ensuring Admin access only through compliant devices and phishing-resistant authentication protects Admin portals from unauthorized access, reducing the risk of compromise.

Note: This should only be used if you utilize PAWs for your admins, as it WILL block sign-in unless the user is primary on the device

CAP 19:

CA605-MFA-IdentityProtection-Admins-PIM-AnyPlatform-Require MFA for PIM elevation v1.0

JSON | MITRE ATT&CK Technique ID: T1548.005

Requiring MFA for Privileged Identity Management (PIM) elevation ensures that only verified Admins can escalate their privileges, reducing the risk of attackers gaining unauthorized elevated access.

Note: This policy is applied to an Authentication Context, which can be used at multiple places in your environment, and will enforce the same grant control for all.

CAP 20:

CA701-MFA-IdentityProtection-GuestAdmins-PIMelevation-AnyPlatform-Require MFA for PIM elevation v1.0

JSON | MITRE ATT&CK Technique ID: T1548.005

This policy mandates MFA for Guest Admins attempting to use PIM to elevate privileges, protecting against unauthorized elevation and securing privileged guest access.

Note: This policy is applied to an Authentication Context, which can be used at multiple places in your environment, and will enforce the same grant control for all.

CAP 21:

CA702-MFA&PWDreset-IdentityProtection-GuestAdmins-AllApps-AnyPlatform-Require MFA & Password Reset for Medium & High user-risk Guest admins v1.0

JSON | MITRE ATT&CK Technique ID: T1110

Enforcing MFA and password resets for Guest Admins with a medium or high user risk, mitigates brute force attacks, and compromise via trusted partners.

Note: This will directly block a guest user, as it'll require a password change in the guest users home tenant. To remediate, they should reset password in their home tenant.

CAP 22:

CA703-MFA-IdentityProtection-GuestAdmins-AllApps-AnyPlatform-Require MFA for Low+ sign-in risk for guest admins v1.0

JSON | MITRE ATT&CK Technique ID: T1110

MFA is required for all sign-ins identified with low or higher risk, adding a consistent security layer for guest admins and mitigating brute force attack vectors.

CAP 23:

CA704-TOU-ComplianceProtection-GuestAdmins-CombinedRegistration-AnyPlatform-Require TOU for security info for Guest Admins v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Requiring Terms of Use (TOU) acceptance for updating security information ensures compliance with the corporate policies, while raising the guest users awareness for the security obligations that's placed upon them, reducing the likelihood of malicious account changes or creation.

CAP 24:

CA705-SessionControl-DataProtection-GuestAdmins-AnyPlatform-AllApps-Non-persistent browser session & 1h frequency v1.0

JSON | MITRE ATT&CK Technique ID: T1185

Restricting browser session persistence and requiring re-authentication every hour reduces the window for potential AiTM attacks, such as session hijacking, or extended access by unmanaged devices.

CAP 25:

CA900-AuthStr-IdentityProtection-Breakglass-AllApps-AnyPlatform-Require Phishing-resistant Authentication for BreakGlass Accounts v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Requiring phishing-resistant authentication for BreakGlass accounts, helps prevent unauthorized use of these high-privilege accounts, ensuring secure fallback access.

This should be enforced by configuring FIDO security Keys which would then be stored safely in case of an emergency.

Note: This will fulfill the requirements for access to the admin portals for Breakglass accounts in regards to the MFA requirement for all users as publicised by Microsoft May 14 2024: Microsoft will require MFA for all Azure Users

---

Closing Time: Access Granted!

And that’s a wrap for this part of the series on Conditional Access—focusing on privileged access!

We’ve journeyed through the why it’s essential to secure these critical identities, backed by hard-hitting statistics, and covered the how with recommended Conditional Access Policies that bolster your defenses.

Remember, security is a marathon, not a sprint. Implementing these Conditional Access Policies is just one piece of the puzzle. It’s about building a resilient security posture that can adapt to evolving threats.

In the upcoming post, we’ll tackle Workloads & Service Accounts—Stay tuned as we dive even deeper into how to strengthen your security posture with modern, cloud-based tools.

And now, to lighten the mood, here’s another bad joke to seal the deal:

Why did the security consultant bring a ladder to work?

Because they wanted to take their access control to the next level! 😎

Don’t forget to bookmark my blog Cloudy With a Chance of Security, share this post with your colleagues, and keep checking back for the next post.

Let’s keep taking those access controls to the next level, together!