EP267 AI SOC or AI in a SOC? Cutting Through Hype, Pricing Models, and SIEM Detection Efficacy with Raffy Marty

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here is ever myself, Tim Peacock, the Senior PM for, well, a bunch of fun stuff in Google SecOps. And of course, Anton Chuvakin, reformed analyst and now 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 on our YouTube channel. youtube.com/@cloudsecpodcast. 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, what are we talking about today? We're talking about SIEMs since I was in elementary school.

So this is actually a fun episode and the guest is— and I was really looking for this pithy one-liner and here it comes. Oh, that guest is the person with whom me and him mutually think of each other as the second best sim expert on the planet.

I love it.

I hope— well, I wouldn't name him quite yet, but I hope he wouldn't be offended by this. But I think the episode went really well. And he— I acknowledge that he's been dealing with sim for longer than I did, which is kind of a pretty big deal, I would say.

That is a big thing to say. I love the idea, listeners, of a world where there's 2 experts, each of whom consider the other guy number 2. I wonder, like, outside of perhaps the hockey players of Heated Rivalry, are there cases in history where there have been other experts like that? Anton, did you watch Heated Rivalry?

No, I know of it, but I have not watched it.

Okay. You know what it is?

Yes, I know what it is. Yes.

All right, listeners, that is enough pop culture for today. Let's turn things over to today's guest. Today we're joined by Rafi Marti, an operating advisor, and we're also joined by Anton's fresh from London haircut. So listeners, let us know what you think about that. Raffi, we're talking about SIEM, which is something that you've been doing even longer than Anton, which is hard to believe. And, you know, you've said recently that calling SIEM obsolete is a marketing slogan, not a true thesis. And while I personally agree with that, I'm curious what in your view as an operating advisor is driving that and what's the real pain, what's the actual gap And is SIEM actually dead? Please tell me it isn't.

Let's start with the small questions right away, right?

Yeah, yeah, yeah. It's an easy warm-up question, a real softball.

Yeah, exactly. No, I like it. So I think what's been interesting over the last few months, I've been digging back into the SIEM space because I've seen so many investments in new entrants, right? There's all these new SIEM companies, there's these AI SOC companies. And if you start looking at them, I'm like, wasn't that what we were trying to solve as SIEMs back in the day, right? Or along the last 25 years. And I think the premise is still the same, or to the promises they make today. But as the sim space, we kind of failed to really deliver on a lot of these different components. But it was always part of the vision and part of the architecture and all of that. And so, I've just been seeing lots of these new entrants coming on the market and getting funding. I was like, okay, there must be a gap. And so, I started looking back into the sims and Yes, there are gaps, but they're only sort of temporarily there, I believe, right? Because the new SIEM entrants, they have some kind of a value proposition of, hey, we have this much cheaper architecture, we're scaling better, we have better detections. Guess what? If the SIEMs are not going to correct it themselves, they're off the market. And then what are the new things? They're still called SIEMs again. So the incumbents, the Splunks, the Exabeams, the whoever, whatever they're still called, right, after all the acquisitions, They have to get on this stuff. And so I've been writing a lot about this in my blog. It's like the SIEMs are not dead at all. They just, they need to get going again, fix the gaps, fix some of the problems. I mean, look at some of the incumbents' retention rates of the SIEMs, right?

Mm-hmm.

Like, why are they losing customers? And there's some reasons, but I'm seeing too much temporary sort of fixes in the AI SOC space. Like, hey, Hey, we can help you reduce your alerts by 80%. Well, guess what? It's not that hard what you're doing, and the SIEMs are going to pick that up very quickly. They have to.

So is it more accurate to say perhaps the SIEMs, the old SIEMs, the incumbent SIEMs appear dead in the water, not dead dead, but if they don't pick up the pace, they will actually transition out of the water and into being dead?

I think so, right? And I mean, they have huge advantages. I mean, look at Splunk, right? They're part of Cisco. They're making billions of dollars. They have like big investment budgets. They gotta do something and they have the data too, right? It's not like they don't know what's wrong. They know their pricing is not ideal. They're doing something about it, but—

