EP149 Canned Detections: From Educational Samples to Production-Ready Code

Security.

Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Tim Peacock, the Senior PM for Threat Detection here at Google Cloud, 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.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You should also follow the show on LinkedIn, where this episode originally aired as a livestream. If you want to catch the video content from that livestream, you can also follow our page on YouTube. Anton, we're talking about detection engineering, we're talking about trust, we're talking about transparency. This is a heck of a dive into detection engineering today.

Correct. But it also has a particular spin. It's not just a dive into detections. And by the way, today I think we violated one of the rules of our podcast.

We have rules on our podcast?

Not really, no. But we violated them anyway because it's called the Cloud Security Podcast. So we're supposed to—

We didn't talk much about cloud, did we?

We are supposed to make the audience say something about the cloud. Like, I think that if they say, wow, what a cloudy day today, and point at the sky, that would qualify. But we did not do that.

We talked about cloud once. Once.

We did?

Yes.

Wait a second.

Listeners, see if you can find it because Anton's already forgotten, but I'm sure we talked about it once.

Okay.

Maybe with that, let's turn things over to today's guests. Folks, welcome to yet another live session of the Cloud Security Podcast by Google. We are delighted that today, not only have you chosen to join us live or watch the video later, we're joined today by John Stoner, Principal Security Strategist, and Dave Herald, Head of Adoption Engineering. John, Dave, no strangers to the podcast. Thank you for coming back to join us.

Thanks for having us back.

Thanks for having us.

We're talking about detection engineering today, which is no small task. Let's start out with trust. I think trust is this really interesting sort of alchemic ingredient when building security products. What makes people trust vendor detection content? Easy question, right, guys?

Yeah, yeah, don't jump in all at the same time.

Well, I'll start off. I think that if I'm a customer, and I've been a practitioner throughout my career before I kind of moved over to the vendor side, and so if I was a customer and I'm looking at vendor detection content, really what I'm thinking is, what makes this vendor special? Or like, why can they assert to me that they're any good at this? And I think The kinds of answers that I look for, for that are things like, do they have threat intel that's not easily accessible to other vendors? Are they a cloud service provider or are they an EDR company that has visibility into vast swaths of the internet? And then are they connecting that intelligence to their detection engineers and are they actually making use of it? So, Those are the kinds of very direct questions that I would probably be asking and looking for some level of assurance that they're actually delivering on that.

I like that answer, especially the part about connecting threat intelligence to the engineering team. Anton, which guest was it that told us about the story of the CISO who was buying threat intelligence reports to read in between meetings?

Yes, that was the story which I've tried to politically incorrectly share on Twitter with some obscured— some details obscured, and you can check what happened as a result. But yes, I think that Intel as entertainment is a valid business. I think if I'm writing about exciting threat actors doing really exciting things and I have an audience, that's great. But ideally, we want threat intel to reduce risk for somebody somewhere down the chain, right?

Yeah. To me, intel is how can you apply it, right? That's the key question of threat intel. And I think detection creation is one of those ways, but it's not a given. It's not a given that just because you have that visibility that you've turned it into useful detection content.

Yeah, it's not enough just to have it sit there. You actually have to do the work.

John, what do you think? John's probably written more detection rules than I have.

Having good threat intel goes such a long way. I kind of think back to— I had a circumstance where I had a customer using open-source threat intel, and they kind of just took it all, and they kind of started working with it without trying to decide which one was of maybe higher quality, maybe which ones had better fidelity, maybe prioritizing certain kinds of data sources on their side. And they ended up with hundreds of events to triage every single day. And there was probably a Greek mythology story in there where, you know, it's the rolling the ball up the hill. Is that Sisyphus?

Yeah.

Right. And it rolls back down at the end of the day. That was almost the kind of task that they were taking on without having good threat intel, without having good information there to be able to help prioritize which of these things is more important. And so that alone, without having that to start with, and you're just taking everything as the same level of quality, it can be paralyzing, quite frankly.

So let me briefly— this actually makes sense, of course, but let me briefly switch to the possibly other types of detection content that may be written by a vendor. So going back a long, long time ago when I was working for a particular SIEM vendor that shall remain nameless, a lot of the early SIEM thinking behind detection content was about providing samples for customers. And I think in one of the blogs, we've reflected the fact that some vendors and some customers actually treat out-of-the-box content as education. Oh, these are some samples. You can learn from them. But other people treat them as prod code, as production code. So this causes, to me, still causes a headache to a vast slice of a security community. If I buy a tool that can detect stuff, and it comes with detection content. Is this detection content more education, like an extension of a manual, samples, or is this stuff that you're supposed to run? I'll just, like, ask it bluntly and expect a beautiful short answer with bullet points and possibly slides, too. Okay, no slides. It's a podcast.

