Identity is Not Enough: Enforcing

Thank you for staying with me. Much appreciated. I will be talking a little bit more practical and showing live demos. Not really live demos, video demos. If you want live demos, just come visit me upstairs and I can show you far more practically hands-on. At Excalibur, what we are doing is we are trying to understand what the user is doing as he is doing it and trying to match it to what he should be doing. That's why we like to call it intent-aware access. Why is this important? This is important because cybersecurity today is, if you think about it, kind of reactive.

We have filter lists and we are trying to update them and they can protect us only against threats they know of. This worked for the last many, many years, but now with the rise of AI, we can have zero days basically daily.

So, filter lists cannot protect us anymore. This is just a graph of what is the ability of the recent anthropic models to find, generate autonomously zero-day exploits.

So, SONET was not so long ago. OPUS had like 14% success rate in finding and generating zero days and now the new MITOS model has over 70% success rate in autonomously, you know, out of thin air creating a zero day.

So, it won't be a rare occurrence anymore. It will be a daily occurrence.

So, we have to change and adapt somehow. So, what is the architectural flaw? The architectural flaw is kind of universal, if you think about it. It is that every security solution today doesn't matter if it's a VPN, zero trust networking, privilege access management or whatever else. You will end up with a direct connection to the target. And I always like to say, whatever you can connect to, you can exploit.

So, now when you can generate zero-day exploits on demand and you can connect to everything, you are kind of in a bad spot. So, we have to do something about it, right? Because once you are in, you can use that target as a live bridge and move laterally everywhere.

So, it is like a structural thing. And if we just keep adding stuff on top of that, we won't be able to fix it, right?

So, it's a structural flaw. So, we have to create a new architecture how we do that.

So, let me start with how we solve the first layer, and that is isolation. The videos have audio.

So, we will try with the technical team, hopefully, to make the audio play. If not, I will voice over myself.

So, let's see. ...still give users direct network access to target systems. We take a different approach. The users only interact with a safe visual representation of the application with no direct network access exposed. In this demo, we will run several attacks, again, a vulnerable target with direct network access.

Then, we'll repeat the same attacks through our platform to show how it blocks the threat and keeps the application secure. On the left is an intentionally vulnerable web application. On the right is the same application protected by our platform.

First, let's try an attack by modifying the network request. On the left side, we log in as Alice and open the user profile page. The URL contains a parameter, ID equals to one. If an attacker changes this to two or three, voila, they can access Bob's data. But through our platform, the URL only shows a secure token with no other exposed parameters. The same attack doesn't work. Let's try another attack by modifying the cookie. We see a user role cookie. We change it to admin and refresh the page. We can see the admin panel, which should not be accessible to normal users.

On our side, there are no cookies from the real web app. Next, let's look at the page source. We can see a secret API key in the comments. On our side, the original source code is never exposed. Users only receive a safe, reconstructed view of the real site.

Now, let's go one level deeper and look at how the user's browser communicates with the remote browser. Open the developer tools, go to the network tab, refresh the page, and filter for socket requests. What is sent to the remote server is limited to user interactions, such as mouse movements, clicks, and typing. We use these simple attacks to prove a core point. When the user only sees a streamed application, they cannot modify network requests, tamper with cookies, view source code, or access the browser runtime directly.

The attack surface is drastically reduced and limited to user input, creating an isolation air gap. For input-based attacks, our AI layer provides the next level of protection, which we'll cover in a separate demo.

So, these were extremely trivial attacks, I know, but they are only used to illustrate a point. If you think about it, if you cannot see the details of the executed application, such as a web page, then basically you cannot modify them, you cannot attack the web page.

So, this is something our analyst friends have been saying for many, many years now, that if you have a web target that is really critical, that you really don't want to get hacked, the best thing you could possibly do is to use remote browser isolation on a jump host and then just stream it as video, right? Because when you stream it as video, you cannot really attack the target.

So, that's like the fundamentally best way of protection, because it's just streaming of visual representation. And if you just see pixels, how can you hack something if you just see pixels that cannot modify whatever internal workings of the app, right?

So, that's kind of like an understood thing, where if you can use RBI, great, but it's not scalable. Because if you think about classic remote browser isolation, that's something like one Chrome instance per user per session, and every Chrome instance requires a few gigabytes of memory, it will not scale to thousands of sessions, right?

