Zero trust is a security model that’s actually quite simple in theory. At its heart is the idea is that no device or individual can be trusted without verification. No matter if you are already connected to a corporate network, have been verified previously, or even have elevated administrator status. Everyone and every device must prove who they are and that they permitted to be where they are at any time.
In reality, however, the concept of a zero trust network runs contrary to years of network design thinking. Networks have always been built with zones of trust. In the simplest versions, you have an “inside” and an “outside,” representing your network and the public internet (or any other external networks you might connect to). You put a firewall in between the zones and control access between them in both directions.
Everything on the inside is said to be trusted. Any computer inside your network can connect to any server, or printer, or any other device. Everything on the outside, though, is untrusted. Now, untrusted doesn’t mean there’s no access between the two, but rather the access is controlled. Ideally, this control should involve some sort of authentication and authorization mechanism that determines what resources you can access and forces you to prove who you are.
Zero trust means those controls are applied to everything, all the time. Nothing is trusted automatically just by virtue of being connected to the network in a particular way.
Where does the zero trust model come from?
The idea of employing zero trust security to networks is nothing new, the term being first coined in 1994. As networks and the internet continued to grow, it became increasingly difficult to define the “perimeter” or edge of a network. By 2009, Google had begun its transition to a zero trust architecture, one of the first global networks to do so.
Today, zero trust architecture has become the prevalent security posture for most networks, driven largely by the rise in mobile BYOD (bring your own devices) and a shift towards cloud-based services and applications. Several national organizations, including NCSC (National Cyber Security Center UK) and NIST (National Institute of Standards and Technology in the US), are working together to create a set of zero trust model standards.
The benefits of a zero trust network
The trouble with having everything on the internet is an attacker can easily gain access to it by simply stealing (or guessing) a password. An attacker can compromise one system and then use this access to compromise other ones. For example: If everything on the internal network of a large corporation is trusted to access the accounting system, then all an attacker needs to do is compromise the accounting system—and work backwards. All it takes is a simple security vulnerability that was never patched, or maybe a default system administrator password that’s ignored because it can only be used from the internal network.
There are also many easily compromised devices on any corporate network, like printers, video conferencing cameras, smart TVs, and legacy appliances. Nobody ever patches these systems, and they’re all encrusted with security vulnerabilities. If an attacker can set up camp on one of these systems, they can operate with impunity from the trusted network.
A zero trust network focuses on protecting resources (assets, services, workflows, network accounts, etc.), rather than network segments, as the network location is no longer seen as the prime component to the security posture of the resource.
What is “AAA”?
The key aspects to good zero trust security is the “AAA” model: access control, authentication, and authorization. For example, the NCSC outlines 6 such principles for zero trust models:
- Single strong source of user identity: Single Sign On (SSO) authentication that allows access to several related but separate applications of systems.
- User authentication: Identify the person behind the keyboard. Usernames, PINs, key fobs, and even fingerprint scans can all be factors.
- Machine authentication: Identify the machine (device) trying to access the network. Certificates, 802.1x, and Active Directory are examples.
- Additional context requests, such as policy compliance and device health.
- Authorization policies to access an application set by an administrator.
- Access control policies within an application set by an administrator.
The intent: isolate everything. If one device is compromised, whether it’s a user workstation or an insecure camera, there’s very little an attacker can do to damage the rest of the organization. If a compromised printer is segregated onto a different network that’s isolated by a firewall, except for specifically authorized printing functions, there’s almost nothing dangerous a compromised printer can do.
Zero trust security isn’t perfect
Zero trust is a good thing and a good idea, but it doesn’t solve all of your security problems. You can still get malware. Your software-as-a-service provider can still be compromised by a clever attacker who’s aware of flaws in their system. And there’s also the possibility of a denial of service attack that simply makes you unable to reach your systems or your data.
The most prevalent example from the last several years is ransomware. A tiny piece of malware runs on a user’s computer and automatically assumes all of that user’s access rights, including the ability to modify files. If those files are on the central corporate file server, they could cause extensive damage.
With a zero trust security posture, we aren’t trusting the user’s computer, only the user (the resource). But unfortunately, there really isn’t an easy way to tell the difference between malware running under a user’s account and legitimate software running under that same user’s account. 
Imposing a more granular authentication model in which the user has to authenticate every individual action is also unworkable because they’d have to constantly re-authenticate themselves. (Yes, I really meant to do that. Click. And again. Click.) And this still wouldn’t eliminate the threat completely: a piece of malware could sneak itself into the endless series of authentication requests and trick the user into supplying authentication credentials for a malicious action.
And just because you’ve instituted a new zero trust model, that doesn’t mean other vital processes, like config backups, device and network health monitoring, and alerts can be ignored. Every process is a component in your over ability to protect, diagnose and troubleshoot potential issues before they become critical.
How can you include zero trust in your network?
A big change over the past few years that has facilitated the general move towards zero trust networks is the widespread adoption of cloud services and applications. Today, if your email, file storage, and office automation suite are at Microsoft Office 365 or Google Workplace, then you’re already partway there.
If, say, your accounting system is a cloud-based software-as-a-service model, or if your core business applications are running in cloud services that requires users to sign in using a secure web browser session, that’s already two forms of zero trust you’re employing. The systems are already separated from the users by firewalls, every user already needs to authenticate everything they do, and the authorization models in these services already restrict who can access what.
What else should you consider to help enforce a zero trust network across all your resources?
Increase your cloud-based services
Many cloud-based applications have, by their nature, a form of zero trust security included in their design. The need to authenticate both the user and the device requesting access, as well as the access restrictions placed on end users by admins, gets you most of the way there.
Separate authentication across devices or networks
Forcing users to authenticate using more than one device is another strong security component to zero trust models. For example, employing a Google Authentication app via a user’s mobile device, on top of a user authentication and a machine authentication on their laptop.
Separate application access and network access
Again, using separate login and authentication procedures for both access to applications and network resources helps to ensure that no one can use one compromised access point to wander around your network.
One step at a time
Achieving a zero trust design for your network is not an overnight process. Like any changes you bring to your network, it takes a lot of iterative steps: observing, evaluating, planning, testing, deploying, and optimizing.
Take Akamai. It took the company over nine years to fully implement a zero-trust model. After lots of review of the original infrastructure, they realized they had what they referred to as a “Security Twinkie” — seemingly tough from the outside, but soft and mushy if you got in. Their solution exemplifies all the points we’ve mentioned above:
“Users access applications and services at Akamai on a case-by-case basis via a web interface after they—and the devices used for access—have been fully authenticated and authorized. Broad network-level permissions have been replaced with a narrowly tailored zero-trust model where every application access request is verified and vetted. No applications are visible from the internet and therefore cannot be directly accessed from it. There is no VPN access either… In Akamai’s model, an attacker with access to a user’s account would only have access to the specific tools and services available to that particular user and nothing else.”
