Walk me through the lifecycle of a detection, from idea to maintained rule.

A detection is not a one-time deliverable; it is a product that must be built, validated, operated, and eventually retired. The detection engineering lifecycle borrows directly from software engineering discipline.

The stages

1. Identify — pick what to detect. Drive this from threat intel, an ATT&CK technique with no coverage, a recent incident, or a hunt finding. Prioritize by relevance to your environment and threat model.
2. Research — understand the behaviour and which telemetry actually reveals it. A technique you cannot see in your logs is not yet detectable.
3. Develop — write the logic (e.g. a Sigma rule), with metadata, severity, and ATT&CK tags.
4. Test — run it against known true-positive data (lab reproduction or emulation output) and a slice of production-like benign data to gauge noise.
5. Deploy — ship it, ideally staged: monitor-only first, then alerting once the false-positive rate is acceptable.
6. Validate — confirm it actually fires via adversary emulation (Atomic Red Team, purple-team exercises), not just hope.
7. Tune and maintain — track false positives, refine, and retire rules that are redundant, perpetually noisy, or cover a technique that no longer applies.

Detections as code

Store rules in version control, review them in pull requests, and run them through CI that checks syntax and schema. Coverage is mapped to ATT&CK so gaps and overlaps are visible.

Why this matters

Senior interviewers probe for lifecycle thinking and the willingness to retire and validate, not just write. Anyone who deploys a rule and walks away will eventually drown the SOC in noise and blind spots.