Lead Field Technologist, End User Computing, VMware.

Brian has been in the EUC industry for 25 years, and is currently the lead field technologist in VMware's EUC Office of the CTO. Prior to joining VMware, he was known as the creator of BrianMadden.com and the BriForum conference series. Brian has written six books, thousands of blog posts, and given hundreds of speeches around the world.

Brian Madden: What is zero trust, and how real is it today?

October 24, 2019

If you’re reading this, you’ve surely heard the term “Zero Trust.” It’s super trendy, and most likely on the list of future things you feel like you should learn about but that you haven’t made time for yet. (Also on that list: “AI”, “blockchain”, and “edge computing”.) There’s a good chance you think Zero Trust is a BS marketing term since vendors are scrambling to convince you they’ve been doing it for years.

In this post, I’m going to explain what Zero Trust actually is, and how you can legitimately do it today. (I’ll most likely also mention VMware Workspace ONE, sold by the vendor I work for, who’s been doing Zero Trust for years. ;)

What is Zero Trust?

Put simply, Zero Trust is an IT strategy where you decide that you don’t trust anyone or anything. (Literally you have “zero” trust for things.) Since you don’t trust anything in a Zero Trust world, you have to verify everything. This is a big departure from the old days, as these examples show:

The Old Days: “You’re connecting from a domain-joined laptop? Cool, you can get in.”
Modern Zero Trust version of that: “I don’t care if your laptop is in the domain, we’re still going to verify that you got a secure boot, are running our corporate security software, and that your laptop’s configuration matches what we approved—then you can get in.”

The Old Days: “You’re connecting from the internal LAN? Well, you got in the building, so you must be fine. Come on in!”
Modern Zero Trust version of that: “It’s too easy to bring random devices into the building, so we are going to perform additional checks even though you’re already inside.”

The Old Days: “You have the correct username and password? Great, you’re in!”
Modern Zero Trust version of that: “Having the correct username and password is one of the things we’re looking for, but we’re also going to scan the device you’re coming from, look at where else you’re logged in, and maybe apply some machine learning to decide whether we need to challenge you further (maybe with a two-factor authentication request).”

The Old Days: You are trusted, or not. Your device is trusted, or not.
Modern Zero Trust version of that: Nothing is trusted, so we’re going to watch everything you do and decide at every step whether it makes sense to let you.

In the Zero Trust world, trust levels are not pre-assigned. It’s not like the old days of, “Oh this laptop is corporate-owned, so we trust it,” or, “this network packet came from a trusted source, so it’s cool.” We don’t trust anything.

In order to do this, we have to look at everything.

In most Zero Trust implementations, the trust level is continuously verified. So even if a user’s laptop initially met the criteria to be trusted when the connection was first made, if something changes—say, the user installed unauthorized software or switched networks—it’s possible the Zero Trust system could kick the user out, require them to re-authenticate, and/or change the behavior of their apps and environment based on the new level of trust.

Doing this also means that Zero Trust implementations require a strong conditional access engine, since access decisions happen continuously (possibly many per hour per device) versus the old days of once per day. Furthermore, Zero Trust access decisions are based on dozens or hundreds of signals and characteristics, each with many states and values, versus the old days of just looking at a few yes/no things like username/password combo.

Another key element of Zero Trust is granular (and minimal) levels of access. In the old days, a single username/password combo could potentially let a user access anything they wanted once that initial authorization was done. With Zero Trust, the access decision is made each time a resource is accessed, and it’s possible that something could change between subsequent requests. This approach is used across the IT stack, including networks (with micro-segmentation that only allows the user or device to connect to the specific addresses, ports, and applications that have been authorized), servers, and applications.

To be clear, Zero Trust is a concept, not a single product you buy from a vendor. Zero Trust is typically implemented via coordinated efforts between your Unified Endpoint Management (UEM), your network, your security tools, your identity provider, and other EUC platform-type products.

Zero Trust exists because the traditional security approaches that the end-user computing industry have relied on for decades have broken down. This is mostly due to the facts that today’s users (1) use many different types of devices, which (2) may or may not be owned by the company, to (3) run many different types of apps, (4) from almost any location (5) at any time.

Many IT practitioners think Zero Trust sounds like a pain when they first hear about it, since constantly checking and verifying everything seems complex and a lot of work. But there’s an upside to Zero Trust too: if you don’t trust anything and are manually checking everything, suddenly it doesn’t really matter whether a user’s device is corporate-owned or personal, because we’re going to check it either way. It doesn’t matter if the device is inside the building on the LAN or far away across the internet, because we’re going to check it either way. And it doesn’t matter whether the device is Mac or Windows, iOS or Android, because we’re going to check it either way.

This is old, right?

Back in the old days of IT, the concept of Zero Trust didn’t really exist since the boundary of trust was the physical office network itself. (“If you’re on the network, you’re good to go!”) IT had “full trust” of whatever was on the LAN.

Then once laptops and Wi-Fi became a thing, the “we trust everything that’s on the network” model broke down because (1) users started to connect to the corporate Wi-Fi from non-authorized devices, and (2) users took their company-issued, fully-trusted devices to non-trusted locations such as their homes, hotels, and coffee shops. Both of these scenarios meant that IT had to get a bit more sophisticated than the, “if it’s on the corporate network, it’s trusted, and if it’s off the corporate network, it’s not trusted” decades-old practice.

