EP202 Beyond Tiered SOCs: Detection as Code and the Rise of Response Engineering

Secure running. Hi there.

Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Risk Analytics and Cloud Threat in Google CycOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of the Cloud Security Podcast listeners on our Google Cloud Security Community page. Without any further ado, let's turn things over to today's guest.

And today's guest is Amine Besson, Tech Lead on Detection Engineering from Behemoth Cyber Defense.

Welcome to the show. Hi, Anton.

So this is kind of an interesting conversation because, of course, we've been writing these now a year-old series of blogs on detection engineering, and then finally you're on the podcast talking about, surprise, detection engineering, right?

Yeah, here we are.

So I want to start with a somewhat suspicious question, and it comes up in some discussions where People hear about detection engineering and their reaction is, but I don't want to engineer. I just want detection to magically happen. So, what is your best advice to companies or to people who start with, oh, detection engineering. Oh, but I don't want to engineer?

Yeah, my stance on it changed a lot in the past 2 years. When starting doing detection engineering in my organization, I was told that I was not allowed to call it engineering. Because engineering was for the IT team. So I think that the best way to look into that is in terms of ownership. How much do you want to own your SOC? And if you want to own the efficiency of your operations, it also means you own the understanding of your technology, which translates to owning your content ultimately.

Mm-hmm.

So I would think more in terms of ownership The precise definition of detection engineering started with really writing detection rules, but I think nowadays it's also operating your technology at a higher level of understanding. So I would probably start somewhere there. How much do you actually understand your technologies?

So people who say, I want to own less of my SOC, less of my detection response function, They would then not own engineering, and ultimately they would pay somebody to do it. So somebody would still engineer detections for them, but it wouldn't be themselves.

Yeah, correct. It's actually a very popular model nowadays, right? Is that you outsource everything and you just have an oversight role. It's very limiting sometimes. It can be also very efficient. But if you want the highest level of quality possible, you need ownership, whatever that means in your exact case.

Yes. I think that the impression is that while the model is popular, we also hear about all those exciting outsourcing failures where people confuse the MSSP or MDR with some magical machine that does detections for them. Well, in reality, it's kind of a business that makes money.

Yeah.

Happens to be in detection engineering detection, but ultimately, it's a business and driven by profit, not by necessarily your results, right? Like, that's— I don't want to badmouth MSSPs. There are a lot of Robust MSSPs and MDRs out there, but the model of ownership is very clear that if you don't own it, you probably have somewhat limited demands of what they would do for you.

Yes.

So, to go to the kind of more classic model, we sort of talk about SOC, or some people, of course, talk about SOCless. So, what is the state of the art in your assessment, in your experience, when it comes to SOC? Do we even allow it to say— are we allowed to say SOC anymore? Should we say fusion of cyber defense? I mean, this stuff has befuddled me quite a bit for a good number of years, because I thought fusion is— well, first I thought it's about physics. And then I thought it's about government only, like a fusion center in some kind of government agency. So what's the story with the SOC, not SOC, fusion center, this whole—

Yeah, that one is fascinating. So yeah, I started to talk to— so I'm an independent contractor slash privateer slash freelancer slash courser, whatever you want to call me. So I have a chance to go in many, many SOCs. both internal or MSSP. So I've been on both sides of the table. And I started to talk to this gentleman who is like 3 times my age. And I told him, well, as a SOC leader, he directly cuts me off and he says, I don't own SOC. This is old school. I'm not old. I do CDC, Cyber Defense Center. And I was really stunned.

Mm-hmm.

And it took me a while to understand where he was coming from. But for him, SOC was almost a dirty word because he was so long in this business. SOC was basically IT operations to him. It was the whole, I click on noise to generate less noise and I get burnt out after 6 months. That's a SOC for him.

Okay.

