EP234 The SIEM Paradox: Logs, Lies, and Failing to Detect

Security running. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Detection, UEBA, and Risk 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 Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we are talking about parenting teenagers today. Is that right?

Uh, yes, but we're also talking about SIEM.

What's the difference?

Well, roughly, yes, that's the theme. I mean, I was putting the resources for this episode and I thought, Parenting teenagers as a management book. Yes. With that caveat. But I had a few moments of kind of slight déjà vu. And of course, a lot of Pokémon. What's the plural for Pokémon? Remind me.

Pokémon.

So Pokémon. Okay.

Yeah.

So it was a déjà vu and Pokémon kind of episode because some of the mistakes she presented, the guest presented, are kind of eternal.

Oh yeah.

And that's a little depressing. Yeah. Yeah.

Yeah. No, they've been around forever. Can I tell a funny story about parenting teenagers?

Sure, you should.

I have a friend who absolutely lost it one day when she found a whole collection of books with titles like Parenting a Moody Teenager, How to Deal with a Teenager Who Hates You, I Hate You, Mom, Now Take Me to the Mall. Her parents had bought these books as a joke, hoping she would find them, and left them on a shelf. A whole bunch of books about dealing with an annoying teenager. Brilliant prank by her parents. So maybe with that, listeners, Imagine all the titles you could have for books about parenting an annoying sock or an annoying Sim. Let's turn things over to today's guest, who has seen more of those than most people. I am delighted beyond measure to introduce today's guest. Today, we are joined by Svetla Jankova, the CEO and founder of Citrino. And she was with the Google team, in her own words, quote, forever. Svetla, delighted to have you on the show. We've been talking about doing this for a long time now. You've seen it all in the world of SIEM, and I want to start off with hopefully an easy question. Why do so many organizations, you know, collect all the logs, but they don't detect what they want to detect? You know, like, why is our industry spending more money than ever on their SIEM tooling and still not, you know, winning against the Tier 1 or even, like, Tier 51 adversaries of the world? What's up with that?

Oh, great question. And super great to be here, Tim and Anton. Really, really great question and something I've been thinking about for a long time. I mean, even the other day, CISA came out with a new implementation guidelines. And they were saying basically, hey, if you don't use this for detection and all the other things, use a data lake instead. And it was funny to me that they weren't saying, like, don't, like, actually do the stuff, right? They were just saying, hey, it's okay to throw things into compliance. I think the answer to why is very complex, and it has to do with the fact that it's just hard to operationalize. And a lot of companies get into the throw the data in, throw the data in, and it gets so exhausting, so overwhelming. It's such a long project to just throw the data in that the operationalization just never gets there. There's just patterns around, you know, the data becomes kind of a glorified grep situation where I have to find different ways, need humans to search for it in certain ways. I don't have a meaningful way to make sense of it. Threat intel is all over the place. Detection content is all over the place. It seems like, you know, it's more of a quantity versus quality type of game with those types of things. And when you aggregate all these factors, people get slammed, they get overwhelmed. There's so much to look at. And it just goes back into this whole, well, at least I get to use it for forensics, right? Which is not bad. But—

I mean, the reason I'm going to freak out over that is because this conversation we just had, this conversation fragment, we could have had 2 years ago, 3 years ago, 5 years ago, 10 years ago, 15 years ago, except for Tim, maybe. He wasn't born back then. But the point is that what you said makes sense. But it all made sense to the very first SIEM designers in the late '90s when the first SIEM products were built. That conversation would look exactly the same. And that, to me, is kind of Scary, because that argument is solid, but it's a solid argument for 20 years more.

It is. And have you noticed there was a little bit of a regression in the sense that the first—

That's right. There was. It made it worse at one point. It got worse? Yes, it did become worse.

She's right. It became worse. The first 10 products, they had their downsides, but they were semantically obsessive in a way, right? Like, they wanted to have a data model, and they wanted that data model to be opinionated, and they wanted you to normalize. And then we became so obsessed with this whole easy-to-ingest, click-a-button type of thing, right, that normalization became kind of optional, right? And schemas became optional and all these types of things. So, yeah, in some ways, it even became worse because the more complexity you shift away from ingestion, the implicit part is you're shifting it away to the humans or, you know, insert potential future robots, et cetera, agents, whatever. But you're shifting that complexity. That doesn't go away. Something needs to semantically interpret that data. And so, by turning things from kind of data model driven to glorified grep scenarios, there was even more complexity that was shifted. And I remember kind of early in the Chronicle days, we were insisting on kind of mandating a schema in a data model.

