Nicole Beckwith: [00:00:00] The hash values, the IP addresses, and the domains with AI are essentially gone

Ashish Rajan: A lot of people may even think it's as, as simple as pointing an agent to a SOC tool, and suddenly you have a smarter SOC.

Nicole Beckwith: You could write a thousand detections and technically have, you know, the MITRE ATT&CK framework covered within a day, but you're gonna seriously piss off your incident response team.

Nicole Beckwith: The thing that stops looking trustworthy to you is coverage that's mapped to a framework. So think about MITRE ATT&CK, PCI. You start distrusting that we have a detection for that technique, and it's very different from we could catch that attacker. With the GTG 1002, you know, threat actor, they did all of this under 60 minutes.

Nicole Beckwith: No human could have done that, right? And so that's where a lot of detections fail. CISOs are being told, like, "Hey, I need you to use AI to cut your team in half." How can we use AI to not replace people, but help them do their job better?

Ashish Rajan: If you are a detection engineer, you probably have wondered [00:01:00] how long do you have to keep the detection lifecycle management, but maybe there's another way.

Ashish Rajan: I was having a great conversation with Nicole Beckwith. She is a senior director at Cribl. We spoke about the APEX framework they developed, which by the way, anyone can apply it and you don't have to have a certain path. It's just more of the, the framework thinking was really interesting in terms of how you bring that all together instead of building a lot more detections.

Ashish Rajan: So I'll give you that much of a hint, and I'll let you listen to the whole episode where Nicole does a great job of explaining the APEX framework, how you can apply it to your existing security program and whether pointing an AI to a data lake or an AI agent, uh, is the, or a SOC AI agent is the future.

Ashish Rajan: What are some of the blind spots over there as well? All that and a lot more in this episode with Nicole. If you have been enjoying the episodes of the podcast for some time and have been coming here and maybe sharing these episodes with your friends, I really appreciate if you take a quick second to hit the follow, subscribe button, whichever podcast platform you listen or watch us on.

Ashish Rajan: We are on Apple, Spotify, YouTube, and LinkedIn, [00:02:00] and wherever you consume your podcast from. I hope you enjoy this episode with Nicole, and I'll talk to you soon. I also wanna give a shout-out to Cribl for sponsoring this particular episode of the podcast. Now back to the episode. Peace. Hello and welcome to another episode of the podcast.

Ashish Rajan: I've got Nicole with me. Hey, Nicole. Thanks for coming on the show.

Nicole Beckwith: Yeah, thanks for having me.

Ashish Rajan: Um, I'm looking forward to this conversation, but maybe to kick things off, if you wanna give a background, like maybe a professional background about what you've been up to, your cybersecurity journey as well.

Nicole Beckwith: Yeah, absolutely. Uh, so Nicole Beckwith, I am Senior Director of, uh, security engineering and operations over at Cribl, so running the, uh, security team there. Um, my background is kind of unique. So I started as a, a developer, um, you know, and tinkering with computers ever since I was young. And then, uh, more recently worked as law enforcement, uh, with the Secret Service, State of Ohio.

Nicole Beckwith: Transitioned from that to threat intelligence you know, at GE Aerospace now. Uh, and then transitioned [00:03:00] from there to Kroger, where I, uh, built out the detection engineering team's intel hunt insider. Um, so ran enterprise security operations there. And then just recently transitioned, well, I guess in March, it's been a few months to Cribl.

Nicole Beckwith: Uh, so I knew about the Cribl team, uh, when we were doing, um, a whole SIEM migration at Kroger and, uh, loved the company, loved the people, and, and when this opportunity came up, I took it. So, I've been in the security operations space for some time and working on SIEMs and SOARs and detection engineering.

Nicole Beckwith: And so, you know, one of those crazy people who kind of likes this space, uh, but, uh, and the challenges and being on call, you know, isn't for everybody. But but I enjoy it. So that's a, a little bit about my background.

Ashish Rajan: Awesome. Considering you've been spending a lot of time in security operation and have probably seen what good detection usually looks like, I'm curious as to what was the...[00:04:00]

Ashish Rajan: Uh, obviously, I feel like these days you cannot have a conversation without talking about AI. So I'm curious from a SOC professional experience perspective uh, from your Kroger days before, when you were working with Secret Service all the way to GE what was something that you used to be okay with and w- when was accepted before AI, and what is something that you now look at and go, "Oh, that's different"?

