What is
Zero Trust Network Access (ZTNA)?

In the ZTNA model, access is only approved once a user is authenticated by the ZTNA service which then provides an application or network access via a secure and encrypted tunnel. The service prevents users from seeing applications or data that they do not have permission to access, thereby preempting lateral movement by a would-be attacker. This kind of movement is something that would otherwise be possible if a compromised endpoint or approved credentials could be used by an unauthorized device or agent to pivot to other services or applications.

With ZTNA, protected applications are also hidden from discovery, and access to them is restricted via the ZTNA service (also known as a trust broker) to a set of preapproved entities. A trust broker will only grant access to an entity if the following conditions have been met:

• The entity (a user, device, or network) supplies the broker with the right credentials.
• The context in which access is requested is valid.
• All applicable policies for access within that given context have been followed.

In ZTNA, access policies are customizable and can be changed based on system needs. For example, in addition to the requirements above, you can implement location or device-based access control that prevents vulnerable or unapproved devices from connecting to a protected network.

Firstly, since application access is isolated from network access in the ZTNA framework, network exposure to infection or access by compromised devices is reduced.

Secondly, ZTNA models only make outbound connections. This helps to ensure that network and application infrastructures are invisible to unauthorized or unapproved users.

Thirdly, once a user is authorized, application access is provisioned on a one-to-one basis; users can only access applications they have been explicitly granted access to instead of enjoying complete network access.

Finally, since ZTNA is software-defined, device and application management overheads can be substantially reduced.

Here are a few popular use cases that illustrate the power of ZTNA security models.

Replacing VPN

VPNs are slow, relatively unsecure, and can be difficult to manage. ZTNA is fast becoming the preferred security model that is posed to replace VPN for provisioning remote access to central networks.

Reduced Third-party and Vendor Risks

Access permissions and data transfers to or from third-parties or external vendors are an inherent security gap for your IT infrastructure. With ZTNA, you can reduce these risks by ensuring that external users never gain access to a secured network unless they are authorized and that, even with access, they only have access to specific applications or databases for which they are approved access.

You can deploy ZTNA at your organization as follows:

• Via gateway integration, in which any traffic attempting to cross a network boundary will be filtered by your gateway.
• Via secure software-defined WAN that can optimize and automate network access using a built-in security stack in each network appliance.
• Via Secure Access Service Edge (SASE) that provides software-defined WAN security via a virtual cloud appliance.

ZTNA is recognized as a cybersecurity best practice. The best thing about ZTNA is that it does not require a significant redesign of your existing network to deploy it. However, since any IT endeavor requires onboarding people and devices and redefining policies, and ensuring stakeholder buy-in, decision-makers must consider the following before partnering with a ZTNA solutions provider:

• Does the solution help you to secure data and applications with microperimeters?
• Can you protect data in transit?
• Does it have default-deny segmentation and granular policy design and testing?
• Can it be deployed irrespective of your existing infrastructure?
• Does it provide violation alerts?
• What kind of workload security provisions are available?
• Does the solution provide user-based segmentation, remote access control, and lateral movement prevention?
• Is there device-level segmentation, unknown device detection, and device quarantine?
• Is there default containment, even before threats are identified?
• What kinds of visibility do users have, and what kinds of audits are available?
• What kinds of integrations are included? Consider the following:
• Orchestration with Chef, Puppet, or Ansible
• Container platform orchestration with Red Hat OpenShift, Kubernetes, or Docker
• Security analytics with Splunk and IBM QRadar
• Vulnerability management tools such as Qualys, Tenable, or Rapid7
• Public cloud tools such as AWS Cloud Formation, AWS GuardDuty, and Azure
• How quickly can I segment my network environments?
• How can my existing investments such as host firewalls, switches, and load balancers be leveraged to enforce segmentation across legacy and hybrid systems?
• What kinds of REST API integrations are supported? Important tools to check for include OneOps, Chef, Puppet, Jenkins, Docker, and OpenStack Heat/Murano

Discover how Zero Trust segmentation can help protect your organization.