Succinct is not exactly my strongest suit. I'll take this as a starting spot, and it's a little bit tricky. And having worked at another SIEM vendor that will remain nameless to go along with yours, one of the first things I know our services team often when they walked in the door was to turn off all of those detections that our customer had turned on during their install because it didn't provide that high fidelity that the customer was looking for. They were getting buried in alerts, right?

Their own content from the same vendor? I'm sorry, I have to ask.

It's no different vendor, but probably a different vendor that we worked at.

Okay.

But yes, that same kind of challenge, right? You know, it's funny, vendor agnostic signatures, which I think a lot of folks aspire to writing, are really, really nice because they give you a lot of flexibility, right? I can turn it on for anybody. And so I can start seeing value right out of the box, right? That's the buzzword that goes along with that.

You mean like portable signatures, you can move from vendor X to vendor Y?

Right. That's the idea with that vendor agnostic. But at the same time, each customer has their own specific nuances, their own risk tolerance, their own edge cases, their own unique application that cause these things to run. And to be very frank, Both parties, the provider as well as the customer, need to kind of have an agreement and understanding that, as a vendor, you aspire to have good signatures that you could utilize out of the box.

Mm-hmm.

But there also has to be a recognition that each customer is bespoke, and one size never fits all. So that's kind of the starting spot with that. The vendor-agnostic pieces that rely on threat intel, those are maybe places where you could take more advantage of those right-out-of-the-box pieces.

Mm-hmm.

Because you bundle threat intel sources that maybe have high fidelity, not like what we talked about a few minutes ago, but high fidelity intel sources combined with maybe those vendor agnostics, they can be a little bit more tolerant. But if the vendor is providing Cisco firewall rules or CrowdStrike alerts as their starting spot, you're potentially cutting out large swaths of your population by being too vendor specific. Those are some of the things. I'll stop because I told you I'm not going to be succinct on that one.

I like what you brought up about swaths of the population, and I maybe want to take a different tack here and ask, There's analysts of different levels of skill. How do we help SOC 1 people who maybe can't even read the detection logic trust that their vendor is doing a good job?

Right, right. Sorry for barging in, but it reminds me— I'm going to age myself again, but the previous time this discussion flared was in the IDS wars in probably the early 2000s, right? When I say, I have Snort, you can modify signatures, you can look at them, you can do whatever you want. It's all open on the website. And I have some commercial IDS vendor that has since died. I wonder why. Where signatures are really secret and you can't really look at anything, but they're really good somehow. But then I am the guy who does not understand the SNORT signature format. So for me, it doesn't matter. My vendor has open signatures, closed signatures. I don't understand the format.

Listeners, I just want to point out that when Anton was fighting in the Clone Wars, I was in middle school.

He was probably in— no, I think it was you were in TK.

Well, I mean, there's a few different topics there, but I think that the secrecy, the transparency maybe is a better way to say it, of SIEM rules. I think it's an important topic. I'm an advocate for vendors to be as transparent as they possibly can with the logic. Everybody understanding that depending on the vendor that you chose, they might have sources and methods that they don't want to disclose, but they still want to convey some value with the knowledge that they have. And so, hey, we're going to maybe not show you all the logic that we're using for that, but to me, that's where metadata around detections comes into play because, hey, maybe I don't know exactly what that SIEM rule was doing, but I know things like, oh, what was the telemetry source that that came from? That helps me a lot as an analyst to say, oh, that detection came from Windows event logs. That detection came from a Palo Alto Networks firewall or some sort of network telemetry. There's a lot, I think, even just natural language explanations of what that detection is.

Hmm.

Or what would fire that, I think goes a long way towards helping an analyst make one of the hundreds of decisions they have to make that day about, is this important? How do I assess this? How do I triage this? Those types of things go a long way, even short of showing the rule logic.

Did I hear you right? Are you in the camp of, yes, please give me LLM-generated explanations for findings? You said natural language explanation of findings. Do you mean you want the person who wrote the rule to include some context, or do you want the robots to explain it to the user?

Well, the former.

The former. Okay.

I think that's a responsibility of a professional detection engineer, a person that's certainly a person that's writing content to go into a product. Like, that's really on them to explain that as well as they possibly can. And sometimes I think that's even more important than maybe exposing the rule itself. Just because, to the point, not everybody understands how to interpret a rule. And let's face it, some detection rules are hundreds of lines long.

