Cisco Hypershield: AI-Driven Security for Dynamic Environments

Hello folks. My name is Andrew Ooff. I'm distribution engineer and portfolio CTO for our network security business here at Cisco.

And here today with my colleague j Whi, who you will meet in a few to talk about Cisco Hyper Shield. Before we talk about sort of the details, the gory details, I would say of a hyper shield, what it does and what it is I wanna talk about how it fits into everything else we are doing with Cisco Security portfolio and specifically network security. Up until not too long ago, there was a tendency to use the network firewall for all things security only network, which sort of makes sense.

I had customers, very large customers, very big companies who managed to take a firewall, put it into the data center, and actually put each application host into a separate private or isolated vlan and use the firewall to stitch them all together. Which you can only imagine how complex, fragile, and, uh, well, frankly, mindblowingly interesting. I would put, put it that way.

It was. But lately, the tendency has been to simplify data center security in general, and this is what we call today, Cisco Hybrid Mesh Firewall. And the basic idea behind know three word term hybrid mesh firewall, at least not an acronym right, would be kind of weird to have an acronym like that.

But the basic idea is that firewalling is a function, not a device. So we take every environment and we build the firewalling function out of a device or product and application that's fit for that particular protection purpose. So if we take network firewall, which again we used to use for all kinds of purposes in protecting all kinds of things, it still belongs at the edge of your data center because you typically have a network and you do want to put features like IPS and maybe some malware protection, waf, API, gateway, whatnot.

You also use that with something like SD WAN to interconnect things like branches, campuses to your data center, which again, is very convenient. But then also lately, and we, we've heard that in some of the other talks today and probably yesterday, there's a tendency to do things in the cloud. Now cloud is your stuff running on somebody else's hardware.

So no exception with the firewall or any kind of cloud delivery security solution. It's the same feature set, same, more or less outcomes. We say running in the cloud.

But it doesn't mean that the cloud should be completely separate from your edge firewall. Cloud firewall. Edge firewall should be very similar.

So they should work together. So cloud firewall and on premises data center, edge firewall, they should work together to admit users, again, interconnect things and otherwise do what firewalls do In forest policy, if you look at public cloud, public cloud is now, that's again, your stuff running into somebody else's data center at a whole different scale because it's not just your stuff, it's everybody's stuff. It's running there.

Public clouds, each one is a little bit different and each has its own little tricks and twists on how you insert things. And obviously visibility is very different into threats and everything else in public cloud. So we have a solution called Multi-Cloud Defense, which speaks the language of public cloud and specifically serves in the public cloud at the edge as that edge firewall.

Slight twist on the firewall with that, uh, kinda hint of public cloud specificity, if you get deeper into the data center, get into the host operating system, for instance, again, kind of foolish to put a firewall in front of every VM or every host. So we have a solution called secure Workload, which goes deep into the application, looks at the process trees and how processes interacts, does various fingerprinting and behavioral analysis, and eventually feeds all that information into enforcement points like firewalls and, uh, built-in firewalls into the host operating system. So it does provide the firewalling functionality inside the operating systems.

And finally, last, but definitely not the least, especially today, we get into Hyper Shield. Hyper Shield is relatively new, not just a product. It is a product, but it's more than a product.

I'll talk about how it's more than a product in a few minutes. But Hyper Shield takes what workload does at the application host OS level and turns it into proper inline security for pretty much every input output call into every individual application. So we took the traditional firewall at the edge of the data center, and we went all the way down through the floor into the application host operating system, into the actual application attachment to the rest of everything.

And that allows us to not only do kind of segmentation you otherwise can do with a firewall, but also get all kinds of visibility. Not into the network alone, but into, for instance, disc access. Is this application writing something on a disc or adding something from a disc?

It shouldn't be. So again, a very, uh, granular way of segmenting things. And of course, on top of all that, you know, five different things doing five very important functions.

