In the third year of the coronavirus pandemic, it has now long been clear that many companies are likely to remember the virus as beneficial to their own business. VPN solution vendors definitely fall into this category: When home office and teleworking mutated from the exception to the rule in many companies, existing VPN solutions became substantially more in-demand. Hardly anyone expected the load on the VPN gateways to explode overnight. The large network manufacturers were happy to help out their customers as many admins purchased more powerful systems for OpenVPN (Figure 1).

Figure 1: Homegrown VPN solutions, such as this one based on OpenVPN, are no longer suitable for state-of-art security. © KIT

But do VPNs really solve the problem of network security? Many experts are not so sure. Implicitly, all parties involved with VPNs start from the following premise: There is a difference between the internal and the external network, and it is safe to treat internal clients differently from external clients. VPNs are regularly used specifically because admins do not want certain services to be accessible from the Internet at all. In many companies, VPNs form part of a security architecture that has grown organically over many years. Because security requirements have increased continuously over the past two decades, companies have invested more and more money in private networks and cut off more and more services from the outside world.

But cutting off external users only solves part of the problem. The classic division into an insecure external and a secure internal network implicitly assumes several things. First of all, it assumes that you can reasonably make assumptions about expected usage behavior based on location. This misguided narrative invites the belief that the company's own employees couldn't possibly mean any harm, unlike sinister hackers who hack into other people's environments from the Internet. Another faulty assumption is that you can safely make inferences about who the client is and what permissions they should have based on location. Anyone who makes it onto the internal network is automatically considered trustworthy and enjoys expanded privileges, including access to infrastructure components that remain closed to external clients.

Today's knowledge of information security shows that such approaches are questionable. Clients on the internal network also pose a security risk. The risk could come from a user who opens a malware-infected attachment, a disgruntled employee, or a former employee who still has some form of access. Another problem is the constant presence of visitors coming and going with sophisticated (and highly networkable) mobile devices.

Zero trust is a set of principles designed to establish rules for eliminating the location bias in networking. In the zero trust model, every user is considered untrustworthy until vigorously proven otherwise. The zero trust rules also codify other best practices for network security, creating a state-of-the-art environment that corrects many of the out-of-date assumptions that put networks at risk.

Long History

The term "zero trust" dates back to a doctoral dissertation by Stephen Paul Marsh at the University of Stirling in Scotland [1]. Marsh's work was based on the concept of "trust" as something that can be defined mathematically, apart from the concept of morality and the complexity of human interaction. An international group called the Jericho Forum began to meet around 2003 to study the problem that they defined as "de-perimiterisation." The Jericho Forum raised awareness to the need for a new approach to network security, with the emphasis on eliminating the archaic idea of the internal network as a safe and protected space. The Jericho Forum's Commandments [2] were a forerunner to many of the principles now associated with zero trust.

Of course, it took some time for the real world to catch up with the theorists. It is worth remembering that the first local area networks as we know them today were isolated and typically didn't even use protocols that were routable on the Internet. When the push for Internet connectivity began in the 1990s, the concept of the LAN as a "safe" space was already firmly entrenched, and the effort to stop intruders from gaining entry focused on the gateway device. Large companies, in particular, have had a hard time letting go of the security strategies that worked for them in the 1990s.

In 2009, Google implemented the BeyondCorp security model, which is now considered an early implementation of a zero trust architecture. Meanwhile, academics and security experts continued to develop and explore the principles of zero trust, and the components that are now the building blocks of zero trust, such as encryption and identity management, continued to evolve in parallel.

The first government policy documents defining zero trust appeared a few years ago, with the US National Institute of Standards and Technology (NIST) SP 800-207 "Zero Trust Architecture" [3] in 2018 and the UK's National Cyber Security Centre (NCSC) "Network Architectures" [4] in 2019.

Here in 2022, the division of the world into "good" (internal) and "bad" (external) is becoming increasingly irrelevant, and the zero trust model is quickly gaining ground as the better approach.

Assumptions

Several formulations of the zero trust principles exist, all of which have similar goals. NIST SP 800-207 states these tenets as follows:

1. All data sources and computing services are considered resources.
2. All communication is secured regardless of network location.
3. Access to individual enterprise resources is granted on a per-session basis.
4. Access to resources is determined by dynamic policy – including the observable state of client identity, application/service, and the requesting asset – and may include other behavioral and environmental attributes.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.

The idea is that the organization will design a zero trust architecture based on these principles and then will implement that architecture to build a real-world zero trust network. The principles ensure that no important details are left to chance. Close examination of these tenets reveals that many of the components of zero trust are things that modern networks worry about anyway, such as logging, monitoring, access management, and secure communication. The zero trust model creates an overarching structure and ensures that the principles are applied systematically.

In zero trust, a service always assumes that a client has sinister intentions until it proves otherwise, for example, by logging in with unique credentials. But even the login does not result in unrestricted trust; a sophisticated authorization strategy is an integral component of a zero trust environment. A client must have explicit authorization for a specific task in order to proceed.

Another central factor in zero trust is that all connections must be encrypted. Of course, the question arises as to what kind of encryption and what encryption tools – these questions are best answered at the design stage. One could ask whether something like a VPN is even necessary, if encryption is used on the local network anyway, and zero trust principles eliminate the concept of the internal network. Would it not be possible to just access anything from anywhere using SSH? This argument, however, reveals an incomplete understanding of zero trust.

Google's mail servers, for instance, are not directly accessible from the network via SSH. However, this is not because Google has given up on its own zero trust. It is far more the case that administrative access to infrastructure is usually reserved to a small, fairly static group of people. There is simply no reason for the average user of Google's services to access the servers via SSH. On the other hand, quite a few central Google services – those for the masses – can actually be accessed without any special connection such as a VPN. The zero trust model does not exclude the use of VPNs for special purposes. It merely contradicts the assumption that a client with VPN access should enjoy special rights.

There is much work to be done before admins can switch off the VPN in an existing environment or restrict its use, because zero trust cannot be achieved by installing a specific program. It is far more a matter of creating a strategy that integrates all the necessary components of an environment in the best possible way.

Users and Rights

As you can see from the preceding tenets, the zero trust system is heavily dependent on the need for a centralized authority for assigning granular rights to specific users. For any zero trust infrastructure, a centralized user and rights management system is a must-have. Two systems have established themselves in the market for centralized user management: LDAP and Active Directory (AD). Especially in corporate IT environments, you will often find a reasonably up-to-date instance of Microsoft's AD (Figure 2), and, with a bit of luck, LDAP compatibility is enabled. Most management software today offers support for at least one of these access methods.

Figure 2: Active Directory can act as a central component in a zero trust architecture. © Microsoft

If there is no ready-made user directory available and you want to create one for a Linux environment, you have several choices. One option is LDAP in the classic implementation of OpenLDAP. OpenLDAP is available for Suse Linux Enterprise Server, Ubuntu, and several other distros. Red Hat, however, does its own thing and delivers Red Hat Identification Management instead. Red Hat Identity Management is based on FreeIPA, a competitor implementation to OpenLDAP with some additional features. For example, FreeIPA comes with integrated management for SSH and SSL keys, systems and users out of the box, and a variety of CLI tools.