Not ideal.

Wait, wait, wait.

It wins you the overstatement, understatement of the year prize right there, Rafi, right?

That's really good.

Pricing for that company is, dramatic pause, not ideal.

That's a good one.

I'm trying to be very Switzerland here, right? Being Swiss, I'm trying to be like—

Ah. So Anton, you have a very interesting follow-up question, I think, and I want you to ask it because this is a topic we've talked about on the show before.

Yeah, I mean, it may be too painful for some of us because I feel like ultimately the point that Rafi made is just like definitely existed in my head for quite some time as well. So we kind of got nothing to argue about in that sense, and we are almost in a near telepathic agreement at this point. So that makes it not so fun. But we may or may not agree on the whole decoupling decentralized SIEM. And I feel like sometimes it's 2 topics where decoupled is the capability of storage separated from capability of security. But federated also means that storage itself is spread all over the universe from something that SaaS vendor stores for you to something you store in your uncle's flooded basement. Because, of course, people love to store logs in—

Yeah.

You know, uncle's flooded basements. It sort of inspired a very old story from years back. The point is, the central platform, SIEM as a central platform, is still kind of a default for most people. But can a truly federated and/or decoupled SIEM architecture ever achieve the same fidelity of data, quality of results, and also prominence in the market? Because again, I checked LinkedIn earlier today, And all those pro-decoupled, pro-federated SIEM people are there shouting how they are amazing. But in terms of what people buy, it ain't that. Like, I'm sorry, guys. Like, I know you have this exciting stuff, but what people buy is not you. People buy, still buy largely single platforms. And so that's why I'm kind of like, figured since Rafi is here, we'll just give this problem to him to solve.

Yeah, help make sense of this disconnect for us, please.

It's something that, as you said, right, like, I feel like we're discussing quite a bit recently on various platforms. And I still, like, a number of new entrants are like, oh, we're doing this federated stuff. And I've always been a big proponent of trying to say, hey, push the compute to where the data is, right? Why would you centralize all the data? But now you're getting into this catch-22 where, like, you need to understand the data access patterns, If you're leaving the data at the edge and you're doing some correlation or whatever, some intelligence, you have to centralize certain pieces. At some point, there is an analyst that looks at a queue. They are getting something somewhere. And even if it's multiple ones and you do sort of whatever, right? But so you're getting this data. Guess what? Now the analyst needs to do something, or the AI bot or whatever it is, the agent, right? They have to do some more investigations, some enrichment, some deeper dives. They might have to pull some other data back. Now you're centralizing the data again. So you have to understand these access patterns, right? So I think we need to end up in a sort of a hybrid world where you might, on the endpoint, all the system calls and everything, you're not centralizing that, right? You don't need all that data all the time. It's like, that's the EDR. The EDR looks at system calls and everything and says, here's something potentially bad, sends it centrally.

Mm-hmm.

And then you need to correlate across the entire universe of other things, right? Back in the day, you look at the firewall, you look at the IDS, you look at the endpoint, and you figure out if it's a true positive, right? And so you have to centralize some of the data. Now, you can do it intelligently, you can try to do adaptive sort of infrastructures and so on. And I think there's definitely something there. And sort of these smart data routing things, I think, is where it's at, right? Like, even based on detections you have, you don't always have to throw all the data centrally because for most of it, you never even look at them, the detections, the rules never even work on them. But for certain things, you need it. Again, the whole cross-correlation of data feeds is absolutely necessary. This whole— I had a debate on my blog, this whole, like, single feed or single event triggers, that's basically Sigma, sorry, guys, it's useful to a degree, But the false positives are huge. It's like an IDS looking for a string in a packet, right? So there's still a lot to be fixed.

So I want to pick on something you said in there about data pipelines and routing data. You've also called data pipelines the Trojan horse that would enable, you know, a swap out of the SIEM at the end of it. And there's, you know, from a PM's perspective, a million things that make a SIEM very sticky in its usage and its users. So just looking at this one piece of stickiness or potential unstickiness, what do you think? Is it really a Trojan horse? And 2, what should all of the SIEM vendors have done like 7 years ago to have avoided this fate of welcoming the pipeline horse into their gates?