We have that one management layer of Cisco Security Cloud control, which again, I'm very, very confident. We've heard, we all heard about in other talks as well. So I'm not gonna spend a whole lot of time on that.

So Hyper Shield starts as the first tangible thing in this application security solution, quantum factory, whatever you want to call it. But hyper share, like I said, it's more than just one product. It's a, it's an innovation framework and that the innovation framework will continue expanding.

So it starts in the application, it'll expand across the entire network fabric. It is based on a few key principles or concept. So one, we want to really build a firewall engine into every device, every aspect of enforcement or connectivity we have across the network.

It could be something inside a switch with DPU data processing units. It is something inside the kernel with extended Berkeley packet filters. It's something inside virtual environment.

You get the idea. It is taking a consistent enforcement threat protection engine and dispersing it across many different little tiny firewalls versus one big one. Uh, then there is the data plan resiliency.

There's a tendency with traditional high availability clustering solutions to be a little more rigid. You upgrade, you don't really know what happens after you reboot. Is your firewalls still working the way you expect something being dropped because somebody made a an error in the code?

You push the policy. Same thing is, am I gonna get a call from my CEO? Because, well, we pushed the rule and it blocked something they really, really cared about.

So we have this concept of dual data plane or shadow data plane where every software change, every policy change should be tested automatically inside that secondary shadow data plane before we switch all production traffic to. So it gives you an opportunity to, well, preferably not have an outage at all, but at the very least if you do have a an outage, it is contained to a very small set of flows which are mirrored through that secondary data plane. So that's another concept.

And last but not least, everybody talks about artificial intelligence. Obviously AI is no, no presentation goes without the obligatory AI mentioned nowadays. But we do want to use AI for proper purposes.

We want to introduce AI to reduce, for instance, policy complexity. 'cause you have tens of thousands of applications. I worked with many bank customers.

That's literally what they have. Uh, I was, uh, at IETF meeting some years ago and was a presentation by a CIO of a major bank. And he was talking through, uh, some of the flows they experienced in their environment specifically because, uh, they wanted the TLS working group, which I was a part of, to do something to the standard to make things easier for them to troubleshoot.

Long story short, that didn't go through, but the one statement resonated with me. He said, we have, uh, 400 applications. When you, when you basically we go to your online banking, you click the login button, put in your username and password, there's 400 applications making 10,000 connections to each other, just to bring up that first page with your bank balance and all the other details.

And obviously, if you have to write a policy, which looks at 10,000 connections across 400 applications, doing it by hand is a very difficult task. It's a combination of application manifests from DevOps team, but also behavioral analysis and some of the artificial intelligence machine driven help that you get for read those policies. Make sure that yes, this connection or this call from this application to this other application is actually expected and legitimate.

And we all, we are all fooling ourselves. We think that application developers know exactly what calls their application make at any given time. Let's be honest about that.

So that's kind of the, the framing, right? So Hyper Shield starts as this application security component, but eventually it becomes this framework which incorporates those concepts across all kinds of network security products that we build at Cisco. And now to get into more details on Hyper Shield J Today, um, let's focus, uh, a bit.

So a hundred took like the top level message, how everything fits in the portfolio, how things are evolving. So now let's spend a render of time doing somewhat of a deep dive into, okay, what is hyper shield? What can it do?

How does it work? Right? So what we've been announcing and, and talking about quite a while, uh, are these two use cases.

And by the way, people keep asking me when is it real? When is it real? So lemme try to use an analogy that everybody always understands with cars is, you know, on these car shows when people have, like, when, when garvans have like these fancy prototypes that they always know how this super cool, but they're never gonna make it.

Well, we have this fancy prototype, but now we actually made it and customers start using it in early access and soon it will be like general availability. So it is something fancy and cool in my mind. Uh, and it's something that actually is going to be, uh, delivered quite soon actually.

So what we've been talking about initially are these two use cases. So autonomous segmentation, well, what's in the name, right? So the key thing that we're trying to do here is take the, the challenge of, okay, we have this environment that you want to segment for all the, the, the known reasons, right?

