Feeding Certificate Authority with Data

For Conditional Access to do its job and ensure flexibility in rule creation, you need to provide the PDP with at least the data that you also want to use in the rules. Herein lies the strength of zero trust: Interfaces that incorporate other data, insights, and information for evaluation establish the necessary trust.

User identities, group and role assignments, and devices from AD will give you a good start, and you will easily see which of these are as hybrid Azure AD-joined devices. If you want to connect smartphones or devices without a domain affiliation, you will need to integrate and manage them with Microsoft Intune. After doing so, you can identify devices running macOS, Android, and iOS and have the compliance status shared between Intune and Conditional Access, allowing Conditional Access to apply a Require device to be marked as compliant tag.

If trusted work locations exist that can be defined by IP subnets or GPS locations, you can store these locations as a trusted location in Conditional Access, which then allows Conditional Access to apply various rules on the basis of the IP address and, for example, waive the need for MFA or device status checks. To handle temporary exceptions, an IP check is useful, but in terms of the zero-trust concept, IP subnets are too easily manipulated to be checked securely.

For secure administration, you can also have Conditional Access enforced for admin workstations; then, Conditional Access not only checks whether an admin is working on a known and permitted device, but if this is also the specified device. This check is known as a device filter and lets you tag a device as a secure admin workstation or a privileged admin workstation. Admins then need to pass a check (e.g., user has an Exchange Service Administrator admin role, is working on a trusted and compliant device, and the device is tagged as a privileged access workstation, or PAW) before they can, say, access Exchange [2].

The more data you provide to your PDP as input and to the PEP for risk mitigation, the more powerful the toolbox you have for verifying trust or establishing it through restrictions or reviews, as appropriate. To mitigate risk for scenarios in the Microsoft cloud, the most important thing is that you deploy MFA and have a strong credential strategy in place, accompanied by self-service password resets in the event of account theft. If you're deeper into the Microsoft cloud, limited sessions and cloud access broker reviews offer another good tool.

Faster Detection of Breaches of Trust

A new concept, already in use in some Microsoft applications, supports even faster responses to breaches of trust. Services can gain deeper integration with Azure AD and Conditional Access insights. With the help of an event subscription, applications learn that a user has been locked out, is at risk, or is working from a different location. The application can then invalidate the access token immediately after the event arrives and send the user back to Azure AD to request a new token.

This process reduces the time between two Conditional Access checks during token issuing, during which the token is valid and no zero-trust check can take place. Microsoft calls this continuous access evaluation [3], and the technology is already integrated into Exchange, Teams, and SharePoint and will be offered to other manufacturers as standard in the medium term.

Conclusions

Zero trust starts with a new mindset, grows as you create a database for trust decisions, and thrives on a combination of decision and enforcement points. In the Microsoft universe, Azure AD with Conditional Access occupies this place, and it makes use of other components, such as device management, risk assessment, or user roles.

The system has long since outgrown the MFA enforcer stage and implements complex rulesets that not only enable zero trust, but also ensures flexible use of critical data, services, and applications that go beyond Office 365.