Look at the Cribbles of the world, right? And there's others, DataBan, Observo, blah, blah, blah. What they've done is said, Hey, send the data to us, and then we'll help you optimize the feeds, and we help you route it to the right data store to stay cheap in whatever you do, right? And so, you're sending the data there. Now, you have this abstraction layer where they own your data integrations. That is super, super hard to get out, right? That's very sticky at this point. Now, they're routing it, mostly everything to the SIEM at the beginning, But then they have all these low-value data. We put it into your data lake somewhere that's very cheap. Oh, by the way, we have a search capability on the data lake. Oh, by the way, we detect simple things. We now run Figma rules on it. Hello, now I have a simple SIEM. And then guess what?

Yep.

Oh, you know, I don't like my SIEM. SIEM number 2 comes in and says, oh, just give us the same data feed, and then we figure out what to do with the rules and the configurations that you have. But now the SIEM that was very sticky in the environment, super, super deep tentacles everywhere, it has this abstraction layer and can just be exchanged, which is fantastic for the end customer, right? But more and more, the data pipeline people become SIEMs. You have seen the same thing with the UEBA players back in the day, right? Exabeam was UEBA, then they added the SIEM to it. Securonix, UEBA, Added the log management components. So, it's the same is happening again. And so, what you ask, and I said this in my blog, Splunk, you have to add the data pipeline components as features into your product. You have to.

So, I like most of it and I agree with most of it kind of philosophically, but I feel like growing a pipeline vendor into a full SIEM vendor with a full security brain, with storage, Possibly somewhat decoupled. It's kind of a tricky journey. I mean, Yuba, I guess it was tricky for Yuba and some succeeded back in 2010. Yeah. So, there's a— well, I'm kind of a little on the fence about it. Like, whether it's— if all you have is a pipeline, then 2 years later, you have a full modern SIEM. Doable? Not doable?

Well, you don't have to get to the full-fledged SIEM to start with, right? You start with some core capabilities. Who is using all the features of the SIEM? Nobody. So you're building some of the capabilities.

Yeah, there's that.

And then you partner with these AI SOC companies that are doing some intelligence on the alert feeds. Now you put 2 things together and then you put on a PE hat and they're like, oh, that's fine. This data piece and this AI SOC piece and you have a new company and you're making money, right?

I think that AI SOC, a pipeline and third-party storage and a bunch of duct tape together, you have a somewhat competitive product, which requires us to have a decent AI SOC. Sorry, I'm oversimplifying the craft. You're the CEO craft, Rafi. That's why you should never trust me with anything businessy. Yes, that's right.

But— Listeners, Anton clearly believes that the secret of product management is duct tape, which also happens to explain why he became an analyst, not a PM. But it's fine, it's fine.

Go on with your duct tape. Don't forget the whiteboard interview. Yeah.

Okay.

The actual piece that's required for the is, of course, AI SOC. And it's a very triggering question. And I think when we presented the draft questions for the show to Rafi, he's like, where is AI SOC? And we're like, where is it? That's an excellent point. So here it is. I am hesitating and shuddering and causing some pressure to rise. But what do you think of AI SOC with your I've been dealing with SIEM since 1999 experience?

So if you look at it from an investor perspective, it's very interesting. Because what happened is you have all these MSSPs out there, right? And that's only in the last few years, I feel like this explosion of managed security service providers. And it makes a lot of sense because we're starting to come downmarket with offering these security solutions, and you have to have a managed service provider in there. So the MSSPs are sitting there being overloaded with alerts. Okay, what do you do? Well, you have to optimize the alert load somehow. It turns out the SIEM feeds are pretty bad out of the box. These MSSPs with all these different customers don't have the budget to implement a SIEM like a big bank would and customize all these rules and everything for every customer. It's too expensive. It wouldn't make financial sense. So now you have the default set, you tune it a little bit, you get all these false positives.

Okay.