Yes. So his entire team, it was like 30 or 40 people, were actually all detection engineers, response engineers, intelligence people, threat hunters. And for him, that was the highest level of quality of delivery in a SOC. And I think he could do that because he had a lot of money on his hand, to be honest. But it started to get a lot concerning is why do we do this? Why do we look at noise? Why do we consider that junior analysts are a good match for the complexity of threat detection? And I think ultimately it's because SOC comes, I think you've described it a lot, Comes from an IT operations background, from the NOC, SOC, NOC, putting big screens on the wall and thinking that's a good idea. So the state of the art is, I think we'll come back to that, but first, there's no more tiers. You have experts in your SOC, and the concept of trashing, the concept of investigation is now something that you can engineer, automate when you can, and make expert people be better at it when you can't. So right now what I see is that the SOC is becoming this triangle between intelligence, detection, response, with people having a mix of engineering/analyst backgrounds working around those 3 things.

But ultimately, you made a few fairly profound points. One of them is that this specific company that sort of inspired you to say this, also had a very well-funded operation.

Exactly.

Namely that when I sometimes describe this type of detection engineering-centric or even engineering-led type of DNR operation, which really frowns at being called a SOC because they don't think of themselves as descendants of NOC, they think of themselves as engineering-powered detection response. The conversation happened at companies that are thinking of the pyramid, not even the top 1%. We are talking about top Fractions of a percent of businesses, perhaps even of large businesses. So is this limited to the elites? And maybe I'm asking not only is this limited to the elites today, but is this doomed to be limited to the elites?

What was very eye-opening for me after some of my experiences in the EU was looking at what the US was doing. And in the US, it's almost the opposite. It's the smaller company who are spearheading the innovation. Whereas in the EU, it's more a very big SOC with more ambitions who's going to look into what's next. And I think even looking at my more local markets here in Benelux and even the Nordics, you see that 2 years ago, detection engineering was unknown. And now you see dozens of jobs opening for that. People are opening up to it. And so I think it's moving, and it's moving quick. The awareness of SOC leaders has changed. They understand that they did not do a good job with detection content before. They should do it better now. And ultimately, I think this will trickle down to more and more organizations. Because if you don't have budget to engineer detections, you probably don't have budget to hire 10 analysts. And those 10 analysts, might or might not be the one doing the tuning, but most of the time, they still live in noise. So, it's changing.

So, actually, this is another profound point because if you had money to hire for the old NOC-style SOC, you probably use some of the money to actually hire fewer different people for the more engineering-led operation, and you'd get better results. People would be happier, and you may end up spending roughly the same amount of money. Is that pushing it too far, or is that realistic? Instead of 10 junior people—

I think that's realistic. It's just how it all evolved. It's for a long time, we just threw people at the problem. That's the analyst mindset, is that if you have a lot of backlog, you just throw more people at it. The engineering mindset is asking why we have this freaking backlog, why we have 4,000 alerts in the queue. And analysts for a long time were just used to not ask questions and just look at all those alerts one by one.

Shovel. Exactly. Just shovel.

I think we're moving away from that model. And the economics are becoming way more clear that maybe your SOC of 40 people is actually a SOC of 10 core people and 30 that you use to balance the table. So I think people now are getting a way better idea of if I spend my money towards better detection engineering, it has real economy of scale.

Yes, I think that part is— that comes up in a lot of discussions that I have with clients sometimes when people's minds are blown when we tell them that we decoupled the link between threats and assets and the number of people we have in the team. And people basically just have this utter resistance to believe that it's possible. Like, we tell them, hey, in the DevOps and SRE, they cut the link between number of system admins and number of servers. And that's accepted by now because it's a 2009 innovation, right? But then we say, hey, in security, in what used to be called SOC, we can also cut the link between the number of humans and the number of assets. And they're not correlated. There is no linear growth. There's very sublinear growth. And people just refuse to believe that. They say, no, no, no, what do you mean? If I have 1,000 servers, I need 10 analysts. If I have 2,000 servers, surely I need 20. Like, how can it not be like that? And I'm like, hold on. You think it's the truth, but it's your belief. And here I can show you evidence. It's not the truth over here. If you set up things that way, you don't have the inherent link. Sorry, I'm rambling too much, but that's roughly the theme, the same theme, right?

