Trust No One, Control Everyone - The Basics of a Zero Trust Architecture

01.06.2022•Stefan Welsch
Cloud Zero Trust Security

Today’s topic is the Zero Trust Security Model (alternatively Zero Trust Architecture, ZTA), in short: Zero Trust. Zero Trust also strictly follows the approach: “Trust nobody, verify everyone”. Zero Trust is not a framework or software that you can install, but there are various concepts and principles that are important when implementing a Zero Trust architecture. Many of these concepts are not really new either. The term Zero Trust has been around since 1994. Stephen Paul Marsh first used it in his doctoral thesis on computer security. In 2014, a swiss security engineer, Gianclaudio Moresi, built the first system that implemented the principles of Zero Trust. In 2019, the National Cyber Security Centre recommended that new cloud-related services should be deployed with a zero-trust architecture. Since 2020, large IT platform and cyber security providers have been providing usable examples of a zero trust architecture.

Zero Trust Basics

Zero Trust is a cybersecurity paradigm which aims to protect resources and never takes a relationship of trust as a given. Companies like to rely on a firewall to protect them against all attacks from the network. In most cases it does, but if the firewall is breached, oftentimes the full system is open to the attacker, since there are usually hardly any other security measures within the company network. Even internal employees who do not access the company’s network via the firewall can “move freely” within the network. Zero Trust starts right here and protects every single resource against unauthorized access. This means that each user must first authenticate and authorize themselves for each request to a resource. The term “user” is also not entirely correct. This suggests that these are exclusively people. However, it is about every entity, for example another computer or possibly a technical user. Therefore we should rather speak of a subject.

In the following diagram we see an example of how a subject accesses a resource. Permission is given by a Policy Decision Point (PDP) and the associated Policy Enforcement Point (PEP). The system must therefore ensure that the subject is authenticated and that the request is legitimate. This implies that Zero Trust applies to two fundamental areas: authentication and authorization.

We see the “Implicit Trust Zone” in the chart. It represents an area in which all entities are trusted up to the level of the last PDP/PEP.

Let’s try to picture this a little more clearly: At an airport, every passenger has to go through a security check before they are allowed to board. This security check would be the PDP/PEP in our diagram. All people who have not yet passed this point are therefore in the “Untrusted Zone”. All those who have passed this point are consequently in the “Implicit Trust Zone”.

So the PDP/PEP provides certain controls so that the request for the PEP has a basic level of security. A PDP/PEP cannot issue any further rights to a request. This then requires another PDP/PEP, which then provides other controls. To apply this to our airport example again, we can imagine that passing through the first PDP/PEP (Security Check) does not necessarily mean boarding the aircraft. Before boarding, usually the boarding pass is compared with the ID card (Boarding Control).

Zero Trust Principles

A Zero Trust architecture is designed and deployed in compliance with the following Zero Trust principles:

  • All services and data sources are considered resources.

  • All access to resources is secured, regardless of network location.

    • This means that an internal network does not imply a relationship of trust. Requests from the internal network must therefore meet the same security requirements as requests from the external network.

  • Access to individual resources is allowed on a session basis.

    • If access to a resource is granted, access should also be allowed for the next request in the same session. However, this does not apply to other resources.

  • Access to resources is determined by dynamic policies.

    • When accessing a resource, it’s not necessarily just the username or role that matters. A policy is a set of access rules that an organization assigns to a subject. The client identity can include a user account and any attribute assigned by the company. The type of device, installed software versions, etc. can also play a role.

  • The company monitors and measures the integrity and security status of all owned and related assets.

    • No asset may be trusted through inheritance. This means that the company evaluates the security status of the asset when evaluating a resource request. Assets that are not managed by the company itself can be treated differently than company-owned assets.

  • All authentication and authorization is dynamic and strictly enforced before allowing access to any resource.

    • This includes, for example, the use of multi-factor authentication, which is repeatedly requested at certain intervals.

  • Logging and monitoring of all communication in the network.

    • An organization should collect data about the security status of assets, network traffic and access requests, process that data and use any insights gained to improve policy creation and enforcement. This data may also be used to provide context for subject access requests.