startup founder or entrepreneur shows up and says, show me your problems. Oh, I can solve that for you. Look at this stuff. It's an alert that's showing up very frequently every day at 8:00 in the morning. That is a password misconfiguration of a service account that is trying to do something. That's a false positive. Like, they come up with these heuristics, and very successfully so. So they plug in these very big problems for the MSSP of reducing the alert volume by 80%. MSSP says, hey, I will pay for it. I have now 10 customers as the new startup. Investor says, hey, show me traction. I have 10 paying customers. They're like, let's invest. There's a market. Like, it makes a lot of sense. But guess what? This market is not going to be around forever. At some point, someone figures out that the problem is downstream with the bad configurations or correlations or rules or whatever you want to call it. So the SIEM or whoever is going to fix that again. And so we have better signal. And then there's a whole world of detection engineering and whatever they're trying to fix this stuff. So that's the right place to fix it. And so a lot of this stuff will crumble. Now, the other challenge in the AI SOC space is that they're not solving one problem. I look at like, I curated this list of things that are wrong with the SIEM today that still need to be fixed. And if I look at the AR/VR companies, out of these 15 items, most of them solve like 3 or 4, but not always the same ones.

Yeah.

So, this explosion of something that will help you with better— making the sim better, but in the end, it's stuff that needs to go back into the sim. And a lot of things will not survive because you're fundamentally patching the wrong thing without really solving the problem.

And I mean, this is kind of reminiscent of what I see people obsess about alert triage, and pretty much 2/3 of AI SOC vendors are sort of triage helpers. And they all talk a big— some of them talk a big game about how then next they would fix detection engineering, next they would fix collection, next they would fix parsing. But for now, they just fix alert triage, sort of, maybe. You know, some of them fix it at $10 per alert. Again, don't get me started on that one.

But no way, nobody's charging $10 per alert, Anton, right?

Yeah, they There is a natural barrier.

If you're paying $10 for an alert, I'll do it for $9.

No, but per the intake, I mean, I usually joke, again, it goes into kind of a sidetrack, but if you have too many alerts, you can't afford it. If you have too few, you don't need it. With that pricing, that's an obvious logic. So there's probably like a narrow sliver of just enough trouble where it's affordable. I don't know. Okay, fine.

Okay, so pricing is a great topic.

Ah, okay, fine, whatever. Go ask the pricing question.

I want to ask Rafa a pricing question. So what does good pricing look like? Because you said earlier that there's not optimal pricing for some vendors. What do you think it looks like if we get to a world of more correct pricing? And what does that look like? That doesn't—

I want to jump the shark and literally not let him answer. Sorry, I'm going to be a bit—

You're the worst host today.

Technically, nobody knows this, Rafi, right? So you can't possibly have an answer.

I think he might have an answer. He looks like he has an answer.

You know, it's the best minds. Anton, you said it in the beginning, we telepathically are somehow connected. The pricing question is incredibly hard, and I do not have the right answer.

Ah.

I ran cybersecurity for ConnectWise for 4 years, and we had a SIEM. We sold to the MSPs, and our customer base is used— the MSP, MSSP, they're used to thinking seats. How many seats do I sell? How many users are at the end customer? That's how I sell my EDR licenses, my whatevers, right? If I ask them to pay by volume, they're like, what are you talking about? I don't know how much data I'm gonna send you. I need to go to this calculator to, like, understand, and then it's going up and down. I can't afford that. I'm in the middle. I'm just trying to sell a service to the end customer. They're not gonna change, like, based on the data volume I'm gonna give them a service. So, we sold literally by the number of users or in certain cases, by number of devices, right? That's not always— because in the end, what you have to understand is that a product, a company still needs to make money somehow, the vendor, right? And I think we all agree, even the end customer sees that. They don't— like, if the vendor doesn't make any money, they're going to go down. They're going to be out of business. So what is the fair way, the right way to price something? Again, for us at ConnectWise, it worked because we had a mixed sort of calculation we could do. We have a mix of customers and some of them benefited from others that wouldn't send that much data. But in the end, the data is what costs me. This is like, that's just what I'm being like, that drives the compute, drives the storage, drives all these different things. And so that's the fairest way for the vendor. It's not necessarily super fair to the end customer. It is fair in a way because the more data you send, the better your detections, Right. But it's just, it's hard. And I mean, this is what Splunk has been accused of, right? Like, their pricing, it's too high. And like, okay, the firewall data is now free, right? Because it's super voluminous, blah, blah, blah. It's a tough thing to figure out. And that's why if you actually look at the new entrants in the SIEM space, the new sort of these startups, a number of them say, bring your own compute and your own storage. And they just provide—

