EP213 From Promise to Practice: LLMs for Anomaly Detection and Real-World Cloud Security

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Risk Analytics in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our listeners on the Google Cloud Security Community page. Links to all of that and more in the show notes. Anton, we're talking about something sweet today, are we not?

Yes, we are. But I think that sweetness of the episode that's coming is secondary to the fact that it's about AI.

It was not just about AI. It was an in-depth discussion of techniques in AI for novel and hard things.

True.

And I think that it also presents an interesting and kind of creative use of LLM for anomaly detection, which to me is kind of exciting because people assume that LLMs are good for summarizing text and writing bad blogs, but not for anomaly detection. They're great at that. They're great at writing bad blogs. Absolutely.

Listeners, I will let you in on a little secret here. AI has, in my humble opinion, gotten way better at generating questions for podcasts as well. And I will not say where I learned that trick.

Yes, but it's actually very our AI, the Google AI specifically, not like this other guy's AI.

And it's not just Google AI, it's Google AI that Anton customized to the purpose of the show. But that's really getting us off track from talking about what I think is a genuinely fun, genuinely interesting look at something which I felt was fairly novel using genuine AI. So maybe without any further use of the word genuine, let's turn things over to today's guest. Today we are joined by Yiga Elberger, Head of AI at Sweet Security. Thank you for joining us. We hope this is a sweet episode indeed. Anton and I, before we started the call, have already been cracking sweet jokes left and right. So I want to dive right in and talk about LLMs and security because this is one of the I feel hypier, frothier, more full of pixie dust areas I've seen in a while in security. And so not to start you off on a back foot, but what's the gap between the promise and the reality?

Okay. So yeah, I think many vendors were very quick to implement all kinds of LLM-powered features on top of their products.

At least they were in the marketing materials.

Exactly. And whenever you do something on top of it, whenever you do something as an afterthought, it's never going to be close to what it can be, close to the full potential. So what we have are features like summarize my text and describe this better, and maybe all kinds of simple RAG applications. But this is what users basically got. And this is only scratching the surface. LLM can do so much more. And whenever we see that, we shift the LLM left in that sense, meaning whenever we mix the LLM earlier in the process. And if we're on the focus here on cloud detection, type of products, then when we shift the LLM left and mix it in the process of making decisions about the security, we get 10x better results. So I mean things like, I want to have the LLM be part of the determination of how severe an incident is. I don't just want it to describe it, how severe, and to prioritize that incident. I want the LLM to tell me, out of all the input that I give it, I want it to pinpoint The one smoking gun, the one piece of evidence that can tell me as fast as possible something bad is happening in your environment. Most of us are not using LLMs in that way today, but we should. And we are doing that, and the results are phenomenal. So this is what we call storytelling. Cloud detection, it's not just about capturing every possible event and you're good. The other half is storytelling. And this is something that LLMs do very, very well.

Yeah.

And users are extremely happy about it.

Okay. That sounds actually rather fun because I do see a fair bit of LLM use cases in security which are sort of starting to skew to more mundane. And I think I am, generally speaking, happy about that because I felt like the glamorous use cases are basically just lies in many cases. Not in all cases. But I also seen that maybe as we switch to more utilitarian use cases, the magical use cases that do exist start to become less visible. Like, I remember the VirusTotal use case to me was in the magical category, and this perhaps maybe is. But before I go to the detailed question about this, remind us, Suite Security is more of a CDR or more of an ADR? Like, remind me where you fit in the whole universe of security technologies. And sorry for— apologies for my acronym-making former colleagues.

No, I mean, this is the most analyst we'll see Anton be all season, listeners. Hey, I don't remember about your company. Describe it to me using Gartner terms.

I didn't exactly say that, but I kind of did actually. Fine, whatever.

Okay. SWEET is a detection response-first CNAPP, and CNAPP is a very broad term.

Ah.

