ZTNA

What is Secure Remote Access?

Secure remote access is a combination of security methods and technologies that allow outside end entities to connect to networks, without compromising digital assets or exposing networks to unauthorized parties. Remote users could be logging from lots of unsecure networks, such as a coffee shop public Wi-Fi. Users remain the main conduit by which bad actors gain access to the network. More than 60% of all breaches involve user credentials, stolen or hacked.

How is Remote Access Secured?

Secure access has all or most of these features, depending on how you configure "Remote Secure Access":

• Data Privacy: A state in which information is concealed from the public and privy only to select people.

• Data Integrity: The accuracy and consistency of data over its lifecycle.

• Authentication: The process of verifying the identity of a person or thing.

• Authorization: The function of specifying access rights to resources.

• Accounting: The record-keeping and tracking of agent activities on a computer network.

How does ZTNA Compare to VPN

A VPN is a private connection across a public network that enables a user to exchange data safely with a private network, as if their computing device was directly connected to the private network.

Site to Site VPN

Site-to-Site VPN: is a connection between two or more networks, such as a corporate network and a branch office network.

Secure Remote Access VPN

Secure Remote Access VPN: is a connection between a remote user and a network. A secure remote access VPN is composed of a client, server, and protocols.

Zero Trust Networking Accsess ZTNA

Zero Trust Networking Access ZTNA: is similar to VPN in that it satisfies the goals of secure remote access. Essentially, the principal difference between VPN and ZTNA is that ZTNA applies the zero trust principle, which is that no user or device, whether it is inside or outside a network, is trusted. Around ZTNA is a regime of strong authentication and other security measures that allow a network to trust users and devices.

What is ZTNA?

ZTNA establishes a secure session between an end entity and a network, while ensuring granular control over access to resources and exercising zero trust, regardless of the location of either the end entity or the network. Part of the zero trust principle is the practice of the least privilege access. This means that users are only granted access to the resources necessary to fulfil their job requirements, and no more. As a network security concept, zero trust operates under the premise that no user or device inside or outside the network should be trusted, unless their identification and security status have been thoroughly checked. Zero trust operates on the assumption that threats, both outside the inside the network, are omnipresent. Zero trust also assumes that every attempt to access a network or an application is a threat. So, regardless of whether the end entity is remote or on-premises, the connecting computing device automatically establishes an encrypted session with the network. Specifically, this connection takes place between a ZTNA client at the end entity and the ZTNA access proxy, which could be a firewall. The proxy point hides the location of requested applications from the outside. The Proxy directs the client's request to the application, which could be on-site or in the cloud, only if the user meets access requirements. Other ZTNA components are authentication and security. Because the user is identified through authentication against an-on-premises backend server or an Identity-as-a-service (IDaaS), policy can be applied based on the user roles.

Also, the ZTNA policy server enforces policy-to-control access, specifically to applications. For example, access could, in part, be based on geolocation. So, if the remote device is connecting from an unexpected point in the world, access to an application could be denied or privileges reduced. Likewise, if a device fails a security sanity check, the user could be denied access. Security is composed of firewalls and the ZTNA access proxy, which control access and provide security to application resources.

ZTNA Workflow

Unlike IPsec VPN, but similar to SSL VPN, ZTNA is vendor specific. This means that each vendor can implement ZTNA in a way that best suits their specific requirements.

The diagram on this slide is the Fortinet ZTNA solution. The Fortinet ZTNA client is FortiClient.

Expatiation of this diagram.

Also in this diagram, FortiClient Endpoint Management Server (EMS) acts as the ZTNA policy server. When an endpoint deice with FortiClient attempts to connect to the network for the first time, it is directed to FortiClient EMS to register. During the registration process, FortiClient provides the server with information about the device, the user, and the security posture of the device. This information is written to tags and shared with the firewall, FortiGate.

Based on the information in the tags, the device can be grouped, and certain rules can be applied. The rules act as instructions for FortiGate. FortiGate applies the rules to the device each time it connects to the network. An example of a rule could be that a device with Windows 10 plus antivirus software is allowed access, but a device with Windows 10 and no antivirus is denied access. At the end of the registration process, FortiClient EMS generates a digital certificate for the device, and sends the certificate to the device and shares with FortiGate. From this point onward, the device submits the certificate to FortiGate each time it needs to identify itself. FortiClient is in continuous communication with FortiClient EMS, if the end point information changes, the server updates the client tags and resynchronizes with FortiGate. The ongoing communication between these components is called network telemetry, and it provides agile and dynamic responses to enhance network security.

How Does Fortinet ZTNA Work?

Step 1

1. Device identity validation A. The endpoint connects to the ZTNA access proxy. B. FortiGate challenges the endpoint for device identification. C. Endpoint sends the device's certificate to FortiGate, which had been issued by FortiClient EMS. D. FortiGate applies the tags and rules associated with the device.

When the endpoint connects to the ZTNA access proxy, FortiGate challenges the endpoint for device identification. The endpoint sends the device certificate to FortiGate proving the device identity. Then, FortiGate applies the associated tags and rules and either rejects the request or allows the device to proceed.

Step 2

1. Device identity validation

2. User authentication A. FortiGate challenges the endpoint for user authentication. B. FortiGate forwards the credentials to the authentication server, which could be an AD, an LDAP directory, a database, or Identity-as-a-Service (IDaaS). C. The user's identity is validated and the user's roles are retrieved from the authentication server. D. The user's roles are used by FortiGate to determine access to the network application.

FortiGate challenges the endpoint for user authentication. The endpoint prompts the user for their credentials and delivers the credentials to the access proxy. In turn, the access proxy sends the user credentials to the backend for authentication. The authentication server could be an AD, an LDAP directory, a database, or IDaaS. The ZTNA access proxy retrieves the user's identity, along with role information. FortiGate uses the role information to help determine if the user has permission to access the requested network application.

Step 3

1. Device identity validation

2. User authentication

3. Encrypted session

Finally, assuming that the device and user have been identified, and the device's tags and rules plus the user's roles allow access to the resource, an encrypted session is initiated between the ZTNA client and the ZTNA access proxy, and the user gains access to the application.

Traits	IPsec VPN	SSL VPN	ZTNA
Secures what level(s) of the OSI model?	Network	Transport to Application	Transport to Application
What implementation is required at the client?	VPN client application	Web browser application or an SSL VPN client application	ZTNA client
What access control to network resources exists after a session is established	No access control after a user has established a VPN connection.	Some granular access control as SSL connects users to specific apps and services, such as an email app.	Granular access control to specific application. Access control is based on user roles \ policy, plus ongoing security checks of the connected devices.
Authentication	Authentication takes place between the VPN client application and the private network.	Authentication takes place by way of a login prompt from the browser after the SSL session is established.	Both the user and the device go through an authentication process and are re-identified and checked each time access to an app is requested.
Tunnel type	IPsec tunnel only	Session-based or tunnel	Session-based only
Category	Industry standard	Vendor specific	Vendor specific
Configuration	Requires installation Flexible setup A. Mesh and star topologies B. For clients or peer gateways.	Does not require installation, if using the web type Simpler setup A. Only client to FortiGate B. No user-configured settings	Requires the installation of a ZTNA client Simpler setup A. Only client to FortiGate B. No user-configured settings