What is Zero Trust Security?

Learning Objectives

Understand fundamental security concepts.

• Zero Trust
  • Control Plane
    • Adaptive identity
    • Threat scope reduction
    • Policy-driven access control
    • Policy Administrator
    • Policy Engine
  • Data Plane
    • Implicit trust zones
    • Subject/System
    • Policy Enforcement Point

What is the Zero Trust?

Traditional security models follow a "moat and castle" or "trust but verify" design, this means to verify users at the perimeter of the network and then trust them completely once they are inside. This allows authorised users within the network to operate freely with minimal security checks but also allows unauthorised users to do the same. Therefore this model is increasingly proving to be inadequate in the face of sophisticated cyber threats.

This realisation has led to the emergence of the Zero Trust security model which follows more of a "trust nothing, verify everything" design.

Zero Trust is a holistic approach to network security that assumes there is no trust boundary, such as the network perimeter, upon which users are automatically trusted once they have crossed that boundary. Therefore no entity, whether internal or external, is implicitly trusted by default. Instead each request of a system or user must be validated and is ran through a continuous authentication process before access is granted.

Planes of Operation

Zero Trust Architecture(ZTA) is logically(sometimes physically) split the into two functional planes of operation, the Control Plane and Data Plane:

Control Plane

The Control Plane is where the policies and rules for the network are set. It consists of the ZTA core components such as the Policy Enforcement Point, Policy Engine and Policy Administrator. This plane is separate from the rest of the network and is used to communicate among the ZTA core components on how to maintain, configure and control the rest of the network and it's assets.

The Control Plane also consists of 3 additional concepts:

• Adaptive Identity: Adaptive Identity applies security controls based on a range of factors and risk indicators in real-time to authenticate users and prove they are who they say they are. This can include Device configuration, User behavior, Location, IP address, Time of day and much more. If analysis of this information is deemed high risk or does not satisfy the networks policies then the Adaptive Identity system can increase the authentication requirements to make the user to provide additional forms of identification.
• Threat Scope Reduction: This concept aims to reduce the possible avenues of threat to the network both internally and externally. Examples of this would be to decrease the number of possible entry points to the network, segmenting the network on the inside and also to enforce principles of least privilege so users only have the permissions to do what they need to do and nothing more.
• Policy-Driven Access Control: This is where access to the network and its resources is driven by policies. This is a core concept for Zero Trust security as it relies on a predefined set of rules(Policies) to make the final decision for all requests on the network. Once all the information about a request is gained you can combine Adaptive Identity with these policies to decide whether access should be granted.

Data Plane

The Data Plane consists of the communication flows of subjects, assets, resources and the applications/services used for the actual purpose of the network. However these communications may not be possible before the communication channels are first established by the Control Plane. It is important to note that the Policy Enforcement Point exists in the Data Plane so it can monitor all the network traffic but also has access to the Control Plane so it can feed the information back to the other ZTA components so that they can carry out their respective roles.

The Data Plane also consists of an additional concept:

• Implicit Trust Zones: In the diagram below you can see the Implicit Trust Zone located between the Policy Enforcement Point(PEP) and the end Resource. The aim of ZTA architecture is to remove the implicit trust that is common in traditional networks, however since it does this by authenticating at the PEP it can't remove all Implicit Trust Zones completely. This is because the PEP can only authenticate at its own location along the flow of data. If there is "space" between the PEP and the requested resource then the user becomes implicitly trusted in this "space" as they have to be able to move through it to reach the resource. This is a potential risk and therefore it is important to minimise the space between the PEP and each resource and also important for these zones to only have the minimum amount of resources needed for each specific request.

Components of Zero Trust Architecture

In Figure 1. above you can see our version of NIST's Zero Trust Core Logical Components diagram. Note how all untrusted requests from a Subject/System goes through a Policy Enforcement Point(PEP), which communicates with a Policy Decision Point(PDP), before being trusted and gaining access to the requested resource. You can also see how everything is separated into the Control plane and the Data plane.

Subject/System

In the Zero Trust model this refers to the Users, Services, Processes, Systems or any other entity that requests access to a resource or attempts to use permission rights on the network. All of these requests must be validated and authorised before being granted the ability to do so.

Policy Enforcement Point (PEP)

To be able to enforce all of our policies and procedures we need something along all of various pathways of the network to enforce them. This is where the Policy Enforcement Point(PEP) comes into play.

The PEP essentially acts as a gatekeeper for all subjects that attempt to access or use the network as all traffic on the network must run through a PEP. The PEP then gathers all the information about the subject and their request and feeds it to the Policy Decision Point(PDP) to receive the final decision on whether to grant or deny the request. The PEP also actively receives other decisions from the PDP such as to end currently ongoing sessions between a subject and resource.

While this might make the PEP sound like a singular device, this is just a broad abstraction for the purpose of explaining its role. In reality there will likely be multiple PEPs made up of multiple types of devices for different sections and resources of a network. They all work together to make sure Zero Trust is enforced network wide.

Policy Decision Point (PDP)

The Policy Decision Point is made up of two logical components that make and communicate the final decision of granting or denying access to each request on the network:

1. Policy Engine(PE)

The Policy Engine is responsible for making and logging the final decision to grant or deny each request from a subject.

It does so by combining the info provided to it about the request with info from external systems such as Adaptive Identity, Threat Intel, SIEM and CDM systems as seen in the diagram above. This gathered set of info is entered into a trust algorithm that compares all the inputted factors alongside any predefined set of rules or policies to decide if the subject and their request should be trusted or not.

Once a decision is made it is logged by the Policy Engine and sent to the Policy Administrator to be executed.

2. Policy Administrator(PA)

Once the final decision is made and logged by the Policy Engine, the Policy Administrator is the component responsible for establishing or ending the communication path between the subject and requested resource based on that decision.

In the case of granting access it does so by generating any authentication tokens or credentials needed to access the resource and then configuring the relevant Policy Enforcement Point to pass these onto the subject to allow the session to start.

In the case of the request being denied or previous approval being revoked, the Policy Administrator would be responsible for commanding the Policy Enforcement Point to deny the subjects request and/or ending any session that is currently on-going.

The Policy Administrator also manages all communication and sharing of information between the Policy Engine and the Policy Enforcement Point.

How does it all work together?

Let's take a look at a basic example of how it would all come together:

1. Subject makes a request: It starts with a subject or system making a request to try and gain access from an untrusted zone. This is done over the data plane and goes through the Policy Enforcement Point(PEP).
2. Gathering info: If there is a policy enforcement that needs to take place then the PEP will gather the information provided from the subject but also additional information from adaptive identity systems. It will then provide all of this information to the Policy Decision Point in the control plane.
3. Making the decision: The Policy Administrator receives the information from the PEP and then communicates this to the Policy Engine. The Policy Engine will then combine this information with external data streams and predefined policies. This information will be entered into a trust algorithm which will make the final decision on whether this traffic is allowed and log the final result.
4. Enforcing the decision: This decision will then be be passed back from the Policy Engine to the Policy Administrator which will then communicate it to the Policy Enforcement Point along with any required credentials who will apply the decision of allowing or denying the traffic.
5. Repeat: This process is then repeated for every single request on the network.