Mm-hmm.

And that was controversial. It was very controversial because we were right in kind of in the middle of that, in my opinion, regression. I don't know, Anton, if you've seen that kind of in your world too, but in my opinion, regression around Let's not worry about semantics now. That's a later problem. When you make semantics a later problem, it's kind of a never problem, right?

Hmm.

I mean, I've had— I don't want to joke about it too much because, again, it would sound like I'm boasting about stuff. But there's probably, like, from all the blogs I've written on my personal blog, there was a blog I've written called Security Correlation Then and Now: A Sad Truth About SIEM. It's like the most popular blog I've ever written.

Really?

And it talks about, like, in the history of me, Including probably Gartner blogs. And that's what it's about, that the SIEM has kind of— there was a period of time with obsession with raw logs and stuff that SIEM became worse. And it was— so in that sense, Seth is right. Some things have become a little bit better, then a lot worse, and then they became better again. Okay. So let's wash this off for now and ask a future-looking question. We still complain and we still hear complaints about people not getting the right context to the analyst to triage the alert. And as the current obsession with agentic AI for SOC specifically comes up, the context becomes even more important. So, it's in theory, here's an alert, here's a signal even before there's an alert. I can say, here's the asset info, here's threat info, here's this info, here's the history. It sounds kind of logically simple, but we still kind of collectively, not at SecOps, at SecOps we are quite awesome, We suck at it collectively. So why? Why is context so hard?

I think that we're getting okay with the first level of context, like kind of in the Maslow hierarchy of context, if you will. We're getting okay with the, you know, what's the asset and what's the alert and what happened and all of that. What we're still severely lacking, and it goes back to this idea that every log source is treated on its own because of the whole ease of ingest type of thing, right? When you treat everything on its own and not as a correlation story, then those second-tier, third-tier, whatever-tier contexts become really difficult to capture, right? Is this asset related to an application? Which application? Which environment? Is it a business application? Is it a critical application? Is this normal or abnormal? Those become really difficult questions to ask. And if we unpack kind of, like, why we don't have this information, It really kind of goes, to me, to this idea that we've been reluctant to put data in front of human eyeballs. Because the pattern I've noticed is the more data you put in front of human eyeballs, or, you know, you have to be careful about it, the more you get this idea of, like, ah, because of this and this and this field, I know that this is a critical application, so I can automate this as part of that. So, that feedback loop is missing if we're just trying to present, hey, here's your threat intel verdict, here's your magical score, here's your this, here's your that, make a decision. And so, they do make a good/bad decision, you know, pretty quickly. And that's fine. And you want some of that. But I think, you know, in some ways, we've kind of over-automated that decision. And we're not putting those feedback loops in place to get those second-tier, third-tier data.

Wait, wait, we over-automated something? I almost want to pick on this thread because it sounds very, It sounds very unthinkable.

That sounds unlikely.

Not unlikely. Yeah. So in what sense it was over-automated?

You know, one thing I noticed in my own personal experience too, like when you look at things like SOAR, it's funny. It's not obvious what the best practice, or at least in my opinion, the best practices with SOAR, because you look at it as like orchestration, automation, remediation, right? Like people think, okay, I'm going to just contain endpoints, right? Or I'm going to remove emails from inboxes. And all that is good, and that's part of the goal. But nobody thinks, oh, you know what, I'm going to put things into case management. And so, when you take on a SOAR project, you go into, hey, let me find every single branch of the phishing use case, things like that. That starts taking a lot of time because that branches off into a lot of different use cases. What I find that is more critical is you need to have some sort of place where people touch the data and interact with every alert. Not 10% of the alerts are touched, the other ones go into some sort of a hole, not 1%, et cetera, but people need to interact with every alert. And in some ways, like going breadth-first as opposed to depth-first in SOAR, I find to be very beneficial. The end result may end up being the same, but with breadth-first, you get the feedback loops, the KPIs, the metrics, the reporting. You get all of these things, and it's just kind of the human factor of people get more excited to look into the data, get ideas, talk to their security engineers, incorporate those ideas into playbook, loop that in forward versus the opposite, which becomes a big waterfall project of automate phishing, right?

Hmm.

Yes, we will end up automating phishing, but Is that the place to start, or is a quicker win more available there?

