Present and Future of MDR

What is the future of MDR?

In this episode of the mnemonic security podcast, Robby is joined by Migjen Hakaj from mnemonic's Innovation & Emerging Technologies Department and Amine Besson, Director at Behemoth Security.

They've joined forces by collecting their shared extensive experience with security monitoring, and published a popular three-part blog series on what Managed Detection and Response (MDR) really is on a deep level, where they examine the past, present, and future challenges within the field.

In their conversation they talk about the evolution of the SOC space, what main forms of security operations they are seeing today, and why they believe the SOC needs to change.

They also explain why it's hard to define what MDR really is today, the main value proposition of MDR providers, and what the next big differentiators for MDR providers will be. As well as in what ways they've seen that the industry has matured over the last few years, where the industry needs radical change, and where AI SOC has a place and where its main challenges lie.

Interested in more? Visit their blog series:

The Present and Future of Managed Detection and Response: https://detect.fyi/the-present-and-future-of-managed-detection-and-response-01a72088e6f6

The missing link in MDR. Spoiler, it starts with a Detection Engineering framework: https://detect.fyi/the-missing-link-in-mdr-spoiler-it-starts-with-a-detection-engineering-framework-5f836347c92f

Beyond Detections : Scaling Analysis & Response to keep MDR relevant: https://detect.fyi/beyond-detections-scaling-analysis-response-to-keep-mdr-relevant-592285d0fd25

Transcript

Speaker 0:03

From our headquarters in Oslo, Norway, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.

Robby Peralta 0:15

I've tried to stay on top of the security monitoring space ever since I learned what this infamous security operation center was. Ten years later, I've experienced a fair share of acronym inflation with classics like SIEM, EDR, UBA, SOAR, XDR, CNAPP, and somehow NDR became a thing again, even though we kind of started out there. Twenty years renaming the same three things logs, packets, and endpoints. And now we're adding AI in front of it all. Obviously, this is difficult. Even the very best with seemingly unlimited budgets have been breached. And even if you've done a perfect job and no material breaches have occurred under your watch, you'll eventually find yourself having to defend your spending to someone higher up in the company that doesn't understand a word of what's coming out of your mouth. The life we chose. If you're one of the few with the luxury of getting help with security monitoring, you'll likely be subscribed to a so-called managed detection and response service. What exactly that is, or should be, is what I wanted to talk about with today's guests. Migjen Hakaj and Amine Besson. Welcome to the podcast.

Amine Besson 1:37

Hey, man.

Migjen Hakaj 1:38

Thank you.

Migjen Hakaj 1:39

Thank you for having us.

Robby Peralta 1:40

So, I mean, I've known Migjen for 10 years now. And I've spent five of those, five and a half, asking him to come on the podcast. But the moment he starts collaborating with you, he's suddenly on board. You chair the detection engineering and threat hunting special interest group at first, the detection engineering tech lead at the European Commission. So, my first burning question to you why would you why would someone so high up be friends with Migjen?

Amine Besson 2:08

Well, I kind of love his podcast already. No, it's uh Well, we kind of met, I mean it's boring, right? Over LinkedIn, I was doing some blog posts and uh I kind of knew what mnemonic was. So when he reached out, I was like, ah, cool, it's good to have interest from someone there. And then it kind of just really clicked. I there's not a lot of people in the world who focus on what MDR are at a deep level and focus on what the strategy around it should be. And so when we started to discuss, it was surprising how a lot of things immediately clicked. And uh we we took almost a year, I think, to write the first blog post. We took our sweet time. Uh, but in the end, I'm I'm just super proud of the results. And I think there's very few pieces of work out there that start to describe the challenges in MDR so well.

Robby Peralta 2:53

Well, I'm definitely looking forward to discussing those blogs in more detail. And Migjen, you know, I'm just pulling your leg, as they say. Uh, you've always been my go-to guy for SOC-related matters. You started out in Norway's national level cert, or Nwudesat, as it was called. You then joined me at IBM and were our Qradar man. You then left me to be a SOC consultant at PwC before you joined Norway's favorite app slash financial organization and helped them build out their SOC. And then you joined mnemonic, where you've headed our cloud team and are now our principal detection and response strategist. Great times. So let's start out by going over what's happened in our lifetime of security monitoring. Um, how do you view the evolution of the SOC space during your time in it?

Migjen Hakaj 3:46

Uh well, if you look at the timeline of it, like uh going all the way back to the 90s, early 2000s, it was almost like network-based, uh, network-based protocols, right? But over time, we understood that that really wasn't cutting anymore. More and more traffic was encrypted. And you would see most people uh pivot over to doing a log-based uh type of practice around log analysis, moving into kind of the sim space. From that, we pivoted over to EDRs, then XDRs. Then we quickly realized that all these new types of tools, technologies, they're creating more and more noise. Uh, and then came SOAR to kind of try to help the Secop space handle all of those noise that we were creating. That's kind of where we are now uh at the end of the tale, trying to uh look at AI-based solutions, more ways of kind of handling all the noise that all these uh technologies or uh problem, let's call them problem areas, are trying to address.

Amine Besson 4:48

