The H.A.C.K.E.R. Project

“How do you know who is trustworthy?” is a very important question to consider in the realm of cybersecurity and network management. When establishing the framework of an organization’s network, it is almost always a given that entities outside of the organization cannot be considered completely trustworthy, and sometimes the assumption is made that all members of the organization can be trusted. Unfortunately, this is unrealistic; all it takes is one disgruntled employee to cause a cybersecurity incident.

If that is the case, then how can one make sure a network is secure? For starters, the Principle of Least Privilege is a great way to manage user permissions to minimize the possibility of a cyber threat from within an organization’s network, but this is only one step on the path of network security. Beyond user permission management, it is also important to consider network access as a whole. There are various models and services available that help to manage and secure network access, and one such model is known as Zero Trust Network Access (ZTNA). Zero Trust Network Access, is, foundationally, “an IT security model that assumes threats are present both inside and outside a network” (Cloudflare).

What is ZTNA?

Generally, ZTNA works by “[removing] implicit trust to restrict network movement and reduce attack surfaces” (Cisco). With the ZTNA framework, nobody- or, more specifically, no device or account- is considered trustworthy by default, including company employees and management. To gain access to a network that uses the ZTNA framework, users and devices must be verified and are only trusted after this verification (Fortinet). This is especially useful for remote workers, since ZTNA “provides secure remote access to applications and services based on defined access control policies” (Palo Alto).

In a sense, ZTNA divides up a network into its individual applications and services and either grants or denies permissions to these parts of the network to individual users. This works by “[hiding] apps and services from discovery and [authorizing] access only to specific applications” (Cisco). Importantly, “ZTNA connections need to be re-verified and recreated periodically” (Cloudflare). This ensures that a user’s permissions and level of access is always up-to-date and minimizes the possibility of already-verified accounts being utilized for malicious activity.

Cloudflare provides a wonderful, real-world example to explain how ZTNA works.

Imagine a scenario in which every resident gets a phone book with the phone numbers of every other resident of their city, and anyone can dial any number to contact any other person. Now imagine a scenario in which everyone has an unlisted phone number and one resident has to know another resident’s phone number in order to call them. This second scenario offers a few advantages: no unwanted calls, no accidental calls to the wrong person, and no risk of unscrupulous persons using the city’s phone book to fool or scam the residents.

Cloudflare

The first scenario represents an organization’s network without using a framework such as ZTNA; the phone book is, essentially, the organization’s network, and each phone number is a different application or service on that network. The second scenario with the unlisted phone numbers represents an organization’s network that uses a framework such as ZTNA. If a person (a user) does not have a person’s phone number (the need to access to an application), then they cannot call them (they cannot use that application).

While each organization may have their own specific policies or configurations in place for ZTNA, Cloudflare has identified the following principles that “remain consistent across ZTNA architectures”:

• Application vs. network access: ZTNA treats application access separately from network access. Connecting to a network does not automatically grant a user the right to access an application.
• Hidden IP addresses: ZTNA does not expose IP addresses to the network. The rest of the network remains invisible to connected devices, except for the application or service they are connected to.
• Device security: ZTNA can incorporate the risk and security posture of devices as factors in access decisions. It does this by running software on the device itself … or by analyzing network traffic to and from the device.
• Additional factors: Unlike traditional access control, which only grants access based on user identity and role, ZTNA can evaluate risks associated with additional factors like user location, timing and frequency of requests, the apps and data being requested, and more. A user could sign in to a network or application, but if their device is not trusted, access is denied.
• No MPLS: ZTNA uses encrypted Internet connections over TLS instead of MPLS-based WAN connections. Traditional corporate networks are built on private MPLS connections. ZTNA is built on the public Internet instead, using TLS encryption to keep network traffic private. ZTNA sets up small encrypted tunnels between a user and an application, as opposed to connecting a user to a larger network.
• IdP and SSO: Most ZTNA solutions integrate with separate identity providers (IdPs), single sign-on (SSO) platforms, or both. SSO allows users to authenticate identity for all applications; the IdP stores user identity and determines associated user privileges.
• Agent vs. service: ZTNA can either use an endpoint agent or be based in the cloud.

Cloudflare

Fortinet, a well-known cybersecurity and networking company, produced the following video that goes over the general concept of ZTNA, using their products as an example:

In addition, Palo Alto Networks, another well-known networking and cybersecurity company, produced a video covering ZTNA as it applies to their product, Prisma Access:

Note: This article was not sponsored by either of the above products. These videos were simply provided as examples to showcase the common features/abilities of ZTNA tools.

How Does ZTNA Increase Security?

One notable benefit of incorporating ZTNA is an increase in data security. Generally, ZTNA “protects data by: granting role-based, least-privileged access[,] setting perimeters around assets and controls network flow[, and] hiding applications from the public internet” (Cisco). Each of these steps limits the amount of data that any given user can access, which greatly decreases the damage a threat can pose. For example, say a hacker were able to gain access to an employee’s account within an organization. If that employee only works with storing product serial numbers into various databases, then all that hacker will likely be able to access would be product serial number data (which, while still detrimental, is arguably less detrimental than having access to company financial data). In addition, “[by] not allowing access to an entire network, ZTNA lowers the impact of a breach, reduces business visibility on the public internet, and minimizes security risk” (Cisco).

Furthermore, once a user and their device have been verified and granted access, ZTNA “then provisions access to the application on the user’s behalf through a secure, encrypted tunnel” which “provides an added layer of protection for corporate applications and services by shielding otherwise publicly visible IP addresses” (Palo Alto). ZTNA, in a sense, provides access directly to the application itself instead of to the network that the application resides on. While this may sound similar to Virtual Private Network (VPN) technology, there is a crucial difference: A VPN grants “complete access to a LAN”, while “ZTNA solutions default to deny, providing only the access to services the user has been explicitly granted” instead of a wider network (Palo Alto). Defaulting to denial means that, unless a user and their device pass all of the necessary checks- and continue to pass these checks on a routine basis- of the ZTNA software, the user will be unable to access the desired applications or services.

Palo Alto goes on to describe other key differences between ZTNA and VPN setups:

Identity-based authentication and access control found in ZTNA services provide an alternative to IP-based access control typically used with most VPN configurations which help to reduce an organization’s attack surface. ZTNA also allows organizations to implement location or device-specific access control policies to prevent unpatched or vulnerable devices from connecting to corporate services. This alleviates common VPN-related challenges where BYOD remote users are granted the same level of access as users at a corporate office, despite the fact that they often have fewer security controls in place.

Palo Alto

Thus, it may be worthwhile for organizations to upgrade to using ZTNA in place of a standard VPN in order to gain these security benefits. After all, there is no such thing as being too secure. Finally, as a relatively new framework of technology, ZTNA will likely continue to grow and evolve as new threats and techniques are discovered, which can make it an adaptable and versatile solution.

Resources & Further Reading

Cisco. “What Is Zero Trust Network Access?” Cisco, Cisco Systems, Inc., www.cisco.com/c/en/us/products/security/zero-trust-network-access.html.

Cloudflare. “What Is Zero Trust Network Access (ZTNA)?” Cloudflare, Cloudflare, Inc., www.cloudflare.com/learning/access-management/what-is-ztna/.

Fortinet. “Zero Trust Network Access (ZTNA) to Control Application Access.” Fortinet, Fortinet, Inc., www.fortinet.com/solutions/enterprise-midsize-business/network-access/application-access.

Palo Alto. “What Is Zero Trust Network Access (ZTNA).” Palo Alto Networks, Palo Alto Networks, www.paloaltonetworks.com/cyberpedia/what-is-zero-trust-network-access-ztna.