Hmm. So I like this direction we're going down. I want to pick at this a little bit more and ask, like, you've seen a lot of organizations do SIEM adoption and migration. What are the big org challenges that keep people from getting the benefit from the stuff they're buying? And what should people avoid?

I think we are almost trying to not ask about the SIEM-specific, the tech problems.

Like, it's like the org problems.

Like, don't say, Oh, yeah, they're just using the SIEM from 1998. They should stop. Like, sure, we agree, but it probably isn't the main reason.

No, no. Tech problems are on one side, and they're not necessarily obvious. They kind of stagger onto each other, if you will, right? Like, they're not something blatantly obvious. I think when it comes to org challenges, talent is the biggest challenge. You know, one thing I found in my career, the one good predictor of a successful implementation is a really strong security engineer. In the team. So, like, companies finding and nurturing that talent, like, even one person can make a huge difference for an org.

Isn't that like a Captain Obvious kind of insight? So, sorry for my snide Google hubris comment here, but, like, if you have good people, you have good results. No?

True, true. It is. It is. Absolutely. But it's hard for organizations to do that because it's hard to attract that talent, retain that talent, even identify that talent internally. And then, when you look at kind of how security engineering and SecOps and the operations team interact with each other, there's challenges there in terms of kind of dividing the functions and the roles and how does that flow into a SIEM implementation, a SOAR implementation, and so forth. So yeah, absolutely. It is absolutely obvious. And it's still, I think, a major challenge for organizations to basically kind of, like, have the right type of talent and present them with the right training. Because sometimes people are like, oh, let's just ship them off to training, 3 days in a classroom, You know, they're good to go, versus presenting them with the right hands-on opportunities to learn the technology, spread the knowledge, you know, really propagate that appropriately within the organization.

Hmm. I like that. And I think that's— it expanded from the sort of initial, what seemed obvious to me, comment, but I think it made sense. And almost like these tools are still complex, whether they use AI or they don't. And sometimes because they use AI, perhaps they're more complex. You do need somebody with an engineering mindset of that sort. And if you expect You seem to run because you bought it. Yeah, it's the mistake in '95, 2005, 2015, and today as well.

Yeah.

So mistakes. Yes. Our favorite subject.

I know.

Just go run through your favorite sim mistakes and whether they're like big, little, with tech, with product, just go wild.

Go wild with mistakes.

Go wild with mistakes.

Yes. They go all over the place. There's little funny ones. There's big ones. You know, all kinds of things. I think, you know, even the word mistakes is a misnomer when it comes to this type of technology because it's rarely something like, you know, put your pants on before you go to work. It's rarely something obvious where you're like, don't do that, et cetera. It's oftentimes something that just either the technology or the process or something naturally kind of guides you into a certain type of direction. I'll tell you a little funny one that I see.

Hmm.

SOAR makes everything easy and plug-and-play, and you just install this integration, you get your alerts, and everything is peachy-cheesy. And that's great, and it works awesome. However, I do think it's more healthy for data and for alerts and for workflows to go through the SIEM. Less obvious, right? Not so much the plug-and-play, you know, go install, click, click, click, and you're good workflow, but a much more healthy kind of scenario where things go into your kind of detection engineering workflows and rules and—

Yeah.

And everything else. So this is just one example of how it's not necessarily a mistake, but it's kind of like a learned behavior based on how the technology workflows drive us. That learned behavior could lead to disparity where now you have, instead of having consolidation of your consoles, like your EDR and your whatever consoles, now you have N+1, where now SIEM is just one of your consoles. And you really don't want to do that, not if you're investing in SIEM at the least, right? Yeah.

Hmm.

And how much of it is blamed on tech? Just like, you dude chose the wrong SIEM for your environment. Like, the mistake is the product selection.

Well, I think that last one was actually really interesting. Hang on. Before we do that, I think it's really interesting to think about a world where it's easier for a user to do click, click, click, it's in my SOAR versus all of the work to get into my SIEM, but it's better to have it in the SIEM.

Yep.

Can you talk about why it's better to have it in the SIEM? Because I think that's a— it's really interesting, and I think there's a lot of value there. So, Svetlana, could you just expand on that real quick?

