Fortinet Security POC – Zero Trust Network Access (ZTNA)

Introduction

Zero trust is a philosophy for only trusting a user or device after explicitly confirming their identity and status. The zero trust mindset focuses on users, devices, and the specific resources being accessed, utilizing segmentation and zones of control. 

Zero Trust Network Access (ZTNA) is a solution that provides secure access from authenticated and appropriately postured users to their applications from anywhere. ZTNA architecture consists of four primary components, including a software client for endpoint access, an authentication provider, a centralized enforcement point and application gateway. 

The Fortinet ZTNA solution components include FortiClient, FortiAuthenticator (or 3rd party authentication provider), FortiClient Enterprise Management Service (EMS) and the FortiGate firewall. Users are authenticated against FortiAuthenticator using Security Assertion Markup Language (SAML) and Lightweight Directory Access Protocol (LDAP). The enforcement policies as defined for clients and other devices are from the FortiClient EMS Server. FortiClient provides telemetry back to the FortiClient EMS Server. The server uses the telemetry feed to monitor changes in device posture, user activity and endpoint tags, and swiftly initializes any FortiGate policies relevant to the telemetry provided. 

The ZTNA solution also includes the services provided by FortiGuard AI to ensure protection against the latest polymorphic attacks, IP reputation and botnet security, and inline sandboxing to protect against sophisticated and zero-day threats.

The diagram below provides an overview of the Fortinet zero trust architecture. 

The Fortinet Zero Trust Network Access solution consists of ZTNA telemetry, tags and policy enforcement to protect clients on and off the network. The diagram below shows the correlation between the various elements.

The FortiGate firewall acts as the application gateway for the Fortinet ZTNA solution. The diagram below shows the traffic flow of the Fortinet ZTNA solution for secure access to the protected applications.

Proof of concept testing

The team at the WWT Advance Technology Center (ATC) tested the core functionality and usability of the Fortinet ZTNA solution including:

• User onboarding
• Protected resource testing
  • Multi-factor authentication
  • Identity and group policy based access
  • End point posture checking
  • Critical vulnerability tag enforcement
• TCP-forwarding testing with RDP and SMB
• End point lockdown and live session blocking
• Reporting

The Fortinet ZTNA validation was conducted following a detailed test plan to validate the core functions as outlined below in Table 2: Evaluated test cases.  No issues were encountered during testing and most configurations used were derived from using the Fortinet Administration Guide as a reference.

Table 2: Evaluated test cases.

Testing environment

The lab topology was deployed in a virtual environment that consists of a datacenter network, an On-Net LAN, and simulated Internet. The environment testbed included a full Active Directory Domain (fortlab.local) running on Windows Server 2019 and is used as the LDAP source for users and groups. This setup includes a Root Certificate Authority that was used to provide the wildcard certificate used throughout the lab. Group policies were created to auto-enroll users and computers for certificates along with pushing out the Microsoft Group Policy Objects (GPO) required to auto-install FortiClient during the domain join. 

FortiClient EMS and FortiAuthenticator both used the AD domain as their source of user information and authentication. FortiClient EMS will sync periodically with the user and computer database to ensure it has a local copy of users and computers that are up to date, so that any changes (such as group membership) will be reflected in the ZTNA tags should they need to change based on moves, adds and changes. 

FortiAuthenticator (FAC) used the AD domain, LDAP service as the single source of the user database. In our scenario, FAC provided the SAML Identity Provider (IdP) used by the FortiGate to provide extra level of security as well as Multi-Factor Authentication (MFA) for users configured to require One-Time Password (OTP) tokens. 

The diagram below provides an overview of the lab topology.

Testing components

Table 1: Testing components

Testing highlights

The testing followed a comprehensive test plan. This section will provide a summary of the results of the test. Please work with your WWT account team if you are interested in accessing the results of the full test plan. The results will be summarized below.

Test case 1: Unregistered device access to protected resources. 

Result: Unregistered users and devices are denied access to resources appropriately as show in the figure below.

Test Case 2: User onboarding with AD/LDAP verification.

Result: A user was onboarded by joining their computer and user accounts to the domain. Once joined to the domain, the GPO policy created auto enrolled certificates for both the user and computer as well as automatically installed FortiClient on the computer. The endpoint registration was validated in the FortiClient EMS admin console.

Test Case 3: Register the FortiClient ZTNA agent to FortiClient EMS with 'New User' verification.

Result: FortiClient EMS sent an invitation to the user's email address to prompt the user to install the FortiClient software. The user was authenticated to LDAP for verification that the user installing the software is a member of the domain. The endpoint registration was validated in the FortiClient EMS admin console.

Test Case 4: Protected resources access with MFA Policy.

Result: User connected successfully to the engineering server after providing the proper certificate and completing user authentication.

Test Case 5: Protected resources access based on identity/group policies.

Result: A single user configured can have access to an HTTPS resource, while all other users were denied access. Access was provided to the user by applying the appropriate zero trust tag.

Test Case 6: Disallow protected resources access with critical vulnerability tag.

Result: Validated the client was not allowed to access a protected resource when the endpoint has been flagged with a critical vulnerability. When the vulnerability was detected, the zero trust tags were updated to include the malicious file tag to limit access until the vulnerability was remediated.

Test Case 7: Protected resource access based on endpoint posture checking.

Result: A policy was configured to allow the client to access the protected resource if the endpoint has Windows Firewall enabled and Windows Defender is running. The policy worked as expected and allowed access to the protected resources when the compliance tag was applied due to the policy being met.

Test Case 8 and 9: RDP access and SMB drive mapping using ZTNA TCP-Forwarding access proxy with MFA.

Result: TCP-Forwarding Access Proxy (TFAP) allowed the user to RDP to a remote computer and map a drive using SMB after proper authentication and posture validation. 

Test Case 10: Endpoint Agent Lockdown.

Results: FortiClient can be configured to prevent users from changing or disabling features. FortiClient EMS provides various settings such as password required to disconnect, turn of the ability to create new VPN connections and ZTNA destinations, as well as other targeted settings to lockdown the FortiClient application.

Test Case 11: Live Session Blocking.

Results: User sessions can be blocked using various methods including disabling the user, revoking client certificate, place user in quarantine group, etc. In this test case, the user session was successfully blocked by deregistering the client from within FortiClient EMS.

Test Case 12: ZTNA FortiView dashboard in FortiAnalyzer.

Results: Logging to FortiAnalyzer provided detailed information about the ZTNA environment including sessions, users, servers and more within the FortiView dashboard of FortiAnalyzer.

Conclusion

Overall testing was very straightforward and no issues were encountered. Each test performed as expected, correctly exposing ZTNA tags and protecting those resources based on the requirements of each test. 

The Fortinet ZTNA solution was evaluated using criteria: user onboarding, protected resource access, and administrative features, including lockdown, monitoring and report capabilities. The evaluation summary below provides further insight into the experience working with each of the criteria outlined in the lab test cases.

Table 3: Evaluation summary.

References

https://docs.fortinet.com/ztna

https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/35450/forticlient-ems-enterprise-management-server