Transcript
The integration is based on three key components, 4DClient EMS server, 4DGate, and CrowdStrike inside XDR. In this architecture, both 4DClient EMS server and CrowdStrike inside XDR acts as the policy engine which continuously monitors endpoint posture status to assign the zero-trust tags or ZTS scores while 4DGate acts as the policy enforcement point. As per the integration, 4DClient agent will retrieve zero-trust assessment score assigned to the endpoint by CrowdStrike and later forward it to the EMS server as part of the endpoint telemetry updates. Later, these ZTS scores will be used as one of the parameters within the security posture tags to enforce adaptive access controls on the 4DGate acting as the application gateway. With that, let's look into the configuration aspects related to this ZTNA integration. Starting with 4DClient EMS server, the dashboard provides summary of connected as well as total number of managed and unmanaged endpoints. Moving on, under the endpoint tabs, you can view the complete list of endpoints within an organization. Further, we can get detailed information on each endpoint like its connection status along with various features enabled via endpoint profiles and policies. Here, we can also notice that this device has CrowdStrike Falcon sensor installed for endpoint detection and response. Now, let's look at the security posture tags that we will be working with in this demo. The endpoint compliance tag looks for multiple parameters like domain, antivirus status, vulnerability status and based on the configured rule logic, all these conditions should hold true for an endpoint to receive this tag. CrowdStrike low ZTS score tag is assigned to an endpoint with the score less than 65. Medium ZTS score tag is assigned to an endpoint with a score between the range of 65 and 75. And similarly, ZTS score high tag is assigned to an endpoint with a CrowdStrike ZTS score greater than 75. Once the tagging rules are configured, we can navigate to tag monitor tab to view endpoints classified as per the configured rules. Now, let's move on to the CrowdStrike console to view the zero trust scores assigned to all the onboarded endpoints. As you can notice, we have three hosts out of which two hosts have received ZTS score greater than 90 which classifies them with the high ZTS score tag. Whereas the third host with a score of 33 was assigned low ZTS score tag. With that, let's move on to 4DGate and see how these ZTS scores get enforced on 4DGate in real time for adaptive access controls. 4DGate utilizes 4D client EMS connector or two-way webhook to get real-time information on endpoint posture status based on the defined tags. Under the ZTNA tab, we can find all the configured private applications. And for the sake of this demo, we will be working with 4D analyzer server. Under the security posture tags tab, we can view all the tags synced from EMS server to 4DGate along with the endpoint classification information. Here we have two endpoints classified with endpoint compliance tab. Similarly, two endpoints with the high ZTS score and one endpoint with low ZTS score tag as we have seen on the CrowdStrike and 4D client EMS consoles. Now let's quickly glance over how these tags are enforced via ZTNA policies. I have configured a deny policy at the top that looks for critical vulnerability or low CrowdStrike ZTS score tags. And if endpoint has any one of these tags present, user access will be blocked to all configured private applications. Next, for the 4D analyzer ZTNA policy, I have again configured two tags, high ZTS score and endpoint compliance. But in this case, both the tags need to be present for clients to access this application. Further, I have enabled antivirus and IPS security profiles within this policy. Now let's verify private application access. As you can see, this endpoint is managed by 4D client EMS server and it has received both the required ZTNA tags. Let's try to browse to faz.tmg.local, the 4D analyzer ZTNA server. First, 4DGate will prompt the user for device authentication based on the unique certificate issued to the endpoint by EMS. And later, based on the configured authentication rule, 4DGate will redirect us to 4D authenticator acting as the SAML IDP for user authentication. Once authenticated, we will be able to access our ZTNA application. Now let's hop on to another endpoint. It is also managed by the same EMS server, but this PC has received a low ZTS score tag. Now if I try to browse to same 4D analyzer server, 4DGate will prompt us for device authentication. But because of the low ZTS score tag attached to this endpoint, we will hit the very first rule with the action set to block. And here you can notice that 4DGate did present us with a response page stating the reason for the block. We can verify all this activity by looking at the ZTNA traffic logs on the 4DGate. Under the log details, we can get information on the user, its group, the matched ZTNA rule, and also the tags that were associated with the endpoint during the time of application access. This concludes the demo. Thank you for watching.