What I've been focusing on is also uh detection coverage. It's trying to understand what we do against threats exactly. Because today, if you go to any SOC, big or small, and you start asking enough questions, people get frustrated. If you start to ask a very you know, Fortune 100 company, what's exactly your detection coverage against this threat in this cloud domain? Either they bullshit you or they get kind of flustered because they can't answer. So that's that's the evolution I'm also seeing is that not only it gets harder, um, but also we have a growing awareness that it's not about analyzing log, it's about detecting threats finally. So there's also this aspect which is getting very visible now.

Robby Peralta 5:31

What are the the main forms of security operations that you see today?

Migjen Hakaj 5:36

I think that's changed earlier when uh customers or organizations looking to build their own capability of being able to detect threats. They kind of had a classical take on it where like we want to outsource the generic stuff to a partner uh because they see generic every day, right? They have the tools at scale, the people at scale to do this for us. Let's use our own internal capabilities or our own capacity to do what's specific to us. Let's have uh those clear boundaries. And that's in my perspective, the clear playbook or over many, many years, but uh the whole practice, the whole landscape, the problems that the industry has faced over the last 20 years, has just increased. And they're bigger and there are also more complex, which kind of breaks this model. Uh, and not only does the threat actors themselves and how they operate break it, but the maturity of the security industry as well has also broken this model. Uh, major players in the industry, such as Microsoft, AWS, uh, GCP, Wiz, CrowdStrike, Palo Alto, they're all building capabilities, they're all building platforms, which kind of uh tries to eat away at this kind of nice separation of responsibilities between what was called SOC as a service, MDRs, and the customers themselves, because they're trying to wedge their their spot into this mix as well, which changes this ecosystem uh a lot.

Robby Peralta 7:09

Yeah, and now the customers have access to cool graphs and nicer tools than uh the stock provider, the external stock provider themselves offered. Do you have anything to add on to that?

Amine Besson 7:18

I mean, I used to work at KPMG, so that's uh we all have detours in our life, right? And uh when I was that, we often talked about um the uh outsourced SOC, the in-source sock, the co-manager hybrid. So you have kind of continuation between what's in and what's out. What kind of blew my mind is then when you had like a very seasoned SOC leader, which you know I thought was completely behind on everything, and I'm like, okay, I'm going to be the big dog and advise him. And he just stops me and he says, SOC is dead. The guy was 7C, and he told me that, right? SOC is dead, it's an old world. Stop stop talking to this about me. I say, all right, what is dead? Because I started to reframe my my worldview. And he said, Well, SOC is really about L1, L2, actually. It's about triaging alerts. And he says, I don't want to do this anymore. I'm doing everything in-house but the L1L2, and even that I want to automate. And so what are we seeing? Uh we're seeing a I think a market where MDR customers are much more interested in two outcomes and they understand a bit closer what they want from it. If you look at it 10 years ago, uh it was different. It was people would just want a subprovider to feel safe, to feel covered, to feel like they can check a box. And of course it doesn't work. We get popped, we get hit by some cyber threat, and they start to wake up to that. So I think what we tried to explore with Miguel and was how uh complex that ecosystem is getting into, and how when you have tools which do accelerate that idea of analysis or that idea of response, and you can acquire them yourself, it starts to reframe in a lot of customers how they think the MDR should be. And as it turns out, MDR is less about analyzing threats and much more about extending detection coverage and performing analysis and responses of scale customer comps, but not just driving alerts. So there is a stepping stone to that, right? And today what MDR really is is kind of undefined. So when people get into the MDR market, they don't really know what they're getting. And doing some RFPs and stuff like that, you realize that there's a lot of expectations outside analysis. And I think this is where the market is getting into wanting external providers who provide a platform and or service, but who address needs like threat detection coverage, creating more detection, extending that, providing intelligence, providing context. So that's that's the evolution I'm seeing. It's like the traditional model that was very kind of segmented. Now it's kind of getting merged and blurring. And what matters are outcomes. What do you want really from your MDR provider?

Migjen Hakaj 10:06

The main value proposal that uh MDR providers have kind of been giving customers over time is I I like to say it's two-parted. It's being able to give customers an ability to be able to detect certain threats, so to speak. And the way they've done that is that they've told their customers from a centralized point of view as long as you give me all the logs, all the information and network uh telemetry that you have, we will provide the technology, the people, competence, and processes to be able to tell you guys when we think something has gone wrong. That's basically detections, right? And the second valid proposal is that we will provide the same people that works as some kind of a filter for the detections that we have created and only tell you about detections we think matter to you. And that's kind of where that was super valuable 10 or say 20, 10, 15 years ago, because customers didn't have that trivial access to modern security operations capabilities that was provided by their vendors. But like fast forward to today, with the emergence of cloud and like access to the security operational platform that you're basically able to stand up in a very short amount of time, you're able to get a lot of the same value proposals in days, weeks, uh at worst months that you used to be dependent on an MDR provider to get before. And this dynamic, back to your original question of how what does the customer look like and what type of models exist for when they do things themselves, when they acquire an MDR, when they uh go into tight relationship with their technology vendor? That dynamic has changed significantly as a result of these moving parts.

Robby Peralta 11:54

But aren't we just overcomplicating it? Can't we just put people to actually like respond to what's being brought up and then we're in a good place again?

Migjen Hakaj 12:02

