Practical Protection: Baby Steps Towards Zero Trust 

When I was younger and somewhat less risk-averse, I rode motorcycles. My rule was simple: “all the gear, all the time.” I wouldn’t even ride to the end of my street without a helmet, gloves, and abrasion-resistant clothing. This was a big hassle, it was often uncomfortable, and it made me look dorky, but (to me, anyway) the safety benefits were worth it. Being consistent in applying protection was the best way to stay safe. 

The same is true of zero trust security designs. Implementing zero trust in the world is a big hassle, often uncomfortable, and frequently dorky—plus, it can be expensive. At the same time, moving closer to a zero trust model helps harden your network significantly, and you may already have many of the tools and techniques you need available without much extra cost.  

A Working Definition of Zero Trust 

Stephen Paul Marsh coined the term “zero trust” nearly 30 years ago. It’s taken that long for the concept underlying zero trust models to take root in the marketplace, but they go back earlier—one fundamental assumption of the Kerberos protocol that underlies Active Directory authentication is that the network can’t be trusted. The zero trust model extends that lack of trust by saying, basically, “not only can you not trust the network, but those devices on it are also probably shady too.”  

If you port this concept over to a typical enterprise network, it means that devices and users must be separately authenticated, and that access to resources should rarely (if ever) be granted based on a previous access grant. It also means assuming that every device and endpoint is untrusted. In other words, it sounds very much like the modern Internet, more particularly the modern implementation of Microsoft 365. For instance, consider a traditional VPN that allows a connected device to go anywhere on a corporate network: once the user supplies credentials, her device (which may be infected with malware or otherwise compromised) acts like it just plugged into the corpnet. The user and device are free to send traffic anywhere on the corpnet. 

Now compare that approach to using something like Azure AD Application Proxy, where a connected user must authenticate to the service (meaning that conditional access policies and MFA can easily be applied), and then a separate set of controls can be applied to limit the user’s access to one specific application—or even parts of an application. There’s quite a difference in scope between these two approaches. 

The UK’s National Cyber Security Center has a pretty good definition of the principles behind zero trust network architectures: 

• Single strong source of user identity: in Microsoft 365, this is obviously provided by Azure AD. 
• User authentication: all of the services included in Microsoft 365 depend on Azure AD for user authentication.  

• Machine authentication: while Azure AD or on-prem AD allow devices to be authenticated, this isn’t mandatory.  
• Additional context, such as policy compliance and device health: this is one of the biggest benefits to using Intune, but some additional context will be available to you even if you don’t use it. 
• Authorization policies to access an application: Azure AD conditional access policies are the primary way to implement this aspect. 
• Access control policies within an application: Microsoft already has comprehensive access control policies built into the Microsoft 365 applications themselves. 

What you Already Have 

Just from reviewing the above list, it’s evident that Microsoft has already done some of the legwork to help you deploy a zero trust model in your Microsoft 365 tenant: by default, the service assumes that every device is untrusted (and untrustworthy!), and of course authenticating to one service endpoint alone doesn’t give you free rein over Microsoft’s entire network. (They do provide single sign-on so that you don’t have to keep re-authenticating as you move from Outlook to Teams to Planner.)  

Although you don’t necessarily see these capabilities in action, Microsoft also applies security policies to decide when to require multi-factor authentication or when to tag a sign-in attempt as risky based on additional context (where did the user log in from? Is this account known to be compromised?) 

The default set of these 365 features provides one of the key benefits of a zero trust architecture: an attacker who compromises one Microsoft 365 device or account doesn’t automatically get an easy way to move laterally and compromise another account or device. (unless, that is, the attacker manages to compromise an account with elevated privileges, but that’s a separate class of problems to solve!)  

Extending Your Zero Trust Reach 

Of course, Microsoft would be delighted to sell you a bunch of licenses for all its products to help you implement their vision of zero trust. While this might be a great long-term goal for you (or it might not!), you can make some significant progress without sending Microsoft a huge chunk of your IT budget. 

First, consider whether you would benefit from using machine authentication via Azure AD domain join. This allows you to reduce or eliminate the use of local accounts and ensure that every user and device mutually authenticates, a key part of zero trust design. 

Second, a few minutes is all it takes to review the access control permissions and role assignments in most tenants. This is time well spent, and it’s something you should do regularly. Strictly speaking, this isn’t a zero trust-related issue, but it does little good for Microsoft to implement a broad set of application access controls if you don’t regularly audit who has permissions to what data. 

Third, adding additional authentication context is often very useful as a way to improve your security. That starts with using MFA (of course!) but extends to incorporating location, application usage, and other factors. Some of the context available to you may require buying Azure AD Premium P2 licenses, but you may not need licenses for every user. 

Fourth, as we’ve discussed repeatedly here at Practical 365, conditional access policies give you a great set of tools for applying authorization policies for application access. Careful planning and study, and a little judicious experimentation, will help you determine which specific policy conditions, grants, and exceptions make the most sense for your environment. 

The good news is that Microsoft has a vested interest in helping its customers stay secure—security breaches cost them money and spoil the carefully-cultivated trust they’ve built up since the dawn of the Trustworthy Computing initiative. For that reason, you can expect them to continue to provide the basic building blocks you’ll need to implement zero trust. But it’s your responsibility to take advantage of these tools.