LAB/03Research area
Detection engineering: detections built and tested as software
Detection engineering turns knowledge of a technique into a rule that fires on it and stays quiet otherwise. Labs treats detections as code: specified, versioned, tested against real telemetry and retired when they stop working.
- Area
- LAB/03 · Detection Engineering
- Outputs
- Detection content in Sigma, KQL, SPL and other query languages, with test data and tuning notes, Testing methods and pipelines for detection as code, Research notes on telemetry gaps and detection design, Coverage reporting formats that separate mapped from validated, Detection logic and test cases for XDR development
- Status
- Active research
01Open questions
What we are working on
How should a detection be tested before release, so that it fires on the technique and stays quiet during normal administration?
What is an accurate way to report ATT&CK coverage, so that a mapped technique is not mistaken for a detected one?
Which detections can be written once in a portable format such as Sigma and compiled to several query languages without losing meaning?
How can silent or degraded log sources be detected as reliably as attacks are?
Which entity and time relationships allow detections from endpoint, identity and cloud to be joined into one incident?
How should the cost of a detection be measured, in data volume and in analyst time per alert?
02Method
How the work is done.
- Detection as code
- Rules live in version control with a written specification: the technique, the data source, known false positives and the response expected. Changes go through peer review and automated tests before release.
- Validation by attack simulation
- Each detection is exercised by reproducing the technique in a lab with tools such as Atomic Red Team and custom scripts, and by replaying recorded telemetry. A rule that has not been seen to fire is not counted as coverage.
- Coverage and telemetry mapping
- Coverage is recorded per technique with its state: no data source, data source only, detection written, detection validated. Gaps are reported as plainly as coverage.
- Tuning from outcomes
- Alert dispositions feed back into rules. A detection that produces mostly benign results is rewritten, given better context or retired, and the reason is recorded.