Ashish Rajan: Uh, I'm curious about the, the change you've noticed in the detection engineering space because of AI.

Nicole Beckwith: Yeah. So there's, there's a couple layers there, right? So in working through all three of those you really come to understand the thing that stops looking trustworthy to you is coverage that's mapped to a framework.

Nicole Beckwith: So think about MITRE ATT&CK, PCI. So you start distrusting that we have a detection for that technique, and it's very different from we could catch that attacker, right? So you're really looking at you know, your [00:05:00] log sources, your, uh, adversaries that you're trying to track. And then AI has completely upended how we look at detections.

Nicole Beckwith: So when you think about, you know, detections 10 years ago until maybe two years ago, they're really IOC focused and they're focused on the bottom of the pyramid of pain. The hash values, the IP addresses, the domain names And so when I'm building detections out now post-AI and, really focusing on the top of that pyramid, I'm looking at behaviors.

Nicole Beckwith: I'm looking at the TTPs behind it. And so I want to catch the adversary on the behavior that they're doing, not on the IOC or the tool that they're technically using, right? And so for me, it is building those higher fidelity detections that has made a big difference for us right now in the detection engineering space.

Ashish Rajan: Oh, interesting. The next question that I had was kind of on [00:06:00] a similar note. Because of high fidelity use cases, there's also a change in how people view a single pane of glass, and I use that word in air quotes- Yeah ... particular context, I guess. Everyone has always wanted the one ring to rule them all and the one glass pane to see all, see them all.

Ashish Rajan: Obviously you and I both were at BlackHat, and a lot of the conversation was around federated search, federated data. Um, I'm curious about what these terms are 'cause a lot of people still may be on that SIEM ecosystem, and I was the same as well. So I'm curious if you can just- Yeah ... expand on the whole federated data, federated SIEM, and is there truly one lens for everything today?

Nicole Beckwith: Yeah. So I particularly hate the term single pane of glass, right? And, and we're switching to single lens, as you've said. And you know, it's really interesting to me because in the past you may have a single pane of glass, right? But every tool has that single pane of glass. And for an analyst who's working in the [00:07:00] space, especially, you know, in a SOC, you want a true single lens over everything that is giving you, all of the context that you need.

Nicole Beckwith: So when we think about that single lens over federated data what's interesting is that query translation across all the sources has to be deterministic. So the same question has to be asked. If it doesn't produce the same answer at 2:00 a.m. that it did in your tabletop that your, your SOC team just did, then it, it's no good for the team, right?

Ashish Rajan: Yep.

Nicole Beckwith: So when you're taking a look and you're really focusing on that, you know, the join keys, you think identity, host, session, like IDs, they already have to be normalized across every source before that incident even starts since you can't build entity resolution live. But the thing that's interesting is where that cracks and where that starts to break down, even with federated data, right, are the permissions So when I think [00:08:00] about, you know, doing the tabletops with my SOC team, we wanna know that we have the identities pre-provisioned to read, to have read access across all the systems that we need before we go into, that that incident response scenario at 2:00 AM, right?

Nicole Beckwith: So federation needs that querying identity to be pre-fu- provisioned to have read access, right? Um, so- How is that different

Ashish Rajan: to SIEM? I guess 'cause isn't SIEM similar as well in deterministic search?

Nicole Beckwith: It is, yeah. With a SIEM, uh, you definitely have to have that deterministic, um, search. And uh, I know Clint our CEO, wrote a, a blog post about this, right?

Nicole Beckwith: Talking about how a unified lens on data needs to be deterministic, and that federation should be a capability of the platform. So that, that is, um, what most SIEMs are, are dealing with today, right?

Ashish Rajan: Oh, right. I guess, and to your point, it's also not the fact that because I think I was reading on one of the blogs [00:09:00] about a SIEM is just about log aggregation and then, um, having some kind of a language on top of it.

Ashish Rajan: But I guess, uh, the way federated search is working, and you can correct me if I'm wrong, that multiple data sources through one lens is... Did I g- get that right to what you were saying? Instead of me hogging all to one, all the data in one go, it's looking at multiple sources with one lens at when I need it- Yes, it should be

