Visibility into the Cloud – Identify Risks and Threats in Your Cloud Environment with Fortinet

Hello, my name is G O'Brien and today I'm going to be talking about Fortinets product offering called Forti Synap. So what is a for to C app and why would someone want that? So, forti synap, uh, SYNAP stands for Cloud Native Application Protection Platform.

Um, and that's kind of a fancy way of saying it's a set of tooling that allows you to get insights into the chaotic and tumultuous nature of the cloud. So, uh, we all know the cloud is just, um, you know, uh, a playground for developers these days. It's super easy for them to create resources, create networks, and it gives a headache for security professionals to try to keep, um, up to speed with what's going on in the cloud.

Um, and it's not really something that individuals, uh, can do. They can't log into every cloud console. They can't look in every region and every account.

Um, and things change so fast it's almost impossible to keep up with. So for, to synapse sees cloud security as a data problem, as a big data problem. And so to solve that, we take in data from these cloud environments and analyze it hour over hour to learn what's normal for your environment, for your application, for your business.

And then we only let you know about the deltas, about the differences about any anomalous activity that's happened within that environment. That could be things like someone logging into your, uh, cloud console from a new geolocation they've never logged in. That could be a, a workload making, a network connection outbound that you've never seen before.

Anomalies like that will raise for you to take a look at. And maybe that's normal. Maybe that someone's on vacation and they just logged into the console to check something for work, you know, could be fine.

But we want you to know about those anomalies. And then you only get those high fidelity alerts about those changes. And we try to reduce the noise of alerts.

So how do we do, how do we give this visibility into the cloud? Um, we have a few different ways that we do that. Um, the first and the easiest two ways to do that don't involve involving developers.

You just need some cloud credentials and to be able to run some infrastructure as code is, um, integrating directly with your cloud. Um, and basically that allows us to pull in cloud activity logs, which we can analyze. It allows us to pull in configuration and all of the permissions and roles that may be, um, assigned within your cloud environments.

Um, the next one we do are compliments. Uh, we have our agent list and agent, um, capabilities and those complement each other. The agent list is very similar to our cloud integration.

You basically run some infrastructure as code, or you can do some click ops to set these things up. And we scan, we take snapshots of all of your VMs, whether those are raw compute instances or nodes in a Kubernetes cluster. And then we can analyze every single file within those volumes to look for, uh, known bad binaries, to look for vulnerability, vulnerable packages from applications like Java, Python or PHP.

Um, and then we have our agents. And this requires a little bit of engagement of your development teams or your DevOps teams to get this into your development and your deployment processes. But these can be installed on VMs or within a Kubernetes cluster.

And this gives you real time telemetry about what's going on in your environment. We can monitor the network, uh, to make sure, um, and track all outbound and inbound requests that are going on within your environment. We can monitor individual files for changes like password files or configuration files, and we can, um, do limited scanning for vulnerabilities as well within that environment.

Um, but we don't want, we want to keep the agent performance, so that's why it compliments the agentless scanning we have that can look at every file. The agent only looks at a subset of files. 'cause we don't wanna destroy your disc or your network or your memory or your CPU.

So we try to stay very performant. Um, and we also can notice new binary watches so that that's all the data that we can collect out of the cloud. And as I said, with that, we analyze that hour over hour baselining looking for anomalies that happen.

And the final way we can help secure the cloud is with code security. And that's part of that shift left story that's going on in security where we'd rather stop security issues before they make it into production, before our vulnerability scanning can find them before agentless scanning can find them. And so we can integrate our code security directly with your Git repositories, whether that's in GitHub, uh, Bitbucket or, um, GitLab.

And there we scan for known vulnerabilities and IAC uh, vulnerabilities as well. And this compliments the rest of our, uh, cloud offerings for sure. Yeah.

You mentioned a lot of different capabilities. Yes. Are these all under the umbrella of four to capp?

Yes. Okay. So if I was looking to purchase something like this mm-hmm.

Would it be a single license or are some of the things you're talking about additional add-ons? So, um, this is under one platform for sure. There might be some differences in the pricing for different, uh, portions of our platform, but you can purchase all of this under one, under one license.

Okay. But if I already have a code scanning solution mm-hmm. That I'm happy with, right?

Yeah. I don't need to pay for your solution. I could buy a smaller package Yes.

That include the parts that I don't have a solution for you. Yeah. I'm not exactly sure how granular you can get with that, but certainly, like if you don't want to use our code scanning, you're not required to integrate with that.

