Terminal devices increasingly reside outside the corporate network and can be reasonably trusted on there to access applications and resources – if they use VPNs, multiple-factor authentication (MFA), and certificates. However, if the application, parts of the infrastructure, or the data itself are not on the internal network, a VPN is not a very elegant approach, to put it mildly.

The catch is that the VPN configuration is installed once only – presumably along with a certificate – on a user's smartphone or PC to provide the return channel to the corporate network. Does anyone actually check whether the certificate matches the device, if it has been sniffed, or even if the device is still in use by the user who originally commissioned it? The same applies to the intended use of VPN tunnels: Does the tunnel follow the intended route or does the process have anomalies?

Defining Trust

If all of your devices, users, apps, and resources operate in the cloud, anomalies are easier to detect, and checking for the normal state is simpler. A learning process that can reliably certify correct and trusted access or identify risks is thus possible. You need to be able to verify that certain conditions for access are met, depending on what object is to be accessed, before you can allow, say, a mailbox to be opened by an email client on a computer outside the corporate network. The mindset behind this is "zero trust," and it follows the approach of looking closely at a person's access context and making a decision according to the results of the check: The mailbox is then either opened or it remains locked.

Numerous aspects can be checked in the process: Whether the user is known and has completed MFA at login, whether the device is familiar or even considered "healthy," whether the user and device can be matched to a region that corresponds to the work location by IP or GPS data, whether the access times and work patterns across multiple applications match the employee's normal behavior, and whether the application accessing the data gives rise for concern.

If the logging and access controls on the internal network are based on the Kerberos protocol, it is difficult to implement zero trust with legacy techniques. Kerberos and NT LAN Manager (NTLM) do not have any mechanisms to evaluate the access context – just the device account, at best. The normal ticket lifetime is also several hours before any re-evaluation of the context is possible. Modern protocols are different. More can be done with tools like mobile device management (MDM), identity providers, and web protocols that interact with the user; more importantly, it can be done permanently because access tokens in the OAuth 2.0 standard are usually only valid for one hour, after which you need to obtain a new token, which involves an in-depth reappraisal of the access context. At the end of the day, it's all about minimizing risk and protecting your network against unauthorized access and data leakage while maintaining the productivity of mobile or hybrid workers.

Conditional Access Technology

In the Microsoft cloud, the zero-trust concept is built into many components. The control mechanism found at both the Policy Enforcement Point (PEP) and Policy Decision Point (PDP) in the zero-trust environment is Conditional Access, which is part of the token service that issues modern access tokens for Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0 applications integrated with Azure Active Directory (AD) [1]. Anyone who wants to access a resource like an Exchange mailbox that is integrated with Azure AD needs a token from the service, and the token is cross-checked by Conditional Access.

Before issuing access tokens for connected resources, an access context check is performed. Azure AD itself can look at the user's account, group memberships, and role assignments. With the help of the Identity Protection feature in Azure AD, advanced risk assessments are possible for the user account itself or the specific login process. For example, Azure AD blocks access from Tor browsers, users who request access tokens almost simultaneously from two distant locations on the basis of the IP address identifiers, or user accounts whose passwords are believed to be known on the dark web.

In addition to Identity Protection, Azure AD uses other data from surrounding systems (Figure 1). The compliance status of the device comes from Intune, which can certify the device as compliant with the enterprise configuration and health requirements. Windows AD can send information about devices with classic domain membership; the devices are at least "known" in this case, even if they have not been credibly checked for a compliant configuration. Up-to-date threat information for endpoints is added by Microsoft Defender for Endpoint.

Figure 1: A sample Conditional Access setting for a critical app, in which applications with sensitive data can only be used in the context of MFA on a trusted device.

Armed with these checks, administrators can formulate rules that describe access, such as:

• Employees can access their mailboxes with Outlook if they come from at least a known or managed and compliant device.
• Employees who belong to the "No Outlook" group can access their mailboxes from a browser if they come from a known or compliant device or have passed through MFA.

Where possible, modern protocols allow interaction between Conditional Access and the user, which means that Conditional Access is not restricted to simple issue or deny token decisions. If trusting the user's end device is inappropriate, the ruleset allows for alternatives. The user can be prompted to use MFA or dragged by a rule into Microsoft's cloud proxy, which blocks all downloads in the session and prevents data leakage. The employee can then access the data – after carrying out an MFA procedure – while IT ensures that no data is leaked to unknown devices. If some members of the workforce do not have compliant devices or are not allowed to use a company smartphone, enterprise IT simply applies the Conditional Access policy and requires MFA and the use of a Microsoft app populated with an Intune configuration to regulate and restrict data leakage, isolation, and copy-and-paste.

For these cases, zero trust can mean that access does not fail in the classic sense of a user being blocked, but that an acceptable and manageable risk is achieved with user session restrictions, after which, employees can then go about their work.

Establishing Manageable Rules

Conditional Access is based on rules (policies) that describe permitted access patterns and their consequences, such as access, denial, or restriction. Because the tool allows a large number of data points to be checked and because you need to reconcile a large number of differing requirements, user groups, and applications, the ruleset can quickly become complex.

The sooner you have a clear picture of the work patterns, applications, and equipment you want to allow, and in what combinations, the sharper the ruleset focus can be. If you can standardize the rules, that's even better, because a large number of exceptions and special configurations for small user groups will complicate troubleshooting and debugging.

If you are able to create a three-party team consisting of staff from security, application owners, and people from production or the workplace to decide what patterns are allowed and what needs to be avoided, you will benefit from a large amount of crucial input. Security can say something about the risk and protection needs of the resources you want to protect with a Conditional Access rule. Application owners help to classify the application and analyze the data and information expected to be used in it. People who supervise the workplace, tools, and day-to-day operations can provide important input on productivity, single sign-on (SSO) requirements, and app usage in terms of frequency, endpoints, and locations. The hints given by these three groups result in a single classification for each application in an ideal case, specifying the ruleset or the restrictions on use for the application.

This process then develops into an enterprise-wide classification that facilitates the assignment of applications to Conditional Access rules: Once the band of three and IT have reached an agreement, critical applications and data can always follow a specific access pattern. For example, a trusted, healthy device plus MFA opens all doors, and less critical applications are only accessible from trusted devices or with the cloud proxy plus MFA. On the basis of this rough classification with a few rules on top, scenarios can be created for the everyday applications used by most employees. Even a single Conditional Access rule for the classification covering several apps is conceivable.

You need to look at exceptions separately: For example, do you have data and apps that need to be accessible to non-trusted devices? If so, is it legitimate for a company to ask employees to install familiar Microsoft apps on their – potentially private – smartphones to cover these additional scenarios (Figure 2)? Should B2B guests never be able to access critical applications and data as a matter of principle, or is access legitimate with certain restrictions? Another exception could define, for example, to what admin accounts are allowed to connect.

Figure 2: Sample Conditional Access configuration for a non-critical app in bring-your-own-device scenarios.

The art of defining correct classifications lies in taking the middle path with as few rules as possible to maintain clarity, and as many rules as necessary to accommodate all relevant exceptions. Conditional Access is the tool that you use to define and implement policies for zero-trust operations – a clear-cut structure and policy helps you create a strict set of rules that is only softened in case of relevant exceptions.