Ashish Rajan: rather than all the time.

Nicole Beckwith: It should be. Okay ... yeah. Correct.

Ashish Rajan: Oh, and so good, that's a good segway into something something else which has been top of mind, is the whole telemetry thing as well. And the question of how do you decide, and this is probably the, the question that every detection person, SOC person, every SOC leader has to ask is, initially we were of the belief that send me all the logs.

Ashish Rajan: Then became quite like a costly exercise to go through that. Then it became more like, "Hey, like give me some of the security logs only." I'm curious over time, on all the experience you've had, what's been [00:10:00] your for lack of a better word, a north star that helps you decide on what to drop and what to keep kind of a thing in terms of- Yeah

Ashish Rajan: uh, and obviously I, I, I understand it's a very general- generalized question. So, uh, what do you consider are important things that people should consider having for detection and, uh, Yeah ... what is a must-have,

Nicole Beckwith: yeah. So this is really the million dollar question, right? Every SOC team right now is asking which log sources do I need?

Nicole Beckwith: Which ones can I cut? Can I pipe them to a data lake, right? To save the ingest cost from your SIEM or from whatever tool you're using. So when I did a, a SIEM migration I was looking at log sources. So I'm tying it to detection coverage and the detections that we're using within the SOC. So did a full audit of our detections, said which log sources are feeding into these detections that we absolutely need to feed the SIEM.

Nicole Beckwith: And then the ones that weren't, or if they were You know, say under [00:11:00] 10% of the time were used for a detection or for an investigation, then those were the ones that we would cut, we would pipe to a data lake. And then hopefully you can replay those with a tool and for me it was interesting because we went through this scenario and, and we happened to pipe a few of those log sources that were under that 10% threshold to a data lake to replay them.

Nicole Beckwith: And of course, next week you're gonna get the, uh, the incident that pops up and you're like, "I needed that log source." But luckily you hopefully have piped it to a data lake or somewhere you can replay that, right? Yeah. So, for me it was all about the context of security detections and those alerts that needed to fire.

Nicole Beckwith: So we went through the exercise of, all right, what are the top alerts? And just kind of map them all the way down, right? And then map the log sources to those alerts to figure out, you know, what's actually needed. There's a lot of regulatory and compliance log sources that-

...

Nicole Beckwith: Aren't necessarily [00:12:00] needed in a SIEM or, or your alerting solution that you can pipe somewhere else.

Nicole Beckwith: And so those are the ones that I tend to cut first and just keep them, you know, so you can replay them and, and keep them for the, the compliance checkbox, right? But at the end of the day, a lot of those don't, uh, come into play when you're looking at an incident

Ashish Rajan: I guess your point is you're classifying them if I were to get that right.

Ashish Rajan: You're saying classify the ones which are like a must-have, not because of- Yes ... uh, anything else but for compliance. But then there's another category for you would need this when you have that 2:00 AM incident.

Nicole Beckwith: Yeah. So for example- It may not be...

Ashish Rajan: Yeah.

Nicole Beckwith: Yeah. Confluence data, right?

Ashish Rajan: Yeah.

Nicole Beckwith: How many times are you gonna need to do a pull in Confluence logs for an investigation?

Ashish Rajan: Yeah.

Nicole Beckwith: Probably pretty rare, right? Yeah. But on that one instance, um-

Ashish Rajan: Yeah ...

Nicole Beckwith: that comes up, you might need, you know, to, to audit something that happens to be in Confluence. You know, that might be something that was under the threshold that, then one day you're gonna need, but again, you should be able to replay that [00:13:00] data.

Ashish Rajan: Interesting. G- you also mentioned data lake as well. I wonder-

Nicole Beckwith: Yeah ...

Ashish Rajan: what does that look like in in, in a practical sense being applied in an organization? 'Cause every time I'm talking to many people these days, a lot of the conversation come down to: Can I just run an AI through a data lake, and wouldn't that be federated search as well?

Ashish Rajan: I'm curious as to what's your thoughts on that and what's the reality of doing something like this especially in like a pipeline context, like, I'm sorry, a data lake context.

Nicole Beckwith: Yeah. You-- that's changed significantly over the years, right? And what's interesting to me is now a lot of SIEMs sit on top of a data lake, and so they're essentially doing exactly what you're talking about.

