Zero Trust architecture is the new trend of Security Philosophy based on the principe, never trust and continuously verify trust, which means even if the user is authenticated and permitted to access corporate resources with least privileges using RBAC, he is continuously tracked and monitored to detect any malicious activity, anomalous behavior, or if the posture is not changed, if this occurs, an automatic action and response is required to quarantine the host or to suppress the initial permission.
One important layer of Zero Trust is to perform continuous monitoring and analysis which leads to the "Continuously Trust Concept" in the Zero Trust Architecture. This layer is used to detect any malicious or anomalous activity such as data hoarding, data exfiltration or any connection to CnC server from a compromised host. And if a violation occurs or a malicious activity is detected, an action to quarantine the host is applied. One of these tools is Dynamic User Group. DUG is used to dynamically put an infected host for example in a Dynamic Group that will be used in the security policy to limit or to deny access.
The idea behind the DUG feature is to perform automatic remediation when the presence of threat is detected.
To do this, the Log Forwarding Profile is responsible to first tag the user based on the criteria you define inside this profile, an example of a criteria is Sinkhole for any connection to malicious domains (the User-ID feature must be enabled before). If the criteria Sinkhole matches any threat log entry for a specific user, then the Log Forwarding Profile will assign a TAG to the user.
Once the user is tagged with a specific TAG, the firewall registers the user into the Dynamic User Group, the DUG must be configured with the same TAG you define in the Log Forwarding Profile.
Finally, you need to define a Security Policy Rule with the Source user "the Dynamic User Group you created previously" as a condition and an action DENY to quarantine the host.
In this example, we have an EDL with a list of malicious domains in the server 10.1.6.20.
Create the External Dynamic Lists object.
Create a Dynamic User Group and assign the TAG Sinkhole as a Match Criteria.
Create a Log Forwarding Profile with Log Type threat and define an action the Firewall will take if a threat is detected in the Logs.
The action is to add the tag Sinkhole (the same tag assigned to the Dynamic User Group) for any user detected in the Threat Logs with DNS sinkholed.
Create an Anti Spyware profile and define the action sinkhole for the EDL created previously.
Edit the Security Policy Rule that allow access to INTERNET, associate the Anti Spyware and Log Forwarding Profiles.
Configure a Security Policy Rule named Sinkhole-Rule-User for auto remediation. In the Source User select the Dynamic User Group and the action Deny.
Login to the Internal PC using the AD user credentials.
Access any website that does not belong to the External Domain Lists. The connection should be successful.
When the user tries to access the www.eicar.org website, the Firewall intercept the DNS request and applies the Sinkhole action defined in the Anti Spyware profile.
In the Threat Logs, we can see the sinkhole action for the user maradona.
The firewall adds automatically the user maradona in the Dynamic User Group.
Because now the user is added to the Dynamic User Group, internet traffic is denied by the Security Policy Rule Sinkhole-Rule-User as shown in the Traffic Logs.