You are rambling what I'm thinking about every night in the shower. It's like, why do you think that? I think it's, again, it's a question of culture. If you've had 20 years of analyst mindset, I think it's a hard truth, but we all try to self-justify what we work on. And if we work on noise every single day, then you have to justify to yourself, it's a necessary evil. If you come with an engineering background, and SRAs are by definition strong engineers, very strong developers and infrastructure engineers, then they get it. They say, no, all that noise is noise we create ultimately. We decide what's noise and what's not. So we can engineer the hell out of it and have an exceptional monitoring situation where we can respond quick. I do think that SRAs is also Almost the prototype of what SOC could be if we applied those lessons learned to our domain, basically.

Yes, that's exactly right. And I think it seems like even for a good number of years, we've been kind of on parallel journeys in this regard. And then we kind of finally met in the vlog series, of course. So if somebody shows up and says, no, I think that I need to have level 1, level 2, level 3, like my grandfather had in a NOC in the '80s. I think this is part of the story. Like, we also see this whole tiered SOC or funnel SOC or whatever becoming kind of less common, becoming less of a thing. But why specifically it breaks when it encounters modern threats? Why is this model actually bad as opposed to suboptimal?

Yeah, I think this is the complete tech debt. But tech debt does not exist itself. It's not in our language. But it is tech debt, is that for how many years did we work in Jira or ServiceNow, which are linear ticketing tools where you get an alert going into an incident? And it's even worse than that. It is one log source monitored by one detection rule on one system, which generates one event, creating one alert, opening one case, attaching one playbook, and assigned to one analyst. 1, 1, 1, 1, 1, 1, 1.

I'm cringing already. I'm like, want to jump off the window when I see this type of product.

Yeah, but it's horrible. Threats are nonlinear.

So that means that you can't improve it.

Well, you can't improve it.

If you push this model further, you'd still have the same model. Yeah, you can't improve it. You need to leave the model.

That's why we scale with analysts, right? It's because if you get more noise, you need more analysts to look at all those alerts.

Yep.

Yep.

So we have linear tools who acquire data linearly. And when you look at the job of a Tier 1, what really a Tier 1 is doing is grouping alerts. They are looking for similarly raised alerts, which may be part or not of the same threat event. And of course, it's insane that they do it when we all say that correlation engines are mature. But they still do that. And the Tier 2 is basically validating and enriching.

Yeah.

So when I had to explain what an analyst was doing, I was actually really stunned because every time I would say something, I would feel stupid and think, oh, this can be made smarter.

Yes. Yes.

So actually, it's an exercise I did. I work with a great guy called Nick in Belgium, very specialized into OT security in his company, Soteryx. And I kind of convinced him that MDR was a good idea somehow. And we started to have this really hard discussion of how much time does it take an analyst to look at one incident? And I was completely like, I could not answer that. It's a crazy question to me because it depends so much. And when I was trying to explain it, I realized it depends so much because we do a bad job. If we did a great job, the responders would only have to look at very highly qualified events, which they don't.

Yeah.

And because we don't do a good job, we have this tier structure. But when your complexity, when the volume of threats, when the size of environment becomes too big, then this is where the tier structure collapses because you just can't scale anymore.

Yeah. No, that's the part that's the most annoying because people have been trying to almost push this button harder and harder, but the machine that they launch with the button is not going to solve this problem. It's like pushing the button harder is not the answer. It's almost like The vision I have is somebody calling an elevator by pushing the button harder, but they need to fly to the moon. So, the elevator is not going to go there. So, I don't know. So, I stuck with metaphors today. So, let's go to the next question then. I think that one thing that's puzzling when people try to adopt the more modern model is that they start becoming enamored with detection engineering and detection as code. And just a few days ago, I noticed people arguing on social media about do you have to actually code to have detection as code, or do you follow software engineering practices to have detection as code? So, what's your definition? Can we call it maybe the final definition of detection as code?

