EDR detection quality is not the same as alert quality.

01 / Research question

When a security team reports that an EDR is “working,” what evidence actually supports that statement? Alert volume alone is not enough. A useful evaluation asks whether the control observed the relevant behavior, produced a defensible signal, preserved enough context for investigation, and supported a repeatable response.

02 / The detection chain

Detection is a chain rather than a single event: telemetry must exist, the relevant behavior must be observable, analytics must interpret it, the platform must generate a signal, and downstream workflows must preserve the context. A failure at any point can make the final alert misleadingly reassuring.

MITRE ATT&CK separates detection strategies from platform-specific analytics. That distinction is useful because a high-level strategy describes what defenders are trying to detect, while an analytic describes how that strategy is implemented on a particular platform. citeturn0search17turn1search1

03 / What should be measured

• Coverage: Which adversary behaviors or security assumptions are actually tested?
• Telemetry dependency: Which event sources, sensors, or data components must be present?
• Fidelity: How reliably does the analytic distinguish the target behavior from normal activity?
• Context: Does the alert contain enough surrounding evidence to investigate it?
• Latency: How quickly does the signal become available to the analyst or response workflow?
• Actionability: Does the resulting signal lead to a clear investigation or response decision?
• Stability: Does tuning preserve the intended detection instead of simply reducing alert volume?

04 / Analysis

The central distinction is between “an alert was generated” and “the control demonstrated detection of the intended behavior.” A mature validation exercise therefore starts with a defined behavior and expected evidence, then works forward through telemetry, analytic logic, alert generation, enrichment, and response.

ATT&CK’s current detection strategy model reinforces this approach by grouping analytics into higher-level detection methodologies. Current strategies also document concrete log-source and correlation requirements, illustrating why a detection cannot be judged independently of its telemetry and implementation context. citeturn1search2turn1search3

05 / Red Hawk validation method

The Red Hawk approach is to define the target behavior, run a controlled scenario, observe the available telemetry, inspect the detection path, and document what the defender could actually see. Where a gap is found, the control is tuned and the scenario is repeated. This follows the broader Red Hawk validation loop: FIND → ATTACK → OBSERVE → DETECT → RESPOND → FIX → RETEST.

06 / What this does not prove

A successful test does not establish universal coverage. It establishes that a defined scenario produced the expected evidence under the tested conditions. Coverage claims should therefore remain scoped to the behaviors, platforms, telemetry, configurations, and time period that were actually evaluated.

07 / Defensive takeaway

Treat detection as an engineering capability with measurable dependencies, not as a dashboard status. Track what is intended to be detected, what telemetry is required, what analytic implements the strategy, what evidence is produced, and whether analysts can act on it. That creates a much stronger basis for security validation than alert counts alone.