No, it's a good question, and there's many reasons, right? Like, if you subscribe to the fact that SIEM is your place for investigation and for forensic, when you do investigation and you— when you do some sort of research, you look something up, half the alerts are here, half the alerts are there, your investigation workflows are fully, you know, inconsistent. And then, you have to do the manual correlation work to tie SOAR together with SOAR, you know, which sometimes works, sometimes doesn't. But even if you're looking at an alert, you have to kind of make sure that this context becomes available, that there's alert A and alert B and alert C, which the SIEM makes that fairly specific.

Mm-hmm.

I think it also comes to the fact of how do you even deal with detection methodology, right?

Mm.

If you have 5 connectors here and 17 rules there and some out-of-the-box stuff, your detection methodology and measurement becomes, So, it's one of those things that it becomes harder with complexity. If you have something simple, it's not a big deal. But with complexity, all these kind of meta systems that are created to define and design the thing are then bad. And then, you know, we kind of brushed upon AI and agents and things like that. That becomes more of a mess for them to deal with because the data is not centralized. It's not unified. It's not in one central place. So, that's more disparity. to deal with. We're somehow like unpacking the SIEM problem and kind of like dispersing that a little bit. So, that's a very good question. Yeah.

That makes sense. Anton, now you can ask the question you wanted to ask, but I wanted to get the expansion on that.

Yeah, I'm kind of curious to ask about the tech. What about the actual tech mistakes when somebody just chose the wrong SIEM? I mean, we've seen companies that picked the product based on marketing copy and it was not a match to their requirements. Deep in your heart, how often is this? Like, it happens, but in my mind, it's rare. But like, what is rare? 1% or 30%?

It happens and it's rare. I would maybe say these days it's getting in the teens or 20s of percentage, but that's just a rough ballpark estimate. I think generally, A, buyers are doing a good job, and also vendors are doing a good job of doing the right things for the most part, right? So, buyers are doing their due diligence. I'm seeing a lot of that kind of conversations come up. We're not seeing too much kind of, like, crazy decisions, like, hey, let's throw it in the data lake and write SQL, and that's gonna be good enough. You know, like, I'm not—

Sorry, I'm making— what was this cringy Pokémon, Tim? You had this cool metaphor earlier today, not cringy Pokémon. What Pokémon was it? Disturbed Pokémon? There was— I made a face and Tim said, you made a—

Listeners, listeners, this is what Anton gets for making fun of me for not having been born in 2000. I was born well before that, for the record. I referenced surprised Pikachu earlier today, and now Anton is on the call with us making some kind of weird, like, nervous squirrel energy and thinks there's a Pokémon that corresponds with it. So listeners, this is a generational conflict we're having here. But no, Anton, I don't have an appropriate Pokémon for you. I just can make fun of you a lot.

Yeah, I have a Pokémon hat somewhere. I mean, yeah, I need to bring— actually, it's a Pikachu hat. It's not just a generic Pokémon hat.

Oh, even better.

Yeah, it has floppy ears.

Spela, where were we?

I love it. I lost the thread on surprise Pikachu, which Anton did make that face. Yes.

It was mostly because something improved and people are buying SIEM as a closer match to requirements. People don't make this mistake as much as before.

I don't think so. I don't know what you're seeing on your world, but I don't think they're making this mistake as much as before either. You know, they're not just buying it for the compliance checkbox. They're not falling for gimmicks as much as before. It's just gotten a lot better, right? Like, they're not buying a UBA solution and calling it a SIEM and things like that.

Oh, thank goodness.

Yeah, thank goodness.

Not seeing much of that going on. Yeah.

Okay.

Let me ask you this. I mean, it's sort of logical. Yeah, I'm going to jump in the queue a little bit, but like, go look at the past a little bit. And do you see these mistakes Being different to when your career started with SIEM? What's the trend line?

They're better. You know, people make better mistakes. No, I think that the fundamental mistakes, and if you look at like, what are really the worst mistakes, it's kind of like when you're building the house, the worst mistakes are at the foundation, right? So, the hardest mistakes are really at the data layer. And those are not much different when we started thinking about this problem in, you know, 2015, 2016. problems are not much different than, you know, Anton, I'm sure you've seen those for a while now. When it comes to new problems, I think that there's a lot of quick fixes, or should I say, in quote, quick fixes that got introduced over the years that present a new opportunity to make mistakes that are even less obvious and even more subtle.

Mm-hmm.

And they do go back to the foundation, but, you know, things like, UEBA, when not implemented properly, that's just kind of an alert fatigue increase that hurts some other things. Things like SOAR and over-automation can actually deter a company from doing any sort of automation if done poorly on the get-go. It's kind of like that— we talked about something that's like either a 0 or a 1 oftentimes with companies, where like we don't do something at all or we do it at its max. Different technologies have presented that challenge in very different ways.