Yes. So, technically, detection as code is purely defining your detection content using files that you can back up in a versioned repository. So, that's a simple definition. The implementation is what varies a lot. And I think a big problem with that is that the early adopters of detection as code really wrote code. If you look at Red Canary, which were one of the precursors of detection engineering, they wrote detection rules using their own domain-specific language, which looks a bit like Ruby, which is completely unreadable to the non-initiates. And that's very scary.

Yes.

But nowadays, the better direction is declarative programming, which means basically like Terraform, you define your target state and you have a system which aligns you with your target state. You don't program, you just define resources. So my definition of detection as code is it must be declarative, it must be transparent. You need to be able to look at your detection rule and know what's going to be on your system.

Mm-hmm.

And it needs to be able to deploy differentially. Meaning you need to be able to deploy a single detection rule at a time. And why? It's because I think that's the key to adopt detection as code. If you deploy your entire repository at once, you are not able to do staging or testing or whatever.

Correct. Yes.

It's a declarative system where every detection rule is a file backed within the Git repository with CI/CD pipelines to deploy that. And you're able to do differential deployments. So, the only thing that changed, it's very much the same concept as Terraform. Terraform does exactly that. So, we're just applying the success of infrastructure as code back to security operations.

So, you wouldn't hold it against people who maybe don't do it in Python or don't do it in Go. They do it in, well, equivalent of Terraform for this. Maybe they do it in YARA-L or in whatever else. So, you wouldn't necessarily demand that they use a quote-unquote real programming language.

Yes. And I even think it's a bad implementation to write detection rules.

Yes, it's the same.

Because, you know, I know one SIEM vendor where you write your detection rules using Python, and it raises so many questions.

Yeah, I think you'll win the understatement of the year prize by it raises many questions. It kind of sucks.

Yes.

It's hard to teach to people, and it's hard to convert former SOC analysts to that.

Yeah. And so I think it's actually a bad approach. If you build your entire system from the ground up, it's your IP, you own everything, maybe it's a good idea. For the vast majority of SOCs, no.

So another mystery that I wanted to visit quickly is that we talk a lot about detection engineering, but there is in parallel a conversation about how people want to do response in a kind of a low-code, no-code platform, whatever that is. And it seems like there's no conversation about response engineering. Like, what's going on here? Like, surely if we have the DNR, detection and response, and we have detection engineering, it should have its brother called response engineering or a sister, I don't know. But should there be? Is there? Like, explain this whole thing to me. Sorry, big ask.

Yes, I think it's— the evolution is similar. So before detection engineering, there was SIEM engineering. Which was just looking at the system, basically, but not really the content. And I think when SOAR was introduced, we do a bit the same. We look at the platform, not at the content. And we build basic playbooks, basic automation, but these are different people yet. So the detection engineer and the response engineer are 2 different personas.

Oh.

But really, they should not. They should be the same person. It's a continuum. So if I'm really good at understanding threats, I should be really good at detecting them. I should be even better at plugging that into my response. So I think it's something which is still emerging even more than detection engineering.

Mm-hmm.

But in some of the best SOC I've seen, it's more detection and response engineering where you are not just handing over detection to another team to build some playbooks with it. You're actually end-to-end. You're building your response alongside your detection, and you end up with fantastic detection strategies potentially, which are end-to-end. So it's more than the sum of its parts.