It may come as part of one of our packages, but you just wouldn't end up using it. That'd be something you can negotiate with your sales person for sure. Yeah.

I I just know a lot of organizations already have a code scanning tool for sure. That the developers suggested or the InfoSec team suggested, right. So they might not be as interested in that Yeah.

But scanning the cloud portion and especially into Kubernetes clusters and other, uh, platforms that are part of that cloud. Yeah. That's, that's pretty useful.

Yeah, It is very useful for sure. Yeah. Sweet.

And, and the agentless scanner, you're essentially taking snapshots and then attaching those to a external instance that is doing the scanning? Yeah. Um, I, I glossed over a little bit.

Um, we're kind of running short on time, so I was trying to move a little quickly, but with with Yeah. No, no. Good.

No, it's a great question. It allows me to, to answer this a little full, a little more fully, um, the way the agentless scanning works is we call it secure by design. So we, when you do the deployment, you deploy a little bit of infrastructure into your cloud account, and those snapshots all stay within your account, uhhuh.

And the only data we ever get is that metadata about those pa those, you know, paths for the files and the vulnerabilities. You're spinning up instances that are attaching those snapshots and scanning them Yeah, exactly. Within your environment.

But that way we never get, we never touch your sensitive data if there's, you know, credit cards or you know, other sensitive, you know, right. Um, person you're Just sending metadata about what the scan finds exactly. Your platform.

Yep. Okay. Yeah.

And that happens on a cadence of like as little as six hours to 24 hours as normal for something like that. And you can control that through the platform. So How much of the signal that you have from things like when we've got like supply chain, uh, issues, you know, we had, like recently there was a go library that they had redirected the source URL to like a, a, a mirror mm-hmm.

Changed it. So like we were just like deploying, deploying, deploying. So when that comes up in there, how much does Fortinet know about, like, outside stuff that feeds into the, so inside checkers We might be able to scan and see the, like if there was a known hashes for those binaries or those artifacts, we could scan and find.

But that redirection is out like in your build platform, which would be outside of our normal purview to see, um, you can integrate our agent into our com, our CLI into your build process, and it can scan the code or scan images as part of your deployment pipeline. But I don't think we'd be able to see that particular, like that it was going to the wrong URL. Right.

Because it's not within your, necessarily, within your cloud account. So, yeah, good question. And then quick question from a DevOps team perspective, I'm curious about, you know, what is like, first off, is there like a demo or something, um, that we're able to check out if we were interested in, you know, implementing this in our infrastructure?

And then also is there any like Terraform modules that we can use to spend the sub? Yeah. Yes.

Um, all the stuff I talked about, um, except the agent itself all has Terraform modules that you can use. When I, I, um, I, I build out the, the demos for, um, for, for the C app. And so I use Terraform to, to create and destroy all of those integrations for sure.

Yeah. And Okay, nice. I'm all about Terraform in all the things.

Oh, yeah. So am I. It's a, it's a great tool for sure.

Yeah. I click ops is, uh, is too, it takes way too much time. Exactly.

Yeah. Um, uh, as far as the demo, um, probably the best way to get a demo to reach out to our sales team, and they'd be happy to give you a demo. Um, and if you're, you know, wanting to do self-serve, they can get you hooked up where you, I can add you as a user to one of our, um, te demo tenants for sure.

Within the organization. So, yeah. Awesome.

All. So once we have all this data from that we've collected from your various, uh, cloud sources, we've basically split those into two buckets. That's, uh, risks versus threats.

So in the risk side, these are all those latent issues that may be, uh, lurking within your platform. Those are mis misconfigurations at the cloud level. Those are vulnerabilities within the software packages and the software that's running your environments.

Those are, uh, too many entitlements assigned to users. Those are all these things, all these risks that we have. And then we have our threat side.

And the threat side is all the active things that are currently happening within your environment. Those are alerts that we may send you about, uh, events that we've seen happening. Those are those, uh, anomalous connections to bad URLs or external, um, uh, sources that, uh, are new.

Those are logins from new geolocations using API services or deploying resources into regions you've never used before. Um, and so those are the two broad buckets that we split things into. And finally, oh man, I hit the wrong one.

And finally we're going to, uh, I'm gonna just give you a quick overview of sort of the deployment that we have. Um, you can see here, this is a very, uh, sort of typical e-commerce application that's deployed into AWS. We have on the, uh, right hand side, we have some, uh, sorry, I'm on the wrong laptop.