I I think we're kind of getting to what we were also discussing in our blog post, though, that like can we just put people in a space where they just respond to it? Or uh the problem with that has always been scale. And that's kind of what I love with the means take is that a lot of the challenges that we've sp have been speaking about in terms of detection engineering, in terms of being able to respond to threats in a certain uh uh in a certain model, they've kind of been always broken. And we need we need new perspective, new ideas of how to address these problems. Like uh, how many conferences, how many talks, podcasts have you listened to where they talk about alert fatigue? And you're now also saying that can we just respond to it? But the classic issue is that we don't have the means to scale response, and we're trying to we have been looking at the ways to scale response in the same-ish ways for a lot of years now, and we kind of need radical change. Yes, radical change in how we deliver the stock, how we kind of uh what positions the MDR vendor needs to take, what position the global security companies take, and what positions the companies themselves have to take going forward to enable to actually be effective at response.

Amine Besson 13:19

I I think the the best rebuttal of can we throw more people at it is uh AISOC, right? Because there is a reason why AI SOC did not just completely take over everything. There is a mindset from the AISOC provider, which is let us throw our agents at your problem. Because people are expensive. So don't hire five people, get our tool for 120k. First of all, it's a rug pull because if they are burning so much tokens, there's no way it's going to be 120k in a couple years. I mean, sure, they are burning their account to the ground, right? They leave on a on a ramp made of funding. That's why they can say, All right, let's throw all your alerts at us, right? Doesn't matter. 90% false positive, get us. Um, I think that's not scalable precisely because it was not scalable with humans. You you can't scale attention, be it of agents or people, to thousands of false positives a week or a month. That does not exist. This does not work. And the solution has always been to shift the balance of power from analysis to engineering, where you build a detection platform, your platform made of your content and your tech stack and how all that interconnects, where you you shift the tide. It's not about false positive, it's also about detection coverage, but you have that in control and you're able to feed your AI sock or the people you have, etc., with the best quality incidence, with like the tightest scope possible. I mean, I've been in so many projects where we do the mistake of enabling all the vendor content, right? You you acquire Microsoft Sentinel, you enable 300 roles, and then you spend the next three years sorting the mess, right? So I really can't see it working well just by throwing more people at it. There is a need to we call it shift left. I think it's an abuse of the term, but we say there's a left, middle, and right part of SecOps now. That's a term that is getting popularized. Where the left-hand side is a threat detection, the right-hand side is kind of a response, an automated response part, response engineering. Uh, and the middle part is the part we are not good at, which is how do you go from detection capabilities to incident-worthy events? And the mindset now is to throw AI socket, I think that's the wrong one. I think the better mindset is to extend detection engineering to also have the control over that middle part. And then when you feed your people your incident, it's not an uh one event to one rule, to one alert, to one incident. It's a full context thing. And this is what we're missing now. How do we go from low context to high context? And then AI sock can work. So it's kind of the opposite take of the AI sub direction. But if you look at how it's been going in our practice in the world, I think we both agree that's the better direction, and that's the more sustainable one as well.

Robby Peralta 16:08

Well, mnemonic is happy to hear you say that, at least uh, but we're gonna come back to AI SOC. Uh what you're talking about with this engineering, is that am I right to think like detection and response is code, or is that kind of off as well?

Amine Besson 16:22

I I think it's 100% in. There is um an analyst mindset and there is an engineering mindset. The analyst mindset is how do you solve immediate problems. There are people who have immense skills that I don't because I was a terrible security analyst, but they have skills to go deep into things, right? So and I think the engineering mindset is a systemic mindset, is how do you solve problems as a fundamental thing. So it's not about how do you do the thing which doesn't work and find the process, it's maybe the thing that doesn't work has to be re redesigned. So what you see is the same with detections. An analyst mindset is over-tuning, an engineer mindset is logic change, uh things like that. And detection as code is a hundred percent in the books because it's how do we scale our detection library, our detection content. And detection as code is actually the best example you could have used because it's literally taking what's happening in software engineering for the past five, six, seven years. I mean, infrastructure as code is an old topic now, and how do we bring that maturity back into the back into detection engineering space? And so this we didn't see before because we did not have that engineering mindset. And people were very content with going on a GUI and clicking around. And now they are realizing this is not good enough. And we're realizing it again because we have this growing engineering perspective into the into the SOC. Response engineering is the same, but maybe lower maturity still, where we have mature source tools, but that don't do everything. So you have uh more expertise around them, but I still think with a response part, we don't have a perfect recipe on how to automate that and how to make a real engineering stream out of it. So to answer your question, 100% in scope, but what's interesting is why are we only realizing it's now, right? It should have been an old topic. We should have done this years ago. Because there's a growing, growing awareness.

Robby Peralta 18:17

And you're I think it's your first, maybe it's your second blog, you had a knowledge graph. Like this threat relates to this, this relates to that. Can you just uh take like a campaign by a scattered spider or I don't know, quick fix, or just take one of the campaigns? How do you like back to our point in the beginning? How does a customer know what they are protected against? What they can say that okay, now we have we have this, these things under control. What does that look like today? Is that even possible?

Amine Besson 18:46