I mean, that's a logical answer, and that to me, that makes sense. And again, it's very similar to what I've seen at some of the maybe really, really top-tier detection response teams is exactly that. It's the I guess I shouldn't use full stack, but it is kind of a full stack from light threat research to detection content to triaging the signals flowing through a pipeline. So to me, this vertical or maybe horizontal integration of detection and response engineering is the logical one. But sometimes, I guess maybe I shouldn't believe what I read on social media is kind of the point. Because yeah, I think that you brought me to the much more comfortable and logical place in this case.

Yes. And in a lot of places, it's also a product of hell, right? Is that they take 9 months to adopt a SOAR.

Mm-hmm.

So the complexity of spinning up makes it very distasteful to even think of plugging detection response. They just want something that even works. So the maturity will come eventually. It comes in some places, but for most, most people are still stuck at the SOAR engineering, not response engineering.

Correct. I mean, some of them suck at installing freaking SOAR product or even enabling traditional playbooks that are already in the SOAR. So I think that teaching them response engineering when they're struggling with installing SOAR product is kind of tricky. I think that makes sense. So I also want to touch on the intel part because this is another piece that you alluded to of the modern detection and response approach is that it has to be tightly coupled to intel production and intel generation. And again, a lot of this is covered in the blog series, but what are maybe some of the top struggles related to intel for modern D&E?

The funny thing is, I think in our long blog post, I think every single post complains about intel a little bit.

Yes, correct. That is exactly right, actually. But that's gently, very gently.

And we complain about it because it's so fundamental. Everything we do now is supposed to be threat-driven. But if you look at what's incoming, so the input to a SOC or a detection engineering team, it's really, really thin. Most detection engineers do their own intelligence, which to me is a problem if you already have a CTI team. Why do you do your own intelligence? You know, it's not even being in a jump role. It's really compensating for bad intel.

Bad, not usable for purpose of DE.

Bad is a little harsh. But I'm harsh with it because what I say is that a lot of TI teams are transforming PDFs into more PDFs.

For executive entertainment. Yes, there is intel as executive entertainment.

I think the key to it is that if SOC came from IT operation, intel actually comes from the military space. where you have threat briefing to superiors. So the expectation of intelligence, I think, has also been translating into these tactical, strategical, operational views of intelligence.

Like impress the general kind of approach as opposed to serve— I didn't think about it like that.

Interesting. Send a memo to the president every morning about the next 3 targets for the US, something like this. And great, but if you're on the field, you want something very operational. What do I need to care for? What is my threat in my immediate vicinity? And a lot of TI teams don't know how to deliver that. I've talked to so many of them and how they do it is, how do I even break it down? What do you want? And I tell them, what do you have? What threat is relevant for us? And so you have this kind of dichotomy. I think you really need to integrate your intelligence team down to your They do their processes so they can see what you actually work with and what you should expect. And when you do this, it gets better. But if your TI team is very far and is just a provider, it's complicated. The thing which is very, very telling is that some TI teams think that you should just give MITRE ATT&CK techniques and the detection engineering team can work with that.

Huh.

Yes. What about giving them an textbook from intel school or something?

Like, they should be able to figure it out.

Exactly. I think it's in line with why they think that summarizing with LLMs— when I use LLMs on intelligence, I don't summarize, I extract. I extract key points that I should create detections for. But their immediate thinking is summarize because this is what they do. They look at too much information and they have to find commonalities. And so ATT&CK does exactly that. They look at all the behaviors out there, they summarize into Generalized techniques. It's an exceptional thing. You can really talk the same language now, but I don't care about talking the same language today. I care about building detections for new threats. So mining is very different from ATT&CK. And if you use ATT&CK as your starting point, I think you got it wrong. ATT&CK should actually be the—

Wait, wait. Is it even as a starting point? If you use it as a Well, okay, wait. Explain this one briefly, if you may.

If I give you cardinal points and I tell you, you should go towards the east and you'll get to New York or whatever, it doesn't tell you how to get to New York. It gives you a direction.

Right.

And that's the same thing, is that ATT&CK gives you a direction. Hey, you should look into cloud credentials being abused. You should look into vault courses being reused. You should look into this and that.