We have over here, we have a, uh, we have, uh, all right, on the right hand side, we have an internet gateway with a load balancer. We have a Kubernetes cluster that has a number of different containers running in it. There's a front end that is the website that, uh, we saw in Julian's portion of the demo that talks to a few microservices in the background.

Um, down service, we have some stuff talking to API gateways and Lambda functions. We have some databases that we're, uh, recording stuff in, and a few raw EC2 instances that we're, uh, doing backend reporting. So this kind of makes up a very sort of typical architecture for a cloud deployment.

And so now I'm gonna, I'm gonna end the slide and I'm going to switch over and we're gonna actually take a look and see if for to C app could have caught this, uh, attack that Julian performed. Alright, so now we're in the, uh, four to C app, formerly known as Lacework platform here. And we're looking at, we're in the, uh, threat center, and we're looking at a set of alerts that have come in.

Um, and these are, uh, you know, you could get notifications via email or other alert channels that you've configured within the platform. And so, as you can see here, we have three kind of very bad looking alerts. We have the first one here, which is a crypto jacking artifact.

We have a potentially compromised K eights alert, and we have a potentially compromised host alert. None of this sounds like a good day for a, for a company. So we're gonna go through all three of these and just take a little, little look through and see what we can find out about the attack that that, um, happened.

And so in this one, we see it's a crypto jacking artifact. It says it detected a crypto jacking artifact. Crypto jacking is an act of hijacking cloud infrastructure to illegally mine cryptocurrency.

So that sounds like a bad time. We can see that Root was involved in it. Um, it looks like it was, um, on, uh, this, uh, Umuntu, uh, server.

If we go over to the, uh, processes, we can see it ran on a few different VMs or a few different virtual machines. Um, we can see the process IDs, and if we highlight over here, it may be a little hard to read, but this, we can see the, the commands that were actually run. We can see Bash was started.

They installed some curl, they, uh, downloaded XM rig from GitHub. Looks like they did some, uh, configuration, and then they started XM RIG and ran it. So, uh, this looks definitely like confirmation that XM rig was run within this platform, within this, uh, in cloud environment.

Um, just to, to, uh, show the sort of capabilities of the CNAP platform, we'll look at, um, a little bit more data. One of the things you really want is as much information about this attack, about what happened, about what risks there might be in there. So we're gonna look at the exposure view here.

And we can see here that this, uh, exposure polygraph shows sort of a, a how an attacker, uh, could gain access to this. It shows that we have an internet gateway with a load balancer, a security group that leads to this EC2 instance, which is one of those, um, nodes in a, in the Kubernetes cluster that we, uh, that it, uh, was, has been breached. And so now we can, we could look at each one of these in detail if we wanted to.

We can see there's machine details here. It looks like there's a whole bunch of vulnerabilities on this machine. We can get the internal IP address of it.

Um, this could help us, uh, locate that within the, the cloud console if we wanted to. Is Lacework, Uh, built into cmap or is that, is this like where we're talking about a Different thing? No, no.

So, um, Lacework was a, a startup that got acquired Yeah. With Summer by, by Fortinet. So it's now been rebranded as for to capp.

So it is, this is for to capp, even though it says Lacework up there. Yeah, sorry about that. Sorry.

No, no. It's a, a subtle difference. It's referred to as for to capp.

We haven't updated all the branding quite yet. No, good question. Yeah.

This is for to C app, what we're seeing this entire Platform UI team's always the last one to know. Right. Take a while to get those logos updated.

The last thing to be updated is the executable, right? Yeah. Our CLI is definitely still called Lacework.

Oh, The last thing to be updated is the program from our frameworks. That's why Mac OS still has everything labeled ns. Fair.

Fair. So in this case where you were capturing the CLI, uh, yeah. Like you were capturing the artifacts from the active session.

Yeah. What's that pulling from Cloud Trail? Is it sort of like an eeb PF sniffer that you've got basically, as you can see, the outside of the container where This would've been the agent that That's inside the agent?

Yeah. The agent would've been running a bit, been able to see that. I don't think this would've made it to the cloud logs, because this is all happening within your vm, right?

Right. Mm-hmm. So the cloud logs generally would see like if you created new resources or you deleted resources or added a user, things like that.

