EP228 SIEM in 2025: Still Hard? Reimagining Detection at Cloud Scale and with More Pipelines

Security running.

Hi there. Welcome to Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior Product Manager for Risk Analytics, Detection, all things cloud 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 all on the Google Cloud Security Community page. Anton, we are talking about our favorite topic today, which is clearly SIEM, not cloud security somehow.

Yes, I think the detection and response does sell the tickets. I don't know, like we, we are not renaming our podcast to same security podcast or it seems security-related or anything else. No SIM jokes.

Oh, no.

But the DNR does sell the tickets. I mean, people show up, people, you know, cheer for us. People say, give us more. We have a lot of really fun DNR episodes planned, including how Google does it, including some stuff on detection engineering. A lot of fun. But today—

But don't give away our roadmap. Tell the listeners what we're doing today.

Right. Excellent point. So today we are talking about One possible vision for a future of SIEM. It's not coming from us, it's coming from a different company. But it's interesting that that thought that there may be various choices, various visions for a future of SIEM, and this one is interesting enough to feature on the show, did occur to me.

You know, this episode was very challenging for me because as we were recording, I was struggling to wear my podcast host hat and not my SecOps PM hat, and I wanted to jump in with all of my, but this is why we do it this way on SecOps, and not hear out our guest on why they do it that way. And so listeners, maybe you'll detect my internal struggles during this, or maybe you won't. But with that thought of it's hard to wear multiple hats, let's turn things over to today's guest. Today we are joined by Alan Braithwaite, the co-founder and CTO at RunReveal. Alan, we're talking about SIEM today, which is a topic recently dear to my heart and for a very long time dear to Anton's heart. And one of the more basic observations about SIEM is that it's hard. You need to get storage, security, end-to-end user journeys, and you have to be better than these products where you can go out on the street, wave a stick, and hire 20 people that have been using an incumbent SIEM for the last 20 years. And so how do you approach that? How do you get the idea that's like, yeah, let me go build a SIEM, that's a fun idea?

Yeah, yeah.

First of all, it's great to be here, but I think it's a little bit of hubris, or maybe a lot of hubris, that got us started on this.

For sure.

My co-founder Evan has worked in security operations for a long time, and my background is actually as a data engineer properly. So when I looked at the SIEM space, This is something I've followed for quite a long time. What we saw was that their SIEM has kind of been lagging behind in the technology space in terms of what has been brought to the analytics and the business intelligence space in terms of really sophisticated big data tools that you can do all sorts of cool things with.

Sure, sure.

Yeah, so we decided very early on that we weren't gonna build a database. lean on this database called ClickHouse to build the SIEM, and then really just focus on the product offering. So, we realized pretty early on that to build a really good SIEM, you have to kind of approach it with a first principles perspective and build all of the different features that security engineers are looking for, just kind of right out the gate. And so, the first year we spent just building from the ground up. all of the detection features, the analytics, and all of that right out the gate. So it's difficult, but by leaning on these new data warehouses and OLAP tools, it gives you a lot of flexibility and leverage to be able to integrate with a lot of other tools that are more big data native, for lack of a better term.

I mean, it would be kind of weird to build a SIEM in 2025 on a relational database. I think it was weird in 2010 to do that. But yeah, I think that you do it. But also, I agree that you building a custom data backend for 99% of the SIEM builders would be really weird as well today.

Yeah. Yeah.

So let me ask you a strange question in the context. So when you watch the industry discussions, and by this, I really mean LinkedIn discussions, you do see people who fight this somewhat artificial battle between decoupled SIEM where the data storage is provided by one vendor, or maybe it's just provided by a customer somehow. And then, the vendor just builds a security layer, the machinery, the detection logic, the content. And at the same time, there are people who offer the opposite, where they combine SIEM and storage and UX and EDR and kitchen sink and a firewall, in some cases, maybe not a firewall. And then, it's like a SIEM, EDR, XDR of some sort. So these points in different directions. And if you have— which camp do you sit in, or do you think the whole debate is stupid?

Feel free to tell Anton the debate is stupid.

Yeah, yeah, you kind of got at the root of it there, I think. I think really the debate is kind of moot because you really want to be able to utilize and activate and extend the data that you're putting into your security data platform, whether you're building a security data lake or just a data warehouse to store your security data. You want to be able to use that data for more than just what your SIEM can provide. And that's what we've really seen when we talk to customers and prospects about what their problems are. They've really struggled to get the extensibility out of their SIEM, so they're kind of locked into whatever that SIEM provides out of the box in terms of functionality. So we kind of see it as not necessarily an either/or, but By building a platform where you can store your data in a database that you have full access to, and you're able to extend and add tables to and add new views to, it gives you as the consumer a lot more flexibility in what you can build. That being said, it's from what we can tell based on our conversations, not a lot of people want to buy just a security data database. Right? They really want the built-in features like the detections, like being able to filter the data as it's coming in so it's not costing an arm and a leg just to be able to store that data and query that data. And so that's when we realized we had to build all these other features on top of the data store itself. So really what we see SIEM as is the evolution is becoming kind of a white glove service for data engineering for the teams, while still providing these point solutions that get at the core of what a SIEM is supposed to do, which is detection and response.

