Tip of the CAP: Getting started with Conditional Access Policies

The widespread adoption of cloud-based services has opened new attack surfaces, exposing things that used to be only accessible from the intranet to anyone in the world with an internet connection. Some of the most widely used productivity software is sold by Microsoft, which is why they are one of the most impersonated brands in phishing attacks. Too often, these phishing attacks are successful.

Cloud-based identities are increasingly vulnerable. Microsoft’s Conditional Access Policies (CAP) serve as a prevention tool that can help keep your users and data safe, even if their credentials have been compromised in an attack. In this article we’ll break down the components of CAPs and talk through how you can apply them to your environment.

Let’s get started.

What are Conditional Access Policies?

In the world of Azure AD, every authentication event has certain “signals.”

No, not those signals…

These signals are the attributes of the authentication event. They include things like the account used, geolocation of the IP address, onboarding status of the device, application that made the request, and more. These signals are the building blocks of CAP enforcement decisions and Azure AD Identity Protection alerts. The distinction between alerting and prevention can be tricky to understand, so let’s break it down.

Azure AD Identity Protection alerts rely on the same signals from the authentication event, and translate them into user risk or sign-in risk. For detection types that are listed by Microsoft as “offline” (the majority of them), the data has to make its way through Microsoft’s threat detection algorithm before showing up in your portal as an alert. According to Microsoft’s documentation, that can sometimes take as long as 48 hours. For “real-time” detection types, the turn around is closer to 5-10 minutes.

Putting it in different terms, Azure AD Identity Protection alerts are retroactive alerts for authentication events to Azure AD. These alerts do not block adversaries from successfully authenticating, and require investigation to determine if they are true and false positives. Marking these alerts accurately provides feedback to Microsoft and helps improve their fidelity over time.

But what if you want to block the authentication from ever succeeding in the first place?

Using those same underlying signals, CAPs can be created to prevent unauthorized authentication, even if the user’s credentials have been compromised.

How do Conditional Access Policies work?

CAPs require configuration and are set to the firewall equivalent of “allow any any” by default and operate directly upon those user authentication signals we mentioned previously. (If your tenant was created after October 2019, Security Defaults may be enabled.)

CAPs can apply restrictions on a granular basis. For example:

• Blocking access to SharePoint or OneDrive from unmanaged devices
• Forcing phish-resistant MFA on all administrator accounts
• Forcing a user to reset their password on next login

In short, CAPs are a powerful tool for prevention and response to credential theft. Microsoft’s graphic does a good job of summing it up:

Graphic courtesy of Microsoft documentation 

Your user and location, application, device, and real-time risk signals are matched against your CAPs in order to allow access, require MFA, or block access to specific Azure AD applications and data.

How do I get started?

Setting these up for your environment may take some time. Microsoft provides some great templates to get you started and Daniel Chronlund has put together his list of baseline recommendations. These templates can serve as starting points to work off of when building policies for your organization, and should be thoroughly reviewed with the appropriate “break glass” exclusions in place before deploying to your environment.