While IT departments were cautious when dipping their toes into this new world, they got there eventually. It started with remote desktop technologies (like VMware Horizon for VDI or RDSH app publishing) that let home users connect to and run Windows desktops and applications running in the corporate datacenter from their home computers. IT departments essentially let employees use whatever devices they wanted at home, because the VDI/RDSH software and remoting protocols could be configured to disable client drive mapping, local/remote clipboard synchronization, and local client peripheral support. By blocking everything, it didn’t matter whether the user’s home computer was trusted or not, because IT could deliver access to the important applications safely. This was the first version of “Zero Trust” that a lot of companies saw.

Another example of Zero Trust that many companies have been doing for years also involves remote access, though this time it’s the VPN software that has the ability to perform checks on the remote client device it’s running on, ensuring (for example) that the user has the required security or antivirus software running, and that their machine is configured properly before they’re allowed to remotely connect to the corporate network.

Both of these examples illustrate the bigger trend—in the old days, the trust boundary was huge (e.g., the entire corporate network, or the entire domain), and today, that boundary has shrunk (e.g., the datacenter, the app, or the network segment), and everything outside it (all end user devices) are not trusted.

So really, Zero Trust was the inevitable end result of two decades of continuously bringing the trust boundary closer to the core.

Cool concept, but I can think of about 15 reasons it won’t work!

I spent last year meeting with over 150 customers all over the world, and many more since then. Zero Trust was a topic I probably discussed with 50 of them. What strikes me about these conversations is that while most customers agree that the concept of Zero Trust is a good thing, and they believe they’ll get there eventually, a lot of folks tend to start listing all the reasons why Zero Trust won’t work for them. (They’re Zero Trust NIMBYs!)

Their reasons for protesting vary, but they’re mostly around not being able to support every device type, or their network and security people are on a different team and Zero Trust isn’t a priority for them, or they feel that they’re a “special” case (regulated, secure, too big to fail, etc.) and so they can’t risk it.

As I mentioned previously, every enterprise customer is doing some type of Zero Trust today (VDI, RDSH, SSL-VPNs, NAP, Wi-Fi certs, and many other “traditional” technologies have some elements of Zero Trust). So, when customers object, I respond with, “Actually, you’re already doing it. All I’m saying is you should do it for all users in all situations.” :)

In the old days, since the technology didn’t exist to do a deep inspection of every device, IT departments had to look for clues that a device could be trusted. In the Windows world, that meant domain-joined machines, fully managed with GPOs and SCCM, and locked down enough that IT didn’t have to worry about them.

But today you can verify the integrity of a Windows 10 machine regardless of whether it’s in your domain or not. (The specifics of “how” are for another day. It has to do with Trusted Platform Modules, Modern Management, signed code, and lots of other wonderful technologies that both Microsoft and Intel had a big hand in.) With Windows 10, you can remotely verify that the machine booted a certain version of Windows, and that it wasn’t tampered with, and that certain settings are applied.

So, in today’s world, a Windows client doesn’t have to be in the domain for us to be able to trust it—we can define our standards and then make a trust evaluation regardless of whose device it is. (This is helping to fuel the explosion of Employee Experience improvements, like allowing employees to use any device they want, and letting them set up new devices direct from the store without IT’s involvement.)

In other words, in today’s world you can say, “I only want to allow Windows devices running 1803 or newer, with hotfixes XYZ, with this white list and that black list, (and whatever else you can think up),” and I’ll say, “No problem!”

Similar stories are happening outside of the Windows world too. Modern MacBooks with Apple’s security chip offer similar functionality, as do all iOS and Android devices.

Why now?

Okay, so even if Zero Trust is a thing, and even if it’s possible for us to do, why is this something we should think about today?

Three reasons:

  • Zero Trust is the inevitable end game.
  • Zero Trust is more secure.
  • Zero Trust provides a better user experience.

First, like I said, Zero Trust is the inevitable end game, so the sooner you get on board, the better.

Second, implementing a Zero Trust approach is more secure today than piecemeal systems. Most typical organizations manage Windows laptops with one tool, Macs with another, and mobile devices with even another tool. This means that there is no consistency in capabilities across device types, which means there are holes all over the place.

Today’s Zero Trust implementations are also more secure because bad actors can’t use trusted devices or stolen credentials to get around policies. And if someone does sneak through, it doesn’t matter, because we don’t trust them and continuously monitor and verify their activities and security posture.

Third, Zero Trust provides a better user experience. It lets users use the devices they want, to get the access they need, from anywhere and in the way they want.

Next Steps

VMware Workspace ONE can be the platform for your Zero Trust implementation.

If you want to learn more about Zero Trust, and the specific steps you can take to begin to implement it, check out our Mastering Zero Trust activity path on Tech Zone. (The website where you’re reading this blog post.) Workspace ONE has the ability to do this today, in many cases working with your existing identity providers, security systems, and hardware. Zero Trust is not a goal that we want to get to someday, rather, it's something that many organizations are implementing today, and by using Workspace ONE, you can too.

October 24, 2019

Lead Field Technologist, End User Computing, VMware.

Brian has been in the EUC industry for 25 years, and is currently the lead field technologist in VMware's EUC Office of the CTO. Prior to joining VMware, he was known as the creator of BrianMadden.com and the BriForum conference series. Brian has written six books, thousands of blog posts, and given hundreds of speeches around the world.