Which is back to decoupled, right? But it's also kind of cheating, right? Because if you say customer, you bring up, like in the days of our childhood, like you bring your own Oracle and you pay for the license. And by the way, while you do it, you bring your own hardware. It's like some horrible flashbacks to the '90s when you tell the customer, bring your own storage, bring your own hardware in a modern way. But the cop-out logic is the same, right?

And I think there's 2 important things to see here, right? is purely economical from the SIEM vendor. If I don't charge you for storage and compute, I don't have to mark that up, right? Because in the end, I need to make my 80% margin. So if I sell you something and if I pay for the storage, I have to mark it up and sell it to you for more expensive. So now if you're bringing your own compute, Yeah. you can get the deal with Amazon or, sorry, Google Cloud, That's right. And so I don't have to mark that up. So it should be cheaper. Now, obviously, there's less revenue for the SIEM company in the end, right? And then the other thing that we also need to make sure is that the SIEM product actually gives you the right tools to understand if you're sending the right data or you could optimize it, coming back to data pipelines, right? But we're still making sure that you have the right data coming in to actually trigger detections that you're interested in. So, it moves the responsibility a little bit, but I think it's not a bad approach.

I think that— okay, Tim wants to say something. Okay, interesting. You have a PM hat on. I see your PM hat appearing on your head, I think.

I'm just terrified by this notion of SIM used to be bring your own oracle. And you called it your childhood, but it was literally my childhood when that was happening. But I do think there's something elegant about that from a user standpoint of like, yeah, listen, We're not going to try to make money off of a commodity thing. You can buy a commodity as well as we can. But then I think maybe that's not actually the case. And part of the advantage of being Google or Splunk or whoever is you can actually buy the commodity cheaper than anybody else. So I'm not convinced about this decoupled thing actually being that user advantageous for users below a certain size anyway.

Hmm.

Lots to think about there.

Oh, I look, I absolutely Agree with that, right? Like, if you're an SMB and you're buying a SIEM, you don't wanna have to provision machines and monitor them, and you scale things and monitor them, all that kind of stuff. I think the SIEM still has to somehow give you all these management capabilities for you to manage your infrastructure. And again, the SMB wouldn't even— they don't have an AWS account, like, probably, or a GCP account, right? Like, So it depends on your end customer, on what you're going to do. And I think that's something that lots of companies forget, like even startups, right? Like one of the first things you need to figure out is what is your ideal customer profile? Who are you selling to? How are you going to market? How do you sell this stuff? How do they buy? All those product manager, like, things that you have to think through, right?

I think that this— I'm going to summarize in a very Probably in a very throw out baby with bathwater kind of manner is that it still, it depends is still the right answer. And there's probably still no, well, don't price the SIM by collection because if, especially if you make customers buy their own storage, right? Then you can price by something else as you kind of pointed out. But if you have the integrated system and even if you don't mark up storage, volume is still is your cost, right? Like the volume of data you take. Okay. So this becomes in a Tim and Anton podcast, SimPricing podcast, which I think is a little too nichey and dry, and Tim is making a cringe face. So, why don't we go switch topics to something way more exciting like detection engineering? And of course, in mine and Rafi's childhood, it was called, what is it, content authoring? What was the late '90s term for detection engineering?

Gosh.

The ArcSight had a role called, like, content author or something. Like, I am vaguely...

That was like, yeah, like 2004 or '05 at some point. I think we created a content team and like, yeah, build content. But we just—

It was actually not the ancient history. It was kind of like middle old history.

