Detection Engineering That Holds Up Under Investigation

Start with a precise adversary behavior and the business context in which it would matter. 'Detect PowerShell' is not an analytic goal; 'identify encoded PowerShell launched by an Office child process on user workstations' is much closer to one.

This framing makes the data requirement, expected false positives, triage path, and testing strategy visible before a query is written.

Every detection depends on a contract with telemetry. Name the sources, event types, fields, collection assumptions, and known blind spots. If a field is optional or inconsistently parsed, that is part of the analytic risk—not a footnote.

A small data contract also gives an operations team a way to notice when a once-working detection has silently lost its evidence.

A detection should trigger on the behavior it claims to identify. That requires a positive test. It should also tolerate the normal activity that resembles the behavior. That requires negative tests using known administrative tools and business workflows.

When tests fail, do not immediately widen the query. Determine whether the source event is missing, the parser changed, the hypothesis was too broad, or the test did not match real attacker tradecraft.

A production rule needs an owner, an investigation guide, a severity rationale, and a planned review after it sees real traffic. Those details make it possible to tune deliberately rather than letting alert fatigue decide the rule's fate.

The goal is not zero false positives. The goal is a detection whose signal, context, and response expectation are well understood.