In my last blogpost I told you about my approach and experiences at designing CA rule sets. While this blogpost was focussed on the basic features I now want to cover the more advanced features. This first blog is about Risk Based Conditional Access and I hope that Session Controls will follow soon.
Risk based Conditional Access
Using risk scores is an important step to adopt Zero Trust Security. In connection with CA, three risk types are relevant:
- User risk – A user risk represents the probability that a given identity or account is compromised.
- Sign-in risk – A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner.
- Machine risk or Device Threat Level – A machine risk represents probability that a given device is compromised.
These metrics have different sources and options for action, but they can all – depending on your environment – become part of your rule set for identity-based protection of your environment.
In addition to determining the risk level and the option to configure policies, IPC provides alerts on the Intelligent Security Graph (ISG), which then e.g. can be processed in MCAS, MTP or Sentinel. If you want to learn something about these alerts, I recommend these posts on Sam’s Corner and SecureCloudBlog
Using User risk!
According to the documentation the user risk is calculated offline using Microsofts threat intelligence sources. At the moment of writing user risk can’t be used in the Conditional Access section of the portal. You have to use the Identity Protection section. But although there is no direct reference here in the portal, the documentation speaks of CA policies.
Integrating user risk in your rule set is relative straight forward. Just follow Microsofts guidance and configure a policy that enforces a password change for high-risk users.
To selfremediate the users have to register SSPR and MFA upfront. You can enforce this with the MFA registration policy in the Identity Protection or as a registration policy at SSPR (in combination with Combined security information).
Using Sign-in risk!
For sign-in risk some realtime detections are added to the offline calculations using Microsofts threat intelligence sources. It can be configured at Identity Protection or in CA Policies and it depends strongly on the complexity of your requirements and designed rule set.
My favorite approach is to use the sign-in risk in Conditional Access because it is more powerful and flexible. The app profile approach I described in the last blog post can be added in the following ways, for example:
- Additional MFA for Light or Medium Restricted Apps at Medium Risk or above.
- Block Access to Heavy Restricted Apps at Medium Risk or above
Using machine risk!
The machine risk can be used in Intune Device Compliance policies and thus in Conditional Access. For Windows 10 this metric can be set by Microsoft Defender Advanced Threat Protection, for Mobile Devices the metric can be set using the Mobile Threat Defense Connector by a list of partners.
The definition of the risk level varies a little in the wording depending on the platform (Mobile and Win10), but can be used consistently.
| Risk Levels Win 10 | Threat Level Mobile Devices | Risk Levels Win 10 Description (the description for mobile devices deviates only minimally) |
| Clear | Secured | This option is the most secure, as the device can’t have any threats. If the device is detected as having any level of threats, it’s evaluated as non-compliant. |
| Low | Low | The device is evaluated as compliant if only low-level threats are present. Anything higher puts the device in a non-compliant status. |
| Medium | Medium | The device is evaluated as compliant if existing threats on the device are low or medium level. If the device is detected to have high-level threats, it’s determined to be non-compliant. |
| High | High | This option is the least secure, and allows all threat levels. It may be useful if you’re using this solution only for reporting purposes. |
In my experience, the response time from downloading an EICAR to a BLOCK by CA is relatively short but of course far away from real time. I think the delay is mainly due to the lifetime of the access token, but should be less than one hour. There is a nice explanation on the SecureCloudBlog.
In my example rule set from the last blog about CA, I could expand the device compliance to no longer allow systems from a defined risk level on to the resources. If you decide to include the risk level in the compliance status, you can greatly increase the security for your environment, but you must be prepared to support the users quickly and always to reduce the risk level again or to have acceptance that the users are cut off. In addition, CA does not replace response actions on a machine in MDATP, for example to isolate machines from the network.
In my opinion the integration of machine risk into device compliance is a bit unfortunate and is often not usable in conditional access, since there is only a cumulative device compliance and cannot be differentiated. If I decide to use the Machine Risk in a compliance policy for a user / device, this applies to all CA policies that use the compliance status.
My first attempts to integrate Device Risk into rule sets were these:
- additional MFA as in the use of Session Risk
- different risk levels as conditions for different apps (or categories)
Unfortunately, both approaches can only be used if device compliance is not used elsewhere. To use the device risk in a truly effective and granular way, direct integration is required. (I asked for it via Uservoice)
Instead of scoping in CA my advice for the integration of machine risk is to scope the Intune device compliance policies on the base of user or devices. Note that you can use more than one policy per device and therefore you can e.g. add an additional policy for admin accounts that includes the risk level. So compliant does not mean the same for all users.
Risk and Guest user
If you’re using risk policies you should take care of your guests! Make yourself familiar with this DOCS article about possible problems.
My summary of the problem:
- The user and sign-in risk level is managed in the source tenant and can’t be remediated in your tenant.
- The machine risk is handled via device compliance and does not work cross-tenant.
To deal with the problem, my recommendation is to exclude the guest users from the „normal“ rule set and to create a separate rule set for guests. With CA policies, this can be done directly via the account type. When configuring the user risk in the Identity Protection Portal, this can be done via a dynamic group. This can then also be used sensibly in other places, e.g. at the Access Reviews.