I want to pick at the costs aspect because we're in a world where there's just more and more and more data, and everybody's seen what happens with cloud environments. And so, as you're building this product where you're using somebody else as a backend, you said ClickHouse, how do you address that cost trade-off, and how do you do the scaling, and what does that look like for you?

Yeah, that's an excellent question. I think cost is a big one because nobody's going to be successful selling a SIEM more expensive than Splunk today.

Wait, wait, wait, we need a brief pause to let that sink in.

Let that sink in, yeah.

But also, like, there are so many jokes about Splunk costs we could make on the show that I almost feel it would be misconduct not to make at least one. So would you like to make at least one?

Exactly, yeah. So we realized that from day zero, of course, and that's one of the beauties of picking up some of these modern tools that have really high compression ratios, and the compression ratio also helps with the performance. So when using an OLAP database, similar data is stored close together on the disk, and that gives you the ability to store more data in less disk space.

Mm-hmm.

And ClickHouse is really good at this. That helps with the costs just right out the gate, but then also we realized that there is a big need for just being able to own everything inside your own infrastructure, and that really helps with costs too because we realize that when you're buying a SIEM product, there's oftentimes you're sending it to somebody else and it's locked up in their database And you're paying rent on rent on rent, right? They've got their own database that they're building or buying, and then they're passing on those costs to you. But by allowing people to bring their own database and supporting on-prem from very early on, you can control the costs of the database and the whole deployment just by having the right amount of controls for filtering data, for transforming it.

Yeah.

And for routing it to things like long-term storage, like S3, or to your ClickHouse instance, which is going to be your very fast query database.

So you're managing the trade-offs, in other words?

Yeah, yeah. We just expose those trade-offs to the customers so that they can better manage it themselves, because it's really hard for, as a vendor, to know what's going to be important to the business or not. So it's really important to expose those controls and the management capabilities to the end users so that they can actually be empowered to make the decisions that are important for their business.

This is kind of, quote unquote, the right answer, I think, but it's also an answer that can cause stress to some customers where it would be about, well, what would you like to keep, X or Y? And if you keep both X and Y, then you're out of money. So I, certainly respect the position, but ultimately, I want this storage to be cheap. But as I sometimes joke, for every SIEM, cloud or on-prem, somebody is paying for hard drives. There's no way to not pay for hard drives. And a lot of this just pushes into the laws of physics in my mind.

Yeah.

The bits have to go somewhere.

Yeah.

It has to go somewhere and stay there sometimes for a year or 2. As a funny aside, I was talking to somebody a couple of days ago, and they pointed out that their SIEM that is supposed to be modern, has the cold and hot storage. And I'm like, what year is this? Like, why are you— like, I mean, to me, the fact that you have hot and cold storage and you, the customer, have to decide what to do with data with this supposedly cloud-native SIEM is kind of— something is off. Like, I don't think that's how it should be.

Yeah.

It brings horrible memories of uploading Oracle partitions. in the '90s to a certain SIEM that used to do that.

Yeah.

I don't know.

There's a bit of analysis paralysis there for sure. And we're trying to get ahead of that a little bit by pulling out signals from your data pipeline, signals that are security relevant. So for every source that we connect with and integrate with, we can go through the different event types and only select the events that are really important for detection and response. And then save the rest to S3 just in case you need to do an incident investigation. And just really making the process of reloading that data from S3 into the SIEM to make it easier to investigate. I think making that workflow really smooth is important there. But you're exactly right. When people just want to be able to send all their data into the SIEM, it makes it really difficult. So, there's some decisions to be made there.

And I think one of the decisions is presumably taken on the input. So, that brings us to this new hotness of security pipeline vendors. And while many people know Kribble or Bindplane or others, wouldn't it be like whenever we do maybe an episode on this, and I always had this thought in the back of my mind, isn't it like logical to include it in a SIEM? Like it should be part of a sim and I hear from, well, from you, yours does. So is this like, why is this not common sense that sim would include that capability?

Yeah. Thanks for asking that question, Anton, because that's always nibbled at me too in the back of my mind. Why is this separate?

Yeah, I completely agree. I mean, that's something that we were wondering from day one, you know, I remember A long time ago, watching a video on the Logstash developer talking about how it was rage-driven development that encouraged him to build Logstash and to make it into something that is more reasonable for collecting logs. And I found that very inspirational, actually. And I think that over time, we've just gotten so much more experience with how to handle logs at scale. Things like having structured logs be the default instead of unstructured logs has really enabled a lot of these tools to be able to do these things more easily. So if you imagine, like, when you're just using text logs, it's a lot harder to filter out the data that you don't want, because if you write a bad regex, like, you could suddenly be losing data that was really important, right?