Mm-hmm.

I'm kind of curious what will happen with the whole AI trend and how that will manifest itself into this. But I think, yeah, like, basically, foundational problems are the same. Data kind of hygiene and things like that remain very much a foundational problem. But as we layer the problems on top of that, that presents some fun new problems. But also, solving those problems, it's kind of like, you know, with my house analogy, It's kind of like putting nice finishes on the house. It can really increase the value without necessarily, you know, increasing the costs that much.

Oh, that's interesting. I like that, that last bit there. I want to switch gears a little bit from all this and talk about detection engineering. Do you expect most companies to be writing their own detections in their SIEMs? How much of that should be them doing it versus what comes out of the box from their vendor? And Why is detection engineering so popular with such a small slice of the market?

I know, it feels like we can't get 80/20 with detection engineering, can we? It's like—

No.

It's either we have a team that builds 400 detections or we turn on all the SIEM stuff and we don't worry about it.

Yeah.

Yeah. Like, that seems to be the case with detection engineering. And yeah, part of it is just having a separate function. is a luxury of the elite companies, right? That type of budget is definitely a luxury to have. But in general, I've seen a lot of artificial pressure to vendors to check the box, not just SIEM vendors, but, you know, EDR, et cetera. It's like, do you have MITRE ATT&CK coverage? Oh, I have MITRE ATT&CK coverage. Here you go, 4,000 rules. And through this artificial pressure, you know, a lot of detection content got created, which is not necessarily a bad thing, but it creates 2 possible missteps that you can make. One is just kind of not doing anything with it because it's too overwhelming, right? And I think that can be a mistake on its own, right?

Mm-hmm.

Like, if I just turn them all off and just take the high-signal ones and only use those, that could be a mistake on its own because Things like creating, downloading a service account key may happen 4,000 times in a day, you know, in a certain organization. Who knows? But that one attack may have those signals coming forth. So, really kind of like going overtuning or undertuning can be bad. I think this is a place where, Tim, some of your work in risk-based alerting, risk-based modeling really makes a difference for our customers.

Right.

So, we have the high-signal ones, and those are actioned, and those are great, et cetera, et cetera. Those low-signal ones, those low-severity ones, maybe they kind of feed into some sort of model where they feed into some sort of threshold-building mechanism. That has been really game-changing for a lot of our customers. It's challenging to do because you have to answer some data questions. What is a user? What is an asset? You know.

Mm-hmm.

You actually have to answer some questions through the data, which the logs don't always answer accurately. But once you do that, that kind of risk-based modeling helps us make use of both. So, I think the vendors do a really good job of providing a lot, right? They don't provide everything. They don't understand critical applications. You know, a vendor cannot understand my business, my crown jewels, all of that stuff.

It's pretty hard to infer who's got root in prod just looking at logs.

Exactly. It's really hard to infer.

Or what the system, how the system makes money. That's even worse, right? Oh, yeah. Yeah, yeah, yeah.

Exactly. Exactly. So, I think, like, the answer is in the 80/20.

Mm-hmm.

Which is where we try to work with our customers being. And the first part of the solution is really try to tone down the tar pit, right? Like, try to make something out of it without turning off the alerts specifically, but maybe make them less actionable, more kind of model-oriented, data-risk-oriented, et cetera. And the second part is, for those 20% that companies should invest in their own detection engineering, focus that on where your risk, your crown jewels, things like that are. Mm-hmm. Mm-hmm. And focus that on really important things— correlation, you know, the things that was designed to do effectively.

I like that answer.

I like that answer. I like that answer. There's no but, full stop.

And that's a big compliment coming from Anton.

Yeah, I like this answer. It's a correct answer. And it's the answer that I probably saw or maybe even wrote in some Gartner papers and other people gave advice. The problem with that answer is that it is the right answer and everybody knows this, but people who practice like this are still— is not everybody. It's a correct answer, but it didn't become mainstream. And I'm still a little nervous about that. Like, I believe it's correct, but it's also somewhat not popular, not the most popular answer. We still see people who pile up logs in one place, hope for the best, or call up some consultant once a year to write rules for them.

Ugh.

Or it is still a lot of maybe not abuses as such, but like bad mistakes with this. So, I'm kind of curious whether we'll have the same answer. And you know what will help? Maybe AI would help.