Reducing blast radios, segmenting things, keeping things from each other, uh, complying to rules. Sometimes it's just a matter of you need to be able to check a box to be compliant to this and that policy regulations, et cetera. And there's quite a lot of challenges with those things still today, right?

So this is a tough nut to crack. And with, uh, hyper shield, we actually realize that as we look at the technologies that we are able to use inside of tech, uh, of, of hyper shield, we actually have a few unique approaches that we now can start using to actually make life easier, right? And another, the same time, make it easier, but also do a much more thorough and in-depth, uh, job as us figuring out, okay, what is, what is going on?

So the whole idea behind, uh, autonomous segmentation is that, like Andrew mentioned, we now are using this critical technological called DBPF, right? So without making this in EBPF, eeb, PF deep dive, what is this all about? We are now inside the kernel, we're using a kernel feature, which is called EBPF.

That's a key thing to realize, right? EBPF is a kernel feature, meaning we use a feature and we don't need to go and start modifying the kernel, right? Because if you start modifying the kernel, in my mind, uh, a kernel regardless of the operating system, probably qualifies as being one of the most complex pieces of code and existence today, right?

So if every time you need a new capability, you need to start modifying the kernel to get access to that capability. Sooner or later, not so often things will happen, right? So by using an eeb PF uh, a kernel feature, it's a whole different ball game, right?

Because now you're no longer, uh, needing to change the kernel itself. You can just use existing functionality. Now, what is so cool about DBPF, it actually allows you to add certain specific previously not used or, or custom, uh, capabilities to the kernel, and we will run it inside the kernel.

And doing it this way actually allows us to do a quite, uh, some quite full cool things. First of all, from a performance point of view, it's about as fast as you can go, right? There's no more contact switching, there's no more, uh, refreshing, uh, cache tables, instruction tables and all that.

When you go from user space to kernel space and some stuff then hand off, back to user space. So there's none of that. At the same time, it's still very secure because some say, well, you are now running inside of the kernel.

Are you now not bypassing all of these kernel protection mechanisms? Right? The answer is obviously no.

I mean, we did think about it, and when I say we, it's the whole industry, right? Because EBPF today is mainly on Linux platforms. It's coming for Windows, but it's open source, right?

So the, the hyper scales of the, the likes of like Google, they have like, uh, made, uh, feathers, uh, to go and check, uh, and try and break and make sure that everything is up to snuff. They have a, Google has even released that feather that the, the, the research is there. So it's secure, right?

One of the ways that we actually secure it from a technical point of view is first of all, these programs, they run in a sandbox, right? So a predefined set of rules as to what they can do, right? They can do these things, they can access these data structures and they cannot break out of that.

Second, there's also going to be a just in time compilation process. So when we hand off the code, which is your mini EBPF script, all of the hardening will be checked. They will be, make sure that it's not going to bypass any of the kernel protection mechanisms, et cetera.

And then finally, we even do one additional layer of hardening, making sure that, uh, we don't do funny things with memory protect against specter and things like that, right? Since the CrowdStrike, I was just gonna say, see, every time somebody says the word kernel, then probably a kid and dies. So how do you prevent yourself from turning mediums of computers belly up Again, not you, but you know, you know, the event from, how do you prevent the event from repeating itself?

That event is probably one of the main motivators from Microsoft actually now enable EBPF as a default in their operating system, right? So eeb PF for Windows exists, right? You can, you can search it, you will find the, the GitHub rep with it's there.

The key, the key thing that's missing is it's not a default part of the operating system. So now if you want to start from a security vendor, try to start doing interesting things, like Andrew mentioned, the look at things at pro, at, uh, at, uh, process level, make sure that we can also apply some security enforcement things. If the kernel does not have a Cisco that allows you to do that, you need to modify the kernel, right?

And like I mentioned, it's a complex piece of code. If you make a mistake, everything blows up, right? Mm-hmm.

