Zero Trust and Azure AD Conditional Access

Introduction

By now, Azure AD Conditional Access should no longer be unfamiliar to anyone in IT. As a refresher, it’s Microsoft’s solution for providing a flexible, condition-based, way of controlling access to (cloud) resources.

So, why write an article about it you may wonder? Well, I believe that organizations worldwide aren’t leveraging Conditional Access to the fullest. Personally, I feel there is a lot more to be gained from a better and more elaborate use of the feature; not just from the capabilities you gain, but also from how it fits into a bigger picture and approach, like e.g. Zero Trust.

What is Zero Trust?

Zero Trust is – like many other things – somewhat (over)hyped. It’s often misused or even abused. The latter is especially true when someone is trying to sell you something… Anything that can relate back to Zero Trust must be worth considering, buying… Let me put you immediately at ease: I am not trying to sell you anything, so what follows are my unbiased thoughts on the matter.

To me, Zero Trust is an approach to security. It’s a (set of) principle(s) that guides you along your path to a more secure environment. I was very happy to learn that NIST recently published a draft version of their take on Zero Trust; large parts of their Architecture and approach are similar to how I tend to look at it. In addition, it makes supporting your vision and approach a bit easier at times!

The concept of Zero Trust is not new and it’s definitely not the only architectural security concept out there. Similar concepts exist, albeit each with some (minor) differences in approach, terminology etc. Some popular alternatives are Google’s BeyondCorp or Gartner’s CARTA (Continuous Adaptive Risk and Trust Assessment).

Without going into too much theory, the bottom line for each of these frameworks is something along the following lines: Don’t trust anyone (identity) or anything (device) connecting to your environment/resources (connection).

As such, one could summarize the approach to zero trust in a couple of generic principles. The important part to note is that you don’t take anything for granted, ideally you would perform all of these for each connections/access request/etc. and you would also perform them continuously/regularly:

• Verify identities; verify the identity (authentication)
• Authenticate/validate devices; ensure their health and compliance to your requirements
• Authenticate connections; ensure that each connection is verified and only allowed when necessary

How does Azure AD Conditional Access fit into this?

With the above principles in mind: how does Azure AD Conditional Access fit into all of this? If you take a look at NIST’s draft specification for a Zero Trust Architecture, it speaks of components called a Policy Engine and a Policy Administrator for which it gives the following definitions:

• Policy Engine: This component is responsible for the ultimate decision to grant access to a resource for a given client or subject. The Policy Engine uses enterprise policy as well as input from external sources (e.g., IP blacklists, threat intelligence services) as input to a “trust algorithm” to decide to grant or deny access to the resource.
• Policy Administrator: This component is responsible for establishing the connection between a client and a resource. It would generate any authentication token or credential used by a client to access an enterprise resource. It is closely tied to the Policy Engine and relies on its decision to ultimately allow or deny the connection. Implementations may treat the Policy Engine and Policy Administrator as a single service…

Both definitions fit the description of Azure AD and by extension also Azure AD Conditional Access to a T. Of course, you could have come to the same conclusion based on Conditional Access’ name as well, but having external validation (from none other than NIST) can be helpful.

Where is this rather long intro leading to? To show you that Azure AD Conditional Access is not just a feature that you turn on to e.g. force mobile devices towards using Outlook Mobile or something you do to enable Multi-Factor Authentication for your users. Of course, those are two very real uses cases for which Conditional Access is the way to go, but these use cases are only (a small) part of a bigger picture: establishing a more holistic way of looking at Zero Trust.

Besides the aforementioned use cases, Azure AD has the ability to leverage a lot more signals and apply (a lot) more logic before it grants (or denies) access to an underlying resource. In the grander scheme of Zero Trust, health attestation of a device and subsequently using that attestation to make an informed decision on whether or not to allow an incoming connection is fundamental; especially if you want to allow a flexible strategy on whom can connect to what type of data and what device(s) can be used to do so.

Ultimately, your goal is (or should be) to allow users to consume resources with as much flexibility as you are willing to accept risk for. In theory, you could grant access to any device unless you cannot reasonably guarantee the data can be kept safe if you do. In such case, you would either want to limit or even refuse access all while keeping the decision-making process dynamic and ensuring you are assessing each of the signals that contribute to your conditions as the connections to resources happen.

So, what does this look like in terms of policies etc.? Although the specifics may vary from a high-level, your (basic) set of policies might include the following all whilst making use of Azure AD Conditional Access:

• Require MFA, and preferably use Identity Protection to force MFA based on risk score rather than a static set of conditions. This will ensure that 1) users aren’t prompted every single time and 2) users, sessions and signals are evaluated dynamically, not just on an “IFTTT” rule base.
• Allow BYOD (unauthenticated) devices to access specific resources only. For example: email. However, when accessing email from an unverified device, only allow connections through an application that allows you to enforce specific security settings. In Microsoft’s realm that would be the ability to apply App Protection Policies. If an authenticated device is used (= “compliant” to your Compliance Policies), you could allow unrestricted access as you have control over the device and, therefore, it’s security posture. Of course, the latter must be true before you can get started with this approach…
• On unmanaged laptops and computers, allow online-only access to resources; restrict the ability to download files. This ensures that no data is downloaded on a device you do not own or have no control over. For example, triggering the “Unmanaged Devices Access Policy” for SharePoint. In Exchange Online, you could prevent attachments from being downloaded.
• Alternatively, you can apply session controls which would allow Cloud App Security to apply additional logic (or protection) over resources. For example, you could allow downloads, but automatically apply encryption (sensitivity label) on the downloaded content.

It doesn’t need to stop there… The combinations and capabilities are virtually limitless. However, it doesn’t mean that Conditional Access will solve all of your challenges. Sometimes, additional solutions and controls provided through solutions such as Cloud App Security are required to go above and beyond what is (currently) feasible with Conditional Access. For example, MCAS can reason over connections and data as they are happening, whereas Conditional Access hands off access to the underlying resource once its decision has been made; it will only reassess the condition at the next authentication (which could be as little or as much as 1 hour after the initial authentication).

Even though Zero Trust has been introduced as a concept many moons ago, there is still a lot to be improved and a lot to be gained from even the most basic functionalities in Conditional Access. In the meantime, Microsoft continues to add more functionalities so that, over time, new scenarios are unlocked as new signals, conditions and controls become available.

Does this mean that, by the time you’ve been able to implement a couple of policies like the ones I’ve described earlier, you can consider to be at the panacea of Zero Trust? Unfortunately not. As I mentioned, Zero Trust is not an end state or a goal by itself. It’s a journey. Today, Conditional Access may solve the ability to verify identities and devices, and perhaps it provides the flexibility to evaluate dynamically with more signals such as information from (external) Threat Intelligence feeds, but there’s still a lot of work to be done when it comes to legacy resources, such as servers etc… That is where solutions like the Azure AD App Proxy come into play. But that is for another article!

How are you using Conditional Access today? Would love to hear your feedback!

Monitor Your Hybrid - Office 365 Environment with ENow

ENow’s solution is like your own personal outage detector that pertains solely to your environment. ENow’s solution monitors all crucial components including your hybrid servers, the network, and Office 365 from a single pane of glass. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.