But what SWEET does is first and foremost detection response. It is the world's best, strongest detection response engine for cloud environments, but it is so much broader. You can't just be focus very narrowly on just being a CDR. You want to be broader. So SWEET also does runtime-based vulnerability management and API security. So, and it keeps expanding in places where we feel that we need to dig deep into and provide value to our users. This is what SWEET does.

And actually, even though for a very brief moment, I wanted to start arguing with you because I felt like maybe the DNR component of CNAPP is CDR. But your subsequent comments actually dissuaded me from arguing with you because I think you're right. There are DNR components that aren't tightly wrapped in a CDR bucket. There's other detectiony, responsy activities, including the VM in this case, that perhaps aren't CDR. So I'll leave it at that. So now to the fun part.

Yeah.

This is actually really good. The fun part is when you described LLM use for me before this, I kind of realized that your LLM use is really unusual and quite interesting. And it's almost like LLM-based anomaly detection, which I have to admit my first reaction was like, but wait a second, LLMs aren't for anomaly detection. But then you also convinced me that they are.

Yeah.

So how does that— and maybe the word trick is too demeaning, but how does that work? What is it good for? And actually, how effective can it be?

Great. Okay. So first of all, we're doing several different things with LLMs. What I want to describe right now, as opposed to the storyteller that I mentioned earlier, what I want to describe now is a very innovative way on how we're leveraging LLMs in order to do anomaly detection. And this is how it works. It'll take me a minute or 2. I hope it'll make sense. So we're all used to thinking about LLMs as a model that generates more content. Give me more tokens. But it turns out that there's There's also a way to use LLMs in reverse. And in the sense, what I mean to say is that we can take an LLM and feed it with a given input sentence and iterate token by token and ask the LLM to replace each token with the one that it thinks is the most likely, is the most probable for that position. So we go token by token and we probe, in a sense, we probe the memory of the LLM in order to see what are the probabilities that it would assign to those those tokens that it wants to replace. And when we group those probabilities together, what we actually get is a measure of how that sentence, that input, is likely or anomalous or irregular in the language. Okay? So this might sound very strange. Let's take a very intuitive example to clarify how we're using this. So suppose I take an LLM and feed it with the sentence, Once upon a time, okay, 4 words or 4 tokens. Once upon a time. And if I feed the same LLM with a slightly different sentence, once upon a clock, okay, I'm just inventing, I'm just throwing there any weird word. So I think we can all intuitively understand that once upon a time is much more likely. It's a much more reasonable sentence. Once upon a clock, what is that? So in a way, we can use this mechanism. And we can do that with any LLM. By the way that they work, we can probe under the hood the LLMs and use that as a mechanism to know what sentence or what input is regular or irregular in the language. Okay, so far so good. But why is all this interesting? How does that have anything to do with cloud detection? This is how, this is how it all connects. So Imagine that instead of using an LLM that was trained on English, what if we used an LLM that was trained on a vast amount of cloud log data? Okay?

Hmm.

We can actually, if we have an LLM that was trained on cloud data, we can feed it with a sequence of events that happened in my environment and do the same test and get a measure of how anomalous or regular this sequence of events are. It's exactly the same way as before when the LLM knew that once upon a time is reasonable and the other option is not. It's exactly the same thing when we train it on cloud data. So that's pretty amazing because we get this effect automatically by training the LLM on the data. We didn't have to build special models. And what we're getting, the results are so good It's almost not fair to compare them to previous models, previous anomaly detection models and machine learning-based anomaly detection. The model can be very, very nuanced, very fine-tuned to know which sequence makes sense and which doesn't. Okay? So this is a pretty neat trick that we started using. And I think one of the things that is amazing about it is, I think you're going to hear me say a lot in the next 30 minutes, the word context. Context, context. Everything is around context. If you know how to build the correct context, you are going to get great results from your models, from your LLMs. And this anomaly detection piece is the big piece for what we need for the context, meaning I can ask the LLM, a different LLM, the ones that we are used to. We can ask the LLM, here's a bunch of events that happened in my environment. Can you analyze this? How severe is this incident? Tell me the story. And it will do a great job. But if we feed it also with this baseline, with this super smart baseline, the results are even better, much more customized and specific to the customer's environment. So that's how we're using LLMs.