So, the problem until now was not that we did not understand how to create this kind of stream protection, it was that we were not able to scale it to make it practical as a general purpose web application firewall. So, basically, that's one of the things that we addressed, and we basically changed the security assumptions, because if you think about it, classic RBI is trying to protect you against any kind of web threats.

So, they have to assume that whatever web page you go to can be trying to exploit the browser you are in, so they have to isolate on the layer on top of that, right? Because if the browser would get exploited, you don't want that to affect the rest of the system.

So, classic RBI isolates on the level of the virtual machine or a container, right? But if you think about it, if you rotate it and use RBI as a concept to create a web application firewall, then basically, the web page you are protecting does not attract actors to you, right? You don't expect the web page you're protecting to attack the browser that used to render it.

So, then you don't have to isolate on the level of a virtual machine or a container, and you can achieve greater density. So, that's what we are doing, and that's how we achieve basically isolation through remote browser isolation and streaming the visual output.

So, that is the first layer. Once we have this, we can basically add a layer on top of that.

So, what the next demo will show is basically a thing of like having a cybersecurity expert looking over the shoulder of every single of your user. So, what we are doing there is basically having a domain-specific language that is representing what the user is doing on the web page and feeding that to a large language model and asking the large language model if what the user makes sense, given what he should be doing.

So, let me show you live, not live on video. Okay.

Hopefully, it will play. Maybe a little help from the technical team. Just click play. If it doesn't, I will just explain. In this demo, we will show how our AI can understand the user-provided context, compare it with the actual user behavior, and block the action if it deviates from the intended purpose. In this first example, the stated reason is to modify user information.

However, the user attempts to drop a database table instead. The AI detects that the activity does not match the approved intent and stops it immediately. In the next example, the user provides a broader reason, performing some activity in the database. When the user tries to drop a database table, the AI still blocks the action because it is a destructive and requires more explicit authorization.

Finally, let's try a request that clearly states the intended destructive action. This time, the AI doesn't block the action and allows it.

So, let me just try to rephrase what we just saw here. Think of any kind of classic corporate environment, you will have some kind of ticketing system, Jira, ServiceNow, whatever else. And this usually already contains quite rich information about what should be done.

So, if there is a ticket, like admin needs to go to a system mix to do something that is described in this ticket, and that's basically context you can feed to LLM. And then what we are basically doing is having every action of the user trigger an LLM, asking it, does this match the given intent, which is the ticket of Jira or ServiceNow or whatever? And if it does not, then basically, we ask it again to explain why not, right?

So, if it matches, it's fast. Our engineering target is to keep it under 300 milliseconds for any confirmation. And when it takes a little bit longer is only if this fast detector triggers and something looks off. Then we ask it to explain why, and that's what you saw being displayed to the user, basically saying it doesn't match because the database is different, or his intent was this, and instead he tried to do something else, right?

So, it is just basically contextual understanding of the LLM given what the user is doing in that session. So, this means intent-aware access.

And now, basically, you could ask, what if there is an anomaly? How do we resolve an anomaly, right? Because as any AI system, if you don't provide enough context, or the context is not good enough, it may basically create a false positive, or it may disrupt the flow of the users in a way that basically they will not want to use it because it stops them from doing the actual work they have to do.

So, what then? How to basically fix such situation?

So, for that, we have a system which we call internally peer verification. You can think of it as a form of 4I control, where if there is any kind of anomaly and the system triggers, or you require access to another system that was not granted to you before, you can use this peer verification to basically have another person verify that you can proceed with this. Then we log it, it is cryptographically signed, and then basically you can have an audit and see who did what and why.

So, this is like a universal principle that we use not only on anomaly, but also for any kind of escalation. So, I will try to play it.

Hopefully, it will work. Such as authentication, authorization, anomaly session paused by AI. In this demo, we will show how peer verification works. A user is trying to connect to an RDP target. The user uses their phone to verify the request.

So, on the approver's phone, the approver can approve or deny the request. They are putting some pin code and it is hidden from the screen. The request is approved. After that, the user can connect to the target.

So, this would be quite hard for me to demo live on stage with two phones, so that's why we had it on a video, but what we just saw is just the universal concept that can be applied and configured for any action. You can even use it for if somebody should be triggered, if you want to access the system, you need confirmation from somebody else, right?

So, like a generic for a control, but we use it also for resolving any kind of anomalies. So, these were just a few demos I had prepared for now, but I can show you upstairs, or both, anything that interests you, or any corner case that you would like to explore.

So, I'm here to answer any kind of questions you may have. Thank you.