But all of this would've been opaque pretty much because it's happening within the vm. And so AWS isn't monitoring every single thing that's happening within the vm. They might notice some of your, um, uh, I've gotten warnings for running crypto miners before from AWS, so they might notice that egress stuff, but none, none of this stuff going on internally.

So, yeah, so we can see, we see some more machine detailed machine tag summaries here. This is all just part of your root cause analysis, trying to gather as much information. We can see, uh, the security group here that is attached to this, uh, vm, and we see it opens up a, a whole lot of ports, uh, maybe more ports than it might actually need to.

Um, a lot of outbound rules as well, including that interesting 80, 80, uh, port there. Um, we could look at cloud, uh, cloud the cloud configuration and cloud log trails. And then, um, another thing that, uh, would draw, would draw our attention to this particular, um, vm.

And part of why I'm showing you this screen is that we can see the role that's attached to this particular clicked on it, and it went away. Oops. I didn't, So just to confirm, I know you mentioned like you could get agent agent list installed via, uh, running on Kubernetes via pod or on a vm, but if you are incorporating, like your entire cloud environment, is this this just like a service within the marketplace that you're enabling to scan everything in your, in your console?

No, you'd use like Terraform or cloud formation if it was AWS to set up these integrations, so, Oh, okay. Got it. Got it.

So it's not like a service that's just scanning everything. No. Okay.

Got it. Got it. No, this is, uh, yeah, there's a few different ways you can integrate, but usually it's running cloud formation that sets up a trust relationship between your cloud and our cloud to be able to pull those cloud trail logs and your configuration data out of your cloud account so we can analyze it in our backend.

Okay. And is it like, is it, uh, uh, what is it not container insight. It is Container Insights and AWS, right?

Yeah. I've never used that CloudWatch. And so Oh yeah.

It can incorporate all that. Yes. All of those, all the different logging.

Yeah. I can pull all that logging in Yes. And analyze that.

Okay. Exactly. Yep.

So, um, one of the things that we can see here is the identity that's attached, or the role that's attached to this VM is this EKS node group role. And we have a whole bunch of details about this, including that. Um, for of Synap has, uh, rated this as a risk of high, and we can see it allows credential exposure, it allows full admin, it allows am, right?

It has a whole bunch of things that would make this roll if it got compromised, allow them to basically move laterally into the cloud, create their own users, create their own keys. Um, so this is definitely an anti-pattern for security. Like you normally would not want to do that.

So, um, and we could dig deeper into the identities to look more into this role and see how it's been used. So, um, so this, this alert isn't looking good, we're gonna move on to the next one. And this is the potentially compromised K eights alert.

And what we were looking at before was one signal that was one alert tied to one event with some data that we've collected around that. Um, that particular alert, this alert is what we call composite alerts. This isn't composed of just one single event.

This is, um, an amalgamation of many weaker signals to bring a one higher efficacy alert, um, and bring all that data together. So we can see this looks like, um, this Kubernetes cluster was compromised. We can see some details here about the roll and the arms.

We can see there was an anomalous login to this, uh, Kubernetes cluster. So someone logged in that wouldn't normally have logged into this cluster. Um, then we can see the, uh, the user that they use.

There's this Dessy user that we, uh, that we saw that has some, uh, admin privileges associated. I think that looks sketchy. I, I know.

Yeah. Um, we can see, we saw some anomalous activity. Um, looks like it made a bad external, uh, connection to this XM uh, pool.

This is a crypto minor pool that the XM rig binary communicates with. We can see the, uh, applications that, um, that were vulnerable applications involved in this attack chain. And we can also see, it looks like that we found there was a reverse, possible reverse shell.

We can get more information. It looks like we can see the exact, uh, launch with a binary, this XM rig got launched. Um, we can see a new workload was created.

So some new pod got deployed into our environment, um, that we haven't seen before. And then we can see more information about the, uh, crypto miner itself. Um, in this one here, you talked about it being a composite alert.

How much, what are the other source signals that you're drawing from? Like how much is Lacework pulling in from other sources? Like, and like, whether it's like attaching your steam, how much is pulling versus pushing to lacework?

So Lacework is, is pretty much at the, at the moment, only analyzing its own data. Okay. So it's all the data we've pulled in from the cloud or from our agent or agent list data.

Um, we have other tooling within four to C app that'll be able to pull in data from, uh, uh, from other sources, including four to cna. And we'll see that in the, uh, after the third part at the very end if we have enough time. So, um, taking that a step further.

