Episode Transcript
Transcript is generated by AI and contains errors.
Matthew: [00:00:00] Welcome to the Security Serengeti. We're your hosts, David Schrodinger and Matthew Keener. Stop what you're doing, subscribe to our podcast, leave us a lovely five star review, and follow us at SerengetiSec on Twitter.
David: We're here to talk about some cybersecurity and technology news headlines and hopefully provide you some insight, analysis, and practical application you can take back to the office to help protect your organization.
Matthew: The views and opinions expressed in this podcast are ours and ours alone and do not reflect the views or opinions of our employers.
David: And this week's episode is brought to you by Sysmon, the Dane Cook of endpoint tools.
Matthew: All right, our first title today is from our favorite security startup blog. It's called Cybersecurity Technology Adoption Cycle and its Implications for Startups and Security Teams. And this is a post about how different types of security teams adopt or buy [00:01:00] technology at different rates when a new solution comes to market.
Our focus is not so much so on the startups and more so on the security teams. So when I wrote out the summary here, I skipped parts of it, but I. Thought were more applicable to startups and less applicable to companies like we work for that are doing the buying. In the article, they lay out three different large scale groups of security teams.
They are not very catchy names. I wish he had come up with like a more succinct way to refer to each of these groups.
David: Well, the first one's the MEFS.
Matthew: M E F S, the meths, the meth heads. So the first,
David: acronyms.
Matthew: we could have done that. So the first one is mature and engineering focused security teams. And these are the guys that you see writing blog posts. I see I misspelled blog posts and the notes blog posts and email newsletters about, you know, automating remediation and detection as code.
They're very mature. They're [00:02:00] very well funded. And then to tie this into the Anton Chevakin article, we looked at a month or two ago. These are typically from newer software engineering companies that don't have a knock history because they don't have that history. They were able to kind of create their own security and the form that they needed at best.
The second company is mature, but not engineering focused security teams. So if the other one was meth heads, this would be like Johnny mnemonic MN nef teams, nefs, I don't know.
David: Just give it up.
Matthew: They're still, they're still well funded and they're very organized, but these are, again, from companies with a NOC history. They are typically Fortune 100 companies. They're regulated institutions like government contractors. They are financial firms. They're insurance firms. They're, they're well funded, they're organized, but they typically don't build their own tools.
They buy tools. The final group is less mature teams and orgs that lack resources. It's in the name. They lack the [00:03:00] resources. The company could be very large, but if they're not regulated, then there's no requirement for security, or leadership might just decide it's another cost center and they can't afford it.
The author argues this is the majority of security teams, and that would not surprise me at all.
David: Right. And when he talks about engineering here, he means software engineering. Throughout the article, he talks about an engineering mindset. What he really means though, is an organization whose primary raison d'etre is software development. The mindset implies that you just have to have that worldview, right?
Rather than it being an organization built and designed for software engineering. So I kind of think he miscategorizes these organizations. And it kind of sounds a bit arrogant to me that he's poo pooing anybody who's not in the first group.
Matthew: Typical though, of most, like, Of a lot of these companies. Like if you come from Apple or Google, you kind of think of everybody else's just a tier below you
David: yeah, surprise.
Matthew: So each of these three teams acquires capabilities in [00:04:00] a different way. The engineering focus teams, the Googles, the apples, the et cetera.
They build it themselves exactly how they want it. Then we don't use off shelf tools unless it meets needs exactly. And we've seen this before. I remember. When I was working as a government contractor Google built their own remote forensics tool where you could remember you could like query computers like they were databases using database language.
I think the first time I saw myself something like this is probably 2014 or so. Netflix I looked up, they've got something called Security Monkey that's a custom tool they built for monitoring and securing their AWS infrastructure. If there's not a tool that's out there, they are a company of security, of software engineers, they will build it themselves. This allows them to respond more quickly to new threats. And according to the author, they will switch to a mass market tool if it's capable enough for a good fit. Or if they want to focus a startup to build something specific to what they want, then they will work with a startup.
David: You know, [00:05:00] I'm kind of wondering if, why wouldn't an organization like the size of Google? Who were to build this tool in house, spin up their own subsidiary to do only that thing, and then maintain those tools. Also, you know, build a software, a computer, a security software startup or subsidiary of Google.
So they would never actually ever have to switch over to commercial. They would continue to use that tool and they would have this subsidiary that that's all they did was manage that tool and make sure it works and. And stayed working and had updates and stuff like that to it.
Matthew: That especially makes more sense now that they've built not Sentinel, but what was the Google Sim? I mean, didn't they Chronicle? I mean, didn't they effectively do that?
David: I thought they bought Chronicle, didn't they?
Matthew: they bought Chronicle. All right. So. No, I think that does make sense. Like once you reach a certain scale, it's all, it may be better to just, like you said, create a subsidiary and then maybe you're the subsidiary's only customer, or maybe the [00:06:00] subsidiary tries to sell to other similar companies.
David: Yeah. I mean, it can start off as they're the only customer, but if they get successful enough, then they could start marketing that to other companies. It's kind of like the the concept of a QSO at a credit union where they have a wholly owned subsidiary that can provide services to other credit unions.
But generally those start off as servicing only one credit union.
Matthew: Yeah. Yep. Makes sense. All right. The second team, the non engineering focused teams they, if, if there's a mass market tool, They will have a giant suite of purchase mass market tools, but if they need something new that is not handled by the mass market tools, they tend to try to work with specific startups.
And influence a new product to be more what they specifically want, but lack the ability to build themselves. And I've actually done this several times when I've, in the past, when I've worked with companies where startups would approach the company that I worked for and be like, we have this cool [00:07:00] tool, would you like to try it?
And that's kind of the, the implied exchange there is that, you know, you help fund them while they're building up their customer base and you get extra say in what gets built and what gets prioritized.
David: Yeah, I think that really depends on the nature of the solution and how important the business sees it because I've seen larger organizations won't deal with tiny companies.
Matthew: A sweet spot there because if you're one of the first companies to buy into a startup, you can have a lot of impact. But like you said, most large risk averse organizations don't want to be the first customer because there's a strong chance of failure. They want to be like the 20th customer, the 50th customer.
But by then, if you're the 50th customer, you no longer have much impact into what is built.
David: yeah. These larger organizations are rarely first movers.
Matthew: Yeah, we'll talk a little bit about that later. Finally, the less mature teams, they just wait for it to be commoditized. Their late adopters, they wait for [00:08:00] it to come for free. Example, Windows Defender. They don't have CrowdStrike. They don't have whatever the next gen EDR is with AI built in that makes your coffee when you come in first thing in the morning.
They just use the free one. They didn't roll out a network IDS. They waited for Palo Alto to include it in the firewall. Actually, most of these probably don't even have battle altitude. They probably got one of the small, small business firewalls. So, this is a slightly different way of calling out kind of what we've discussed a few times before.
This has been something that I've had a growing awareness of. I'll be honest. I read stuff like this and I keep trying to implement it. And like, you know, you go out and you read about the latest cool things that, you know, security at Google is doing, and you try and figure out how to fold it into your company.
And I think this explains why I've been mostly unsuccessful so far at folding these types of ideas into the companies I've worked for. I'm trying to take a engineering led idea and trying to fold it into a non engineering led company. And I think Or I'm just really bad at it. [00:09:00] That's a possibility too.
David: think it's a misnomer to call it engineering led though. What you're talking about is you're trying to, you know, Take you're trying to develop software in a company that doesn't do software development. So you're trying to get your organization to do something they don't do. You know, if you're, if you're GM, you know, you make cars, you know, you have a software division that does the software for the car, but you're not a software company per se.
So when you have another software challenge somewhere else in the business, you don't go to this. software development team at GM and say, Hey, I want you to code this thing for me. Whereas Google, that's all software all the time, right? Even though they do have some physical infrastructure now, that's not their primary existence.
Matthew: don't think that's strictly it. It's not that I, not everything that these companies are doing is software specifically, but like for example, let's talk about risk based alerting. We've talked about this for years since we saw it in Splunk, it is kind of the next generation style of alerting and they're not the only ones doing it.
There's a company called AmpleLogic that's doing an additional analytics layer. And we'll talk about, talk about this a little [00:10:00] more in the second article, but it's still, it's still a bridge too far for some security leadership and executives that are kind of mired in that old knock style of, you know, one alert, one analyst.
So you're, you're right that a lot of it is software engineering, but some of it's not, some of it is just. Like applying software engineering principles of automation first and reduce reduce the boring work. There's a word for it. I don't remember what it is. So like, just kind of those principles, I feel like, I feel like there's a whole generation of security leadership that's not ready for that, or that pays or that pays lip service to it without actually Putting funding, resources, and priority behind because everybody says they want to do less work.
Everybody says they want to transform how we do business. But as we talked about the other week, like most transformations are not, I
David: [00:11:00] Right.
Matthew: think, yeah, I think it's more of a mindset, but anyways, anyways, back to the
David: Well, not more of, I'm saying there's, there's multiple things at work here. Having an engineer, a software engineering capability in house, that's, that's, that's what they do is one thing. And then the leadership support of, you know, executing or leveraging that capability
Matthew: fair enough. Alright, so back to the show notes, back on track. So there's a pretty significant gap between the capabilities of these security teams. This purchasing pattern implies to me something like a 5 to 15 year difference in capability between these groups. My assumption is that, let's say that there is a, I don't know, quantum computer security you know, as quantum computers, let's say quantum computers become mainstream next year, and now we need a new capability to protect quantum computers from, from AI. Engineering focused firms, they [00:12:00] can probably develop something in as few as three months. I mean, they've got their own software teams. They've got people they can task to it. There'll be some, you know, research times and testing times and build time. They might have a minimum viable product pretty quickly. If a non engineering focused one, when there's not building it themselves, they've got to wait for a startup come out of stealth mode, I assume, or maybe to approach them while in stealth mode, probably 12 months minimum, probably more like 24 to 48 months. And then if you're one of those less mature companies who waits for it to be commoditized, like that's going to be whenever Microsoft or Google or Palo Alto buys the startup and integrates it into its own product.
So five years, 15 years, somewhere in there. I know that's a wide range.
David: Yeah, but you can't tell, I mean, depending on what the, what the capability is,
Matthew: Yeah.
Yeah, I mean, SOAR, when did we see SOAR really start was that 8 years ago?
David: Yeah, eight to 10. That's a really when it
Matthew: finally kind of [00:13:00] coming mainstream and we're seeing it being integrated into, like, Splunk is now starting to integrate it, and Palo Alto XDR is starting to integrate it, so that was about 10 years to kind of become mainstream and start to become commoditized. I don't think it's fully commoditized, I think it's close. So yeah, I don't know. This is, this is interesting. Now, now I guess my other question here is, is this actually important? Because so much security involves correctly doing the basics. I don't know if this 5 to 15 year gap actually matters much unless you're in one of those industries that's targeted by APT. And maybe this is a lesson for smaller companies, like maybe the IT leaders that treat security as a cost center are correct. Maybe you should be ignoring security as a separate function and focus that time and energy on doing IT right. Of course, no company actually does IT right. So this is not, I don't know if this is actually actionable advice.
David: That sounds very familiar though, as if maybe we've said this a dozen times before cause I mean, we're at the point now really where core security needs have pretty much been developed, [00:14:00] commoditized and, you know, widely available, this new security stuff is really stuff we're talking about that makes difference at the margins.
Matthew: Yeah. And frankly, smaller companies, although actually smaller companies could be doing super innovative stuff, but. Yeah, I don't know.
David: Well, you figure maybe a small biotech firm or something like that, maybe has the necessity to do important security,
Matthew: Yeah,
David: they're a small biotech firm. So if they were wise and doing their security, they would outsource as much of that as possible.
Matthew: yeah. Alright
he states that this is the opposite of most industries. The author states in most industries the smallest companies are the hotbeds of innovation but for security, the largest and best funded are. This makes it difficult for startups as a startup has to convince a risk averse large company to buy their product.
David: Yeah. I'm not sure that's exactly accurate way to, to, to phrase that. Because I think this also is going to hold true for other products that are designed for overhead solutions, like say accounting is up or something like that. It makes sense for [00:15:00] companies. That produce line of business tools where smaller companies are looking to take advantage of the cutting edge to beat out the big boys.
So I, I think trying to say, you know, this is a security cybersecurity problem versus a line of business versus overhead software I think is not exactly an accurate way to put it because the, the smaller companies, they're not going to go with some cutting edge thing. When it doesn't go towards their bottom line, it doesn't make them better in their market. That's just added expense for them.
Matthew: yeah, I don't know that I know enough about how non security companies function to
David: Well, I'm just thinking about it from an economics perspective of overhead versus line of business. And in a competitive situation where the small business wants something that's going to make it competitive against someone who has vastly greater resources than they have, right? So, buying security tools is not going to make that difference for that small company.
Right?
Matthew: Hmm.
David: If it's not, you know, and that's the same thing [00:16:00] for any overhead tool that that small company is doing that doesn't directly contribute to whatever that company's purposes. So I think you're going to see that same probably, in the, in the, in the article, he shows a waveform. I think you're going to see that same thing for other tools that, like I said, or other software packages, suites, or industries, or however you want to phrase that are going to fall in the same line as cybersecurity.
Matthew: Gotcha. Alright if you're going to build your own tool, he recommends not trying to replace a commodity tool keeping the tool simple and focused. He does say that using a startup as a design partner is pretty risky, as most startups fail. He recommended an escrow agreement for the source code if they fail, which I don't know that a startup would necessarily agree to.
David: Yeah, I'm not sure for a couple of reasons. One being that it would make it seem like they're not confident in their product or their, or their, or their company to agree to something like that.
Matthew: Yeah, and I'm not sure that the company would be able to [00:17:00] do anything to take advantage of the quote code if they got it. Like if they can't build their own product anyways, are they going to be updating? Startup code.
David: Who knows what their, what their thing. I think that that's something that goes along with his mindset of being in that tier one company. Right. So I'll tell you what, working for a large financial institution, you're not going to get the source code from some other niche product and then say, Oh, well, now we're going to start developing this code.
That's just not gonna happen. But I think it, they may, if they, if it ends up being a tool that they, well, I don't know. I think at that, if, if a, if a startup were to go under, I think it'd be better as part of a large organization just cut bait 'cause then you end up with legacy code that you have to maintain and stuff over time when, which is just gonna accrue additional technical debt.
So I think it would be a mistake. You can enter into that agreement if you want. Maybe just to tide you over. If that were to happen in an organization I worked for, I'd say cut them loose, you know, [00:18:00] post haste. Because they're going to have to do that for multiple companies, because they're going to end up basically kind of forking that, like open source. Because if they sell to multiple, multiple companies, they're going to enter into multiple escrow agreements.
Matthew: Yeah. That actually, that actually makes me wonder if the, the escrow agreement shouldn't be for them, but maybe that the company will open source. If they go out of business, they'll open source the code before they go out of business or it will become open source. If they go out of business.
David: better option, because then there's a possibility that someone would pick it up.
Matthew: Yeah. If it's, if it's truly like a good tool that the company just couldn't make work or something like that. Yeah. I don't know. All right. There's two quotes in here that I thought were kind of interesting. One of which is we've seen a lot of mass, a lot of large companies use the often using a market leader is a safe choice.
You know, no one got fired for using IBM, but the downside of that is that market leaders can become stale and dated. Uh, and we've, I've run into this myself in the past where. The, I'm not going [00:19:00] to name names, but there's a firewall vendor that I've worked with recently whose signatures are truly awful.
The same, actually there's two, two firewall vendors I've worked with where the, both of them market leaders and the signatures for their network IDS alerts are awful. They're mostly consist of here, something bad happened here. What? Oh, just trust us. How do you verify it? Why would you need to verify it?
Trust us.
David: So, so the the response is just a three blinks of the light.
Matthew: And the second one is don't move tools. Every time you encounter a problem, try to work with the vendor and get them to build what you need. I definitely agree with the first part. I feel like, and I think I've definitely heard stories about, you know, implementing something and then two or three years ripping it up and replacing it. But I don't know that I've ever had much success trying to work with the vendor to get them to build what I need. A lot of times the vendors just ignore me when I make suggestions.
David: unless you're like the size of the U. S. government and you're working with a large vendor, good luck in getting them to move on anything. I mean, if you have the opportunity [00:20:00] to get in on being a beta tester or something for a large vendor, then maybe you could have some influence. But outside of that, I'd be skeptical.
No,
Matthew: gotcha.
David: Mm hmm.
Matthew: . Title two, Sysmon, a viable alternative to EDR. Everywhere that I've worked over the last 10 years since Sysmon came out and kind of became big in 2014 2015, using Sysmon as an extended logging source has come up for discussion.
Windows logging is great, but it doesn't cover a number of items. Mark Krasinovich and Bryce Cogswell developed Sysmon as part of the Sysinternal suite to cover some of those gaps, and it's been continuously updated to cover more and more since then. Microsoft picked it up at some point, I don't remember which year specifically, but now updates and maintains it, and I think they hired Mark Rusinovich I haven't seen Bryce's name associated with it since then, I don't know if he fell off, I pulled that out of the Wikipedia article, Mark was actually the only name I'd heard associated with it, but apparently, I don't know.
David: Yeah, Mark's a big mucky [00:21:00] muck in Azure now.
Matthew: Yeah, so Sysmon covers 29 events that Windows does not by default cover including things like time stopping, network connections made, drivers and images loaded, cross process threads, registry changes, files, hashes, pipe events, WMI events, file deletes, etc, etc, etc. Many of these events are useful for detections and forensics after a malware or other malicious attack, and it's natural to want to get more and more data.
Detection engineers are always like, more! Data, but there's overhead. This is not free. It's free monetarily, but it's, it's not free in terms of time and effort. And Alex Tikshara points out, I think that's how you pronounce his name, points out that in an enterprise environment where you have to cover and maintain That coverage on thousands and thousands of endpoints, Sysmon is not the ideal tool.
He was cautious here to discuss some exceptions. Smaller environments such as test and lab environments, Sysmon's great. Companies that need to rely on free and open source and you don't have a budget for EDR, that's fine. You know, you're, you're, you [00:22:00] are in that case trading time for money. So it works.
So the discussion points is big thing here is that time is an important resource to be considered. You have to take the time to deploy Sysmon. You have to maintain Sysmon, you have to monitor your coverage and you have to restart it when it fails or bigger troubleshoot why it's not reporting in. Then you've got to build and tune the detections that use Sysmon.
As a leader, your goal is to quote, leverage endpoint signals to detect threats. And you're, what you're, what you're focused on here is the detection surface. How much can you cover of your resources? And deployment maintenance, how easy is it to maintain that coverage? The author says he's done it, and he said it was incredibly hard to maintain Sysmon on all of their endpoints.
David: Well, I think that just makes him a sucker because he should have made it IT's problem. But IT
Matthew: Ha! Ha! Ha!
David: Sysmon for their own purposes though. And if that's possible, you know, if that's necessary then you should just ride on their coattails with Sysmon because there's no real downside for you if [00:23:00] IT needs it.
Matthew: Yeah, that makes some sense but that doesn't solve the problem about the detections, which we'll talk about here. The SysMon's competitor these days is EDR. EDR was new and expensive and rare in 2014. SysMon was free. EDR has become a lot more commodified years since. In fact, I would say at this point, actually now I'm curious, I wonder what EDR's market penetration is.
David: It's deep.
Matthew: So. According to market entry strategies for EDR. And Mordor Intelligence. So, in 2024, the EDR market is 4 billion, and they think it's going to be 12 billion in 2029, so that's still quite a bit.
David: That's a nice chunk of change.
Matthew: Yeah, that's a significant amount of growth. So, but it's still, so that means it's not, it's not nearly as widespread as antivirus yet.
David: It's not saturated market yet. Mm
Matthew: Yeah. So it looks like the growth market is small and medium enterprises. So I think all large enterprises at this point [00:24:00] probably have EDR or rolling it out and now they're moving down market to the smaller and smaller companies.
David: It's like we tossed a put in the last article.
Matthew: Yeah. Yeah. That makes sense. All right. So it's not quite commodified yet, but it's close. Definitely much more than it was in 2014 when I think carbon black was the main one. So EDRs watch many of the same things as Sysmon, but they provide additional value. They provide detections and alerts built in, and many of them provide response features.
CrowdStrike, for example, has real time response, which allows you to remote into a system from the CrowdStrike console, which is super helpful. Now, if you compare this to Sysmon yes, you have to roll out both Sysmon and EDR, so that's about the same. Then you have to maintain the coverage. I don't know if that's the same or not I'm not, I've only, it's been years since I've worked with admin and I do remember that trying to bring back agents that had walked away or disappeared or shut off was a giant pain in the [00:25:00] butt,
David: Mm
Matthew: when I used HIPs back like 10 years ago. And the, but the real differentiator is the alert detections. EDR comes with its own alert detections and it comes with the raw logs. Whereas with Sysmon, you've got to develop all the detections yourself. EDR companies have teams dedicated to creating those detections. Can you do better than the, you know, CrossStrike dedicated detection reading team?
And you might be able to.
David: hmm. Obviously.
Matthew: There's probably some places you can do better, but there are a lot of places that you can't. I think the big, the big, so that's his argument. And I think the big counter argument to this is that EDR vendors keep their detection logic close to the vest. It's hard to know what they do detect. I've mentioned it on the podcast before.
This is one of my go to anecdotes about EDR. But a couple of years, several years ago, I asked CrowdStrike because I was trying to develop a map of what MITRE ATT& CK techniques we covered [00:26:00] so that we could try and get some idea of where our gaps were and where we should be developing detection logic.
And I asked our CrowdStrike rep, what MITRE ATT& CK techniques do you cover? And he said, all of them. Or tactics, you cover. Whichever one is the one that, you know, and he's at all of them.
David: Of
Matthew: is, A, not helpful, and B, factually incorrect, because some of them are network based techniques that CrowdStrike Couldn't possibly cover. So what we ended up doing was we ended up going back over the, over a year and the data and our SIM and pulling out a list of all those detections, which they, it is helpful CrowdStrike has in their detection, the MITRE attack mapping. So you can run back a year's worth of those detections if you have that.
And you can at least see what detections have fired in your environment and map that. Spoiler alert. It was not the entire MITRE attack framework. Now the downside to that is it's possible that, you know, you weren't attacked using the specific technique or [00:27:00] tactic. Now, here's where the real answer is.
The real answer is breach and attack simulation. The real answer is, if you have a breach and attack simulation tool, you can run all of those attacks across your environment. And sure, they will be automated attacks. They will probably be fairly simplistic attacks, but at least you can tell if you would see them or not.
David: Now, is there anything that you, you can do with Sysmon or or logs? You can generate one that you can't do with a, an EDR with the right detection.
Matthew: Well, it depends. Sysmon, Sysmon has 29 event types now. You would have to map those 29 event types to what they are. The specific EDR you were looking at would or would not detect it's possible that, you know, maybe the EDR is not looking at WMI event providers. I'm pretty sure most of them do, but it's possible that one of them is not.
And in that case, you'd be like, Oh, well, we need Sysmon if we want to cover that. So, but then you can filter a Sysmon, you [00:28:00] can write a filter for Sysmon so that you're not getting in all the junk.
David: Yeah. Just that narrow band for what you're looking for.
Matthew: yeah, there's also a good use case where, let's say you have production technology of some sort and you don't want to run an EDR on it. Sysmon might be considered lower impact by IT,
so I don't know if that's a, I don't know if that's realistic or not, but that makes sense that you at least have options. If, you know, your manufacturing technology group is like, we don't want you to put CrowdStrike or whatever other EDR,
David: more agents
Matthew: yeah, no more agents. So,
it's possible. You'd have to look at it and you'd have to look at what you're, and this, this again gets back to getting the stupid EDR vendor to tell you what their product does. Which is frustrating.
David: does stuff. Trust me.
Matthew: All right, so he mentions in this article detections versus analytics. Alex says that companies should be built, should not be building their own detections, but they should be creating their own [00:29:00] analytics. And I'm going to admit to some, uh, and there's a corner case for detections where you have special knowledge.
Like if you have a specific system that does a specific thing and you know, it does that thing and you know that when it does something that's not that thing, it's super suspicious than writing your own detection for that is great. So I'm going to admit to some confusion here as to what exactly constitutes a detection versus what constitutes a.
Analytic. So analytics, I know, is a fairly new concept for SEM, and I've only started hearing it regularly over the last couple of years. I originally thought it was just a fancy name for detection logic, and it frequently seems to be used that way. Splunk has a page for detection analytic types, and it has listed under there the analytic types it has are TTP, baseline, anomaly, and anomaly.[00:30:00]
Hunting, correlation, and investigation. These are quote unquote detections in Splunk, but some of them are meta detections. I mean, a correlation rule, for example, is combining two things. A TTP is adding context to an atomic detection or correlation, although correlation is the only one which is enabled out of the box, which is kind of interesting because that's kind of the default, what we think of when we think of a Splunk rule.
IBM mixes these two. It has, quote, search based detection rules and, quote, search based analytics. But then it says you can enable Sigma detection rules as analytics. So, how are they different? MITRE talks about detections based on ATT& CK as analytics. So, I, I, I think as analytics, basically detections you wrote, whereas detections is what the vendor wrote.
Or, Because I was, after, after reading the original article, I was starting to think of analytics as like meta detections or combinations of detections.
David: I
Matthew: IronNet, hmm, I
David: kind of sounds like an idea that a [00:31:00] marketing guy jumped up in order to convolute the market to make their stuff sound fancier.
Matthew: I think it is. So I think risk based learning is analytics on top of other detections. And I saw several vendors at Black Hat last year who are selling content analytics solutions that sit on top of a data lake. I think one of them we talked about late last year was AmbleLogic, where they write a software package that sits on top of, I don't remember what particular data.
Vendor, Snowflake maybe, I don't know, sits on top of a data lake and constantly runs they're not atomic detections like you think of, they're more like a risk based detection where it runs a bunch of different stuff, it does some sort of AI magic or risk magic and then bubbles up the ones that are most important to the top.
So, and I think this indicates detections are becoming commodified, which I think that's a good thing. Thing. I mean, we've talked about this before. It's kind of a waste of time for each company to come up with a unique method of finding lateral movement via [00:32:00] WMI.
David: Cause a finite amount of those, right?
Matthew: Yeah. And there, and there's only so many ways you can do it. And it's an incredible waste of time. If every single company has to. You know, figure out their way to detect lateral movement.
David: No, it was just a green.
Matthew: that's fair. So you have one other quote here, which is kind of hit me right in the heart. Storing even the richest log data has little to no detection value until it is actively consumed. And as both an analyst and a dissection engineer, I'm 100 percent guilty of this. I'm always like, well, we could use it eventually.
I could see where we could use that in a rule. So let's ingest it and let's keep it.
David: the thing is that a lot of people don't consider that there's a cost to the collection storage and the analysis of data, right? So the more hay you throw in the haystack, the harder it is going to be to dig through that haystack. The more it's going to cost you to store that haystack and the more it's going to cost you to get the hay out of the stack.
Matthew: yeah well. Alright, so his arguments boil down to effectively, where is your limited time best [00:33:00] spent? Is your time spent writing detections that may already be covered? Or is it spent improving security operations in other ways? And given a lot of our discussion on this, I'm definitely starting to come around to this. ?
David: Mm hmm.
Matthew: So I guess the answer to that one is probably I should bust out the atomic red team tests or figure out some way to test and validate first.
David: I was going to say, if you do regular rig teams, then You know, you can give a, get some kind of judgment about your EDR as well as your, your recent DAX simulation
Matthew: Yeah,
David: and its detections.
Matthew: that's, I don't know about, I don't know if it works as a red team, because a red team will typically do whatever they want to do. Sounds more like a purple team, where you ask them to test specific stuff. You're like, hey we're thinking about writing detections for this, this, and this. Can you, you know, generate those logs for us, or test and tell us if we're already protected against that?
And then that way, even if they, even if you find you're not protected against it, at least you should have the logs. To write the detections off [00:34:00] of.
David: Yeah. I was originally thinking about, well, the red team doing something you hadn't thought about before, which you couldn't ask them to intern a purple team. Cause you hadn't thought about them to do it.
Matthew: In my mind, on the maturity scale, like, a red team is kind of like one of the last steps. Where yeah, you have all the basic stuff done, and the red team has to get creative and do some wild and woolly stuff that you've never heard of before. But I feel like a lot of red teams now, since the people, companies didn't engage them at the beginning, they never have to break out the weird stuff.
David: Hmm. Hmm.
Matthew: They just, they just, they just keep getting to break in doing the easy stuff.
David: Right, right, right. Yeah. It's like, no one started bug bounty program. So you've got yourself solid. Otherwise you're just going to be hemorrhaging money.
Matthew: you're just giving away free cash. All right. Any other thoughts on that one?
David: No, I don't think so.
Matthew: All right. Well, that looks like that's all the articles we have for today. Thank you for joining us. Follow us at Sam Gettysack on Twitter, subscribe on your favorite podcast app. [00:35:00]
