Detection engineering meets AI-driven adversary emulation

In the first post in this series, Wade shared how our team laid the foundation for using AI in detection engineering. The short version is that an LLM doesn't know your stack. Without documentation and workflow context, it can produce plausible results that are difficult to trust, regardless of which model you use. That post closed with an instruction: Validate before you ship, because the output can look completely right and still be wrong. Every detection an agent writes still needs to go through the same review and testing as a human-written detection. Let’s discuss that last part, because it's harder than it sounds. We'd built a detection-as-code pipeline, and we were proud of it. Rules live in a repository. Changes arrive as pull requests, and they get peer-reviewed, planned, and applied through CI. We had the structure of a software engineering team, and we tested queries against the logs we had. For everything else, we had never watched the detections fire. We shipped those because they looked right. Validating a detection without the logs in your environment means running the attack technique yourself and watching it fire. We didn't have time to do that manually for every rule, and we had no automated way to do it. So here's the question. How many of your deployed detections have you watched fire? Not reviewed – actually watched fire. You don’t want to be answering that question the day an incident happens. Now that detections are code, they need to be tested like code. This post is about what it took to give our detections tests. An AI model did one job to make that possible, which is picking the attack technique to run against each detection. Why "it looks right" is not proof Before we get to the pipeline, it helps to see how a detection that looks right can still be broken. Reading a detection tells you what the query says, not what it actually does. It doesn't tell you whether the query matches any real logs, or whether the detection catches what you wrote it for. Here are five ways a detection can look right and still never fire: That field isn't what you think it is. It might have been renamed between vendor versions. It might be nested a level deeper than the docs suggest. Or it might be sitting in the raw message instead of parsed into a queryable attribute. The query is valid, it's just pointing at something that isn't there. Absence isn't emptiness. You write a condition for a field being missing, and the source sends it as an empty value instead of leaving it out. Depending on the query language, a wildcard matches that empty value, so the condition is never true and the rule never fires. The query language doesn't behave the way you read it. A quoted phrase doesn't always match the exact string you typed. Wildcards work one way on a parsed attribute and another way in free text. Case sensitivity or one unescaped character drops your result set to nothing. The data never reaches the query. The rule might be scoped to an index the logs don't route into. The source might have stopped shipping last week. Or an upstream parser change might have broken the field the rule depends on. The logic is fine. There's nothing for it to read. The threshold is set past what your environment can produce. If the most you've ever seen is ten events in a window and the rule fires at a hundred, you've written documentation, not a detection. Every one of these failures is silent. No error, nothing in the queue. A rule that can't fire looks exactly like a quiet environment. That reality is why "we have N detections" was never a coverage number. That number tells you how many rules you've written, not how many attack techniques you've proven you'd catch. These problems show up the first time you run the attack technique and check whether your detection fires. What this isn't We aren't a red team. I'm not a red teamer, and this isn't meant to replace one. Our approach starts from the detections we're writing or changing. For each one, AI picks the matching attack technique from a library of known techniques, the pipeline runs it, and then checks whether the detection’s query caught it. A red team tells you what you missed. This approach tests whether the detection you wrote works. This post also isn't an implementation guide. There's no code to copy. The emulation tooling we build on is open source, but the pipeline around it is our own. Instead, it covers why we built this, how the pieces fit together, and what we've learned running it. If you want the technical details, I'll be walking through them in a session at Datadog Detect in Chicago on November 2. Both sides of the test are code Detection-as-code is half of what makes this possible. The rules being tested are code. So is the thing doing the testing. Our attack library is a fork of Stratus Red Team, the open-source cloud adversary emulation project maintained by Datadog. Every technique is defined in that fork, released as pinned versions, and c

Extras afișat conform termenilor RSS ai publicației · 200 cuvinte · textul integral și figurile sunt pe site-ul publicației