While now, because you're using a kernel feature, you use this small program, if you make a mistake in that program, that program breaks, but that program will never be able to kill your kernel. Okay? So what you're doing is actually getting feedback from the kernel, but you're not touching the kernel itself.

Yes. Okay. So you're just putting this right in the middle, in, in a way that you can interact with it, but without meddling or fiddling with it.

Exactly. Okay. That's why I stress at the beginning that it is EBPF is a kernel feature.

Yes. It's all about custom codes. And yes, it's all about customizing things, but we're consuming a kernel feature.

So we're not changing the kernel, we're just giving it additional bits of, of functionality. It's almost like a loadable module. But again, without the risk of a loadable module, because a loadable module, You, you're getting input from it.

Yeah. You still need to write the loadable module. Yeah.

If you may, if you get it wrong, same, same disaster, right? Things blows up, get die. Like you mentioned, all kinds of bad stuff happen, right?

So, so it, it's not a, a good place to be. So that's why EBPF is so appealing, right? So it's a very secure environment.

It's a reasonably safe, not just from security point of view, but also a safe way to start interacting with the operating system and everything inside the box, right? Because it's a very well defined set of things that you can access and change. Obviously by being inside the kernel, we can see almost everything because there's still like kernel specific memory locations that we can and should not touch, right?

So we cannot see that from what you can influence. The list is smaller, but still big enough to do is very interesting security protections at the kernel level, right? To give you an example, when I, when I start talking about distributed exploit protection, what we do there is basically take, it's, it's essentially simple.

The idea of what we're trying to do, but to actually build it is quite complex. What is distributed exploit, uh, uh, protection all about, well we have these public databases with non CVEs, right? Everything that every CVE is actually exposed in your environment today is an issue right?

Now we could say, well we can start looking at, uh, the kernel level. We see every single process. We can enrich that information with SBO style information.

So we say, well, we see a process that calls itself engine X. Well, we can talk with the package manager, we can talk with other things that on your system to figure out how, how did it get here? What is the version?

Then we can check, oh, this claims to be NX version one two. 2. Let's check that this is indeed what it claims to be.

So now we have with that view, see Just doing the integrity check as well, It's not well an integrity check. Yes. Because then, you know, yes this is an unmodified version, but more specifically now we know as a fact and near real time what is running where in your environment, right?

So now we know everything that's running, what the version is and all of that. So once you have that view and you compare that with the list of public cvs, now we know everything that's wrong with your environment, right? Linking that with your vulnerability management program, you'd be able to be a lot more accurate in what's actually vulnerabilities in your environment.

Yes. 'cause there's no more guessing involved, right? We know for a fact Lots of potentials.

Yes. Before you had to wait to see traffic. And then you see there traffic coming on 4, 4, 3.

Let's look at the handshake. Let's see what we can see in the head that are not encrypted and start deducing what's there. But there's always some level of guessing.

Now we don't need to wait to see a traffic, right? We see the process spin up even before nGenx even opens a socket. We know it's there.

We know the version, right? And now once we know the version, we know every single thing that's wrong with that particular process. Right?

Now that's a very depressing thing, right? Because now we can actually say every single CVE that's exposed in your environment. So at the same time, that's being very, very depressing.

But now comes the second bit, right? By being in the kernel, it's not just about seeing things, it's also being able to influence things. So now what we do, we have a big fat AI that is consuming all of this public CVE information and what it does, it tries to create an EBPF program that will prevent an attacker from abusing this vulnerability and that EBPF program will load in the kernel.

So essentially what we do, we make those CVS non exploitable. So from an attack point of view, it's as if they disappear. They're still there.

But then attacker can't do, do do anything with them. So to give you an example how that looks like, right? Because I might be quite tricky to wrap your head.

Around a while ago we had this vulnerability and SSH where there was some funny business going on in one of the supporting libraries lip, LDMA, some funny business. Uck in and SSH actually loads that library, then it's uh, exposed, right? Then bad things can and probably will happen.