Oh, no.

So, we're going to just— sorry, Sredla, we'll have to do it to you because we went to RSA and there was this big hose, fire hose sticking out of the wall and it said AI SOC on it. So, both Tim and me kind of opened the spigot a little bit and got the full flow of AI SOC in our faces. Sorry, my metaphors suck today. Help me, help us figure it out. Would AI SOC solve the problems we're describing? Would AI change it dramatically in a year, 2 years, 5 years, something?

No, it's funny to try to even predict where things will be, right? But my personal prediction is AI is going, you know, like, are we going to go out of business as implementers? Is AI all of a sudden going to get into all this stuff, implement the SIEM, tune everything? I don't think so. I think it's going to make the data problem even harder, right? Especially for the most part. I mean, it is kind of good at understanding unstructured things, right, and putting it together, but it can get expensive. You can't just apply it on every log. You have to solve the data problem somewhere downstream. So, I think that the data problem is going to become even more important, and the data mess needs to be cleaned up. And then, it's going to solve a lot of problems that we have today that could be alleviated, such as, you know, interesting data not being highlighted to the analyst, that problem that I called out, you know, who decides what interesting data is. And that's maybe an area where AI could help and highlight some interesting bits and things like that and make some decisions. I do worry, just same as with automation, you know, if we kind of start over-automating things based on AI, one, we're dealing with adversaries, so they can you know, take note of that? But then, two, are we going to over-automate things and over-automate decisions? I think that's one concern that I have in terms of AI SOC. But in general, it's extremely promising. It's already showing a lot of promise in things like clustering and things like showcasing the right data, making kind of the right predictions and descriptions of events and things like that. So it's really showing a lot of cool things. Probably more for adversaries than defenders nowadays.

I'm going to push a little bit because I feel like it's a bit of a noncommittal answer, like things would get better. Well, generally speaking, even our toothpaste gets better every year, but you just don't know how much. So are we thinking things would gradually become better for SOC analysts and SOC teams and DNR teams, or would you expect some kind of a magical improvement moment?

Linear or step function?

Uh, yeah, kind of.

Thank you for the fancy description. Yes.

If I were to place a wager, I would go for linear, and here's why.

Oh, oh, that's unexpected.

Here's why. Adversaries use the same AI much more efficiently, I would say, than defenders.

And?

So the game is changing on the other side too.

That's interesting.

Um, I don't see how is that backing up your point about gradual improvements though, because I mean, if attackers are using AI, defenders using AI, everything can be a step function too, right?

Actually, I think what she argued sounds more like a gradual disimprovement if both sides are doing it and adversaries are doing it better.

I don't know. I'm more optimistic than that.

Okay. I want to pick at another thing here, which is Anton and I were walking around RSA, apparently turning on spigots or something, listeners. I don't know where he was going with that. And we noticed that a lot of the AI SOC vendors, and there were a lot of them in the corners and in the back alleys of RSA, they were making claims that sounded very similar to what we heard from SOAR vendors 10+ years ago. And in your opinion, when we look at what people are trying to do with AI today versus what people were trying to do 10 years ago with SOAR, are we making the same mistakes all over again, or are we making new mistakes?

Okay, so SOAR is an interesting point. SOAR is an area where we might actually get a step function because the problem with SOAR as it was traditionally is you had to hardcode a lot of these branches and a lot of these workflows. And AI presents the promise of kind of like a fuzzy playbook, if you will.

Yes.

And that removes so much of the complexity. I mean, in theory, the complexity doesn't seem high, you know, you just build a playbook. But when you get into the reality of it taking months and months and so much talent and so much, you know, work within an organization to build these playbooks, you know, they just don't, or they just don't do it in kind of a a quick, complete manner. So, I think where it comes to that, there's certainly very, very huge promise of improving that and improving on that message because it just doesn't have to be as deterministic. Now, may we lose some things if we remove the determinism? Possibly. But I think there's probably more to gain than lose living in the reality of just an organization can implement, I don't know, n playbooks a quarter, and that n is not very high at the moment, right?

Yeah.

No, that N is very low for playbooks, and that N is also very sadly low for detection content.

For detections, yeah.

Yeah.

Super low.

Yeah. Yeah. That's going to go send us down into a chute of lamentation and head scratching or whatever other metaphors I can think of, which would be this.

