Simplifying Zero Trust with Infinity Identity: Centralized, Scalable, Secure - EMEA recording

[Royi_Priov]

Thanks, Menucha!

If you have any questions or want to set up a meeting for further discussion, don't hesitate to contact me.

[Tobias_Moritz]

Thank you for this presentation.

When I see identity source query solutions like that, I always think about the following problem and how to circumvent it. Maybe you have an idea about that:

User 1 on Machine 1 is connected to network 1 (10.1.1.10 native).

User 2 on Machine 2 is connected to network 2 (10.2.2.20 native) and network 3 (10.1.1.10 via local vmnetwork (WSL 2 or somethink like that).

User 3 on Machine 3 is connected to network 4 (10.1.1.0 on a WIFI hotspot) and network 5 (10.5.5.50 via Harmony Endpoint VPN).

All Machines are not using legacy Identity Agent. All machines are cloud only joined (so no Active Directory) and Identities are queried using Entra-ID (queried from Intune and/or Defender).

While all three machines are connecting over PEP using different source networks (1, 2 and 5), the data collection by Intune/Defender would also collect the ip addresses from network 3 and 4. You see that at 23:34 in the video. When I understood you correctly, this would invalidate the session from User 1 on Machine 1. Right?

If I am right, how can this effect be circumvented?

[Royi_Priov]

Hi @Tobias_Moritz ,

Thanks for your question.

In the described case, although we are collecting information about all device IP addresses, the IP we will share with PEP is only the relevant one the PEP requests.

It means, in your example, we will share only the IPs from networks 1,2 and 5.

In any case, we are storing the users separately on our database, so there is no relation between shared IPs between different users, until we will join the information per IP before sending it to Identity Awareness. In other words, an invalidation of user 1 won't affect user 2 data. as they are separately stored.

[Tobias_Moritz]

Thanks, Royi, for your fast response.

Unfortunately, I still don't get it. You said "the IP we will share with PEP is only the relevant one the PEP requests". How do you know, what is relevant? I guess you are talking about something like smart pull, so PEP requests records matching its relevant networks. But the problem in my example above was, that all three hosts have the same IP address (on different interfaces) so they are all in the same relevant network from PEP perspective. How can PEP know about that these are in fact different networks on host side, which just have the same ip address space?

Regarding the session invalidation: I also don't get it:

Scenario 2:

1. User 1 connects first. User 1 on Machine 1 is connected to network 1 (10.1.1.10 native).
2. User 1 disconnects its machine from network (or send to to hibernate). No logout event is triggered on any system, it just vanishes from network.
3. User 4 connects 11 minutes later. User 4 on Machine 4 is also connected to network 1.  In this network, DHCP sessions are 10 minutes in this example, so this Machine 4 is getting the same IP address again: 10.1.1.10 native.
4. In this example, you want to get User 4 on Machine 4 to get this IP address on PEP. So in fact, this invalidates the previous usage of this IP address by User 1 on Machine 1.

How can this scenario (you want to overwrite the user/machine to IP binding) be handled differently from the one in my first post (you do not want to overwrite the user/machine to IP binding)?

[Royi_Priov]

Scenario 1:
I think I understand the question better now.

Infinity Identity "job" is to provide a Quantum gateway with all the information we know about the given IP. The scenario exists, by the way also with Identity Awareness. we are exposed to the information the sources provides us, and will share this with Quantum per the gateway request. In this case, we will share only the latest user associated with this IP.

However, there are many other problems with users getting the same IP in different devices, as it will break our ability to understand which user is currently behind this IP, as if both are actively working on their devices, we will constantly get updates from all devices with this IP and they will invalidate eachother constantly.

If this is the same device (multi user host), we do support Terminal Server Agent.

I will add in addition - the customer will be able, in Infinity Identity, filter out specific networks (e.g. internal ones) in case needed. We will also support automatic filter for IPs that has many different users associated with.

I hope this part is clear.

Scenario 2:

We will indeed publish only the latter user, as it will overwrite the previous one once we are unifying the information for Quantum.

If you want to continue this discussion - feel free to contact me directly to set a private session for Infinity identity - royip@checkpoint.com