I will I will take this one and then I want Migjen to to take his uh own perspective because I think there's no right answer here. It's just what what are you used to do and what do you know? So one of the things I'm doing is that I'm leading, I'm maintaining, right? So I'm the dictator for life, technically, but it's an open source project called Open Threat Informed Detection Engineering. And that's the thing that I've been working with the European Commission, CSOC, to get out. And it's it's it to do exactly that. It's to figure out how do we go from threats to detection rules. But more importantly, how do you map it out in a way that uh a year from now you still had a consistent view, you know? It's not lost in conference pages or reports or notes or stuff like that. It's it's structured. And so the way that we land it on is it's all as code, but the data model is what matters, is that to break down intelligence into threat objects, those threat objects can interrelate, those threat objects drive your detection objectives, which is just a written specification of what you want to do, right? Maybe those 10 threats can be addressed by simply detecting anomalous whatever, right? And then we go into rules and your rules map on objectives. And so what I realized two weeks ago is that now I can use an AI to do all this. So I don't have to write those objects manually. And now that's this is actually still reframing my worldview on it. Is how this can scale much faster than before. But then in that graph, yes, we can take a scattered scattered campaign, we break it down onto individual TTPs, we interrelate those, and then we drive our detection engineering path. And that's the end vision. View from intelligence all the way down to rules, and in a way that's building your knowledge base. You are not losing that knowledge when someone reviews your role two years from now and completely forgot the context.

Migjen Hakaj 20:37

And I think like that level of detail that I mean talks about that, there to have that level of detail, uh, that level of insight is what I think is expected of an MDR today. Because it's your question, Robby. What when there is a vulnerability and there is the out there or there's a threat actor doing some specific type of having a specific type of campaign, what the customers are are wondering about, is this relevant for me? What are you guys doing to to address this uh this campaign, this vulnerability in the context of my estate? And going back to what we talked about earlier, sadly, uh the level of detail, the level of granularity we've been at has been more about boasting how many detection rules do we have, and we stop at that logical level. And we have uh maybe uh going a bit deeper, saying we have so many detection rules based on this log source, right? If you give us entry ID logs, we will give you 20 day detection rules back. What Amin is talking about is making sure that we need to have a deep understanding of how threats operate at a very granular level, so that we can tell customers like this click fix campaign is we have a deep understanding of what threat actors out there are relevant for you, how they operate, what type of estate you guys have, what type of products you have. Uh, what those products again have in terms of detection capabilities, and we have that all mapped out in the knowledge base, and we can use that dynamically. And you by by using having that insight and working specifically with that, we can tell you that this is actually extremely potent for you, but but not for you, the other customer. But we are not going to be able to say that, at least uh say that truthfully without having those capabilities, and that's kind of where you looked at uh what the industry has been doing with my retrack uh and mapping log sources, detections to tactics, techniques. That just doesn't cut it. It doesn't cut it to give the actual truthful answers to if these campaigns or vulnerabilities actually matter for that customer, and that's kind of again where we need to just in my perspective, I think in our perspective, we need to change how we address this core problem. Yes.

Amine Besson 22:56

As I was talking uh with Migjen, could I I said, all right, what should be the right target states as an MDR provider, which I'm very familiar with because I'm also working with a company called Soterix to uh develop kind of an OT MDR called Vigilant. And because we had such a bit naive, but in like the best sense, where we we started from the ground up, we kind of wanted to redefine everything and sure, we were not happy with analysis, but also we realized because customers in OT are also kind of much more direct and uh simple sometimes in how they want to approach OT security. You just want to know for those threats, am I exactly that? Am I covered? Am I protected? Am I able to detect and respond? And so my target state became as an MDR provider, that knowledge base should be exposed to the customer. They should be able to go into a portal or whatever, right? And go and say, all right, so let's see for that threat actor, which I've heard about, what my MDR has done and what have they done for me? Do they have more detection rules that they could deploy for me? Maybe I can make a request now. They don't have a visibility. They kind of have to treasure black box and sometimes complain about it, and then you go into those terrible use case development streams where it's like a whole fuss to make maybe five, 10 use cases. And I don't think that's the way to go. I think we should be very transparent with customers about what threat coverage we have for them, what we do, what we don't do, and especially when we are maintaining platforms for them, that they understand what we're doing in there. Something that I think we've underperformed precisely because we went into the turnkey approach, which meant trust your logs, trust your platforms to us, and we'll provide value out of it. And now, now we need to do better. Now we need to be very granular and detailed into what exactly we're doing and not doing, and providing, I think, in terms a threat coverage view to any customer on demand. For me, this is really the target state as an industry that uh we should reach now.

Robby Peralta 25:01

First of all, I just want to say I really resonate with what you're saying. I'm a very simple man, I'm a sales guy. I mean, I'm not sure if Migjen and told you that. How do we get this capability? Please fix. Like what needs to happen for that to be a reality?

Amine Besson 25:13