Yeah. But initially you just build rules and dashboards and reports and whatever other entities you had in your SIEM, right? That was it. Like you're building rules and alerts. I guess alerts is what we built back in the day.

And do you think that today we have any kind of like, can we fix that problem as well? Like, can we have the magically create good detection content that actually works at clients? I'm going to, I mean, that's like a big question. So it's like a Raffi scale question. So like, yeah, of course, humans used to write it and people tried to do threat intel to rules, which sort of didn't work out too well because intel was not so good. Then they tried ML. It kind of worked for this piece of the puzzle and didn't for the rest. And now we have GenAI and agents, and are we getting this finally fixed?

I think a lot of what people are thinking about right now is this detection engineering piece, right? And as you sort of recited some history on how we have done some of the stuff back leading up to this point here, I think we still have most of the same issues that we had back then. I just talked to some people that are actually experts in going in and setting up a Splunk after someone purchased it, right? And they're like, look, we scraped the rule set, we built our own. And I'm like, so, how customized does it still have to be per customer? It's like, it's a lot because the environment is just different everywhere, right? The data sources, the configurations, the thresholds that people are okay with or in the environment are okay, right? There are still all these adaptations you have to make. Now, I think there are pieces that the SIEM products or the detection engine or the analytics engine can help with. And it's just baffling to me that we haven't done this yet. And again, I outlined this in the blog post that I wrote recently. It's like the detection rule should figure out if the data actually ever comes in that would trigger this detection, or at least ask the user, hey, have you configured things so it would actually trigger this stuff, right? Then make recommendations on configuring things correctly and having these data feeds. It goes all the way. And then at some point, You get into more sort of the anomaly detection pieces, and Anton, I know this is your absolute favorite background, right? You grew up in the whole anomaly detection world, and I think we still haven't completely solved it because it's not that easy to find an anomaly, right? And define, like, have a system pick it up and tell you, hey, this is anomalous. Yeah, guess what? I was on vacation in Belize, and I actually did access the data from there, and I needed it because we had a board meeting.

Da da da da.

But I think the other trend that is a good one is what people start calling a context graph. And I guess Microsoft has done— their MS Graph has done a lot of that, where you have, whether it's a graph or not, I think a graph is a good data structure for it, but you're keeping track of the entities, of the users, the app, the endpoint, the application. And you know, at every point in time, what is going on with them? What's their risk? What's their properties?

Mm-hmm.

And you leverage that for the correlations, right? And because if I know that Anton's risk right now is at 20, because I just haven't had him authenticate with 3 factors, and I know he's coming from this IP that he usually comes from, I see the browser agent string that's the same that we've seen for 3 weeks and so on. His risk is very low. If he does something slightly risky, I can still let him do it versus if all these signals are different, I won't. And we haven't gotten to that yet. But that's, I think, is the holy grail, to have this context graph, the risk register, whatever it is, and bring as much data as you can in there. And then you can start doing anomaly detection on those things as well.

So, Rafi, you're describing a topic that's near and dear to my heart, so it kills me to have to do this, but I have to ask our closing questions because we're at time. One, do you have a recommended piece of advice to help SIEM vendors better serve their users? And then 2, do you have recommended reading? And it could be anything except Anton's blog.

Oh, boy. It's a good question. I think so. Stepping back for a second, as the SIEM vendor, really, really understanding what is your customer, how do you sell to them, what's the pain point in the sales process, right? And a lot of it is easy onboarding and making sure you can implement their procedures and so on. Some of the boring pieces, but then also educating customers and working with them and getting to an ideal state. What do they really want to do? What does perfect detection actually look like? What are they struggling with? And building towards that. And from that, I think you will start discovering all kinds of gaps in the pipelines and architecture. And then you have to go and prioritize and make sure that you can still run a business around it because you can't build the perfect system. Nobody will ever pay enough for that to be worth it. Recommended reading, obviously, Anton's blog, but also my blog, obviously.

And 3 of your blogs from recent time are really quite amazing. So, I'm going to put all 3 up there.

