Zero trust architecture (ZTA) provides us with tools and principles to increase security in enterprise networks. This effort becomes especially relevant nowadays with the increase in cybersecurity threats and attacks.
A zero trust architecture assumes that an attacker is always present in the network and therefore, access to every resource is denied by default until the user/device proves that can have access to the specific resource.
Notice that this is not the usual approach in network security. Usually, when a device is connected to the internal network, being physically inside the enterprise, is considered trusted. This is a big flaw in cybersecurity. It is what a zero trust architecture addresses.
“A zero trust architecture (ZTA) is an enterprise cybersecurity architecture that is based on zero trust principles and designed to prevent data breaches and limit internal lateral movement.” Source.
A zero trust architecture is an iterative process. You don’t need to start designing the whole network with zero trust. You can start with some of the processes of the enterprise, even only one process, and then iterate until you get the desired level of zero trust in the organization.
Below, are 5 steps path you can take to implement a zero trust architecture.
How do you build a zero-trust architecture?
You can follow the 5 steps reference architecture to implement a zero trust architecture
5 steps reference architecture to a zero trust architecture
In the first step, you will define the protect surface. These are the enterprise resources that need to be protected. They can be data, systems, devices, etc.
The second step deals with the processes within the enterprise. What are the usual use cases that involve the resources identified in the protect surface? If a user wants to access protected data, what is the process? Authentication and authorization? How does it happen within the organization? At this point, it is of utmost importance that cybersecurity personnel understand the business processes.
Then, we proceed to the network architecture. For this, you can use a reference architecture. Also, a next-generation firewall is usually used to enforce granular permissions at layer 7 of the OSI model.
The zero trust policy defines the rules that need to be checked before giving access to a certain resource within the enterprise network.
The last step states that the network must be monitored regularly. One aspect to monitor should be user behavior information. This can help to identify anomalies and prevent security issues.
The implementation of a zero trust architecture does not contradict most of the security measures already in place. You can keep those controls on certain resources as part of the zero trust architecture.
Below, I’ll summarize the NIST zero trust architecture.
What are the components of a zero-trust architecture?
NIST recommends the following Zero trust logical components.
From the figure above, you can see that there are two control planes. The upper control plane is dedicated to the policy engine and the policy administrator. While the lower control plane is dedicated to data.
One of the 7 tenets of the NIST ZTA is “All resource authentication and authorization are dynamic and strictly enforced before access is allowed”. This means that user trust is established first at the Control Plane level. Only after authentication and authorization is done, the user will be able to access the Data Plane.
The policy engine is the component that will decide whether to grant access to a certain resource or not. This is the component that will enforce the enterprise policy. This component also uses external components, like threat intelligence, to make decisions. Also, it will keep records of all the decisions. This can be used later for monitoring and analytics purposes.
The policy administrator is the component tasked with the execution of the decisions made by the policy engine. It can establish or shut down connections, but always according to the decision made by the policy engine.
Lastly, we have the policy enforcement point. This component enables, monitor, and terminate the connections between a client and an enterprise resource.
The previous components are considered the core components in a zero trust architecture. In addition, other systems provide input to the architecture as you can see in the figure above:
- CDM: continuous diagnostic and mitigation system.
- Industry compliance systems.
- Thread intelligence systems.
- Activity logs.
- Data access policy.
- PKI: public key infrastructure.
- ID management system.
- Security information and event management (SIEM) system.
Approaches to implementing a zero trust architecture
Different approaches can be followed to implement a zero trust architecture. Let’s take a look at some of them.
Enhanced identity governance approach: When you follow this approach, the policies to access the enterprise resources are based on the identity of the subject and its assigned attributes. As an example, an Identity Access Management (IAM) System can be used to define access to specific resources by using policies. Most cloud providers offer this service. You can find here the one that Google Cloud offers.
Micro-Segmentation approach: In this case, the organization might choose to place certain resources in a specific network segment. The access then will be protected by a security gateway. Examples of controls are intelligent routers, next-generation firewalls, or special-purpose gateway devices that act as a policy enforcement point (see the core zero trust logical component figure).
Network Infrastructure and Software-Defined Perimeters: In this case, the policy administrator acts as the network controller that sets up and reconfigures the network based on the decisions made by the policy engine. The clients continue to request access via policy enforcement points, which are managed by the policy administrator component.
Threats associated with a zero trust architecture
As with any type of infrastructure, there are threats that we should consider.
A zero trust architecture will reduce overall cybersecurity risks. However, some specific threats can have an impact on our newly security architecture:
- Subversion of ZTA Decision Process: A network administrator with access to the Policy Engine and the Policy Administrator can introduce unapproved policy changes and/or make mistakes in the configuration of approved policies. To mitigate this threat, we must ensure that the Policy Engine and Policy Administrator are correctly configured and monitored.
- Denial-of-Service or Network Disruption: If an attacker manages to deny access to the Policy Administrator, Policy Engine, or Policy Enforcement Point, the services of the whole enterprise can be disrupted. To mitigate this threat, the enterprise should secure the previously mentioned services by way of secured cloud environments or replicating the components to provide service resilience.
- Stolen Credentials/Insider Threat: Phishing, social engineering, etc. can be used to steal credentials. An attacker can get access to the resources associated with the account credentials that the attacker stole. However, the zero trust architecture will prevent lateral movements. Any different pattern than the usual one on the compromised account will be stopped as access denial is the default behavior in this type of architecture.
- Visibility on the Network: Certain traffic originating from a device that doesn’t belong to the enterprise might be resistant to passive monitoring. If the traffic is encrypted, the traffic itself cannot be analyzed by the tools deployed. However, the metadata of that traffic can be analyzed to find possible attacks.
- Storage of System and Network Information: The data that is stored for monitoring purposes can become a target for attackers. Adequate protections should be in place to prevent unauthorized access to this information.
- Reliance on Proprietary Data Formats or Solutions: If a provider of a data source has a security disruption, it will affect the enterprise services. This type of issue can affect the core business of the enterprise. “To mitigate associated risks, enterprises should evaluate service providers on a holistic basis by considering factors such as vendor security controls, enterprise switching costs, and supply chain risk management in addition to more typical factors such as performance, stability, etc.” Source.
- Use of Non-person Entities (NPE) in ZTA Administration: False positives and false negatives are an open issue in using automated systems in ZTA. So, tuning analysis aimed to correct mistakes should be performed regularly.
3 Vendors that offer zero trust architecture products
Find below 3 of the vendors providing zero trust products:
There are many more.