But you know what? There's another N that's worth talking about being very low there, too, which is the ability of SOC teams to learn to deal with a new alert type or a new playbook type. There's like 3 steps in there, right? There's, I'm going to engineer my alert, I'm going to build my playbook, and I'm going to train my people to deal with Both of those things. And I think that end might be the smallest of all 3 of those.

Yeah.

Oh man.

Absolutely. So you have like security engineering onboarding 20 data sources, like 80 data sources in 2 months. But then you have like maybe a 1 source a month, 2 source a month kind of like onboarding on the operational side. It really lags to how quickly you can ingest data. It really lags towards that. So.

Sorry, I think Anton wanted us to be less depressed and I made it worse. No, no, no.

But I think in theory, AI would magically create rules for all the data sources with magically matching your risks, right? Very soon.

Oh God, maybe.

In theory, I think that—

You're giving it a week maybe though, right? Because it's like, not to go on a quick rant, we have time a little bit. I still feel like if I wake up at 3:00 AM and start dreaming about, no questions at 3:00 AM, but just a dream, is that somebody loads up a bunch of intel into a funnel. And then at the end, what comes out is rules. But here's the twist. People can do that today. Like, I can drop a PDF into Gemini and say, write me a decent SPL. What I want is the rules that I can use in my environment, in my network, with my threats. Like, that to me is still a magical unsolved problem. And I want not just a bunch of TI, a bunch of rules, but I want a bunch of TI, a bunch of rules I can use. And that to me is a subtle but important difference. which I don't think we are quite great at. Yeah.

And can we run at whatever thousands of EPS? Can we run that data through AI models economically even, right? Or what type of optimizations can we make? Because if the question is, can I build a rule for Windows event logs? It's like, okay, go to Gemini or, like, build me 40 rules for Windows event log. It'll come up with some great stuff, right? But if the question is, which ones will work? I think it needs certain knowledge of the data that I think there's certain context windows, economics, things like that. You know, I'm not the biggest AI expert in the room, but I do know that there's certain limitations into making that super practical at scale. And I know vendors are going to be pushing the envelope on that, but it's not going to be tomorrow, right?

So, I hate to do this, but we're at the point in the episode where I have to ask our traditional closing questions. One, do you have a recommended tip to help people get more out of their SIEM tooling when they're adopting it? And 2, do you have recommended reading? And you're not allowed to recommend Anton's blog because I think he did like 3 times already on today's episode, which might be a new record for him.

Recommended tip. Okay. Recommended reading. I have to think about it. I may not have an answer for that, but—

Oh, it can be anything. It could be, it could be fiction you've enjoyed recently.

Right? Raising teenagers with love and compassion. You know, that's a good one.

Is that the name of a book? Raising Teenagers with Love and Compassion?

I think so. Yeah. Somebody, I asked somebody about management tips and they gave me that book. So.

Oh boy.

Unrecommended tip to make the most, I mean, it's probably a Captain Obvious tip, but getting out of lift and shift land and really spending the time to think about doing it right. Even though it's an obvious thing, people get into procurement cycles, deadlines, pressures, all these types of things. And so, if companies can schedule really kind of like a 3-month buffer before that craziness hits, if they can schedule a 3-month buffer, it's not going to be a very intensive buffer, but, you know, not very commonly am I asked, like, how is the right way to do this with this new... technology. It's just like, we have this, we have this, we need to migrate. And I think if people kind of set the time to think about what is the correct way to do it, what are certain things that I can avoid, that buffer could really make a world of difference and also bring the team into enjoying, kind of appreciating that line of thinking. So, what I've seen in engagements where we start talking about that, like, hey, let's talk about context as a first-class citizen. Let's talk about risk. Let's talk about things like that. Even if we'd mentioned it in a meeting like last week, they think about those types of things. It enrolls the team into that level of thinking and outside of lift and shift mentality, which again is it's not anybody's fault. It's just the reality of the procurement cycles that customers get into, right? Hmm.

I really like that advice.

Same. And no buts, no Pokémon cringy faces. Sorry, Pikachu.

Listeners, Anton is killing me today. Svetla, thank you so much. for joining us today. This episode was a long time coming. It actually ended up being kind of a long episode. So listeners, if you enjoyed the longer content, let us know. If you hate the longer content, don't let us know. And Svetla, thank you so much for joining us today.

Thank you.

And now we are out of time. Thank you very much for listening and of course for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcasts. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast.

By Google.