Admins can leverage Microsoft’s Conditional Access Policies to prevent unauthorized Azure logins, even in the face of stolen credentials.
The increasing prevalence of cloud-based services has expanded the scope of potential cyber threats, granting access to previously restricted intranet resources to anyone with an internet connection worldwide. Microsoft stands out among the most commonly utilized productivity software providers, making them a frequent target for phishing attacks and impersonation attempts. Regrettably, these phishing attacks often achieve a distressingly high success rate.
The security of cloud-based identities is becoming more susceptible to risks. To address this concern, Microsoft’s Conditional Access Policies (CAP) offer a valuable solution to safeguard your users and data, even in cases where their credentials have been compromised during an attack. In this blog, we will explore the various components of CAPs and guide you on implementing them effectively within your environment.
Let’s get started.
What are Conditional Access Policies?
Within the realm of Azure AD, each authentication event possesses distinct “signals” or indicators.
In the context of Azure AD, the term “signals” refers to the attributes associated with an authentication event. These attributes include the account utilized, the geolocation derived from the IP address, the device’s onboarding status, the requesting application, and more. These signals form the foundational elements used for enforcing decisions within Conditional Access Policies (CAP) and triggering alerts within Azure AD Identity Protection. It is essential to grasp the differentiation between alerting and prevention, and we will delve into this distinction for better comprehension.
The signals from the authentication event are used by Azure AD Identity Protection alerts, which then transform these into user risk or sign-in risk. To reach your portal as an alert, data must first pass via Microsoft’s threat detection system, which is described as “offline” for most detection types. Microsoft’s help files state that waiting this long is not uncommon. The turnaround time is closer to 5-10 minutes for “real-time” detection types.
Azure AD Identity Protection alerts, to put it another way, are notifications about past authentication occurrences in Azure AD. These warnings don’t prevent attackers from authenticating; it takes time to identify which ones are legitimate and which are false positives. Marking these notifications correctly gives Microsoft valuable input that may be used to improve their reliability in the future.
But what if you need to prevent the authentication from working in the first place?
Even if the user’s credentials have been hacked, CAPs may be made using the same underlying signals to prevent unauthorized authentication.
How do Conditional Access Policies perform?
In order to function, CAPs must be configured, and their default setting is analogous to “allow any any” in a firewall; they thus rely only on the user mentioned above authentication signals. (Security Defaults may be activated for your tenant if it was formed after October 2019).
| Policy | Scenario | Expected Result |
| Risky Sign-Ins | User signs into App using an unapproved browser | Calculates a risk score based on the probability that the sign-in wasn’t performed by the user. Requires user to self-remediate using MFA |
| Device Management | Authorized user attempts to sign in from an authorized device | Access granted |
| Device Management | Authorized user attempts to sign in from an unauthorized device | Access blocked |
| Password Change for Risky users | Authorized user attempts to sign in with compromised credentials (high risk sign-in) | User is prompted to change password or access is blocked based on your policy |
CAPs have the ability to impose fine-grained controls. For instance:
- Preventing unauthorised access to SharePoint and OneDrive
- Using multi-factor authentication to protect admin accounts from phishing
- The user has to change the password at the next login.
In short, CAPs are a strong way to stop credential theft and deal with it when it does happen. The image from Microsoft does a good job of putting it all together:
Access to Azure AD apps and data may be granted, revoked, or subject to multi-factor authentication (MFA) based on a comparison to your custom risk profiles (CAPs).
How do I get started?
It might take some time to adapt Conditional Access Policies to your needs. Microsoft offers several great baselines to work from, while TECHOM Systems has offered its own set of minimally necessary specs. You may use these examples as templates for creating new policies for your firm. Before allowing Conditional Access to your surroundings, ensure they pass muster with the necessary “break glass” restrictions.
| Schedule a Meeting Today |