So I I think it starts by intelligence. You need to be able to have your intelligence, whatever it means, be it your provider, be it your internal team, working with a provider, you need to have your internal team having a razor-sharp focus on providing continuous inputs, meaning they need to break down intelligence into objects, into value outcomes, into all right. This is something to detect now. Intelligence teams are not really good at it historically because they have a different mindset of strategic intelligence. So now we need to jump into the operational intelligence again. It's not IOCs, it's not a big strategy thing, it's right in the middle. What are actors doing today? They need to provide those outcomes. They need to maintain a registry, and the detection engineering team needs to use that registry to create rules. And then, no matter what tool, no matter what data model you use, as long as you respect that threat registry into detection registry, then you have the groundwork to do than that. Just expose that to your customers and make it very transparent to them what you're doing for them. So it starts with intelligence, you need to rework a bit the intelligence program. It ends up with detection engineering doing a better work at consuming that intelligence. And at the end, you need a nice front-end designer to find, all right, in that technical thing, how do I expose it to customers in the best way possible? And there you have it. It is not rocket science, but it requires continuous effort in the mindset shifts into threat-informed detections.

Migjen Hakaj 26:42

And I'd also like to piggy back on that. I think um revamping what is detection engineering and what type of people, personnel, competency goes into that umbrella. Because not only are uh customers of MDR vendors looking to understand what type of threats are you able to detect on my behalf, but they're also looking to understand how do you do it? Uh, where is it best done, and how do you do it cheapest? Because they're all typically very cost sensitive. And and the thing is like to enable to understand answer all of these questions, you you need different types of input from different fields. And what uh you you see with all the detection as code framework is that they typically provide a taxonomy for how to input your competency at uh at a similar logical layer where the threat intelligence analysts can uh uh put the input their perspective, the product experts can input their perspective, the red teamers can input their perspective, and the text engineers can input their perspective. Because uh, to give a concrete example, like uh we haven't touched base on this yet, but like customers are put in a space now where they're typically invested into multiple platforms. If you're lucky, they're into one platform. Typically, you will see two platforms, their own and the MDR vendors platform at a minimum. But then that that's the minimum. And they will be uh they will have the questions of should this detection or should my ability to detect the threat for this threat actor be in this system or in this system? And that requires a very deep understanding of the the specific platform's capabilities, where the data is, the strengths and weaknesses in terms of uh like say you're invested into Microsoft's ecosystem and they have 40 Defender products, and understanding having a catalog of all the detection capabilities that Defender has, typically that is not the insight that the intelligence analysts have, but the ones that do red teaming that continuously assess these products, they do, but they have traditionally not operated, uh they have not synergized with detection engineers at the like the right logical level. And this is kind of where, as a min made uh uh an argument where intelligence needs to kind of come to the right level, so does the product experts, the red teamers, and the others to kind of achieve the goal of fine-grained insights, which is, in my uh perspective, one of the kind of next big differentiators for MDR finders.

Robby Peralta 29:24

So, Amine, I would assume that you know a few companies that uh have those capabilities. Imagine we know a company that has a lot of those capabilities. Is the problem that we're not combining these functions in a way that's like pushable to the client? Is that the main challenge right now? Is that we're like, what do we need to do to solve this as an industry?

Migjen Hakaj 29:44

The SOC needs to change. How we address these problems structurally has to change. And this is kind of where like the silos that we've typically built over time in terms of who is red teamers, who are blue teamers, who are product experts, all of those competencies are are kind of needed to deliver on the actual goals uh for the customers, and they cannot be silos anymore. And one thing is like logical organization of how people work together, but also the other aspect of it is kind of the tooling, the technologies to kind of facilitate this. This is kind of where detection as code framework, uh, in my opinion, is a perspective of trying to merge that gap.

Amine Besson 30:24

It's a good one. I think, you know, first of all, the tech I remember right well back when I joined the European Commission, CSOC, we were building the detection engineering capability. And why it's a good analogy is because technically that CSOC is an MSSP, an internal one to over entities within the commission, which are 80. So it's like a big MSSP in a web, right? And we were not really comfortable to call it detection engineering, because in the mind, engineering was platform maintenance, admin work. Right. So we were doing it, but we did not call it that way. And I think until we're able to really call it that way, it kind of hurted out of perspective. Because it's all about mindset. If you are doing things like creating detection rules, that's good. If you're doing things like threat intelligence, that's really good. I think what we're missing is the right structure in place and the right focus in most MDRs to turn those uh distinct kind of people doing different things into a very focused stream of uh threat detection coverage. Because that angle is really not an MDR angle. There is very few MDR in the world who proactively go out to a customer and say, our whole shtick is to extend threat detection coverage for you, extend our response capabilities for you, and provide you maximum outcome, which is meaning true positive incidence as much as possible. They're not really doing that. That communication piece is not there. And so when you're buying an MDR as a customer, which I have done in my career, you don't really have a feeling that you are buying a partner which is going to extend your maturity. You're buying a partner which is going to just take over the noise, which is going to take over the pain. And that's the the opposite of what we need to do.

Robby Peralta 32:10

How does that transition need to look? Migjen, from your side, like uh I I've understood that it's a it's a train of thought, it is sort of a reorganization of processes, and that maybe the sock should is are we still gonna have a line one, line two analyst at the end of this, or is it just gonna be a verification that what the machines have concluded is correct? What is what is that gonna look like in terms of people?

Migjen Hakaj 32:38