Nicole Beckwith: For me, when I think about data lake, this is something that is separate aside to, you know, where our SIEM lives and we're just piping the extra data into that. As far as being able to run an agent or query over that, so what I like to use that for is, you know, threat hunting you know, replaying the [00:14:00] data that we, like we discussed, we don't necessarily need all the time.

Nicole Beckwith: So you can just pipe your logs to a data lake and, you know, run a query across it. The problem with that is, is the context is lost in that data lake, and AI needs a different type of, You know, it needs the, the context, the metadata, it needs to be humanized in that data lake before you're, deriving a decision from that, right?

Nicole Beckwith: Yeah. So even your AI needs to, to have that identification, that metadata underneath to be able to come to a conclusion. So the data lakes of today are a little bit different than the data lakes of yesterday in that, everybody does just wanna, tie an MCP, point an agent at it, do some hunting, some querying, and, and just call it a day.

Nicole Beckwith: I would venture to guess your budget on AI is gonna skyrocket if you do that. Yeah. So there are some, some nuances there, right, that we need to go through.

Ashish Rajan: Yeah. Would you say that [00:15:00] the, uh, and I, I'm glad you mentioned appointing an agent to a telemetry MCP, uh, may end up increasing the bill.

Ashish Rajan: Is it really, 'Cause I, I guess another part is the whole life cycle of it as well, right? You, what you said about threat hunting, you find a threat. Someone has to figure out, uh, is there, is this a legit threat? Are we going to keep it? How long is... If h- if it has not been triggered for over a year, do we still keep it?

Ashish Rajan: I mean, uh, do you go through that kind of exercise as well when people talk to you about, "Hey, I'm just gonna appoint an agent to a data lake via MCP and call it a day"?

Nicole Beckwith: Yeah. So, uh, we do, right? So you should be auditing your detections, you should be auditing your hunts, you should be auditing your scheduled searches a- and understanding the value that those are bringing to your team.

Nicole Beckwith: And at the end of the day, if you're, uh uh, sending a scheduled search to a data lake, you know, every hour or every two hours, and it's not coming up with anything, that's where you need to understand and pull that back [00:16:00] and be able to, to switch that up and maybe do it at a less frequency. And so you should be auditing all of the, your agents that you are, are sending towards that data lake.

Nicole Beckwith: You should be auditing the time frequency of which they're doing those, those searches and those hunts. And yeah, it's definitely gonna cost a lot less if you're doing those audits.

Ashish Rajan: Are you finding people when, especially when they look at, especially when SOC teams look at securing AI, are you finding anything that people are doing wrong in, especially in that security automation ecosystem, such, like could be from a logging perspective, like logs should they, that they should be collecting but they don't end up collecting in an, uh, obviously we're talking about from an AI perspective, so any agent related logs that people should be thinking about as a security operation person who is collecting logs for that, that kind of a- activity?

Nicole Beckwith: Yeah. So the thing that I see teams make the biggest mistakes on in the, you know, IAM space and, and [00:17:00] log space is teams are provisioning agents as service accounts, not as an identity. And so service accounts, as we know, have always been like the worst governed identity class in any IAM program, right?

Nicole Beckwith: Yeah. Um, so they have broad scopes. It's granted once. They're hardly ever revisited. You don't have a single source owner that's held accountable when you wanna do that, that access review. Credentials are not rotated as frequently as they need to be. And so, provisioning your your agents as identities and not as service accounts is probably the, the one mistake that I see most programs doing.

Nicole Beckwith: Um, sometimes that's you have to, right? And there are, there are instances where you need a service account and not an identity. But when it comes to log sources, You really have to, when you're building your detections out, understand that a service account and identity are going to be a little bit different when you're doing those [00:18:00] investigations.

Nicole Beckwith: And especially when you're looking at agent security and securing AI and understanding like when it's going rogue or when it is, acting or misbehaving inappropriately or, or, you know, uh, has a, a lot more queries than it should. When you're searching or when you're detecting on that, you have to build those detections accordingly.

Nicole Beckwith: So that's probably the, the one piece that I think, uh, a lot of teams get wrong.