Mm-hmm.

And so I think the evolution of the technology has really contributed a lot to how we're thinking about filtering and routing data as it goes into your security data pipeline. But that's just how I think it's evolved.

But it's in a couple of years, people should just have a better SIEM that includes this and not SIEM plus this separate vendor that offers Pipes that you can connect to pipes on both ends and stuff would flow through the pipes. I don't know, like this makes me question my life choices.

Yeah, I mean, it's clear Cribble is kind of going in that direction, right? With— they've got their own security data lake that they provide. So it's pretty clear to me that everybody's kind of converging on this common architecture of having some routing in, in the ingest and then routing, filtering, transforms, and then having your data lake where you build everything out from. So I think we're in good company there in terms of where we're headed.

So I want to talk about PipelineQL.

Sure.

And doing detection in SQL. How does that work for people? Because I've had a lot of conversations over the years with people about language for detection, and some people like SQL, some people don't. I've gotten really mixed results. How is this going, and is this a Good shift in your experience.

No, no, no. We need to bring more rage. Sorry, Tim.

Oh, sorry.

No, no, no. This is like way too mellow.

Anton wants to be angry, listeners. This is great.

Yeah, I want to be angry. The reason I want to be angry is that I feel like we have started with this back in the good old days of RDBMS-based SIEM when we had the 2 choices, the ugly UX, UI by a SIEM vendor, or you go direct to SQL. And admittedly, in my younger years, I've written some detection rules in SQL, and I feel like I'm scarred for life because it was really painful.

Yeah.

And when other choices became available, I felt like we should never write stateful detection in SQL. I mean, it's ultimately, I can do filtering, alerting detections in SQL, but if you try to do a stateful thing, combine elements, or even like, how are you going to do ML in SQL? Like, that's insane. So some of this sounds like a horrible flashback to the mid-1990s, late 1990s, when the first SIEMs were born. So, I almost cannot have a serious discussion with somebody who shows up and says, ah, SQL, we're gonna write detection in SQL. I just wanna strangle them. I'm sorry. It's just not— help me here. Why is it not a horrible choice?

Of course. So, it really started with having a good data store, first of all. So, picking up ClickHouse. ClickHouse supports SQL out of the box, naturally. It's the tool of analysts primarily. So that's something that, like, analytics people, BI people who are used to interacting with big data databases using SQL. But really, we wrote PQL, which is what we're calling it, very early on because we realized that people who work in security just don't like writing SQL. And I understand. It's a lot easier to understand and comprehend piped query language because it's what we're using on the shell and the command line all the time. Plus, I think it's a lot more intuitive to be able to think about a dataset as it's going through each step of the pipeline. And so, we built this PQL to compile to SQL because we didn't really have a way to— well, it just made sense to us, right? Like, SQL is the way that we interact with the ClickHouse database, and it's the way that people can interact with really any large-scale big data database. And so we thought it would be good just to be able to enable that for our customers. And when we submitted it to Hacker News, one of my favorite comments was like, it seems like these guys learned 4 years faster than everybody else that security engineers like using pipeline query languages. So maybe there's some challenges that are inherent in making it performant when it compiles to SQL. But SQL in general, I think, can be very capable for doing things like correlations. I think stateful detections are quite difficult still, but I think a lot of that is actually becoming much easier with LLMs, to bring that into the conversation.

Yeah, okay. I think that, well, I do have a degree of compassion to that point of view, but it also sends me down another dangerous path. path, namely that detection is seen as a subfield of data retrieval, which it kind of isn't though, which it kind of isn't. So it almost like makes me think that a lot of minds would be poisoned by thinking that detection is essentially data retrieval because it uses the same language as SQL, right?

Yeah.

So, and yeah.

I see your point. Yeah.

I'm nervous.

I love this world that Anton is laying out for us listeners where he's worried about our minds being poisoned when it comes to thinking of detection the wrong way. I'm getting like, I don't know, I feel like, Anton, you're taking me down a path from Dr. Strangelove. They're poisoning our precious bodily fluids with this idea of SQL as detection.

I did say minds. I did not say bodily fluids, to be fair.

That's a quote from the movie, listeners. If you haven't seen Dr. Strangelove, it's one of my favorite movies.

Yeah. Okay. I think that it's— I mean, these days with converters, if your LLM is smart enough and if you can convert my beautifully crafted YARA-L into SQL, hahaha, then maybe. And I think we're gonna get to Sigma in a moment. So actually, fine. I think I'm at the point when we need to switch subjects. Otherwise, I'll come up with some other horrible '90s joke about SQL. So in addition to the debatable decision of using SQL, you also have made the great decision of using Sigma.

