Building Better Detection Logic with Endpoint Telemetry

The easiest detection rule to write is also the most fragile one: match on a specific file hash, a specific domain, a specific command-line string. It works exactly once, against exactly the sample you saw. Durable detection logic is built around behavior that survives small changes to the attacker's tooling.

Indicators expire. Behavior doesn't.

A file hash is useless the moment the payload is recompiled. A behavior, like an Office process spawning a command interpreter that immediately makes an outbound network connection, survives across dozens of different payloads. It describes what the attacker needs to accomplish, not the specific tool used to accomplish it this time.

Baseline before you write the rule

A noisy detection rule is rarely the result of a bad idea. It's usually written before anyone worked out what normal looks like in that specific environment. A rule for 'unusual parent-child process relationship' is only meaningful once you know which relationships are actually unusual for your fleet, which requires pulling a baseline window of telemetry before writing a single line of detection logic.

A simple structure for behavior-based rules

• Describe the technique in plain language first: what is the attacker trying to accomplish, and what does that require the system to do?
• Identify the telemetry source that would show that system behavior (process creation, network connection, registry modification, etc).
• Write the initial query broad, run it against a baseline window, and see how much legitimate activity it also catches.
• Tighten with context (parent process, signed/unsigned binary, network destination reputation) until the false-positive rate is manageable, not zero, just manageable.
• Document the technique it maps to and the known legitimate activity that can trigger it, so the next analyst who sees this fire doesn't have to re-derive the reasoning.

Tuning is not the enemy of coverage

A rule that fires constantly on legitimate activity gets ignored or disabled within a month. That's a worse outcome than never having written it. Tuning a rule down to a manageable signal-to-noise ratio, even if that means accepting it will miss some edge cases, produces more real detections over a year than a theoretically perfect rule nobody trusts enough to keep enabled.

A detection rule that gets disabled after two noisy weeks provides zero coverage. That's the same as never having written it.