Ashish Rajan: Do you find that when people are using AI to build detection, uh, I think when we were catching up last time, we spoke about blind spots that people have when they start building detection with A- with AI. I'm curious if you could share some of the blind spots that you notice people experience or maybe miss when they, uh, start using AI for building detections.

Nicole Beckwith: Yeah, sure. Uh, this is one area I love talking about. So, the blind spot here is that people are treating detection authorship as the [00:19:00] hard part, when it was never the hard part, right? Building a detection is easy. Knowing whether that detection is mapped to your environment and whether that fidelity is strong is the hard part, right?

Nicole Beckwith: Yeah. Is that rule firing on your environment's actual behavior? You know, think about your backup jobs, your RMM tooling, the PowerShell script that your, HR team is running every Tuesday. You still have to have that institutional knowledge- Mm-hmm ... um, that manual tuning that, that still goes on.

Nicole Beckwith: That's the hard part when you think about detections. Anybody can take, uh, AI and say, "Write me a detection for..." You can write a thousand detections and technically have, you know, the MITRE ATT&CK framework covered within a day. But, you're, you're gonna seriously piss off your incident response team, right?

Nicole Beckwith: Because you're gonna get a whole lot of false positives or weak detections that fire. And so, the, the hard part is [00:20:00] actually tuning those to, to your environment. Writing them is the easy part.

Ashish Rajan: I, I'm, I'm glad you mentioned this because, uh, it kind of makes me think about the whole agentics AI-ready SOC.

Ashish Rajan: I was gonna say agentic SOC, but I'm p- I'm sure some people are calling it that as well. The AI-ready SOC, uh, version that a lot of people are trying to push for. Uh, a lot of people may even think it's just as simple as pointing an agent to a SOC tool, and suddenly you have a smarter SOC. Uh, I'm, I'm curious as to w- why is that...

Ashish Rajan: Like, what are some of the challenges you have seen in this particular space? And I think you had some answers on how to address these as well.

Nicole Beckwith: Yeah. So, one of the interesting things about AI SOCs and just pointing it at your detections that you already have or your, your log sources that you already have, right?

Nicole Beckwith: Is that detections can sometimes break or go quiet. And so it's the [00:21:00] schema that is, is typically broken upstream, that's breaking your detections downstream, or it's not parsing properly when you're putting it into your SIEM. That's what breaks when you just point an AI SOC at your existing tools, right?

Nicole Beckwith: And so, if you... When I talk about Apex, uh, which we can talk about that, uh- Sure, yeah. Okay ... in a minute. But when I built Apex and the entire, concept around Apex was, you know- Running that across raw telemetry, so not worrying about normalizing the logs and the schema and, having things break upstream.

Nicole Beckwith: You, when you pipe telemetry in and you're using the raw log source, and you're able to just give AI and your detections access to that telemetry and use the raw logs instead of, you know, OCSF or normalization you-- that is the, the foundation of, of why I build Apex. And, the [00:22:00] diagnose, repair, maintenance loop, right, of, what are we seeing that we can, pipe back into that loop and it cont- continuously learn off itself.

Nicole Beckwith: The raw telemetry in, in this case is, is what is the differentiator.

Ashish Rajan: H- how does that apply to, I think, uh, you, you gave me a term, which is, or I guess a group of terms, pyramid of pain, as you called it.

Ashish Rajan: How does the, the Apex thing that you wrote apply to that? And uh, yeah, I'm just curious, how does that apply to that, and- Yeah

Ashish Rajan: what was the behavior that you noticed that caught your attention?

Nicole Beckwith: Yeah, absolutely. When we think about the pyramid of pain, you know, David Bianco put out, you know, arguably the most important graphic in, in our industry in 2013, and we've chosen to ignore that at the context level until now.

Nicole Beckwith: But you know, the bottom three layers, so there's six layers of the pyramid of pain, the bottom three layers the hash values, the IP addresses, and the domains with AI are essentially gone, right? They're still great for [00:23:00] detections and, and, being those atomic indicators. But you know, when you think about polymorphic, metamorphic malware, you know, you're getting different hash values for every victim.

Nicole Beckwith: When you think about phishing kits today, every email that is sent has a different domain and, and, at the appendix at the end of the, the domain is different, so you're not able to utilize that. When you think about IP addresses and, people that are vibe coding overnight and, um, standing up bespoke tooling, all of that changes within hours, minutes, days.

