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.
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:
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:
This information is also present in the FortiClient as shown in the screenshot below.
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.
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:
These attempts are recorded in the ZTNA Traffic log which captures the connection attempts as well as the tags that identify the endpoint.
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
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:
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:
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:
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!