Let me pick at that because this sounds great, but my immediate skeptical hat on is that's going to be wicked expensive. And so how do you compare this to other ways of doing anomaly detection from a cost standpoint? And how in the world do you do all that inference on cloud logs, which I know are big and chatty? Cloud audit is a noisy stream. How do you do that at scale without blowing out your inference costs?

Okay, so to build an anomaly detection engine based on LLM, we don't need the LLM to be a huge foundation model, 600 billion parameters. We don't need that size. We can use 2 orders of magnitude smaller. In fact, when we started the research, this concept, we started with a fairly simple model. About 120 million parameters big, similar to GPT-2, which is totally open source and anyone can play and try that with that model. So these are models that are much less expensive in terms of inference and also the amount of training. This is not endless hours of GPUs for the training. That's how we manage the cost. And by the way, we have other applications, other use cases for LLMs, which are more expensive.

Yeah.

When we run incidents through LLMs in order to analyze them and slice and dice the incidents, it's more expensive than that. And still, using quite clever engineering and all kinds of optimizations, we're able to keep expenses at bay. And it is manageable at scale.

So it's not only in using the— like, a small LLM sounds really silly because, of course, L stands for large.

But—

But small LLMs are a thing. That's totally a thing.

In 2025, totally a thing, yes.

And every day that goes by, more models are invented and released. And this is getting better and better, and costs are going down. So betting on the trajectory or on the trend that LLMs will be incorporated more and more into analyzing a vast amount of data in cloud environments, every day this is becoming more and more of a reality.

That is interesting. I think that it sounds like because of our, well, our humanity, I mean, long track record with failing on anomaly detection, I can see where it sort of solves some of the classic anomaly pitfalls. I don't know if it solves all of them, but I know that it solves many of the classics. The next question is sort of about broader cloud detection response or detection response as a part of CNAPP. So, when you run SecOps tools, whether it's a SIEM or anything in the CDR, there is often this painful trade-off between, give me all the logs, give me every piece of telemetry, now give me also application traces. In fact, just give me all that produces any sort of telemetry, including the print statements. And then you then complain that you have too much noise. So, like, wait a second, you just asked for all the data, and now you're complaining about noise. Is this ever solvable in any way? I mean, whether with LLM or with you, but, like, you've been dealing with this problem for quite some time.

Yeah.

I'm kind of curious how it all sits together.

Yeah, great question. So I think the common or popular theme that I keep hearing is, let's eliminate false positives to zero. Let's just drive that down. Let's eliminate all the noise. And I think it's the oldest cliché in the industry. People have been saying that for always. And yes, while we also put a lot of effort on reducing noise, We're not going to get to zero. It's impossible to get to zero, especially in cloud environments where telling apart the benign from the malicious is harder. Getting to zero false positives, I don't think that's the goal that we should put in front of us, but we should definitely put the goal of eliminating as much as we can. Plus, we need to add another piece to this story. Reducing noise is not enough. What we should start talking about much more, and we are definitely doing that, is—

Detecting.

Minimizing time to respond, time to shut down an incident, MTTR. So, if we have a certain amount of noise and we are able to reduce the time it takes to handle that noise and automate various aspects of shutting down those incidents, this is the way on how to reduce noise and cure this fatigue. That's the way to do it. And AI, LLMs are going to play a major role in this thing. Okay. AI agents are going to automate a lot of these aspects and reduce the time it takes to handle incidents. And that's the key.

So, I'm excited about agents, but one of the things I hear all the time from people is, we built this automated system to do triage, and it was working great, and our numbers were actually better, but it had a false negative. And then leadership shut down the project because they hated that we missed something, even though mathematically it was better. And so, how are we going to get leadership especially over that hump of accepting that sometimes the system will be wrong, but in aggregate it'll be better than the thing that was before.