Nicole Beckwith: So- Why I built Apex you know, was because we have to move up that pyramid of pain and, the top or the apex of the pyramid, right, are those TTPs. And so when you take MITRE ATT&CK and you take those TTPs those are great signals in and of themselves. They're low fidelity. There are some of them that, that are high fidelity, right?

Nicole Beckwith: Like, there might be a single signal that, [00:24:00] that will give you a great fidelity- Yeah ... um, detection. But when you chain those in a sequence and then you time box that, which is what Apex does, takes the TTPs, chains them, time boxes them based off the behavior that you should see and that we have historically seen, that gives you a higher fidelity detection.

Nicole Beckwith: So when you think about the analogy I like to give on this is, if you have a, a Ring doorbell, right?

Ashish Rajan: Yeah.

Nicole Beckwith: Your Ring doorbell probably goes off if you don't have it configured properly 75 times a day because you get 50 cars driving- Yeah ... you know, past your street. You get, you know, the UPS guy or, or FedEx guy, or Amazon in my case, you know, walking up to the door multiple times a day, and you tend to tune those alerts out, right?

Nicole Beckwith: Not because- Yeah ... they are wrong, but because they're not high fidelity. And so- Yeah ... it is the, the actions that matter. So all right, car drives up the driveway, guy gets out, comes [00:25:00] to the door, jiggling the door handle. Like that is the sequence that you should be firing on. So it's the behaviors in that sequence, in that time box that is the differ- differentiator with Apex.

Ashish Rajan: How would that dif- be different to SIEM? 'Cause, I mean, obviously these just SIEMs claim to have the same kind of, "Hey, we can pick up on a behavior and separate that out." I'm curious as to how different is that, 'cause a lot of people already have a SIEM, right? A lot of people or- Yeah ... organizations have worked with a SIEM.

Ashish Rajan: They're also thinking about data lake, as we were talking about earlier, and pointing it to an AI. How does Apex fit into this world for those people who have either, either of those, and they're looking at Apex going, "Oh, wait, so am I ripping what I have out or am I just adding Apex into it?" If that makes sense as a framework.

Nicole Beckwith: Yeah. So there's a couple different ways you can use Apex, but the, the differentiator between what most people have in their, their SIEM today and what Apex does is you're [00:26:00] not focused on log specific rules. So a lot of rules within a SIEM are focused just on a specific log source. They're not log agnostic, and they're not firing on a specific signal.

Nicole Beckwith: They're firing on, that PowerShell execution alone, or- Yeah ... you know, an LSASS touch alone impossible travel, right? So those may fire and you may get a detection. The difference with Apex is that chaining and the time box sequence, and so that's what most uh, SIEMs don't have today. So there's a couple different ways that people can use Apex.

Nicole Beckwith: You know, the first is you can, sit it on top of your data lake, uh, sit it on top of a SIEM, the, the framework itself, right, on top of a SIEM. The whole premise is that you're getting to those behavioral detections, right? And you're, you're boiling it down to the actual TTPs. So the each [00:27:00] TTP is a signal, and when you're taking those and time boxing those that's the differentiator.

Nicole Beckwith: I think it was, uh, GTG 1002 was the archetype that Anthropic's red team came out with. Oh yeah, that's right. And this was the individual that scored the 100 on the Anthropic Ares scale, right? And it was because of that MCP agentic scaffolding, uh, that they did. And so they basically took the in-- the full kill chain and you ran it within such a quick window that you know, most detections, one can't see that and, and aren't going to look at, each of those individually.

Nicole Beckwith: So it was that cluster. So that's the second piece of Apex that, quite frankly, we're still building out and still testing and tuning, right? But it is focusing on the cluster itself, so not having to have that behavioral chain within a time [00:28:00] box window. It is the cluster of activity with, um, that user with, uh, the agent or identity that is doing these things within X period of time that is clustering that is going to fire the alert, right?

Nicole Beckwith: So in theory and you know, if we prove this out, I'm gonna be really excited. But in theory, uh, if you get that cluster, it's going to fire irregardless of, having a detection in place. So this is where I get excited, because if we don't have to write 1,000 detections- Yeah ... for every box of, you know, the MITRE ATT&CK framework and we can cluster based off the, of these signals then we should be able to, you know, in theory, uh, detect all of these alerts, including that scaffolding abuse.

