Detection Engineering as Integration Testing
I can't claim to be a detection engineer, but looking at my portfolio I can spot detection as a motif in my highest impact projects. And I have good reason to think about the discipline more rigorously now, so I want to use this space to start laying the groundwork for an approach that can keep pace with the volume and velocity of data moving through a modern corporate environment.
Let's start with attacks. We know they are going to happen and we know some will be successful. The burden of the blue team is accepting this inevitability. If not all attacks can be stopped, then it is in your best interest to invest your energy in preventing the most catastrophic ones you could imagine, then go about engineering ways to detect all the rest.
But how can one sift through the noise and generate good detection signals? If you operate a system of any substantial size, you are going to need a really low false-positive rate to avoid drowning in alerts. Detection is a delicate dance that depends on rules operating over logs. Lots of logs. And these logs could be coming at you from endpoints, the network, security tools, or wherever else you get telemetry.
This makes engineering detections an integration problem, and the integration problem has been solved already with integration testing, so why not treat a detection flow the same way you treat a build pipeline? Codify detection rules as code and subject them to peer review just like everything else. Write unit tests against your logic to ensure rules trigger on the right signals. That's a good start towards a mature detection engineering program. And while we are at it, maybe we are approaching the stage where broad strokes of the toil could be left to a large language model. It sounds feasible that a coding agent could generate detection logic on the fly and test the rules it creates without having a human intervene. Time will tell.