That's right.

And you are sort of Sigma native from the point of view that you don't need a converter to run detections in Sigma, right?

That's right.

How did that happen? Like, you have converters, you clearly aimed at interoperability. So the first thought that came to my mind when you mentioned this was, oh, so you can use a lot of popular repos of Sigma content. Sure, but I mean, were there other reasons? Is Sigma easier to author for some detection tasks than other choices?

Yeah. So I think when we were getting started, we realized that we were going to be kind of behind in terms of what detection content we were able to provide out of the box. And so we looked around at the ecosystem and we saw that Sigma is really well-loved and popular format for writing detections. And we thought, well, why don't we just try and integrate that into our platform? And it brings up a good point, to your point earlier about how do you do detection at scale with all of these different types?

Yeah.

ways of querying the data. And Sigma for us is streaming only. So it's looking at every single event and looking at the Sigma detection and determining whether or not to pull that out of the stream and alert on it or create a signal based on that. And so Sigma itself was very apt of a tool to do that because it describes, it's kind of self-describing what fields it's looking for in the log. And fortunately, Sigma is mostly based on the raw log itself. So like we can run the Sigma rule on that raw log and as we're processing the data in real time and pull out those alerts. So the SQL-based alerts are better at aggregating data over time, and the Sigma-based alerts are better at pulling out those real-time alerts that are absolutely critical to have in real time. So.

Well, that's really interesting to me that you've set up this dichotomy. How, how well do customers understand that distinction? Like, is that easy for customers?

Wait, wait, real-time and stored or what?

Yeah, yeah. Is that easy for customers to grok? And does that, does that make it hard for them when they're designing their rules and all that? Like, how well does that play with users?

Yeah, I think so, but I'm sure there could be some improvements made. In particular, I think, you know, we've got SIEMs like Panther, which started out as just per-event-based alerting first, and then they started adding some contextualization And then now they have a full SQL-based alerting system as well, based on Snowflake. So I think it's not that unnatural for people to understand the difference between like a streaming alert versus a SQL alert. But yeah, so people have been picking it up pretty well, I think.

That makes sense. Nice to have a shout out for Panther, friend of the show. We're getting close to time on the show today, and I want to ask you, like, what do you think is next for SIEM this year? We've got RSA on the horizon. Listeners, I'll give you a sense of when we recorded this. What are we going to see there? What's coming? What's the future of SIEM?

Yeah, so I really think SIEM and a lot of these big data applications, even beyond security itself, a lot of it is going to come down to data modeling and data access. So because of things like LLMs, and I don't know if you all have been watching the news, but Model Context Protocol is a new way to interact with tools using LLMs.

Oh yeah.

But I think The big thing that it highlights for me is the interface that we interact with our applications is changing dramatically as we're watching it right now. And so I think products are going to be much more about the workflows and the data models that you design into the product. And so how you design that is going to be, like, tantamount to the success of the product. And so that's kind of how we're thinking about it at RunReveal. And I think that's how SIMs generally are going to evolve is like, how can we best make the data able to be accessed and activated and utilized in the ways that our customers really need to utilize it? And so I think we're going to see that across all SIMs and across the industry as a whole. So.

I think that it's the least pretentious reference to agentic AI I've ever seen in my life. Because instead of showing up with a big, big slogan written in crayons, We have agentic AI in our SIEM.

That's right.

You just talked about MCP integration and how you have an MCP server, and it's, like, so beautiful, actually.

That's a very chill reference to MCP. I like it.

Yes, yes.

We try to be pragmatic here.

Yeah. So let's talk about the— well, let's close. And usually Tim does it, but now I'm going to try to not bungle the task. So usually we close with 2 questions we ask. One is, give us some resource or reading material. It can be anything that can be read by humans and machines, perhaps.

And second is just give us one tip Sure. I think one resource that I've really been enjoying recently is TLDRSec. It's a newsletter that kind of summarizes various things that have happened in the last week, both like threat reports and new tools and happenings in the security business space. And one tip for SIEM is just think about what it is that you need out of your SIEM, what it is that your SIEM can do for you. Because, you know, to quote a president, ask not what you can do for your SIEM, but what your SIEM can do for you. Because really, I think a lot of people are just spending way too much time doing data engineering, and we're really trying to change that and do the data engineering so you can really get to the interesting stuff like threat hunting and incident response.

So I think it's the modern remake of the focus on the use cases advice I've been giving for a good number of years. But of course, done in a much more modernized way. So, thank you very much for being on the show. This was fun. And of course, sim episodes do sell tickets.

Thank you so much for having me.

That's true. People love sim episodes.

Yeah, it's very fun.

People love those. Yeah.

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_Chuvaikin and _TimPico. 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.

Security.