Totally.

And necessarily so.

Which reminds me, this also reminds me, like, when I was on a quest for detection transparency the previous time, somebody showed up and said, Anton, it's a misplaced quest. You're so '90s. What about all the ML? But ultimately, it's not just about ML. In your case, you had an example of detection content that's 5 pages long. And I think it was your previous employer that people performed the very long SPL queries that would detect well but give you a headache in the process, right? So the point is transparency. How do we get a quest for transparency and clarity of detections if they're ML?

Also, I love this episode because right now it really feels like the SIEM vendor witness protection program. Everyone here except me has worked at a SIEM vendor, but nobody's willing to name names. This is great. Either it's a witness protection program or there's some kind of amerta around former SIEM vendors. I don't know which is worse.

It's a little bit of both, but since we're on LinkedIn, I'm sure the game's up already on that.

I think it's not so much the amerta, it's a SIEM ex-employees anonymous organization.

Ah.

I think it's more that because it's anonymous, right?

It's a support group.

It's a support group. I see, I see.

It's a support group. In the relation to the ML pieces of this, I think, I don't wanna say ML is easier. I think it's trickier. There are probably less people out there that are in a position to interpret or troubleshoot the underlying ML to go along with this. So the population of folks that are looking to understand the really bits and bytes of it is probably a little bit smaller. But to Dave's earlier point, having a good descriptor around what's happening out there, what is inside of this rule that I'm about to crack open is incredibly important. And the example I think of is that with an ML, right, you've got all of these different algorithms. You've got k-means clustering, you've got linear regressions. If you're not versed in those kinds of things, you probably have no idea what those things are. You're going to go out and Google what those different algorithms are. But being able to say in that detection, in that description, hey, this applies to a Windows platform, this applies to a GCP environment, this is going to be focused on the destination or the target IP address over a 4-week window. And does k-means clustering? Well, that gives me a fighting chance of understanding the context that this detection is going to operate in versus a linear regression over the past day for a specific user logged into systems. So having those specifics in there, and I'm not going to pretend that we have ML kinds of rules that we've built, but on the GitHub site for Chronicle, we have a community rule site where we've actually gone through and tried to build out more of those descriptions, assumptions, references, platforms. Those kinds of pieces to provide that context when somebody takes a look at some of the rules that we write to kind of go, okay, yeah, I kind of get a feel for this. And then the last part of that is also commentary, because you were just talking about hundreds of lines of rules sometimes, right? If it's this or this or this or this, fire these things. Putting comments, which sounds simple, just like code, into your rules goes a long way for somebody to look at that and go, oh, you know what, if I turn that knob over here a little bit more, or I bring in this data source over here, I can get this much more bang for my rule that I might not have had otherwise.

Is it one of those, like, so simple nobody does it kind of thing? Is it, like, so simple and practical that nobody does it? No.

No, it's not so simple nobody does it. This gets back to, weirdly enough, one of the lessons we've had during our management and growth episodes where, like, if you were good at people, you might not have gotten into this field in the first place. And if you're good at communicating via comments, You might not have gotten into writing code in the first place. I think it's one of those.

Yes.

I think that's very true. But I do think that when we talk about using AI and ML detections, I think maybe it's not different from broader concerns with AI and ML of just like introducing things of explainability. I don't need to know how to understand how a neural network works. What I need to understand is what are the inputs to this detection? That were the material inputs that caused it to fire, or some other way that I can understand and explain to myself as I'm trying to triage an incident or triage an alert, like, okay, what were the pieces that fed into this? And can I explain this to myself, right? Do I understand why this fired? And I think that's the kind of context that's very practical that you need to provide to an analyst, even if the— detection mechanism was really, really complex based on all these AI capabilities. It needs to be explainable to the analyst. I think that's the responsibility you have from detection engineering.

And it applies to all black box detections, whether what you have in the black box is AI or actual code that is just not— which is kind of, I guess, a profound thought of the afternoon, I guess, not the day, is that It needs to be explainable, whether it's ML, AI, little gnomes, magic, or code that just isn't exposed to you, right? To trust it, you have to understand. Tim is smiling.

That's good.

I did say something funny for a change.

I like the idea of little gnomes, detection gnomes.

Detection gnomes.