So then you could write a shield that says, look, if your SSH process, he's trying to load this library, prevent it from loading one of the non vulnerable versions, right? Only allow it to load a non vulnerable version. And that you can now do because loading a library, that's a, a ker call, right?

So now you, that's one of the things we are actually through EVPF able to influence. So now when you run that shield, now you can prevent SSH from loading a vulnerable library, right? So the vulnerability is still there as long as that library is available on your system.

If a process would load it, it would make that vulnerability exploitable. But now we can create a SHIELD and UVPF program that says let's not load the bad ones. The impact of that is like how accurate is it in the sense of like, uh, a lot of, a lot of very vulnerable systems are running older versions of things because they have to, they can't upgrade.

And so my concern is am I going to impact, um, the business in any way? Am I going to stop them from being able to do what they need to do because we think it's the malicious actor. Yes.

So there's a few things to that, right? Um, one, first of all, if you look at what we are currently doing, so we have this AI that takes this CV information, calculate shield, right? We need to verify two things.

First of all, is the shield doing what's supposed to be doing? Meaning is the exploit no longer working? That's reasonably easy for us to do and automate the testing form, right?

Because we generate the exploit code, we test the exploit code, we apply the shield, we test the exploit code. Again, if the exploit code no longer works, we put in the knowledge, well pretty sure that okay, the exploit is prevented. Mm-hmm.

But to your other point, that's that's only half of the equation. We also need to make sure that after deploying the shield, we don't break anything else, right? The replication needs to stay working.

That's a tricky bit. So that's the bit that we're still working on, on automating all of that. So one of the reasons why our early, uh, access customers only have a very short list of shields available.

That's because of the sheer amount of human labor that today we still need to go through to validate to your point. Exactly. It's not just about preventing the attack, it's also about protecting the workload and making sure it still continues to work as, as, as, And I guess you will maybe start with a detection mode as well.

For some policies we just say, okay, you have all these machines that are currently vulnerable, they're loading the process that should be updated. So at least that we have an idea before, let's say we intercept also the traffic, uh, which systems are let's say vulnerable to a certain attack type. Yeah.

And I can also imagine, I remember many moons ago, uh, we had a lot of, uh, endpoint security vendors were doing endpoint firewalls with u running in user land performance was really bad. The the red flag. Now we have this additional flag of kind of always the processes in the context of the policy.

So our policy gets a bit more complex compared to, let's say, traditional firewall policy where we have just source destination parts. Yeah, you always have to consider this additional process, but you can now 100% say this is a correct process that we are accepting. And then all these things were, I dunno, attack us renamed processes or, uh, do all these things that do not longer work.

Yeah. With this policy model. Yeah.

Yes. And to, to both of your point, you can extend that line of thinking a bit further, right? Because we need to make sure that we're not breaking anything right now.

Keep that in mind. Now we've talked about a system that can detect a whole bunch of things quite with a high degree of certainty, right? So we improve the how sure we are about things, but at the same time, it's still a system, a security system that's telling you as a security admin, oh, we think you should be doing this.

So If that's where we stop, I don't think we'll be very successful, right? Because why would you trust it? I mean, this thing is saying I want you to deploy the shield and the example I just gave is a very easy one.

I can show you another one, which on the surface sounds very easy, but if you then look at the implementation, it's like, well, I need to be a kernel expert to figure out what this thing is doing. Understanding a single access list entry is easy. Understanding some of these hyper shield policies is everything but easy, right?

So we need to have something else, right? So what I've described so far is awesome if you trust every single suggestion it makes. But I have not done a single thing yet to get you to buy into that notion, right?

Yeah. So I guess that what you would be using, 'cause AI is everywhere now, right? So you're probably gonna be feeding the data so that the AI will be interpreting all these things for you and try to reach to it and put it right in front of you, or Yes to a point.

