What is detection engineering?

What is the detection engineering lifecycle?

1. Requirement: a behavior to detect, from a hunt finding, a threat report or a coverage gap.
2. Design: the logic, the data sources it needs, and the ATT&CK technique it maps to.
3. Test: run it against historical data (a backtest or retrohunt) to see what it would have caught and how noisy it is.
4. Deploy: ship it to the platform where it runs, usually the SIEM or data lake.
5. Tune: reduce false positives as real alerts arrive.
6. Maintain: fix it when data sources, field names or pipelines change, and retire it when it no longer earns its keep.

How does detection engineering relate to threat hunting?

They feed each other. Hunting finds behavior no rule covers; detection engineering turns that behavior into a rule. Detection engineering finds gaps in coverage; hunting checks whether anything is already hiding in them. Most tools in this guide connect the two, for example by promoting a hunt finding straight to a detection (Vega) or by requiring a retrohunt before a rule deploys (Nebulock).

What makes detection engineering hard to scale?

• Every data source speaks a different query language, so one idea becomes several rules.
• Rules break quietly when upstream data changes (see detection drift in the glossary).
• Noisy rules cost analyst time on every alert.
• Coverage is hard to measure, so teams struggle to say what they do not detect.

What is Sigma?

Sigma is an open, generic signature format for describing log events, maintained by the SigmaHQ community. Its main repository holds more than 3,000 rules under the Detection Rule License 1.1, and tools such as Sigma CLI and pySigma convert rules into the query languages of specific platforms. Sigma is useful context for evaluating any vendor: ask whether a tool can import, export or convert Sigma rules.