Wait, you met people who were fired for missing detection or failing?

Not fired, but having their system turned down and moved back to other approaches. And they weren't agentic, they were other techniques. But this pattern of we're willing to accept humans being wrong, but we're not willing to accept machines being wrong, And we're not willing to accept when the machine is wrong once, even though the system is numerically superior. I've seen multiple times in multiple places.

Oh, yes. That's—

so how do we work people through that hump? Because that to me seems like the big psychological issue with the agentic stuff.

I think the root of everything is that the performance is going to be better with machines or with AI or with these types of methods. The amount of noise is going to be lower. The recall or the coverage, the amount of real incidents that we're going to catch is going to be higher, and the speed is going to be higher. So there is going to be no choice. This will be the way to go.

Hmm.

Now, executives, boards, security teams, I think once they realize that the more you try to catch— if you want to catch 100%, you're going to catch 50%. If you are willing to catch 95%, Then you'll be able to come close to that. So a team that says, I want to see 100% of any possible incident that could happen in my environment, I want to handle everything, they're going to miss important things that are happening in their environment. So there is no choice. This is the trend. This is, I think, what will be adopted. And I think it's going to work well. It's looking promising. The performance is good.

Hmm.

So you think it's just inevitable? That's interesting.

Inevitable.

I think that it's— I always just found the original premise to be at times iffy because I've met people whose systems are shut down for too many false positives, but I haven't seen that many people whose systems are shut down for having a small number of false negatives. Because you can stack systems on top of each other. False negatives are fixable by layers. False positives aren't. So, that stuff is just kind of weird, like turn it off for false negatives, Just add another system. Like, I don't get it. It just sounded like iffy as logic.

I think this would be a long rabbit hole. So let's maybe take the next question, Anton.

Okay. And then it's like the next question is, of course, from the stack of kind of my favorite questions about barriers and challenges and troubles, because of course we love to discuss problems other people have. So what are some of the barriers we need to overcome so that LLMs can push the envelope even further in security? And I think that, of course, people have conventional answers like hallucinations or cost of inference or something, but maybe that's your answer. But just give us some more barriers like AI researchers have to fix before LLMs can be more widely used.

Okay. So I think I'll group that into 2 separate groups. The first one will be technical type of things and the other non-technical. So the first one, For the first group, I would say several things, and I can talk about this forever, but things like, we want larger input context that we can use in the models. If what I mentioned earlier, if we want to analyze incidents and we want to do that at scale, we need a much bigger context window. The bigger it is, the more— the better results we will be able to get. Sometimes incidents may span days, so the amount of data is huge. If we have Big context windows. If models can accept not just 100,000 tokens, 200,000, or maybe a million, if we can get more, that's going to be powerful. Obviously, faster generation speeds, token generation speeds. So if we have more efficient models that cost less, like you mentioned before, obviously that's going to push us all forward. Maybe I'll mention 2 more things. So edge models.

Mm-hmm.

To push LLMs to the edge, so many fundamental things are going to change. Just as a quick example, models running at the edge, running on browsers, running on endpoints, that's going to solve the soft belly of cybersecurity, which is the end user. If we can have an LLM watch over everything that the user does in the browser and keep privacy because the LLM is running at the edge, that's going to solve phishing, that's going to solve BEC attacks, which are major things that are hurting, negative impacts. So edge models are going to change the industry a lot. And maybe one last thing about the technical aspects is a cybersecurity-specific LLM, an LLM that was not just pre-trained on a huge amount of very generic English and other types of data, but more focused on cybersecurity. This again could lead to even better results for users. when we use that for cybersecurity purposes. So that's the technical side. Just a quick thing on the, let's call it the approach or the mindset side. So I think there needs to be a shift in approach in terms of the trust, how much users and customers and companies trust AI. Since there were many cycles, many hype cycles around AI.

Oh, yeah.

Many times promises were made. And oftentimes, they weren't delivered. So there is—

Were they ever?