So we use different flavors of automation and pattern recognition and AI or machine learning as mm-hmm as you want. Now the big place where we use AI today in the context of hyper field is to generate these fields, right? That's the big part where we use AI everywhere else, it's algorithmic borderline machine learning, right?

So there is no direct interaction with an AI models. However, these shields and even the pattern matching and the abnormal anomaly detections that we do, those are still, whether or not it's an AI or an algorithm or some developer, you need to have a way to gain some trust in it, right? And it's not going to be by at some point saying, yes, okay, let's go for it.

Let's, let's run rule in a production network. Let's not the way to gain trust, right? So what we came up with is actually something quite, uh, I'll just skip through to get there.

Quite simple, but very efficient because to Andrew's point, AI is perhaps not yet everywhere, but it will be everywhere. And one of the key things is whenever AI assists in coming up with a suggestion, what do you see in this day? And H is, well, the AI is so much percent sure, oh great, what does that mean?

80% sure. Wow, this one is 90% sure this one is 99% sure when, is it sure enough for you? I don't know.

The thing is Hallucination, hundred Percent sure. Yeah. I To say, if it says I'm a hundred percent sure, would you trust it?

I would even trust it less, right? So what Do we do? Things in my life for which I have been very little, I have been in a very low percent sure.

So I'm not really sure if actually see, I'm not even really sure that it is a bit confusing though. But I guess you're gonna be doing this on the detail twin and everything's gonna happen on the shadow data plane. Exactly.

And the moment you confirm it, then you switch it. We Should swap places. I don't talk that fast, but my respect.

So to your point, that is the solution that we came up with and I love it because it's solving a very difficult problem in a very simple and easy way, which is you have the data plane where all the magic happens, right? Where the policy is enforced. Now we just introduce a simple thing.

We introduce a shadow data plan, which is as a performance impact goes not that much because we're not replicating the packets, right? We're sharing the pointer to the thing, we let it decide. So if we have a new policy, for example, we have this new shield, this new segmentation enhancement, we run this in the shadow data plan for a while.

We look at the differences. And the cool thing is the shadow data plan is not in our test or your test environment. This is in your actual environment.

So there is no more gaps in, in testing. You do this wonderful test and test environment. You go live, things still blow up.

Why? Because there is a difference. And that difference is accounting for something you did not anticipate, right?

So this is running in your actual environment. We run some tests and we compare what you, what the policy is suggesting you to do, and we see how it would behave. And then what we do, and by the way, this is not the percentage point I was just making fun of, right?

This is a very measurable thing of how many percent of the actual tests passed. Now again, if I say a test is passed, you again need to trust me. No, why not?

We tell you, look, this is the actual difference. We say it is passed, but we tell you why it's passed because the difference is within 5%. For example, if the CPU difference is within 5%, we call it passed, but you might be in a high compute environment and for you, anything more than 1% might not be passed.

So again, in the test report, we give you all the data to make up your own mind. 5 of a percent. We even show you for each of the different policy rules different than headcounts, et cetera, right?

So now we give you on a platter, this is what the behavior would be of this particular policy. So that we use this as a way to let the system try and convince you, right? Because now it's no more pinky promise and we test it on, on q, free environments and all of that.

No, we actually said this is what would happen in your environment with everything that is your unique hardware, your unique, unique software footprint, your Linux, uh, traffic footprint, et cetera, right? So this is our attempt at trying to convince you. So this is a very measurable score, right?

This is 80% of the test cases. Each of the test cases, you get the data in the test report, and you can even agree or disagree, well, this line is passed, but for me, this is not passed, right? Because the margin of error or the margin of difference that you consider to be passed for me is not acceptable.

And as, sorry, sorry. Please go ahead. No, I was just gonna say the, could I tailor it so that I don't have to constantly look into the details?

I can just say this margin needs to be less than five 1%, as you said. Could I have that so that then it would be more accurate? So we don't have to continuously click through?

