Trust Profiles and Trust Effect by Banyan Security

Ashur Kanoon:

In this video, we’re going to look at trust profiles and trust effect. You want to add device identity and device trust (compliance or posture) to your authentication and authorization policies, but aren’t sure where to start. We’ll discuss a few options and look at how Banyan Security handles these.

Let’s look at a sample policy. In this policy, we want to allow both corporate owned and BYOD devices. Each will get different levels of authorized access. Corporate owned devices need to have antivirus, hard drive encryption, auto update, and an EDR running, while BYOD just needs to have antivirus.

Most vendors use a weighted scale for each factor, so by default, four factors would mean 25% each. This may make sense, but let’s say factor A is disk encryption, and if that’s off, is the system really 75% compliant? Would you want the system to still access the resources? If not, you’ll need to start playing with the weightage until it kind of makes sense. This is hard to do and doesn’t always work easily.

What happens if I turn firewall off? How can I deny access if EDR reports malware? Can I check disk encryption without impacting connectivity? I want each factor to completely deny access.

Here’s an example of a competitor’s products. Here you can see that they have devices and the devices have average scores. These average scores range from -20 to -80. It’s really confusing and it’s hard to understand how these scores are derived and how they affect the user access.

Introducing trust profiles and trust effect. Trust profiles allow an admin to assign trust factors to different groups of devices with available assignment criteria of user groups, serial numbers, operating systems, MDM management, and device ownership.

Look at the end user experience. On the Banyan client, we have various trust factors. Some are from the client itself and others are using our EDR integration. What we’re seeing is that the Banyan client is aware of things like auto updates, disk encryption, and so on. The EDRs are also inspecting the device and reporting back.

On this demo, I’m going to quickly show you what happens to the end user when our trust level changes. I’m going to log into an RDP session, and this is an RDP server that’s running on premises. Here you can see I’m going to disable auto updates by going to settings, general software updates. I’m going to turn off auto updates, which requires I put in my password. Now auto updates are off.

If we go and look at the trust level, the Banyan client has detected that my trust level is deny. And if you want to know how to turn it off, remediation instructions are included. But if you notice, since my trust level has always deny, I’ve lost my RDP connection. If I want to enable my RDP connection, I can refer to the remediation steps and it tells me how to update the system, so I will go and update it now. Now that I’ve turned on automatic updates, we can go back and look at the device trust. It’s back to high, and now I have access to my RDP session.

Now let’s look at the admin view and the configuration. I’m going to go ahead and log in. Here you see the dashboard and there is some info on the trust levels, but we’re going to go to secure access and trust profiles to look at the config. These trust profiles get assessed in order. The device I have is using the default trust profile. There are ways to configure a profile by group, by serial numbers, and so on. We can configure a profile for various operating system. We could also include MDM managed and unmanaged devices, as well as other types of device ownership. If I want to create something for corporate dedicated devices only, they will be the most stringent policies. Employee owned device policies may be the most lax, but they’ll also provide the least amount of access to low risk resources.

Within the trust profile, we have trust factors. For example, we can configure application checks and we can configure the behavior or change to trust. This can be low trust level, medium trust level, or no effect at all. What I had configured for auto updates is always deny, so basically, if the system is out of date and isn’t being updated, I want to make sure that I deny the system access to all resources. This is just done for demo purposes. What you might have configured is deny access if firewall is disabled or if the system is rooted or jailbroken.

Each specific factor has its own effect. You don’t need to worry about how each one is related and how to configure the weights. They all act independently. This makes it much easier. There’s also the ability to look at all the trust factors together, so if you have things like file checks across different profiles, you can see them all in one place for each operating system.

You can also look at the trust integrations as mentioned earlier. These are for EDRs. We have Crowdstrike configured, and Crowdstrike will be sending us a ZTA score. We also have SentinelOne, and both of these will be looking for things like malware and other unwanted behavior on the system. You can make these active or inactive, and in fact, all the checks can be configured independently.

Here in remediation, we have preconfigured remediation instructions, but they can also be customized. These will be seen by the end user if they’re out of compliance. End users can help themselves prior to contacting IT.

Another thing we have here is trust score expiry. Basically what it does is if the device doesn’t check in within a certain amount of time, or the users are mucking around the system and trying to disable access between the client update and the server, we’ll default to always deny. We definitely want the client to be checking in and sending us up-to-date info on trust levels and information about the device before we grant access.

Thank you.

Close Transcript