I think, like in order for me to answer that question, kind of need to uh talk about why do we need to transition? And that is kind of one thing is uh the the core problems of uh of security operations that we've uh kind of addressed a little bit in the context of why does this also have to change uh in terms of how we organize, what type of specific value adds we give as an MDR company, why that has to change. It has a lot has a lot to do with things that are changing around MDR. Right. I think it's safe to say that our industry has matured. At least I uh I'm hopeful and optimistic in that, that more people have more mature understanding of being able to provide these core capabilities that is of reactive security, perform stand-up monitoring solutions, stand-up basic detection engineering capabilities, where they have customers have in-house capabilities, competence on doing analysis response to a larger extent than before. And in comes like over the last eight, nine years, the behemoths out there decided they wanted to take a space into reactive security. Microsoft, AWS, uh Wiz, GCP, all the companies I mentioned before, they decided that we want to have a stake in the business area of being able to detect the generic threats and more for customers. And that how that plays a big role when the when they take that position and want to invest into that. That means that if MDR vendors are now looking to continue down the path of delivering the same value proposal I talked about earlier in terms of being able to detect generic threats, you're basically in direct competition with those vendors. And customers see that. They are asking MDR vendors, like, hey, what's your role now? What's your value added? Exactly. And that that's kind of where we're coming into the perspective we're talking about that we are asked to do, we're asked to either compete or do something different, and that's our perspective or our take is that we shouldn't compete. It doesn't make sense. And there I've not heard about any MDR companies that are at the scale of those other companies that I mentioned, right? So that means what's left of the cake, so to speak, right? And that's kind of actually managing the noise that those the products create, and actually being able to provide competencies that are contextualized to the customers, because that is something that the large players will struggle to do uh over time, because Microsoft or GCP can go to a local customer in Sweden and say, we are we can create a tailored product just for you, but a regional MDR, they have to in order to stay relevant. In order to do that, they will need to have the the competencies, the tools, the taxonomies that Amin was talking about in terms of uh contextualized specific detection engineering, and that's kind of uh how this changes. And in order to do that again, to now under answer your your first question like why does the the structure have to change? This is why. Because in order to deliver that product, we can't have the same structure that we had before, which was that was built to handle a large mass of generic uh information is getting really interesting, right?

Amine Besson 36:15

The real question that will be super hard to answer, and that's the one we've posed in our blog parts is actually if I have uh modern tools like EDRs, like NDRs, like a tool which by themselves are very competence, and if I have just engineering capability to manage those tools and develop detection content, and I have that in-house, why do I need my MDR for if there's AI sock knocking at my door and saying I can try 70%? And maybe I'm doing a not uh an amazing job compared to MDR, but I'm doing good enough of a job at a cheap enough cost that you can reinvest the difference into your own internal capabilities. Whereas before the economic balance did not make sense. It always made more sense to get an MDR at a certain scale. Now this is challenged. Why? Because we just have better technologies, and because Megan saw that, I think, in a better way than I did initially, which is you have a just a strong consolidation of SecOps platform to the point where it feels you can get a full-blown SecOps platform and do better than an outsource provider would do if they provided you their approaches and tools and data first, kind of you know, log forwarding and they do the rest. So this is really the technology landscape which has shifted. It got more complicated, but it got much more uh empowering. And in an ISOC is an evolution of that. It's not perfect, it's full of holes, but it feels empowering and it's maybe economical enough that you can reinvest the difference and do better on the left-hand side if you don't do good on the middle and right-hand side. So, what does the future look like? I think Google had had this. I mean, you know, Google is full of smart people, right? And so we sit around and sometimes they come up with an illumination. And one of them was ASOC. I think they came up with that in 2018, 2019 or 2017, so somewhere there. Uh ASOC stands for autonomous SOC. And it was an extension of our vision that if you have strong engineering competencies, you can move to continuous detection, continuous response, not uh very traditional uh alerting to monitoring to uh charging to response. So we had a completely different different view because they came from a very strong engineering background. I often talk about how they translated the SRE, like the site reliability engineering, onto the detection response engineering parts, meaning they had for infrastructure uh operational incidents, a uh engineering first view. And it became very clear that you can reuse that in security. All right, it's not operational incidents, it's security incidents, but there's a lot of similarities there. And I think in the future, how it would look like is that organization will want strong engineering competencies. They will want platforms which do more, and they will expect uh NDRs to do much more than they can do internally plus an AI SOC, which means providing the end-to-end uh uh threat-informed detection view, extending that for them, performing a scale that they still can't because your MDR centrally has uh detectionering capability across all customers and can move quicker. So the differentiator for sim now is because you are spread across so many customers, uh what makes you do better? Because if you're just doing striaging, being spread across customers is a weakness. You can do less per customer, and you have to see how much you can stretch your analysts. This is dense, right? So if you are spread across customers, what is the value add? What is the differentiator? And yeah, uh technology expertise is definitely one of them. Uh threat intelligence and how it drives uh the content is another one, and understanding, right? How do you use all that scale to optimize the response part? Uh so it's it goes back to customer at a higher value. And I think that's moving away from a traveling view, it's it's moving into an engineering view, and maybe uh response will be 90% automated in the next three years. But it starts with moving to engineering, how do you redefine the problems from a systemic view? You cannot scale with people. How do you scale with systems and how do you scale in a way that the customer can't do uh just with tools?

Robby Peralta 40:30