Yes, but there's a few things, right? So one thing with a, with the hyper shield, everything is API exposed. So our UI is nothing more than like with OpenStack horizon, a graphical front end for a human to translate a mouse and a click into an API code, right?

So everything is automatable. So we are planning to make the, like the, the passing rate human configurable. But at the same time, you can also plug this in, for example, with an automation pipe, A-C-I-C-D pipe, whatever automation, even just a simple python script to say, look for these types of events, if these scores are within that we can do, we don't even need a human to check anymore.

Obviously the long term goal would be you do auto to approve everything, right? But today, there's no point, right? Both us as an engineering group, as you, as a, as user, need to gain trust that this does what it's intending to, right?

So that's what this test report is all about, give you the raw factual testing data of what it's proposing so that when it comes, oh, by the way, I want you to go left pinky promise noise, I want you to go left and if you go left, these are the wonderful things you will see, right? How long is the evaluating that you normally do here for this? So sometimes we have something that is just occurring, let's say on a free, I dunno, a backup application just once a week or so.

How long do you start the telemetry and what are the comparability? So features you have, yeah, Today it's a hard code. It's uh, length of time we're testing with a whole bunch of different things.

For example, start with a minimum amount of time and then look at rate of change so that we see are these test results converging? Or for example, well, we've never saw anything, so that's why I used this example, right? So I could have used the 100% score, but here for example, we see two things.

First of all, there is no hits on the policy. So I've been smoking something and I've made the wrong policy, or I did the test when the traffic was not there. So yeah, I need to rerun the test because right now I can see, well, this test is meaningless, right?

I need to either change my policy so it actually does something so that these headcounts are nonzero also, that the difference between the primary and the shadow is there. Because even if there were headcounts, if the headcounts are the same for primary, uh, shadow, again, your change is not doing anything different, so why bother, right? Or you might see, well, there is, uh, there's no difference or you don't see the traffic.

So you might need to run the test again at a later point in time. So that's why one of the things that we're looking at is a minimum fixed amount of time plus a rate of change to influence how long we test, right? So basically you just need to define on the back end, how long can I store this, uh, traffic data so that I can, this is Not storing, this is testing in real, in real time.

So as, as you deploy this in the shadow policy, in the shadow data plane, this is in real time, right? So as traffic is being seen, we update the differences, uh, that we measure the differences that we're actually looking for. CPU memory, are we dropping, denying the same package as the, the latency changing all of those things.

And once we stop testing, we generate a test report, we store the test report, but it's no longer being updated, right? But Sure. But, uh, to, to get into changes that are just occurring occasionally you need to have a longer evaluation date.

So you need to store the metrics somewhere over a longer term period of time to, You mean historic references and that kind stuff, right? So to get These, yeah. So another thing that, uh, just because he's mentioning this, uh, we're talking about digital twin as, as with any of the highly available and redundant structure or, or an element, then it requires certain expense, certain commitment or compromise is the right word for this.

Then from a performance storage and processing point of view, then what, what's actually what you're giving away? What's the, the cost of all this? So obviously if you introduce a second data plan, it's going to consume more resource resources than if you didn't.

Right? Now, I didn't really talk about the different enforcement points, but each enforcement point has a different implementation. For, for example, on A DPU, it's done in P four and the enforcement vm, it's in a VPP stack, uh, and an an operating system, it's eeb PF, right?

So what we do is we make sure that either we put a guardrail in place in case of EVPF, because by being in the kernel, we can now say, do not allow this to consume more than do so much percent CPU. So it's no longer a data sheet promise. We can actually have a kernel rule that says, do not consume more than that, right?

Mm-hmm. And it cannot break it. And the VPP implementation, for example, we say the shadow can only consume idle CPU.

Mm-hmm. There is no in no impact, right? The only impact might be, well, if the system is not having any ECP available, the time, the test will take more time or never finished, but then at least, you know, while the system is overloaded, right?

So we put all these things into place. I think we're done with questions. Perhaps if we have time for one more, otherwise we close.