Yeah, great.

Now I need what to look for. What did the attacker do exactly so that I can go low and then I can decide how far back I'm going to go, how far I'm going to generalize? Because technically, we always deal with precision and recall concepts. The more precise you are, the less you will see. But if you want to step back and see more of potential threats, you'll be less precise and get more noise. And so to do that trade-off, we need to know exactly the behaviors of the adversary. ATT&CK does not give you that. ATT&CK gives you the direction that the adversary took. So how ATT&CK really should be used is in terms of threat coverage. What do you not do? What, as a detection engineering team, you haven't looked at yet? What is relevant to look at next? So for me, ATT&CK is all about giving you directions and ideas of what you don't do well.

Mm-hmm.

Can't give you precise idea of how to detect. You will have 6 months of R&D around a single technique, potentially.

You can have a single— I think it's still stuck in my head. I think it was the 1438 or something when it's persistence by elevated privilege. And I'm like, oh, for 50 platforms we have, give me all techniques about the persistence or something. And I'm like, whoa, that's 6 months of research right there. That's one item.

Yeah.

Yeah. And the last argument I can think of is attackers don't care about ATT&CK. If you want to invent a new technique—

Yes. The stuff outside of ATT&CK isn't kind of a quote unquote known problem, but I think that it probably isn't what kills you in most teams, right? It's that you don't have it covered. You don't have actual coverage of what you think you have coverage for. When you have, oh, persistence through that. Well, do you have it for routers? Oh, routers. No, I haven't thought about it. Oops. You don't even need the extra ATT&CK techniques you host already.

I think it won't kill you. To close the topic, it won't kill you, but it kind of shows you that the speed of intel is the speed you want to be at. If you have a new threat which is not yet in ATT&CK but is your intelligence, it shouldn't bother you that you're not able to map perfectly or that you didn't plan to address this technique. Potentially, you might want to a new threat based on intel, not based on modeling.

Yes. I think that's also fair because an attack is not meant to trigger immediate action, but intel may.

Yeah.

Yep.

So we have 2 more questions and almost no time for this. So let's try to go run through them. So this whole discussion kind of makes me think that perhaps there is also a different detection stack or a different technical architecture about how signals flow, how correlation happens, what scoring needs to be done. And it needs to be kind of seamless, meaning it's not tied to a specific commercial SIEM, but also rely on integrated response inside. So can you maybe describe this? I don't know how many hours you need to describe it, but if you can describe it, a point maybe would be helpful.

I will leave most of the meat for the white paper if I can recover that. But so no, we mentioned earlier in the podcast is that you kind of have this 1-to-1-to-1 mapping between events, detections, alerts, incidents. And what you see happening now is that a lot of, I think, the newer generation of detection engineers, they really get that what we're actually looking at is signals, not alerts.

Mm-hmm.

You see, you basically have an ocean of signals in your environment, and you cannot process all of them. What you can do is being very smart about how you correlate them. And probably using entities is the right metric. If you're able to do entity extraction from all your signals, you can group around entities. You can start to score based on risk, whatever that means in your exact state. But you are likely able to calculate that risk, and that new architecture, which I called threat signal and entity correlation scoring, which put a I'll probably check it twice before I republish it. The idea of alerts are dead. We look at signals. And because we can do detection and response engineering, we really look at the end-to-end picture where we can raise smart signals, yes, but also less smart context signals. And we are really good at the correlation piece, which today is not truly done by many people.

Yep.

Or done in a very narrow way when it's like a classic SIEM correlation from the early 2000s. If you see this, then you see that, correlated alert gets triggered. So like a 20-year-old correlation is there.