Nicole Beckwith: Now, I did write a, a rule or a chain for that as well, right? And it was the reconnaissance to exploitation to lateral movement to exfiltration, and time boxed that, right? Because [00:29:00] with the, the GTG 1002, you know, threat actor that Anthropic called out, they did all of this under 60 minutes, right? And I think the timeframe was actually, like, 15 minutes or something like that.

Nicole Beckwith: Right.

Ashish Rajan: Yeah. 15-minute window, yeah. Yeah.

Nicole Beckwith: No

Ashish Rajan: human was there involved as well, yeah.

Nicole Beckwith: Yeah. No human could have done that, right? And so that's where a lot of detections fail. And so it is that, that clustering plus the sequencing plus the time boxing that I feel is going to give us the, the high fidelity detections and hopefully not burn our, our SOC out, right?

Nicole Beckwith: So- I,

Ashish Rajan: I

Nicole Beckwith: think- ... that's the difference ...

Ashish Rajan: you kind of mentioned something interesting, right? The, the GTG 1002, for many people, uh, well, I guess most of the industry, it would've been one of its kind, a experience as well. Yeah. And what you're saying is the APEX framework theoretically can help you build those high fidelity events as a way to detect something is wrong here, going back to your UPS example versus a someone coming out of a car and just actually literally [00:30:00] trying to open the door, example from a Ring door.

Ashish Rajan: How do you see... For p- people in the audience who probably h- hear this and go, "What would, how would I apply this to my ecosystem?" And if you have any examples there, because from their perspective, they may already have a SIEM, they may already have a data lake, but we're talking about events that we don't even know what they would look like, if that makes sense.

Nicole Beckwith: Correct. Yeah.

Ashish Rajan: How would you think about APEX in that context?

Nicole Beckwith: Yep. So that's the beauty of it, right? Is you, you shouldn't have to detect every single thing. The clustering alone should be the detection for you. Um, so when you think about the APEX framework and how you can take it today and, and plug it into your existing program no matter what you have, right?

Nicole Beckwith: We've obv- obviously built it on top of, Cribl because we own the telemetry. We have the, the app platform that we built this on top of. But if you don't have any of that then I would say start by [00:31:00] understanding what log sources you already have to work with and where you're ingesting that data.

Nicole Beckwith: Then decide where you want those APEX detections to live, right? Is it your SIEM? Is it on the telemetry? Is it in a data lake? Do you have detection as code, scheduled searches, et cetera? So then you take those and, and say you know, for example, what, what my team did is take our current detections and translate those into behaviors.

Nicole Beckwith: So instead of having log specific signal specific detections, you're taking those and translating those into TTPs and behaviors and getting, up that, that pyramid to the behavior. So the whole goal there is, getting away from those IOC-based detections onto the behavioral-based detections.

Nicole Beckwith: You know, it, it depends on what you have. One of the questions that came up you know, and, and that you and I also discussed were, do you need full process [00:32:00] telemetry to make APEX work? Yes to an extent, right? So I'd put it this way: the insight for APEX is free and portable.

Nicole Beckwith: The fidelity is not technically, right? So you can take this framework, and you're gonna be able to level up your team, your detections, that fidelity, right? But if you have that full telemetry, then your fidelity is gonna be even higher, right? So when you think about, you know, having that full process telemetry, command line arguments, parent-child relationships correlated identity events, et cetera that's what's going to give you those higher fidelity detections.

Nicole Beckwith: But anybody can take the framework, utilize, how we're getting down to those behavioral detections, um, start time boxing those, start putting, you know, different criticality, uh, assignments to those detections and make it a little bit easier for your SOC to respond to the right things.

Ashish Rajan: So is...

Ashish Rajan: To your point, [00:33:00] it's a portable... it, the framework is portable irrespective of them being a Cribl customer or not. At least the framework should be applicable to build a cl- cluster on their own. Would that be fair statement? Correct.

Nicole Beckwith: Yep. Anybody can take this and build it on top of, you know, whatever tool they have regardless of vendor.

