Zero Trust Network Access – Regulating Secure Access with Endpoint Posture Checking by using Zero Trust Tags

In my previous post, I discussed how to access web application and non-web applications via the Zero Trust Network Access in the Fortinet solution. In both of these scenarios, the only endpoint requirement for accessing these applications is the client having an active registration to the FortiClientEMS. While this check is useful for testing the establishment of connectivity, it is not practical for making sure the endpoint is in its most secure posture to protect applications.

Zero Trust Tags

Zero Trust Tags are the foundational object that allows the FortiGate to be aware of the security posture of an endpoint running the FortiClient endpoint agent. To facilitate this, the FortiClient sends its telemetry information to FortiClientEMS with information pertinent to the state of the endpoint it is installed on.

FortiClientEMS

The FortiClientEMS is where the rules to categorize the endpoint are set up based on the telemetry information received from the FortiClient.

There are a multitude of items that the Zero Trust Tagging Rules can check for, however they are platform dependent with the majority of the different checks being supported on the windows platform. For an in-depth review of the individual checks supported on each FortiClient platform, please access the following documentation.

In my environment, I want to ensure that any host that connects to the resources in my lab are, at a minimum, running anti-virus and registered to my FortiClientEMS server. Here is a screenshot of the construction of this Zero Trust Tagging Rule:

Figure 2. – Screenshot of the FortiClientEMS Zero Trust Tagging Rule Set

Once the rule has been created, the next telemetry check-in from the FortiClient (which occurs within 60 seconds) will categorize the FortiClient endpoint within the Zero Trust Tag Monitor as shown in the screenshot below:

Figure 3. – Screenshot of the FortiClientEMS Zero Trust Tagging Monitor

This information is also present in the FortiClient as shown in the screenshot below.

Figure 4. – Screenshot of the tags assigned to the FortiClient

After the FortiClientEMS has been configured with the appropriate tags, the FortiGate can be configured to allow access to protected resources based on that information.

FortiGate

The FortiGate receives dynamic updates from the FortiClientEMS that contain the information necessary for enforcement. Part of that information includes the tags configured for the FortiClients, the FortiClient certificate serial number and FortiClient unique identifier. These core components allow the FortiGate to provide access to each protected application on a per FortiClient/host basis.

This information is populated as a FortiClient attempts to make a connection through the FortiGate. Upon a successful connection attempt, details of the client are displayed as a “matched endpoint” within the FortiGate:

Figure 6. – Screenshot of the FortiGate ZTNA entry for a host recognized by the FortiGate

These attempts are recorded in the ZTNA Traffic log which captures the connection attempts as well as the tags that identify the endpoint.

Figure 7. – Screenshot of the FortiGate ZTNA Traffic logs showing successful connection

Figure 8. – Screenshot of allowed access to FortiSIEM application

Non-Compliant Host Behavior

If the endpoint modifies its local security posture and falls out of compliance to the conditions set by the ZTNA tag, the solution will re-evaluate the access and dynamic adjust its controls to restrict access. To illustrate this, I have created a “vulnerable” tag that matches one of the conditions:

AV Software is Not installed or Running
Notepad.exe is currently an active process

Figure 8. – Screenshot of the FortiClientEMS vulnerable ZTNA Tagging Rule set

Based on the rule above, starting up the “notepad” application on my Windows desktop should assign a “vulnerable” tag to the FortiClient. To illustrate this, I open notepad and then after 60 seconds, display the tags assigned to my FortiClient:

Figure 9. – Screenshot of notepad and task manager

Figure 10. – Screenshot of FortiClient showing the “vulnerable” zero-trust tag

The constant posture reassessment from the FortiClient ensures that the endpoint is adhering to the compliance policy I set from FortiClientEMS. To enforce access restrictions, I have defined policy on the FortiGate to deny access when the “vulnerable” tag is seen from the endpoint. This more restrictive rule is evaluated before the rule that allows access as shown in the screenshot below:

Figure 11. – Screenshot of the ZTNA firewall rules preventing access for “vulnerable” endpoints

With these policies in place, I confirm that my access is blocked via the FortiGate with a replacement message stating “ZTNA Access Denied” as shown in the following screenshot:

Figure 12. – Screenshot of the “ZTNA Access Denied” replacement message from FortiGate

Hopefully the information in this post provides clarity on how ZTNA tags can be used to restrict or allow access to applications via ZTNA on the FortiGate. My last and final post for this series will be focused on troubleshooting this process if it does not work as expected. As always, please leave any feedback you have in the comments below and I hope this helps!

5 3 votes

Article Rating