Yeah. What, What's the security database like? Is it CIS and NVD in the background?

Is it Fortinets own security Database? Oh, where we get the CVS and stuff? Yeah, yeah, yeah.

We have a, a variety of sources that have changed throughout the years. I know we're moving to also incorporate the fortinets, um, security, uh, of vulnerable data for guard, for guard. But, um, but yeah, traditionally, I don't know the exact one we've used, we've changed a few times, but we, I know we pull from the governments, uh, databases as well as other Yeah, as other, right.

Got It. As better take an offline copy. They're disappearing by the session.

Yeah, I know. That's a good one. I know CISA got, well that was one, one of the things that we just had is like, CISA is being sort of dialed back in some weird ways.

And so like, is there any chance that we're as a, as a group at risk because something's gonna stop where we're not getting updates from, right? Yeah. That's a, that's a serious concern for sure.

Yeah. Not to get political, but not dialed back. Absolutely.

Leaderless something like unfunded, gutted might be a good word. Yeah, for sure. Um, so I'm gonna take a quick digression from the alerts.

We're gonna get back and look at that third alert, but I wanted to at least touch on the, the risk center. So these are things that are happening within the environment, and we know that we've, uh, that we've heard there's that log for J vulnerability. So I wanna hone in for that for a sec, see if we've been paying attention to, um, four to a P and what it was telling us if we would've been able to possibly prevent this particular attack.

So we see there's a series of, uh, CVEs that are open, um, I'm assuming when, yeah, there we go. Yeah. You can see that they're, uh, attached to this log for J vulnerability.

I'm gonna copy this CV and we're gonna dig just a little bit into it and take a look. Um, so we can see here, um, we can see when this vulnerability was, uh, entered, and we'll be able to see, uh, the containers, the, the exact package that this vulnerability is present in. So it's present in this Apache log for J it's a Java application.

It's impacting one container. So we'll take a look at this container. This would be useful for the, um, DevOps team to know what container exactly it's running, where it's being pulled from.

We can see the name of the repository, we know it's in Docker io, and we can get the exact Shaw, the exact identifier for this particular container that's, that's, uh, built and running in our environment. So, um, this would help for that DevOps team. Uh, let's see.

Now if we can take in, uh, move over to the code security side and look at the application security. Uh, we're gonna look at the third party vulnerabilities and I copied that CVE over, so we're gonna find that CVE here. So our code security scanning also found the cv.

If we've been looking here, we could have prevented this with a shift left. We'll click in and take, um, take a quick look at the details here. Uh, we have a couple, uh, one very interesting offering that Fortinet, uh, for a synap offers to help fix this.

So we can see some details, the criticalness of it, um, how exploitable it is. And down here we have the information about our particular environment. 61.

There is a fixed version that came out. So when a CV is opened and the, the developers of that package or that library fix it, they'll often post a, a, uh, fixed version that you can upgrade to that fixes that critical vulnerability, right? Um, and then we have this thing called Smart Fix.

We'll take a look at in a minute. Um, we can see the exact repository for this, um, unhackable e-commerce app. And if we see, we click here, it gets us right to the exact lines of code.

So this would help if we were gonna try to open a ticket where security practitioner, we wanted to see the uh, dev team to be able to fix this. This would give us the exact line and the exact repository of where they need to fix that issue. So let's go back to Smart Fix.

71. 82 still has vulnerabilities. You can see here it did fix some of them, but it still has two critical vulnerabilities in it.

82, you'd fix the log for Shell vulnerability, but you'd still be, um, vulnerable to several other critical CVEs that are open against this log for J Library. So what Smart Fixx does is it starts at your version and walks that release tree, comparing it with known open CVEs to give you the closest version that you could upgrade to that's free of critical vulnerability or vulnerabilities, but it also gives you that whole pedigree. So you could decide maybe that upgrade's gonna be a full point version, which is may have backward changing, uh, things and it's gonna take longer to develop and fix and test and get released.

So you may want to live with a low or medium severity to get it that's within your point release you're already on. So you might wanna release that quicker while the devs have more time to work for that full point release to be able to do that. So we give you that full pedigree.

So this really allows you to dig in and kind of, uh, get that fixed and reduce that back and forth between you and the security team. Well, you highlighted what becomes the most common problem. We're all stuck on the alerts 'cause we're a lot of ops people, right?

And we love our alerts. Yeah. We love alert fatigue, right?