I think things will be— those promises will be delivered in the cycle. But we need to overcome this trust issue. And it will take time. But the more we as vendors trust the AI and bring it further in, and the more users trust the results, the more we will be able to push that forward and get better I actually had a weird reaction to this because as you were describing the technical challenges, faster models, models on edge, security-trained models, I was kind of like, he doesn't work for Google Marketing.

Why is he describing everything that we have? And I know that it's not— it's just like, we are not here. This is Cloud Security Podcast. We don't really sell models or anything, but it's just interesting that a lot of the stuff you described is literally most of the stuff that Google is working on. But my actual question is a kind of more fun one. And this is, I can tell you the answer also, but you have to not give the same answer. So from your perspective, are LLMs helping the attacker or the defender more?

Yeah.

And the reason why I want to just prime you with an answer, because I don't want you to give the same answer. And the answer we have and we usually give, because our big bosses give the same answer, is that in the long term, they favor the defender. In the short term, they may favor the attacker.

Absolutely.

So can you answer anything? Oh, you just agree. Okay.

I just agree. I can still man this case if you want. I can make the case for it. I really do believe that LLMs are good news for CISOs. And I love that question. Of course, I hear it a lot. And the reason I love that question is because instinctively, I would assume that the dark side is going to win with LLMs. In fact, maybe I should say the dark side—

Wait a second. They favor CISOs, but the dark side would win?

Wait. No, no, no. saying instinctively, I would go with the dark side. LLMs are going to make their job easier. It's going to give them more zero days. In fact, that side is already winning, right? Cybercrime is going up every year. The frequency of attacks is going up. More zero days, more CVEs. The bad side is already winning regardless of AI. However—

Yes, thank you. That's an important point.

I really believe that within a few years, not too far in the future, LLMs are going to tip the scale in favor of the good guys. And the reason is unit economics. So, we all know to attack successfully, you only need to be successful once when you want to attack. When you're on the defender's side, you need to be successful all the time, right? In order to be an attacker, I wonder if you'll agree with that. In order to be an attacker, you need to be sophisticated, you need to be brilliant. To be a defender, You need to be diligent. So LLMs are going to make the attackers more sophisticated, but that's going to be a marginal improvement. That's going to be diminishing returns. On the other hand, defenders, the bottleneck is knowledge gap and working hands. And LLMs are going to bridge the knowledge gap. LLMs are going to solve the knowledge gap, and AI agents are going to solve— the working hands constraint. And these are on the defense side. This is orders of magnitude improvement compared to the marginal improvement on the attacker side. So I'm team seesaw.

OK.

I love this argument, actually. I think it is a genuinely novel idea.

Yeah, we haven't had this argument before.

Yeah, that's a really good argument. And it's probably now stuck in my head, which probably means it's a really good argument.

All right, well, I hate to end on this note, but I— Unfortunately, we have to. One, do you have a tip for defenders who want to incorporate LLMs into their defense? And 2, do you have recommended readings so that we don't leave people empty-handed?

Sure.

So in terms of the tip, what I would say is that LLMs can do amazing things for your product and for your environment, however you use it. But my tip would be to do that in phases, in evolution phases. So maybe when you're incorporating it into into your product. First generation is the LLM is enriching your current output, your current product. Generation 2, it's working side by side with your current product. And generation 3, the LLM is doing the security or doing whatever you want it to do. So build it in phases because there is a trust chasm that we need to cross.

Mm-hmm.

If you implement it that way, users are going to have a much easier time working with that and accepting it. So that's in terms of the tip. And a resource, I think I will go with Andrej Karpathy, which is my favorite LLM guru. He has a series of articles and YouTube videos about how LLMs work under the hood. I learned so much from that. I think the more people know about it, many people are going to enjoy that and benefit from that. So I think that's my resource.

Nice. We will ask you for the link for that after we finish taping.

Will do.

And just want to thank you so much for joining us today.

Thank you, guys. This was fun.

Thank you. And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Juvaikin and Tim Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.