Yeah. You know, that surprised me because I was mentioning this to someone else, and they actually had the exact same arguments. Like, it's an old thing. And for me, it's like I've been a few years in SOX, and I haven't seen it done really well. So it's an old idea that hasn't been yet completely executed. And I do think this is where we are kind of, you know, it's all cycles, right? We're circling back to that. And I think it's one of the things we see with what I call seamless. A lot of people are not willing to buy a SIEM. They prefer to use a data lake, whatever that is, usually cloud, and build the front end. So build all the detection engine and presentation layer, et cetera.

Mm-hmm.

And often they actually don't even have a SOAR. They just pipe back the alerts to chat ops, so to Slack or Teams or whatever, and they process there. And I was very fascinated by this architecture. But I do think it's telling of 2 things. It's telling that SIEMs haven't fully delivered on value and that the data analytics kind of people caught up to what SIEMs were doing 10 years ago. And now we can do the log analysis with something else. But we still need to be smart about the whole signal management. So things are moving, but I think they're moving in the direction of signals versus alerts.

I think alert is probably one of those words that also has its DNA in a NOC, when you have a blinking light and you're not really intelligently analyzing signals to figure out what the attacker is up to, but you are responding to alerts. I think this is probably another thought that just came up. that it's the word you inherently use, and it is a word with the NOC DNA. It's maybe IT help desk DNA when you literally have something breaking and blinking and screaming, and you need to go and respond to that. But in reality, you have an attacker, and he may not be doing anything now. He may be doing something quiet and not noisy, and you have signals about all of that, and you need to discover the attacker. So this is like mildly mind-opening, I think, in terms of alerts versus signals. And I think that I've seen that exact line of thinking at very elite organizations, but I have not seen it spread down. I've seen it as the tippy tip of the pyramid type of orgs, like the best of the best of the best kind of orgs.

Not yet. Many places are driven by their product and vendors in terms of maturity. So, unless a vendor adopts a framework, they will not use it. So, that's why I think probably Very few places adopt it. But I think as you get more detection engineers in the wild, that will change as well. You will see different things being built.

So one last question about something fun that you started called OpenTIDE. So can you give us a very quick, who can benefit from OpenTIDE and maybe what's next with the effort?

Yes. So OpenTIDE, which stands for Open Threat-Informed Detection Engineering, is a platform that were built in the trenches of a European Commission CSOC that I joined very much at the start of the organization. We scaled the detection engineer team from, I guess, 3 people now to almost 18. And OpenTIDE is the name of a technology powering that, which is a detection as code framework. So it's actually the only modular open source detection as code framework. That can be adopted really quickly. You don't need to build. You can adopt the project if you want to do such things. But it also has a rich concept of having a threat registry and a detection objective registry, where you define all of that as YAML objects. And the whole framework automates itself and builds itself so you can have a knowledge graph at the end, where for any threat, you can understand your coverage. And for any detection rule, you have full traceability back to the threat and even the actor because all those knowledge objects are integrated.

Oh, straight, all the way straight through actor. Cool. So it has the full integration to threat profiles and stuff like that.

Yes. And so in its easiest definition, it's a detection as code framework with a nice modeling and management on top. And in the more complicated one, more complex, is that it can be the engine for your DE team. where you will ingest intelligence, transform it into OpenTIDE objects, and use those objects to drive your next development.

Which makes a lot of stuff we've written in the blog series come to life for people because it's been kind of a bit mysterious. And I've received some responses from people who sort of are befuddled about where to start on some of the stuff. And I think that OpenTIDE approach gives them a thing they can touch and say, Oh, I'm going to do this over here, as opposed to like, I don't know where to do it. Should I do it in Google Docs or in Sheets or in somewhere else? Like they would do it in that platform.

Yeah.

Perfect. This was really, really good. And I think we did run over, but I think it was very much worth it. So thank you very much for being on the show. And of course, looking forward to continuing the collaboration.

Absolutely. Thank you, Anton.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @anton_chuvakin and @_timpeagle. Tweet at us, email us, argue with us, and if you like or hate what you hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.