Ashish Rajan: And c- obviously, you gave a talk at BlackHat for this as well, which I'll find, find a link and we'll probably put that in the show notes as well. I was gonna say, in terms of people who already have a security program, a lot of people went into the BlackHat conference thinking about: How am I uplifting my existing SOC program, security program based on the AI uplift that I may have to do or coverage for AI?

Ashish Rajan: We obviously started the conversation talking about how the detection has changed with AI and now with the APEX framework as well, to what you said, instead of building a lot of detections, if we could cluster events of high fidelity together, we should be able to at least maximize the the detection [00:34:00] without having to create a lot of detection and without having to build a, uh, a SIEM from scratch or whatever as well.

Ashish Rajan: Uh, I'm curious in terms of what are you, what are you recommending the leaders who are looking at uplifting their SOC programs on how to, uh, start thinking about AI in their team? Obviously, you're a leader yourself in a security operations team. How are you thinking about it? I'm curious considering you get to see the, the APEX framework and I guess the the federated search world.

Ashish Rajan: A lot of people are also on the other side. So where, what do you normally recommend these days to CISOs and other leaders who are trying to uplift a, a, a SOC program for a world of AI?

Nicole Beckwith: Yeah. So for me, it is, it is all about, empowering your people not replacing your people. And I know that a, a lot of companies and, and leaders are being asked, up-chain CISOs are being told, like, "Hey, I need you to use AI to, to cut, your team in half or to save money."

Nicole Beckwith: And I think that's the wrong way to look at it, right? And [00:35:00] so, for me it is how can we use AI to not replace people, but help them do their job better? And so is there a way that we can use AI to, either, uh, start detecting on more things, doing more investigation, more enrichment giving your SOC team a, a brief or an overview or, put steps in place for them to be able to, you know, rinse and repeat when they're looking at incidents and events.

Nicole Beckwith: Um, so AI is just another tool in a SOC analyst tool belt, right? It shouldn't replace the analyst. You still need that human in the loop or on the loop a- as the technology or the terminology is changing there. And so, you know, when I, when I think about it I'm pushing my team to use AI, but it's pushing them to use AI in a way that's helping them do their job better.

Ashish Rajan: Right. Awesome. So use AI [00:36:00] to do your job better. It's not to replace people is the message. Correct.

Nicole Beckwith: Yeah.

Ashish Rajan: And may-maybe where, where you can try and apply the APEX framework as well.

Nicole Beckwith: Yes. That would be great.

Ashish Rajan: Awesome. Well, those are the questions that I had for the episode. I, um... Where can people find, connect with you to learn more about the APEX framework and also learn more about what you guys are doing at Cribl?

Nicole Beckwith: Yeah. So, um, if you just go to cribl.io check out our blog. I do have the APEX white paper that is listed there. You can, uh, hit me up on LinkedIn. I'm happy to have conversations with anybody about how we're using it, uh, and you know, where they can find it. No promises on productizing it yet- but we're hoping that you know, we'll be able to roll it out to customers soon.

Ashish Rajan: That's awesome. Uh, well, thank you so much for sharing that as well. And, uh- Yeah ... I'll put those links in the show notes too. But yeah, I'm looking forward to more of these conversations once the APEX framework, to your point, no promise on a product, but hopefully when it develops and evolves into something else, the V2 maybe.

Ashish Rajan: Uh- Yeah ... but yeah. Thank, thank you so much for [00:37:00] your time.

Nicole Beckwith: Yeah. Thank you. Thanks for having me.

Ashish Rajan: Thanks everyone for your time as well. See you next time. Thank you for listening or watching this episode of "Cloud Security Podcast." This was brought to you by techriot.io. If you are enjoying episodes on cloud security, you can find more episodes like these on cloudsecuritypodcast.tv, our website, or on social media platforms like YouTube, LinkedIn, and Apple, Spotify.

Ashish Rajan: In case you are interested in learning about AI security as well, do check out our sister podcast called "AI Security Podcast," which is available on YouTube, LinkedIn, Spotify, Apple as well, where we talk to other CISOs and practitioners about what's the latest in the world of AI security. Finally, if you are after a newsletter, it just gives you top news and insight from all the experts we talk to at "Cloud Security Podcast."

Ashish Rajan: You can check that out on cloudsecuritynewsletter.com. I'll see you in the next episode.

Peace.

‍