And it reminds me of the question that came up earlier, right, about detection content. Is it a jumping-off point? Is it something that you're trying to teach your customers how to phish, if you will? Or is it expected to be production-level code? And I think you need both. If you're a vendor that's putting detection content out there, you need both of those. And you might say, hey, if it's content that's teaching you how to write rules, we might put that into our community and give you a chance to say, hey, oh, now I can learn about that. Maybe I can decide to maybe put that into the tool. But if it's something that's being directly fed into your product, I think there's an implicit agreement there that that will be production level. But I think maybe one piece of good news on that, which I've seen change as I've been in this industry, is years ago you might have an on-prem SIEM. And so every detection has a cost. It's either an explicit cost, or it might be, hey, we only can run a certain number of detections. And so I think With SIEMs moving into the cloud, it's kind of interesting that we've become— the vendors and the customers maybe have become more aligned there because when you're talking about the expense of running a detection, that's actually shared now, or, you know, that's on the cloud provider. So it's to their advantage to make these things run better and be production ready, be more efficient, and it's to the customer's advantage as well. So I feel like there's maybe a better alignment there than there has been in the past where You could just throw a detection over the wall, and if the customer wanted to add it in, maybe they had to add more capacity to their on-prem SIEM. But—

I think this is a podcast episode on its own.

Yes.

The costs. Yes. I think they should almost like— I want to pin it on the board. And this is like a really useful discussion to have. And I'm not going to make fun about certain vendor licensing policies. It really is about what it costs to run certain detections. Like, it's a genuine question for people. But today, what are we gonna cover today, Tim?

Well, I wanna pivot on cost because the cost to run a system is not just the cycles and the disk and the licensing. It's also the team's time to make something valuable. And one of the big places time gets used up is tuning. Is tuning still a thing we should be talking about in 2023? What's going on there?

Tell me about that.

Yeah, I mean—

Oh man, sad noises to start.

No, no, no. Tuning, I'm sorry. I took my car into the shop a few weeks ago and one of the things they talked about was the spark plugs. And after they do the spark plugs, even apparently in electronic systems these days, they still do some level of tune-ups. Either that or he was trying to sell me something else, which is probably a separate conversation.

The latter, yeah.

But anyhow—

Was it a Tesla dealer talking to you about spark plugs?

Take that offline and we'll figure that one out. But I think tuning, I mentioned earlier this challenge of There's always that app, there's always that edge case, there's always that corner case. The rules don't apply, and I'll pardon the pun there, but the rules don't always apply to every single thing. And so, there always needs to be that feedback loop as you go ahead and field your rules. Is this going ahead and doing what I expect it to do? Yes or no? Maybe it's working 95% of the time in the way that we expect it to, but there's that 5% or that 2%. Where there's something there that we need to tune a little bit further to increase that fidelity. And that, to be very frank, to me, that's a function of IT as a whole, right? That's something that we're constantly doing. If we look at code, right, we're constantly fine-tuning our code to get more out of it as well. So this to me isn't something that's a terrible thing. Now, like I said, you come in and the first thing you do is turn off everything and you call that tuning. That's a separate ball of wax.

Yeah.

But it's, hey, here's an alert. We've onboarded new data sources. We've onboarded and upgraded a new parser. We want to see if there's more information inside of that to be able to do something with. To me, that's part of normal operations, and that's not a bad word. That's improving efficiencies over the long term.

To me, tuning, the table stakes for tuning is sort of like scope. And so, I'm talking about things basic like allow list, deny list, as far as Hey, we want this rule to apply to our crown jewels and maybe some, you know, allow lists that represent those, but we don't for maybe other populations, or there's test or dev or those types of situations where I think that to me is just something that I expect to be able to tweak on a rule that comes from a vendor. But if you're talking about tuning in terms of like, hey, am I going to fundamentally change the logic of this rule?

Then you're writing a new rule using the other rule as a sample, right? You're not really tuning, right?

So I feel like it's more of a scoping question. And, you know, I'm trying to think about these things in terms of detection content that comes from vendors. I think it's incumbent on vendors to give you that level of parameterization or scoping, I guess maybe is the best way to say it.

So you can adapt them to most sane environments. I don't think you're going to magically invent the one-size-fits-all for the environment where one size does not fit all. Like, Signatures that magically fit everybody after being written once in the lab is probably not a thing. By the way, before we go to closing questions, I want to ask a scary question. And I mean, you should all brace ourselves because it's going to be scary. And the scary question in every detection discussion is, of course, the false negatives. People obsess about false positives, how they're like a total problem and how they suffer and how their bosses complain, blah, blah, blah. But It's almost like there's a kind of a rule about not talking about false negatives. So, how are we supposed to eliminate them if we don't see the exact details of what's being detected, whether it's ML code or little gnomes? Gnomes especially.

