Zero Trust Network Access (ZTNA)

The cybersecurity landscape has changed dramatically over the last few years. The move to the cloud, plus the uptake of mobile devices to access corporate IT systems and applications, as well as the explosion of the Internet of Things (IoT) have upended the traditional cybersecurity posture of most organizations. Gone are the days of merely authenticating a client or user access request at the network perimeter, and upon successful authentication granting access to the systems and applications they have the permissions to use, along with free run on the internal network. Access can come from any device, and the connection can go to an application anywhere in the cloud. This means that the ability to trust the connection has eroded. The concept of zero trust has emerged as a way of tackling this new reality.

What is Zero Trust?

At a basic level, the concept of zero trust is simple: assume every connection is potentially hostile no matter where the connection originates. For example, a request to access an application that comes from within the network perimeter is deemed to be no different from one that originates on the Internet. Both need the same level of scrutiny, and they need to provide the right authentication responses before access is allowed. The same is true for every access request to any IT system. No connection is assumed to be safe based on where it originates. It moves beyond the traditional model of securing the perimeter. Some key principles underpin zero trust:

• Least privileged access is used for all entities on the network (users, devices, software systems, other processes). Nothing is given privileged access beyond the minimum needed for the task in hand, and the authorization they have is limited to that session. Access in the future has to be requested again from scratch.
• Applications need to be micro-segmented so that each has to be authenticated separately, and authorizations need to be application-specific. (Note that this is different from network segmentation).
• The network needs to be dark. Applications and servers should not advertise on the network but rather any user or device that needs to access them should be configured to know of their existence. Not advertising means that any unauthorized users on the network can't see what is available, and can't try to gain access.
• Multiple encrypted micro-tunnels are used over the Internet and private networks to facilitate secure connections to specific applications.

What is Zero Trust Network Access (ZTNA)?

ZTNA is the framework that delivers on the concept of zero trust. It is also sometimes referred to as creating a software-defined perimeter (SDP). Multiple vendors implement ZTNA via solutions that deliver an adaptive trust security model. As outlined above, trust is never assumed for any user, device, connection end-point or workflow in use. Access is granted to systems and applications on a per case, least privilege basis using granular access policies. Many vendors choose to implement ZTNA solutions in different ways, often building on existing authentication and authorization solutions they provide. ZTNA solutions work differently from edge-based security solutions such as VPN gateways and firewalls. The architecture of ZTNA provides access to applications using the following principles that implement the zero-trust philosophy:

• Application access provision is entirely abstracted from network access and authentication. The underlying network is invisible to users and devices. They get connections to specific applications. This means that any compromised connection cannot access any other applications or servers.
• The IP addresses of resources on a ZTNA based infrastructure are never advertised on the Internet. This means that the applications are on a private darknet and are invisible to cybercriminals browsing for vulnerabilities.
• Application micro-segmentation means that access is granted for each application separately. There is no cross-application authorization. If more than one application needs to be used, then separate connections need to be made. Note that this doesn't stop application servers communicating with each other. Just that such communication needs to request and use individual access requests and authentication just like users and devices do.
• Granted access is valid only for the duration of that connection. Once a session is disconnected, it can't be used again. A new access request needs to be made and authenticated each time access is required.

Two conceptual models for initiating sessions between end-user devices and applications have emerged within solutions delivering ZTNA. An Endpoint-Initiated approach, plus a Service-Initiated approach. Some vendors solutions offer both options. Endpoint-Initiated ZTNA solutions closely follow the SDP specification created by the Cloud Security Alliance (CSA). The diagram below outlines the Endpoint- Initiated approach.

 

Authorized end-user devices have an agent installed that sends authentication requests to a ZTNA Controller. The controller authenticates the user device with an authentication service and then returns an allowed list of applications to the client device. The controller then informs the ZTNA Gateway that the user device is allowed, and provisions access from the device to the Gateway. The Gateway then provides access to the application the user wants to use. In this model, no applications are provisioned with direct Internet access. This means they are protected from Denial of Service (DoS) attacks that they would be vulnerable to if placed in a DMZ. The Service- Initiated approach to ZTNA is shown in the following diagram.

In this approach, an ‘inside-out’ model is used. A ZTNA Controller on the same network as the applications that are to be provisioned creates an outbound connection with the registered applications shared ta a ZTNA Broker/Proxy. This Broker can be on a different network and is often located in a public cloud service. End-user devices send requests to the Broker, which then authenticates them on the authentication service in use. Upon successful authentication, the end-user device and Broker establish a session to the application that needs to be accessed. The service-initiated model is useful as it does not require an agent to be installed on the end-user devices, which can be problematic in some scenarios, like BYOD or access from smartphones. However, a downside of some implementations is that applications have to be based on HTTPS, or a protocol and can be encapsulated in HTTPS. ZTNA solutions are often deployed along with Privileged Access Management (PAM) tools as part of a comprehensive Identity and Authentication solution (IAM) that is governed by a set of policies and procedures that make up an organizations Identity Access Governance (IAG) policy. Deception technologies are often also deployed to provide artificial dummy applications and systems to act as honey-traps for malicious actors who may be attempting to compromise the network.

 

ZTNA Use Cases

Here are some typical use cases for ZTNA solution deployment. This is for illustrative purposes only and is not an exhaustive list.

• Replacement of VPNs for remote access. Gartner predicts that by 2023 approximately 60% of enterprises will have switched from VPN to ZTNA to deliver remote access to applications for users and clients.
• Make it easier to use applications spread over multiple clouds and in hybrid-cloud deployments. ZTNA provides access to the application, and the users don't need to know where it is. They simply connect and authenticate.
• Provide secure access for third-parties to applications needed for B2B interactions. Remote access to the network is not provided via ZTNA. Just publish the applications that third parties need to use.
• Enhance security using device profiles. If a device for a user, who doesn't often travel, tries to access applications from somewhere they shouldn't be, then access can be blocked.
• Enable BYOD access policies securely by allowing access to specific applications by users who can be authenticated from any device using some trusted method other than Device ID.
• Segment application access for IoT devices. Ensuring they can access just the applications they need to store and process sensor data. This is often used in conjunction with Edge Computing services to reduce network traffic flow.
• Extend application to device encryption even over networks that you have no control over or don't trust. For example, home Wi-Fi on domestic broadband connections as people work from home. The ZTNA pipe established between a device and an application can be encrypted end-to-end.
• Reduce insider threats as applications do not advertise their presence or services. Only those who need to know are aware of them. So disgruntled or malicious insiders who don't know about the systems can't attempt to access them. Often used in conjunction with Deception Technologies.
• Make it easier to collaborate or merge with other organizations. Any need to grant access to users outside the organization on short notice is as simple as giving them access to the published applications. There is no need to provide them with any information about the underlying network.