This article was originally published on January 23, 2019, but we’re republishing it today for anybody that may have missed it, since it’s an important one.
By now, you’ve probably heard terms like conditional access, zero trust, and contextual access plenty of times. They’re all over the IT industry, and we’ve written about them, too.
Today, I want to do two things. First, write down our canonical definition so that we have something to link to; and second, explain why conditional access / zero trust / contextual access is the most important trend in end user computing since mobile devices and cloud apps came along.
What is zero trust / conditional access / contextual access?
We came from a world where access to resources was often based merely on being in the right group, connecting from the corporate network, and having a username and password. This was fine when we all had Windows PCs and all our apps were on premises; and we made it work with laptops by using VPNs.
But this old model really started to break down in the last 10 years. Devices got a lot more diverse and mobile, and today you can’t count on users accessing applications and data from a Windows laptop on your network. Cloud apps were obviously not on our corporate network either. We also had an increase in partners, contractors, and frontline workers accessing corporate resources. Here’s the kicker: thanks to trends like consumerization and BYOD, IT often had no control over these changes.
Fortunately, we’ve come a long way. Mobile devices and apps now have management APIs that we can control via enterprise mobility management (EMM) software, and we can easily control cloud apps, thanks to federation standards and identity management-as-a-service (IDaaS) products. These are a big deal! Thanks to a decade of hard work from many parts of the industry, we can now fully manage cloud and mobile.
EMM and IDaaS put us in a lot better place than we used to be, but we still have more work to do. You can have your devices enrolled in MDM, and you can have federation and multi-factor authentication in place, but what good is it if users can still access SaaS apps like Salesforce and Box from any random device they pick up?
This is where conditional access comes in: before granting access to a resource, policies can take into account a much wider range of factors. Decision factors can include the device, the app or client, the user’s behavior and how they were authenticated, and any other relevant security risks that have been reported to the policy engine.
A very basic form of conditional access would be a policy that ensures that users can only access SaaS apps from devices that are enrolled in some type of management or that meet minimum requirements. There are several ways of doing this, and they’ve actually all been out on the market for a couple of years now, so you can go out and build this today. For example, you could:
- Use MDM to distributed certificates, which are in turn required to authenticate to your IDaaS and SaaS apps. No MDM means no access.
- Have your IDaaS check with your EMM platform to make sure devices are compliant, either through a backend API, or by using a product that combines IDaaS and EMM. (An example of the latter is when AirWatch was integrated with VMware Identity Manager.)
- Use some sort device attestation agent to report the state of the device back to the IDaaS. This could include screen lock and encryption status, device type and OS version, rooting and jailbreaking detection, or just a check to see if it’s enrolled in corporate management. This is also nice because it can have a lighter touch than full enrollment.
How conditional access and zero trust expands
Beyond simply checking that a device is under management, there are a million ways that conditional access and zero trust can get more nuanced and more powerful.
First, authentication is getting smarter, stronger, and easier. EMM helped certificates replace cumbersome usernames and passwords on many mobile devices, and mechanisms like authenticator apps, biometrics, and Yubikeys are spreading. We know that two-factor is essential, but soon we’ll also have systems that can authenticate users by many factors, such as their overall behavior.
Next, we’re getting a much more nuanced and close view of risk. We can ask how strongly the user has been authenticated; we can look at the type of device and its security stance; and we can look at the content in the app (in real time). For example, we can see if a user has been downloading tons of files or tried to log in from the other side of the world.
IDaaS and EMM platforms are working to pull in third-party sources of data. Sources can include vulnerability feeds, antivirus agents, mobile threat defense platforms, or other device management platform. Several vendors are working on partner programs to do this, for example the VMware Workspace One Intelligence Trust Network, the Google Cloud BeyondCorp Alliance, and the Lookout Post-Perimeter Security Alliance.
Conditional access and zero trust make sense for cloud apps and mobile devices (the angle that I’m concentrating on for today) but of course it can be used with conventional on-premises resources and Windows-based clients, too. Resources can be published using an identity-aware proxy, removing the need for a traditional VPN. This is part of the BeyondCorp concept pioneered by Google, which is the predecessor of today’s push towards conditional access and zero trust.
Building contextual policies
With visibility into endpoints, control over app access, and a policy engine in place, you can adapt authentication techniques, app delivery methods, and data access in real time, as appropriate.
For example, if a user spends a whole day working in low-risk applications, from their corporate laptop, in the office, then you probably don’t need to bug them to do multi-factor authentication a bunch of times. But if something looks odd—perhaps the worker is in a new location that they’ve never worked from—then do a step-up authentication, alert an admin, or even cut off access.
Or, perhaps a moderately-high risk app can be accessed directly from a corporate laptop when in the office. But if the user is on their home PC, the app is served up in a virtual desktop or remote browser, with DLP policies so they can’t download or copy/paste any data.
Conditional access also helps you be flexible with different endpoint management management models. For example, with a mobile device, you could:
- Require full MDM enrollment.
- Or don’t worry about the device, but stipulate the use of a secure client. Say you allow email access from BYOD phones, but stipulate that it has to be from a secure enterprise email client that’s encrypted and has a passcode at the app level.
- For a third approach, you could use a device attestation agent to verify that the device meets a minimum baseline configuration.
Similar concepts can be applied to Chromebooks, Windows, Macs, tablets, Android, iOS, personal devices, corporate devices, partner devices—you get the idea.
And all this isn’t just for cloud apps—you can run the access controls and authentication for your traditional on-premises apps through an IDaaS, as well.
Doing conditional access and zero trust—especially with all the bells and whistles described above—does require a few building blocks to be in place.
First, you need a to have a enterprise mobility management strategy in place, or at the very least, some way to attest and verify devices and apps.
Second, you need to be doing some sort of modern identity federation. Even if you have apps that don’t support federation standers like SAML and OpenID Connect, some IDaaS platforms have built in password management features. But if you have SaaS apps that are completely unmanaged, well, then your platform can’t really help you with them.
Third, you need a policy engine that can look at all the different sources of data and context, and then control access to your resources. Where do you buy this? Vendors all across our space—especially identity management vendors—are retooling their messaging, products, and approaches around conditional access and zero trust. Citrix and VMware are in on this, too, as this is essentially what’s enabled with VMware Workspace One Intelligence and Citrix Analytics.
What’s in a name?
Conditional access and zero trust concepts have been around for a few years now, but one big issue is that we haven’t settled on a name. Here are all the terms that I could think of, with a few notes on each:
- Conditional access: Microsoft EMS seems to be owning this term, but I believe it’s the one that will win out.
- Zero trust: This one has more security-focused connotations, and is used by many vendors. (Plus, our SEO expert Kyle said that it’s currently the most popular term.) Some people don’t like it, because technically, we do put some trust in users and devices at times, as described above. It’s just that we verify the trust a lot, and the scope of what we trust is much more focused.
- Post-perimeter security: Used by Lookout. I like that it’s descriptive.
- BeyondCorp: The concept as described by Google white papers.
- CARTA: A Gartner acronym for continuous adaptive risk and trust assessment.
- Contextual access: Used By Citrix, Google Cloud Identity, and a few others.
- Device trust: Used by Okta and some SaaS apps.
Why this is so important
It should be evident by now—either from watching all the moves that our industry has been making, or by reading this—that conditional access and zero trust are just the way end user computing should work in the cloud and mobile era. This is how we make the “any-any-any” vision we’ve been talking about for years actually work! I’m excited to see how this develops, because I truly believe that these concepts are the most important thing in our industry since mobility and the cloud.