Transcript
or EIP building blocks, how it is designed and how to make best use of it. So let's get started. Versa solution provides a comprehensive feature set for ZTNA security framework which is created to address the following questions. Is this user trusted? Is this device compliant? And should this user reach this specific application right now? And EIP is an essential component of ZTNA security model. Versa supports EIP on all platforms which includes Windows, macOS, iOS, Android, etc. Each platform has its own characteristics and EIP is an integral part of the VSA client which is used to fetch information from Endpoint about its security posture. Once EIP information is available, VSA client sends the report to Versa gateway where based on this report, gateway will enforce its respective action. Important to differentiate that EIP report is based on EIP profile conditional match and enforcement action then applied in secure access policy rules, internet protection rules or private access rules on the Versa SASE gateway itself. On a high level, Versa has multiple predefined EIP categories and each of the category include a subset of applications where application characteristics are defined. System administrator can also create its own custom applications. Additionally, within Versa solution, administrator can narrow down inside the platform to a very specific registry values, processes running on the OS level or even validate if proper certificate is installed. How it works on a high level is that user first authenticates to a portal and receives EIP agent configuration from the portal. SASE client app publish and client machine profile to a gateway. Gateway enforce security policy based on EIP posture received and this is a continuous process. Let's go ahead and explore EIP configuration and its building blocks in more detail. Within EIP feature, we have endpoint device and EIP agent which is running there as part of Versa VSA client software. It is our information gathering. We have EIP objects and use it to build our EIP profile which comprehensively defines how our endpoint device posture should look like to be compliant with organization policies. Finally, we have our Versa SASE gateway with ZTNA policies and it will validate if received information from the agent match to configure it EIP profile and do ZTNA policy enforcement accordingly. Here it is a match logic that we use to build our EIP profile. At the first level, it is based on rules. We can have multiple rules and here the flow is firewall like approach and until the first match occurs. Inside the rule, we have one or more category and across categories it is and criteria to match. So every category should match in order for the rule to match. Then inside the category it is or statement which means at least one or any of the objects should match. As a result, if all categories match so and condition succeeds, we stop and declare that EIP profile has matched and respective policy can be enforced. Of course, considering that other match criterias outside of EIP feature in enforcement policy are also matched. If the rule inside EIP profile is failed to match, then we move to the next rule until the last rule. If no EIP rule match, then EIP profile itself doesn't match and as a result, the respective enforcement policy doesn't match. Let's go ahead and take a look at it in more in a practice. This is a Versa concerto management portal. Let's take a look what are the components included in designing EIP posture. Go to configure profiles and connectors and EIP section. All the building blocks are configured from this section. As you can see, we have EIP profiles, EIP objects and EIP agents. First of all, EIP profile is our main configuration block that is used as a match criteria within the system whenever we want to enforce some action based on collected EIP posture from end device. EIP profile contain one or more EIP objects inside it and we will take a look at it in more details and now let's focus on EIP agents configuration. As you can see here, EIP agent configuration is done by the system administrator in a concerto portal, but it is actually used by VSA client on the end device and not on the gateway. When VSA client registers for the first time, this request comes to a gateway portal policy rules and if EIP agent configuration is included in a policy rule, it instruct VSA client which specific information should be fetched from the end platform and then share it with the gateway. The administrator can use either user defined or predefined EIP agent profiles. EIP agent profile instructs which particular set of applications or services or processes we are interested in. If we check VSA predefined configuration, we can see here a lot of different categories already pre-configured, while the most common, it will be VSA recommended profile here. This category includes all of available categories except the custom categories if system administrator created any of those. If we check any of category in more details, we can see it has a true option set for various keys, which means that VSA client should collect the status or information about it and then share this information with the gateway. Next is where do we apply EIP agent in order to enforce or instruct VSA client which information we should collect from the endpoint device. EIP agent enforcement should be configured under secure access client based access policy rules. Let's open any rule where we can see a workflow of the rule configuration. First sections are designed for our match criterias. However, like we already discussed, EIP agent is an enforcement action designed to instruct a VSA client which endpoint posture information we are interested in. Hence we go to agent profile from EIP section 8 here under action. And this is the key here. Many engineers could easily ignore this section, which will result that periodical posture information will not be collected from the endpoint, which will lead to the entire security posture breach. Obviously, for EIP agent to be enforced here, VSA client should meet all match criterias of this policy rule. And if it is not, then next policy rule will be evaluated. So important can hear that the rule evaluate the match criteria first, right? Then it will enforce the action. Therefore, during a very first time of VSA client registration, it will send by default VERSA recommended EIP agent information so that the match criteria for a particular policy can be matched, right? So we have EIP as a match criteria here as well. It is called EIP preregistration status call. After that, if EIP agent is not configured here, then no further EIP information will be sent to the gateway. And as a result, other policies enforcements may fail or work in a wrong way. Therefore, it is important to select EIP agent under EIP section here in action tab as the only then periodical information will be collected and shared with the gateway. It is a significant part to keep it in mind because we want to periodically validate as an end device security posture, if it has changed or not, and if it is complied with our entire global security posture defined by our organization. OK, so it was about EIP agent, how it works and how it is configured. Now let's go ahead and come back to our EIP profiles and objects in more details. Let's start with EIP objects. EIP object is a basic component in your entire EIP posture design. Firstly, EIP object belongs to a particular category which identify its intent. Additionally, it contains information about particular application, service, registry value or process depends on what we would like to be validated by the gateway. Basically, object defines what information has to be matched on the gateway based on endpoint posture information that we receive from the VSA client. Important to highlight here is that when you create a custom EIP object, you can assign or select a category from the list. And then for all subsequent fields you define, it will be a strict string match. It is also case sensitive. So it is important to be very precise here. Let's take a look at the example with user defined object. I create a new object. I give it a name object CrowdStrike and I select a category which will be endpoint security. For example, for the fields like installed here, administrator can select one from few supported cases. For example, it is like disabled, which means we don't need to validate this field or basically we ignore it. If it is set to true, then we validate that it has to be installed. Or if it is set to false, then we validate that it should not be installed on the endpoint system. Also, all what you define here within EIP object, it is end condition. Basically everything you configure inside it, everything should match as it is in order to properly match the particular EIP object. So in my case, I will just check that CrowdStrike application is installed here and I click add. Now let's go back to EIP profiles and EIP profiles is a collection of EIP object. Inside it, you can define and configure more than one object category and within a category you can define more than one object with a single EIP profile. So in a single EIP profile can be an extensive combination of different EIP objects based on your overall endpoint security posture requirements. Let's take a deeper look at this contract with user defined profile. I click add new EIP profile and first thing I need to do is to create a rule. I say rule one and now I need to add object in the rule. I select my category, for example, anti-malware. I don't have user defined, so I select predefined and for example, I select Bitdefender and Symantec anti-malware software. And in this case, within a single category, if I add multiple objects with any combination user defined or predefined, it will be OR operations, which means any of these selected objects match, then this rule will match. OK, so I click add, add and now I'll create another rule, rule two. And I say add a category browser and I add, for example, Edge browser in here and I click add, add. So now we have two rules, rule one and rule two. Each rule has its own categories and associated objects. So in this example, it works like with a standard firewall, the evaluation is done top down and if we get a match or wherever we get a match, we stop evaluation further down of the rules. Basically, if we match rule one, it means that we match entire EIP profile or if we match rule two. In case there is no match of any of the rules, including this last rule, then it is concluded that EIP profile doesn't match. So this is a rule ordering based match. OK, now let's go ahead and deep dive more into condition of a single rule match. I will go ahead and add another category here. For example, I'll use endpoint security and I will add our CrowdStrike objects that we've just created and I click add. So now I have another category inside the same rule. As a result, we can see that in a single rule we can have more than one condition to match with the different categories. What does it mean now? It means AND operation. So if we have multiple categories of objects within the same rule, all of them should match in order for the rule to match. This gives us an ability to configure EIP policy where we would like to match simultaneously multiple objects or effectively multiple applications, services, processes or registry values or any combination of those. So how it can be useful, for example, a company can validate if endpoint has proper anti-malware and endpoint security applications installed. I click save and I click next and now I can give it a name, my EIP profile and I click save. So now let's take a look where we can apply our EIP profiles. It can be done under secure access policy rules and also it can be done under real time protection, internet protection and private app protection. For example, I go to internet protection rules and I can open my rule and under match criteria for endpoint posture, I go here, I can click customize and now I can add my EIP profile that I just created. So this is a user defined EIP profile. And as you can see, it was already added some predefined profile. And here in the rule, if you add multiple EIP profiles, then it is OR operation. Either this or this has to match. So the best practice to keep one EIP profile in the conditional match and inside EIP profile, you can build your rule based and or OR criteria to match. And last but not least, it is important to understand that when you are building your EIP posture check for endpoint, it is not meant to enforce any change on your endpoint. It is designed to validate the compliance of your endpoint. And based on compliance result, you can further define action in the rule, whether it is allowed or it is denied or whatever policy you have here. OK, so in this video, we discussed what options are available for you to build an efficient EIP posture check for end devices. I hope it was informative for you and thank you for watching.