Why couldn't Google or Microsoft or these big boys sort of do this in place of an MDR? They have if they have the data, what's keeping them from doing that themselves?

Migjen Hakaj 40:40

When Microsoft decides to build or Google decides to build a detection, their customer is the world. Because their output, their detection is going to be delivered to their core platform that they do that the customers use, be it SecOps, Defender XDR, Sentinel, right? They don't have the luxury that an MDR has in terms of putting in context that would let's say make the alert trigger more. So it can't be granular enough. Exactly. They have because that's what's going to blow up for the world, right? And if an MDR company doesn't allow themselves to scale the capability of doing that exact thing, then you're at the crossroads here where you're overlapping again. So that's kind of one of the core challenges that lies ahead for MDR to be able to solve. And the actual capabilities that are required for MDRs to scale analysis, response, and contextual engineering is kind of what we're addressing in our blog post. And that is moving from, let's say, uh a legacy way of doing IT in general and kind of following the principle of the rest of the IT world with DevOps SREs, following engineering mindset and applying those same principles to the SOC. Because what we're what we're kind of doing in the SOC is following the old ways. We have siloed capabilities in tire one, tire two, tire three. We have supporting capabilities outside the SOC in detection engineering, intelligence, instant responders, and we have to kind of move that to more of and we spend a lot of time moving context around the silos, right? That is that is time that allows us to scale even less. And that's kind of like one of the uh the measures that we're talking about is kind of adapting a mindset of like uh you you build it, you own it, you see it, you own it, right? As an example for scale, if an anal analyst works for a specific customer, they need to have structured input to tell them that the this is the 10th time I've seen this detection, it has been classified as false positive nine of those 10 times. Uh it's been benign positive the other time. Uh, should I shift the should I send this, uh, create a ticket for this and send this to L2 or L3 for tuning? Or should I have the capabilities, the tool stack to actually do something about it, to actually tweak and tune that rule, add some context that makes this rule more specific to this uh for this customer? And in doing so, this is kind of where you create a product that differentiates from what the actual behemoths are able to provide to their customers.

Amine Besson 43:32

Yeah. Uh I definitely feel like adaptation is a strong one. Um, and that's exactly that is that uh NDR is a service, you can tune your service. Uh, these platform are products. So if they want to be able to tune the product for each customer, then they need to figure out how to do it. And they and they haven't done it so far. You cannot go into a sim today and have a very strong workbench, right? To just say, all right, let's start from intelligence. Break it down, go into what I really want to detect and implement. That does not exist. You have a list of detections and you try to search in that. So I do feel, however, that this is something that is actually actively going to be explored in the next couple of years. Because I think this year is when you saw a lot of very strong investment rounds into detection engineering companies. So it kind of got an industry term. And there's a very big acquisition. It's a Splunk acquired Snap Attack. Snap Attack did exactly what I said. They provided an intelligence platform that allowed the customer to create their profile and then create rules. And then deploy those rules and then test them. So they they had that view and they got to acquired by scene. What is it showing that the traditional scene view of just providing content with some tagging to enable filtering is not good enough. And you need to really have a strong adaptation to a customer. There's a whole AI stuff, right? And how to generate rules. I think what really matters is understanding threat profiles, which today is still poor, but once it gets there, you will see an acceleration in those tools as well. So uh all in all, I think the vision is there. The technical means are not. And in a way, for me, that provides MDR, and I do agree with that, that provides MDR with a very nice sweet spot on how can they provide maximum adaptation to customers in a very transparent view that goes much beyond what the products are already doing, beyond the built-in, beyond the, you know, and providing that visibility which today is not there. I think this is a super, super good sweet spot to be in. And it's much more interesting than just scaling, charging with more people. It it really goes back to the core of what we're doing. As I mean, I have a job because there is a need to detect threats in the wild. I don't have a job because there's a need to monitor locks. It's two different things. And I think we conflate them all the time. We focus on threat detection. We focus on threats. This should be our obsession over the next few years. And how do we provide to our customers, to our uh companies, to our clients, how do we provide confidence that we understand threats? Where today, I don't think there is a very strong confidence. You go into your MDR and you have a very uh good friend uh working with OpenType that calls it a market of lemons. You don't know what you're buying, you don't know what this MDR detects versus this other one. You know, this one is a Sentinel shop, you know, this one has their own platform. What does this really mean for you? You're not sure. You have to work with guys a couple of years to understand how things are going. And that's kind of the black box we have in the market for now. We need to be more visible.

Migjen Hakaj 46:39