It's a tough one, right? I mean, to your point, everybody gets worked up about false positives. But on the plus side, with a false positive, if I have an opaque detection, I at least have something that I can work back against and go, no, no, no, no, no, no. Maybe tune that kind of a thing out somehow, some way. I was thinking about that. I was like, okay, what are some ways? Because again, if the logic's opaque and there's no detection, how do I reevaluate? How do I independently judge?

Prayer?

It's just not there. I'm not sure what the right answer for that is because it's almost like you don't have an input, you don't have a logic, how do you get an output?

You can have some kind of a simulator of similar activities maybe, like you have A little Atomic Red Team thing that just like blasts it with everything you can imagine, and then something, I guess, if it doesn't detect anything—

But that's the challenge. You just said that, blast it with everything you can imagine. So, if you can't imagine it—

Yeah, yeah, yeah. It's a shotgun, not a rifle approach. Yeah.

Yeah. It's a really tough thing because if your emulation or simulation environment isn't built to cover those bases, then going back to Tim's earlier comment about efficiencies, There's a lot of burden that you're putting back on that team to go through and build those emulations and simulations to cover all of those different things that you're talking about as well.

It's one of those things where you can never say we're going to eliminate false negatives, right?

Yeah.

But I think that there are things that vendors can do to help mitigate that when they're publishing their detection content. One of which is, I think, categories, like having a category of detection. that maybe you turn on or off, I think can be a really dangerous thing without giving a lot more context about, hey, what is it that you're actually looking for? Even if it's, hey, give me MITRE ATT&CK technique IDs or something like that. Even those, there's a lot of different ways for an attacker to accomplish the same technique. You know, if you're pivoting too hard in your detection on one method, you can still miss things. But I think I've seen products, and this is not a product of any company that I've worked for past or present, but they do things like—

Just in case.

Yeah.

They do things like, they'll have a category of detect Mimikatz. And then you check that, of course, I'm going to check that, right? Like I want to detect Mimikatz in my Windows environment. But then if you don't have that transparency, you're like, okay, you might have a false sense of security. And then, hey, the attacker recompiled Mimikatz or whatever. There's a lot of ways to change the easy indicators and you get owned. And to me, that's—

But then you have to pay some kind of a vendor that simulates 648 versions of Mimikatz and see and hope that your detections fire on at least some of them, right?

Yeah, I mean, I'm not saying that I have a solution. I'm just saying that in that hypothetical situation that I just painted, I put a decent amount of that on the vendor for giving that false sense of security.

Yes.

All right, guys, I hate to do it, but we need to ask our traditional closing questions. One, do you have a tip to help people improve their detection engineering? And 2, Recommended reading, and it could be anything from not Anton's blog to your favorite fiction books.

Mine is kind of both. My tip and my reading suggestion is detectionengineering.net. If anybody has seen that, it's by a person named Zach Allen, who I have not met, but this is an amazing newsletter. I think it's weekly. I think there's ways you can pay for it and there's ways that you can consume it for free. And just really next-level depth on this topic and a lot of breadth.

It's amazing combination of both. It's actually really good for both depth and breadth.

Well said. Yeah. And so that has been great reading. I've been having my team look at that pretty much every week. There's some pointer that I've been sending out about that. So that's mine.

Nice. And John?

You know what? I really have enjoyed getting re-engaged back with some of the Mandiant blogs. I've read them in the past. Obviously being part of the corporate family now, I've been going back into those as doing some additional research. Around a number of different kinds of cloud security issues. So I'd highly recommend those. I find, quite frankly, a lot of the blog reading that I do becomes fodder for being able to go ahead and build detections. And so whenever you're going across things, whether you're in your— do we call it the X feed, I guess, these days, or the Threads feed, wherever you're getting your updates from an InfoSec perspective, or any of the blogs that you read, always be looking through those and be thinking about, hey, This is something I want to go ahead and detect on. And when we say detect, I think that's the other thing is it doesn't have to be that high fidelity, 100% non-tuned alert. It can also be used for hunting because I know that's a little bit of one of my other things that I like to go back to is what are some of those hunting rules that we can be able to utilize for other things down the road as well.

Awesome. Well, folks, thanks so much for joining us today. And thanks for joining us on the livestream. We'll talk to you soon.

Thanks, guys.

Thanks all.

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_Chuvaikinen. 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.