'cause we live off of it like caffeine uhhuh. And when we get to this, the first thing is like I get dependent bot emails that are just heroic and the numbers that I get and it's constantly telling me that I'm doing dumb things in my repos and I also can't move forward. 'cause I'm not a really competent developer, right?

So I could really break a lot of my own applications. Yeah. So I'm constantly weighing that risk when you have this, how does the security engineer tell a developer, by the way, yeah, this is a problem.

What are we gonna do about it now? Yeah. And there's a very human in the loop problem we have in everything that we always wanna move to automation, right?

But a very short percentage of people will actually go to that level. Yeah. So yeah, so I I, this is one of my favorite features we have.

Yeah, it really helps a lot. So we also have a tooling where you can use, um, our a plugin within, um, VIS vs code that'll help do that scanning within your, uh, code editor as well. And our, uh, code security will also open PR well on PRS that can comment on PRS and put this sort of information in the, in the poll request on GitHub as well.

Based on your, how many developers are working with this versus the security team alone? Like do you actually, When when you in, when they get it integrated with the GitHub and they can see it in their poll request, you can actually set it up to block the poll request, then the developers can engage with it pretty easily when it's just in like four to C app or something. The developers aren't in this too much.

It's mostly would be the security practitioners. That's why we like that GitHub and that vs code plugin. 'cause that lives where the developers live rather than in, um, right in, in, uh, this, uh, cloud uh, application.

So, cool. Alright. Let's go back to the final alert and we'll look at this.

Uh, this one, um, anxious to hand it over to Derek here. So, all right, so this is a potentially compromised host. This is another one of those composite alerts.

And in here we can see there's a bun a a bunch more of details. The one I want to hone in just for the uh, sake of time here is that we have, uh, this potentially reverse shell, they have this reverse shell data here and we can see there's, uh, two different instances of it. There's one that connects over the normal port and one that connects over a particularly high port, which is kind of concerning because they're trying to take some EVA steps.

So, um, we see the full command, they executed to perform this reverse shell. And so I'm gonna hand this IP address over to my friend Derek here, and he's gonna look into, at the network level, everything we've been capturing is really at the cloud level and at the workload level, but there's a whole other set of, uh, data that you could collect if you were monitoring at the network level. And luckily we set that up as well.

And so Derek's gonna give you some insights into that. So thanks for all the great questions, everyone. Thank you.

Awesome. Yeah. Let's see here.

I guess while we're waiting, quick question. Um, so I see a lot of emphasis on Kubernetes. I was wondering is there any support outside of Kubernetes, like for maybe like Lambdas RDS S3, um, ECS?

So, um, we can get visibility into like changes to RDS at the cloud, at the cloud log level. So if we see, um, new RDS instances or new S3 buckets and stuff like that, um, we, uh, we don't for to, CNAP doesn't have any products that do like data analysis on those buckets. There are other products at Fortinet that can do that.

Um, DPL type stuff that can look at actual, uh, inspect those buckets and rank them for, um, uh, how, how risky they are and stuff. But, uh, for, for a c app doesn't really get into that. Uh, and as far as Lambdas, um, we have a little bit of support for Lambdas.

You can see some of the invo invoking. Um, but we, at the moment, uh, if you had the code and code repositories, we could analyze that, but we don't have an agent that can run. Um, it's kind of hard to run an agent in Lambdas 'cause they're so ephemeral.

So, um, yeah. So we don't have that at the moment, but, But it, it could still pick up the logs that come in Yes. From Yeah, we can still analyze the cloud logs for sure.

Yes. Yep. For sure.

But not the run to data. Yeah. Yeah.

I feel like that's so, um, is, is it, would, would that be considered relevant though? Or would it just be whatever's coming in via the cases? I mean, if, if someone, you know, was able to update your lamb to make changes Yeah.

Suddenly started doing crazy things. Right. Right.

Think that might be interesting. You know, I, Anything from an execution perspective Yeah. But Lambda are so shortlived, I'm not sure what the value for attackers are except maybe messing up your business by deleting them or Right, right, Right.

That makes sense. Vandalizing them or something. Yeah.

So, yeah, Makes sense. Yeah. If, if Lambdas are front-ended by APIs, we're also monitoring the APIs and building, um, essentially a swagger of what those a, how the interactions should occur to them.

And, uh, tightening the security as we see user interaction and behavior, uh, against, against those functions. Got it.