I and I and I really kind of the more I think about your question, the more I actually love the question. I also think I also think uh one has to be realistic about what's happening around us again, and and to be brutally honest, like the thing that uh Amin is talking about with uh companies spawning uh with uh where the value proposal is providing a detection package, uh three intelligence packages. Uh the big behemoths themselves are going into the space, and there's no question about it that all of these initiatives, all of these uh all of these companies spawning up, they are attacking their traditional value proposal of MDR. And that this is kind of being uh aware of this and making uh and changing accordingly is what is going to separate the ones who survive and the the ones who don't uh doesn't have a right to live, to say it's brutally honest. And I mean I also really love what I mean said about like being able to uh provide adaptation at scale, and that also paves the question of what does the next or the future MDR platform look like to enable this? Because we have talked about a lot of different things now in terms of how we have to organize ourselves differently, what type of value adds we have to uh deliver. But we haven't really talked about uh, or I guess I mean touched about about this that customers want an MDR to extend the capabilities, the features they want to of the products that they acquire themselves. They want MDR vendors to be partners, but there is no real platform out there that allows for the delivery of all these means at is from a central centralized point, right? We have we are we're coming from a world where where we have delivered centrally by ingesting everything, but now we want to operate as a control plane centrally, but but provide value distributely, right? And that is a whole different ball game. Like, how do we provide adaptation, uh, do distribute adaptation to customers at scale when they're invested into multiple products, multiple log platforms, multiple cloud platforms? This is kind of the core challenge that needs to be addressed over time in order to kind of stay off all of these different types of companies that are looking to eat their way into the reactive space of cybersecurity.

Robby Peralta 49:07

If what you're saying, both you're saying is true, I think in the next five years the big behemoths will eventually try to get to that customization, that granular level where they can provide very, very customized stuff. I think that they will eventually, if they can take that market, they'll try. And they're good, they're engineers, they have a lot of good engineers, so they'll probably get there. But in the meantime, what is the role of the AI SOC then? Because I don't think the AI SOC is a totally stupid idea either, but is there a role for that in the next couple of years?

Amine Besson 49:33

The the the big ticket item is uh replace your L1L2. It will not just replace your full responders, right? But the idea is um you have very noisy alerts, and in the course of triaging, you charge alerts into incidents. I mean, people call it different things. Maybe they receive incidents and they escalate the incident, but it's the same concept. They receive some signal and they have to figure out if this is worth looking into for an incident responder. This is the L and L2 job, right? Uh traditional model, which I perfectly hate. I think it comes from the wrong place. I think it comes from a like customer support or something like this. It's really not what we should be doing. Um but uh my my dream for a long time was how to eliminate that because I uh it's not about having less people, it's about having people focusing on things which have value. So, um, with my uh approach with Sotrix when we designed the vigilant for OT, we had this view of all right, we're going to hyper combine signals because in OT you can afford to do it, you only have tools, you don't have logs, so you can kind of combine all the signals to provide a higher value outcome. There's no AI in there, it's just a smart risk combination. But even in that, you're able to achieve massive reduction and massive context improvements, and then you can throw your AI at it. So the place of AI SOC is to free up time to go from signals which should already be not super noisy because you did detection engineering, to incidents which are worth looking into. And that's the crux because AI SOCs are being pushed by their investors to become MDRs. They are all pushed to say, onboard your customer, charge it for them, output incidents. Right? But that's that's the thing. This is the transition of the market, and use more tokens, yeah. And use more tokens and burn them, right? And give money to NVD and Open AI. That's that's the circular industry of AI, I guess. But that's exactly that. Is that the whole thing, right? Where we resonated like crazy with Megan is that these value propositions of taking over noisy alerts and somehow doing something with them. If this is automated, then MDR is about everything else but that. So AI stock has a place and it will help us ask a lot of questions about our own value, our own value chain, our own proposition in the markets. And it's going to, you know, I perfectly think that a year from now you'll have a customer who will be, you know, uh doing uh, I think it will be for you, right, Froby, where you will do a sales speech and you will say that sounds all great. What are you doing that I can't do with insert AISOC? And then you'll be like, ah, then we need to sell everything else, actually, because the triaging part is cool, that this is the challenged part. So AI SOC has a place. AISOC is challenging MDR directly, but I think it is not a perfect approach. You still need to do detection engineering on the left-hand side, you still need to have expert C shirt on the right hand side, and you still need a better way to feed that AI SOC with higher quality signals. So all that's not going away. L1, L2 is, and then we have to figure out what it means for us as MDR providers.

Migjen Hakaj 52:42

I think that was uh great take on it. Uh it kind of puts two lines under the things that we've been talking about that going forward, like MDR does or AI SOC further puts pressure on the thing that the platforms, the behemoths, already have been pushing putting pressure on, and they will put uh even more pressure on it, which again leads to the point that we've kind of been talking about during this episode, and that is MDR has to be better at their own core competencies for their customers in a contextualized way. But that is something that's typically hasn't scaled, but we will need to learn to scale it. Detection engineering, analysis, response.

Robby Peralta 53:26

Well, Migjen when I met you the first time, I said that we're gonna change the world. What I really meant is that you need to change the world. Please fix. Thank you so much for your time, gentlemen. I've learned a lot, I've had a good time, and I'm uh looking forward to adapting my sales pitch based on your words and your thoughts today.

Amine Besson 53:45

No, I think you've I think you've uh created a fantastic uh opportunity for us to discuss it. It's uh a topic very much under wrap, so I think it was great to get it out there. And I must say, for a technical sales or non-technical sales guy, you followed everything. So trust in yourself more.

Robby Peralta 54:03

It's like I said, I talk to smart people all the time and copy what they say. Take care of yourselves, talk to you soon.

Amine Besson 54:10

Thanks, Wood. Thank you. Have a good one.

Robby Peralta 54:12

Bye bye. Well, that's all for today, folks. Thank you for tuning in to the mnemonic security podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonic.no. Thank you for listening. We'll see you next time.