How ZTNA protects against internal network threats

Verify first, trust second

At its core, zero trust means zero implicit trust -- a node in a zero-trust environment doesn't automatically trust anything that tries to contact it on the network. It always authenticates the other party in a connection and checks that communication remains authorized. This is true whether the other party is inside or outside the enterprise network.

Hackers can compromise nodes inside a network and use them to launch lateral attacks. They can go as far as to define what it means to be inside a network, and this can create issues in a modern, cloud-enabled, remote access enterprise.

It's straightforward to expand zero trust beyond remote access at the user level in many environments. Network professionals can channel access for all users through the same access management system that controls remote access. ZTNA's remote access capability operates as always-on, which means it consistently authenticates devices on a network. This feature makes for consistent UX, regardless of if users work remotely or in a company office.

It's much more difficult to expand ZTNA to data center networks and company LANs, however. In a zero-trust network, implicit trust doesn't extend to any network segment or system. A zero-trust node doesn't extend implicit trust to machines next to it in the data center, even if the machines communicated with the node minutes before.

Fundamentally, trust isn't warranted in a zero-trust system. Even if a node turns out to be safe, it appears uncompromised and the network previously allowed communication with it in the past, that becomes irrelevant to if it's still trustworthy and if the network should allow communication now.

The network can be in a different state than it was in the past. For example, networks can become compromised and fail security checks, and policy changes can change configurations. Zero trust requires identity authentication and verification for every connection request.

Identity for everything

Properly implemented ZTNA must be able to identify users and devices in a network. In other words, ZTNA should have proper identity and access management (IAM) for users and systems. Security certificates, which are cryptographic keys that requesting hosts use to verify something on a network, can typically authenticate in servers.

A receiving host looks to an authoritative system, like a software-defined perimeter (SDP) controller or zero-trust gateway, for confirmation that the requesting system has proven its identity. Those systems might require additional proofs beyond identity.

For example, they might require that the requesting system is fully patched and runs endpoint protection software. The requesting node has a software agent that supplies that verification. For end-user systems, the controller might also mediate user identity verification, such as with domain login, and then include a user's identity in access policy decisions.

Policy enforcement

Once ZTNA establishes a node's identity, the controller checks if current security policies should allow communication between the devices. The controller might also verify that users log in through the requesting system authorized to communicate with the receiving system.

An access controller typically looks to an external IAM system but with its own access rules database. This means it is part of a system that incorporates both policy enforcement points, such as the controllers that grant or deny permission to communicate, and policy definition points through which administrators set up access policies.

Closing the loop

Lastly, a true ZTNA system allows negative entity behaviors in the network to affect policy. A device that is misbehaving can drive the system to update its policy to quarantine, or disable access for, devices that aren't behaving properly. For example, a device trying to talk to too many systems it's not permitted to talk to in a short amount of time might trigger the policy engine to shift that device's identity into a deny-all-access group.

ZTNA challenges

Although ZTNA can help organizations with how they protect their internal networks, ZTNA could also create difficulties that complicate how enterprises defend against potential internal threats.

Access policy configuration

For many enterprises, one of the hardest parts of ZTNA is when administrators define access policies. It's difficult to know which systems need to talk to which in complex environments with deep histories. Some ZTNA tools provide a discovery mode that network engineers can use to determine which systems talk to each other. This can be an essential first step for network professionals to sort out where communication is necessary.

ZTNA requires a change in mindset

Another significant challenge of ZTNA is that network professionals must shift their mindsets to use it. ZTNA is a framework and design philosophy that applies not just to network access, but to all layers in the IT stack.

ZTNA treats every device, software system and user account as potentially compromised and requires constant authorization. This represents a radical departure from the typical mindset that a network can trust all devices and users inside the architecture and must be cautious only of what is on the outside.

Many ways to implement ZTNA

Network professionals can use a variety of systems, including SDP, software-defined WAN, microsegmentation services or a combination of methods, to implement ZTNA in an enterprise network. As long as the method of choice provides a way to fully verify every connection, with respect to the identity of the participants and their permission to communicate at that moment, ZTNA can be a reality within a network.

John Burke is CTO and principal research analyst with Nemertes Research. With nearly two decades of technology experience, he has worked at all levels of IT, including end-user support specialist, programmer, system administrator, database specialist, network administrator, network architect and systems architect. His focus areas include AI, cloud, networking, infrastructure, automation and cybersecurity.