I think there's a lot of good content on LinkedIn, right? And I would recommend people, like, follow the people that are sort of in the industry and comment and have discussions. Don't just consume things. But I think that's The benefit of a platform like LinkedIn actually is to have conversations, right? There's some other— gosh, I can't remember right now. There's some other really good blogs, but I'm sure we can— Anton probably has a list of things. What is it? Detections FAQ or something? What's that?

There was a— yeah, there was. I think there were a couple that I've seen recently from various people, so I'll try to collect the recent sources. Okay. So one more question I want to ask is kind of about something really weird that also has like childhood memories for me, like time of Snort and network IDS and network anomaly detection. I hear from some circles that NDR, network detection and response, is not only not dead, but is experiencing a bit of a revival. And some people are launching startups. And I guess the conventional wisdom in 2026 is that things shifted to endpoints first, then they shifted to application. People are doing all this runtime observability stuff, and it's all deep inside the app. And the good old packet sniffing is forgotten. But you hinted that maybe it's not. And then, I saw the signs of it, as well. So can you demystify this one? Because I am honestly, I'm not sure what to think.

Yeah, I find this super fascinating, right? Like, back when we grew up in the SIEM space, it was all about network data. And the SIEM actually came about because we had too many false positives in the IDS, and we correlated that with the vulnerability scan at the end host and actually say, well, is this actually a problem? And we had the hardest time getting endpoint data. We did, obviously, Windows event logs to a degree, right? But that was not super verbose and whatever. But then it shifted, and suddenly we had access to the endpoint. And suddenly it was like, everything is endpoint now. We forgot the network.

Ah, yes, that's right.

But A, like, an endpoint is a single point of failure. It's pretty quickly like, oh, you don't get the data from there anymore. So, if you can validate if the network You see everything going around there, and especially if there are some gateway or something, right? You actually see what's going through, and you can understand, hey, we have 15 machines that we don't get the endpoint logs. So from a visibility standpoint, that is still a very important part. But it has diminished because there is the challenges of encryption and all those kinds of things, right? Now, in recent months, I've been having so many conversations with companies and even end customers Where they said that more and more they're starting to move things back from the cloud into the data center again. I'm like, excuse me, it's an actual trend. What year is this? It's maybe private clouds, right? Call it cloud or not. But especially if you look outside of the US, and I've been doing quite a lot of work in the European PE world, and there is definitely sort of two-pronged drivers, which is political, right? Like, not everybody likes the US anymore as much as they used to or trusts the US. So what are my alternatives to put the data somewhere else? And then it's all the data governance laws from the GDPRs to you name it in Europe and other countries. And so they're slowly moving things back into other clouds and into data centers. And so now you have to sort of look at the network again and to understand what's actually happening, right? So there is some interesting telemetry coming from the network. Now, whether NDR is really coming back, I don't think so. I think fundamentally, we haven't seen enough value for those and look at some of the recent NDR company sales that we had. But I think as a telemetry source, it's still super important. You want to have visibility. I mean, think OT, think again, unmanaged machines, all these kinds of things. We got to look at that.

Yes. I think that this is the value of the data versus the need for a separate market. You gracefully separated them. And I think that's actually an excellent point is that it's not about, hey, let's budget for NDR purchases, but more about, hey, don't throw away network data just because you have a good EDR or because you have application telemetry monitoring, because ultimately your router would get popped and you would never know.

And, you know, I think maybe you have to redefine a little bit what NDR in the end is, right? It's like some of the data collection, but the response piece is still interesting. So, if you can actually do something, it's the same on the EDR, like on the endpoint, I get the telemetry, I feed it back, I do some analytics, and I can hopefully do through that EDR channel, like, do some response to the endpoint. Well, do the same thing on the network, right? Now you have the network choke point. That's fantastic. And whether that NDR is integrated with your firewall and your whatever doesn't really matter. The capability is necessary.

Yes. And I think I like that. And I think that to me is a lot more logical than, hey, let's toss EDR and buy NDR instead. So thank you very much for the clarification. And this really made sense and of course was a valuable part of the podcast.

Awesome.

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 in the next episode.

This has been another episode of the Cloud Security Podcast by Google. Security.