Zero Trust Network, a security paradigm.
Zero Trust Network, in a nutshell, is a cybersecurity model that advocates for trusting nobody and authenticating everybody before granting access to any resource inside a network protected by Zero Trust Network. It is regarded to be a relatively more secure model than network security architectures of yesteryears that made extensive use of firewalls and Virtual Private Networks (VPN). At the heart of Zero Trust Network sits an intermediary authentication system or proxy that is solely responsible for allowing access to an organization’s network (or some other network protected by ZTN) to all those that need it whether they are inside or outside the network.
Moreover, perhaps the most crucial benefit of a Zero Trust Network is the incapacity of an attacker to laterally move across different services once it has access to some service inside a network. This is ensured by the inherently built security principle of ‘least privilege’ in Zero Trust Networks because of its approach of trusting nobody and authenticating everybody. This blog post contrives to highlight some of the major Zero Trust Network aspects such as: implementation methods, policies, how it differs from the traditional network architecture of organizations and lastly some shortcomings of it.
Implementation Methods
3 primary methods of implementing Zero Trust Network are identified and explained in this passage:
1. Software Defined Perimeter (SDP)
2. Micro-segmentation
3. Identity Aware Proxy (IAP)
Software Defined Perimeter (SDP) in terms of its structure is analogous to Software Defined Networks (SDN). SDP comprises three components that help achieve the noble features of a Zero Trust Network. The interaction between these 3 components is how SDP implements a Zero Trust Network. These components are:
1. SDP Client
2. SDP Controller
3. SDP Gateway
The roles performed by these three components are as follows:
1. SDP client is an endpoint device that is trying to access a resource inside a network protected by SDP.
2. SDP Gateway can be thought of as the main entrance and only entrance to a network protected by SDP.
3. SDP Controller is the component that orchestrates the interaction between the SDP Gateway and SDP client. SDP Controller is where most of the SDP logic is configured.
The interaction between the three components can be roughly broken down to 5 steps. In the following scenario we have an SDP client that wants to access a resource in an organization’s network protected by SDP. These steps are further illustrated in figure 1 below followed by an explanation of all the steps.
1. Clients will not be able to directly make a connection with the SDP Gateway. Instead, they must send a Single Packet Authorization (SPA) to the SDP Controller. Along with SPA they also need to send an encrypted key which is used by the Controller to authenticate the Client.
2. Based on the encrypted key that the SDP Controller receives it then establishes a TLS connection using PKI between itself and the Client. This connection is only established if the client is listed as a ‘secure client’ inside the SDP Controller’s database. A client is deemed secured with respect to both user and device authentication.
3. Should the client be deemed to be a ‘secure client’, SDP controllers would notify the SDP Gateway through a SPA packet about granting access to the particular client into the organization’s network. This communication between the Gateway and Controller also happens via a TLS connection with cryptographic keys being exchanged to ensure authenticity. Typically, the Controller sends the secure client’s IP address to the Gateway to grant access.
4. Once the Gateway receives the above packet it enables the Client to establish a connection with the Gateway through a TLS connection. The Client now has access to only the resource it requested initially in Step 1.
5. During the ongoing connection between the Gateway and the Client, the Controller periodically receives authentication information from both Gateway and Client. If at any moment client’s authentication is compromised, the connection between the Client and Gateway (which gives access to a resource inside the organization’s network) is aborted immediately by the Controller.
Micro-segmentation is another method to implement Zero Trust Networks. Although, Micro-segmentation by itself is not a new concept in the networking industry, it is however relatively new in the cybersecurity domain. It helps in implementing Zero Trust Networks by applying network security on a granular level instead of applying a blanket solution over an organization’s network.
More precisely, Micro-segmentation advocates for defining network policies for each segment in an organization’s network instead of the traditional perimeter approach used by firewalls. These policies can be nested with other policies inside the network to create more complex policies. What is crucial in Micro-segmentation is to not only create policies for network connections from outside the organization’s network through the Internet but also create policies for connections from within the internal network of an organization. Subsequently, this nested network structure will end up providing granular security to each individual component of an organization’s network from both external and internal connections.
Micro-segmentation coupled with a ‘Single Sign-On’ (SSO) authentication system, provides a complete implementation of the ‘Zero Trust Network’ paradigm. Micro-segmentation through its internal policies ensures that lateral movement within a network is not possible which as mentioned earlier is a key feature of Zero Trust Networks. SSO authentication system ensures authentication of various endpoints trying to connect into the network along with Micro-segmentation provide a complete implementation of a Zero Trust Network.
Identity Aware Proxy (IAP) is another method by which a Zero Trust Network can be implemented. IAP, as the name suggests, is a proxy that provides network access to users that have the right to access that network, it facilitates identification and authentication of users along with providing access to the network. IAP typically operates in a cloud environment and thereby it has the inherent advantages that come with cloud native services such as scalability and mobility for instance.
IAP operates in a similar approach to that of Software Defined Perimeter (SDP) that was discussed earlier in this blog. Aspects such as device and user authentication are handled by a centralized IAP resource. Along with getting access to a resource in the network, the user also gets a set of permissions which limit the user’s ability to laterally move onto other resources in the network. All the above aspects are implemented in a similar manner to SDP using a centralized resource that handles the above aspects. Where it differs from SDP is in how communication between a user outside the network and a resource in the network occurs. In IAP, users communicate with a resource in the network via a proxy to mediate the communication. On the contrary, SDP uses a tunneled communication between the authenticated user and a resource in the network.
Furthermore, IAP operates at the application layer, all communication between an authenticated user and a resource happens over HTTPS. Application layer provides additional flexibility in defining permissions and rules to a user as the rules are not restricted to just basic TCP or IP header fields such as IP addresses and port numbers. Rules defined in the application layer can be more specific and dynamic with regards to how a service in the network may be accessed by the authenticated user.
Approach towards Zero Trust
Here is a brief overview about the major stages that help us navigate while implementing a Zero Trust network. We recommend that the reader implore more on these to understand their significance.
- Define Your Protect Surface: Begin by identifying what exactly it is that we need to protect
- Map the Transaction Flows: Understand the system and how it system works together
- Architect the Environment: Enable setting up of micro-perimeter bases by placing the controls as close as possible to the underlying unit that needs to be protected.
- Create the Zero Trust Policies
- Monitor and Maintain the Environment: We need to craft a feedback loop of information so as to gauge our effectiveness by gathering telemetry, deploying machine learning and analytics, and automate responses in our policies.
While all the 5 stages are equally important lets jump into stage 4 and attempt to grasp and understand how zero trust policy might actually look like.
Policies
The Kipling Method
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
-Rudyard Kipling, Just So Stories, 1902
For any credible journalistic piece, the writer needs to cover the “who, what, where, when, why and how” of the topic. Without covering these things, the reader is left with a partial story and would prove to be ineffective in conveying its purpose and significance essentially missing out on its key objective.
Interestingly the Kipling method can also be extended to implementing effective zero trust policies and brings forth three important aspects:
- Security teams are thorough in their definitions.
- Anyone can understand these cybersecurity policies aided by its simplicity.
- Ensure it aligns with business objectives.
Real Zero trust architecture is crafted through careful consideration of the Kipling method to apply policies on layer 7 technology. This is in stark contrast to our firewall rules which are most often limited to layer 3.
Lets understand their differences
At Layer 3 our evaluation is performed based only on IP address, port or protocol, it is therefore oblivious to the following facts:
- IP addresses can be spoofed and therefore just relying on it would be a flawed approach for imposing restrictions.
- Simple port scans can help uncover open ports which are often used for exfiltration of sensitive data
- Methods to bypass layer 3 controls are well studied, documented and therefore it is reasonable to assume that our adversaries are well aware of them.
Layer 7 provides a lot more context for our network traffic and helps us make better informed policies. For instance traffic at port 80,443 is not just understood in terms of protocol (http/https) but now we can differentiate them based on their associated application which the external user has accessed and these policies often work with other segments of controls which requires these contextual identifiers.
WHO
“Who is accessing a resource?”
The user identifier tag can be derived through a mix of operations leveraging various data points including the source IP address, host information profile and multi factor authentication.
WHAT
“What application is being used to access the resource?”
Application identification serves as the user agent through which the traffic originates, this is particularly useful when we want to restrict content access through non supported interfaces or access through regular web application.
HOW
“How should the User-ID and App-ID traffic be allowed to access a resource?”
Now that we covered who the user is and what he is using to access your data we can write granular rules on how each content is to be accessed, including the rules the data has to pass over for each scenario. This is very helpful in filtering and delineating separate rules for sensitive resources.
WHEN
Time delineated rules would be apply here, like suppose you would want to restrict access to certain resources along a set of specific working hours of your geographic time zone
WHERE
WHERE statement usually imposes restrictions based on the location of the resource that is being accessed. Some resources such as confidential corporate documents or sensitive government data can be restricted based on where the data is being held.
WHY
WHY statement often appears oblivious to us, but the metadata from some data classification tool could be exploited to understand or reason the full context behind this action and we can use that in the rules to restrict access and controls.
A rule that covers all 6 aspects of queries would provide us with an unique new found opportunity extended by Zero Trust systems to enact a super refined control over our resources. That being said not every policy has to cover all 6 aspects of Kipling method, for some it makes contextual sense to include them for attaining more fine grained granularity of control over resources and impose access controls and that’s why for some rules they cover select few of them.
Here are a few key excerpts from the inventor of Zero Trust himself which are to be considered as we approach towards its implementation:
- Zero Trust is incremental. It is built out one protect surface at a time so that it is done in an iterative and non-disruptive manner.
- Starting with creating zero-trust networks for the least sensitive/critical protected surfaces first (to learn, practice and make less disruptive mistakes), and then slowly working one’s way towards implementing Zero Trust for the more and the most critical ones.
- While designing zero-trust networks, organizations should focus on the business outcomes, make sure to design from the inside out and properly determine who needs to have access to a resource, and inspect and log all traffic at Layer 7 so that a Layer 7 Policy Statement can be defined.
Traditional vs Zero Trust Network
Zero trust is a recent practice and to understand the difference between the old practices and zero trust we are going to define three different trust models and understand the average network reachability of the threat actors in each model. It is believed that if you cannot reach the server you cannot hack it and this phenomenon of reachability is what we are going to test with our models.
In all the models we are going to assume that we will work with 12 Virtual Machines, this just helps keep the network reachability numbers nice and small. As indicated in the Figure 2 to Figure 4, we have divided the setup into three tires WebServices (Web), Application (App) and Databases (Db). We are going to look at the reachability of each of these services from different threat actors. This gives us the empirical way of testing the different security models. There will be 3 different kinds of threat actors which are commonly observed in an attack.
External Threat Actor (ETA): This actors is someone outside the organization i.e., on the Internet.
Internal Threat Actor (ITA): This actor is someone within the trust boundary or inside the network of the organization.
Server Threat Actor (STA): This actor is someone who has managed to gain access to any server within the network.
The 3 models we will be demonstrating in our blog is to understand their difference from a security standpoint are as follows:
Single Trust Boundary Network
As the name implies it has only one layer of trust. This model is similar to most of the environments we work with today. The control boundary is protected by a number of firewalls or entry points to the network. These firewalls control the access from outside of the trust boundary to inside the trust boundary.
If an External threat actor tries to access the services (Figure2A), it has to make its way through the firewall into the network (we don’t assume breaching the firewall). For External actors, on an average, organizations only expose less than 20% of its services. ETA, lets say, can land onto 2 of the Virtual Machines (Web1 and Web2), which amounts to 16% risk (see Table1).
On the other hand if the threat actor is sitting within the network (ITA, Figure2B), this generally happens if internal computer gets compromised by delivering a piece of malware to a machine via email or potentially a weblink that is run by a member of staff and the ETA suddenly have a internal placeholder in the network. In a single trust model the ITA can now reach all 12 Virtual Machines in the network which makes the network 100% compromised (see Table1).
The important point to observe here is, the migration from an external point to within the network through the trust boundary has massively increased the threat reachability from 16% to 100% (see Table1).
In the last scenario, where the threat actor is sitting on the compromised server (let’s say Web1, Figure2C). In this model we have the same account of reachability i.e 100% (see Table1).
Traditionally a single trust boundary was the most common way of providing network security and segmentation. This model only stand out to the external threat actor (16%), if the threat actor manages to enter the internal network, the whole system falls down which is a cause of concern.
Dual Trust Boundary Network
Similarly to the first model it has the same exterior trust boundary but in addition it also has the internal layer. The internal layer is the difference between the Single trust model and DUAL trust model and it sits between the campus networking where all the VM’s are placed and the external layer.
In figure 3, you can observe that the internal layer is protected by ADC’s (Application delivery Controllers) which in simple terms are load balancers. ADC’s have a number of very useful security characteristics like it is a default deny device which means that they won’t pass traffic if it is not setup on them. Second, it is a full TCP proxy implies that the client cannot talk directly to the server, it passes through the ADC’s and then ADC’s repeats that message to the server.
If we test this model with our first scenario of External Threat Actor (Figure3A), they need to pass through the first security boundary as in the first model and then through the second security boundary via ADC’s. In terms of reachability nothing actually has changed in this scenario. ETA, can land onto either of the two VM’s therefore, the risk remains 16%, as the machines that were available in the previous model are still available.
Now when the ETA migrates to the internal network (ITA, Figure 3B), differently from the previous model ITA now has to pass through the internal security layer which does not give it the whole access. In this scenario we are taking advantage of ADC’s. As we have got three different tiers Web, App and DB, only one of those tires need to be accessible to the internal users and they can access their services. So we will only setup to pass the traffic in ADC for Web tier and as it is a default deny device, if the access request for Application and DB tier is witnessed it will be automatically dropped. So now only 3 VM’s of Web tier are visible and accessible. The threat reachability risk in this scenario is dropped to 25% only which is a massive accomplishment in comparison to the previous model.
In the final scenario where the threat actor is sitting on one of the servers (Figure3C), the threat reachability risk is 100%. In case if the server is compromised the whole system collapses as there is no security boundary between the servers.
Zero Trust Network
This is the recommended approach for network security models. This model inherits all the features that previously discussed two approaches have to offer and in addition to it this model has segmentation within the internal security zone (Figure 4). This segmentation separates the servers from each other
If we test our first scenario with an External Threat actor (Figure 4A), it passes through the firewall and the external layer into the second layer, then hits the ADC’s which only presents the Webservices which are setup on them. So exactly as the previous two models we have threat reachability at 16%.
In second test scenario, the internal threat actor sits on the network (Figure4B) and as seen in the previously, it will pass through the second security layer, hits on the ADC’s and only the web tire is accessible, so ADC’s will only pass traffic to the top three servers, therefore, threat reachability in this scenario is also 25% (see Table 1).
Now, finally lets see how the model stands up against the internally compromised server (STA, Figure 4C). Compared to the DUAL trust model, we have network segmentation or internal layers of trust boundaries in place, therefore we can now control the access of each virtual machine. As web tires only needs to access the application tire, that is the only place the server threat actor can navigate. The threat actor can now only access one further virtual machine due to segmentation in place which drops the threat reachability massively to only 8.3% (Table 1).
In all the scenarios we observe that the Zero trust model can essentially build an environment that resists all types of attacks no matter where the threat actors are located. This is the sole reason we think this is the best way organizations should go about defending their infrastructure.
Demerits of Zero trust network
“With great power comes great responsibility”
It’s important to note the various deterrents that are considered as major hurdles for zero trust networks to go mainstream.
1. Increased complexity
The effort and time required to enact a zero trust network is intense and tiring, forcing us to list and cover all possible forms of communications at a granular level of the micro perimeter with which we approach our implementation. This could take a lot of time especially in a complex large scale organization who has a wide gamut of underlying resources to safeguard.
2. Configuration challenges
Since the policy is enforced at each local unit we are now inundated with a plethora of devices or perimeters to configure individually, this is especially significant as today most organizations depend upon multiple cloud platforms. What’s worse is that any minor error in configuration would result in a catastrophic impact (impacting availability) and might even compromise the security that we are trying hard to enforce.
3. Decentralized maintenance
Unlike the old brick and mortar network security which provides a much more centralized view and control, we now have to deal with a cluster of independently managed systems or perimeters to protect our resources. While this proves to be more adaptable it also comes with the disadvantage of not being able to provide a centralized view of the security configurations. This would eventually lead to increased difficulty if we have a single centralized team to monitor and track the system behavior while debugging issues. Overall it’s much harder to manage without increasing and splitting the security teams with each dedicatedly managing its own domain. It might require dedicated security specialists and could potentially lead to higher cost for implementation and maintenance.
Conclusion
“The Zero Trust model enforces that only the right people or resources have the right access to the right data and services, from the right device, under the right circumstances” — Bill Harrod
Corporate security has long relied on the traditional method of corporate networking where we clearly define a boundary demarking internal and external systems and also anything and anyone on the corporate network are inherently trusted. However the underlying trust is a source of major vulnerability that has often proven to be exploited with the scourge of attacks, it highlights one of the mighty issues with digital security itself — the attackers only have to win once while the defenders have to cover all grounds. Zero trust network is an approach that seeks to address this vulnerability by attempting to eliminate this innate trust qualifier and by splitting our internal systems into modular perimeters whose security are independently managed thereby granting more granularity of control over our resources. Despite its challenges the early results have proven it to be effective with large scale organizations like Microsoft embracing it through multiple stages of rollout its adoption has recently gained traction and is expected to continue and gather more followers in the years to come.