Zero Trust Platform Requirements

In order to comply with these principles, there are certain platform requirements. We shall look at these in the following section. The aim is to highlight the platform-relevant aspects of the principles just discussed.

  • The communication at the data level must be encrypted. There may only be an exception on purpose (z. B. DNS).

  • The system must be able to enforce access controls for all types of resources. Access control mechanisms must be governed by identity-centric and contextual policies.

  • Data resource protection should be able to use guidelines reliant on identity and context to control access.

  • System and policy model must support backup of all users at all locations. Policy model and controls must be consistent for remote and local users.

  • Devices shall be able to be verified for their security status and configuration before being granted access and periodically thereafter.

  • It must be possible to differentiate non-company from company-managed devices and to control the level of access accordingly.

  • Access to any network resource must be explicitly granted per policy. No user or device should inherently have broad network access.

  • Access controls must be able to distinguish between different services on the same network resource. For example, access to HTTPS must be granted separately from access to SSH.

  • Access to certain data items contained in applications or containers with different classifications must be enforced based on business policy.

  • The metadata on all network traffic must be connected to the subject identity and logged. It must also be possible to check network traffic for aspects relevant to security and data loss.

  • There must be no difference in the application of policies between on-premise and cloud resources

  • Logs must be ingested into analytics tools to enable rapid policy enforcement. This makes visible which resources are used by which subjects, so that rights can be assigned using appropriate automation tools.

Components of a zero trust architecture

At its core, Zero Trust consists of 3 components: Policy Engine (PE), Policy Administrator (PA) and Policy Enforcement Point (PEP). In the diagram above we can see that the Policy Decision Point (PDP) consists of two components, Policy Engine and Policy Administrator.

Let’s take a quick look at the responsibility of the components. I mentioned earlier that PDP and PEP ensure that a subject is granted permission to a specific resource. We now want to look at how the individual components divide up this work.

Policy Engine

The Policy Engine component is responsible for making the final decision on whether to allow access to a resource. Company guidelines and other external sources (eg. “Continuous diagnostics and mitigation systems”, CDM) are used as input for a trust algorithm. Access to a resource can be granted, denied, or revoked. The PE interfaces with the Policy Administrator component. In doing so, the PE makes and logs the decision (granted/denied) and the policy administrator executes the decision.

Policy Administrator

The Policy Administrator component is responsible for establishing and/or closing the communication path between a subject and a resource. The PA is closely associated with the PE and relies on their decision to ultimately allow or deny a session. If the session is authorized and the request is authenticated, the PA configures the PEP to allow the session to start. If the session is denied (or a previously granted access is revoked), the PA signals the PEP to end the connection. There are implementations that treat the PE and the PA as a single service; here they are split into the two logical components.

Policy Enforcement Point

The Policy Enforcement Point component is responsible for activating, monitoring and finally terminating connections between a subject and an enterprise resource. The PEP communicates with the PA to forward requests and/or receive policy updates from the PA. Once the PEP has been passed, there’s the trust zone (Implicit Trust Zone) where the corporate resource is hosted.

Concluding remarks

Today we got to know the basics of Zero Trust and learned why you use Zero Trust in the first place and which components play a role. In the next TechUp I want to take a closer look at this interesting topic. We want to look at the various enterprise architecture components and consider how they are used in the Zero Trust environment or how they need to be adapted accordingly. Stay tuned!

Stefan Welsch

Stefan Welsch – Pionier, Stuntman, Mentor. Als Gründer von b-nova ist Stefan immer auf der Suche nach neuen und vielversprechenden Entwicklungsfeldern. Er ist durch und durch Pragmatiker und schreibt daher auch am liebsten Beiträge die sich möglichst nahe an 'real-world' Szenarien anlehnen.