DOVE - Detection Overlap & Value Evaluation

Detection engineering is a key capability for modern security teams. Creating detection rules provides visibility into current threats, enables proactive defense, and allows organizations to tailor monitoring to their specific environment. However, this practice can quickly become a double-edged sword.

As the number of detection rules increases, the lack of continuous review and validation may lead to a growing volume of redundant or ineffective detections. These detections often generate duplicated alerts, contributing to noise and analyst fatigue, ultimately reducing the overall efficiency of incident response processes.

At the same time, modern SIEM platforms such as Microsoft Sentinel, Splunk , IBM QRadar, and others, continuously evolve by incorporating built-in detections that cover common threats, techniques, and behaviors. This increases the likelihood that newly created custom detections overlap with existing native capabilities, resulting in duplicated signals and reduced added value.

The DOVE Model (Detection Overlap & Value Evaluation) is introduced as a structured approach to evaluate detection rules based on their uniqueness, usefulness, and risk of duplication. The goal of the model is to help security teams identify whether a detection contributes new signal or simply repeats what is already available.

🔍 Model Overview

The DOVE Model evaluates detections across four main dimensions:

1. Detection Type

• IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
• IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.

2. System / Technology Coverage

• Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
• Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.

3. Threat Recency

• Older or well-known threats are widely documented and likely already covered by existing detections.
• New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.

4. Source / Provider

• Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
• Custom or third-party detections introduce tailored logic and reduce overlap probability.

⚖️ Core Principle

The model is based on a simple but powerful idea:

The more a detection leans toward widely known, mainstream, and already-covered scenarios, the higher the risk of duplication and the lower its added value.

Conversely:

The more a detection focuses on behavior (IOA), emerging threats, and environment-specific logic, the more unique and valuable it becomes.

📊 Practical Application (KQL Example)

To support the identification of potential duplicated detections, the following query correlates alerts generated within a one-hour window and highlights cases where the same assets (including custom detections) could have a relation:

AlertInfo
| join kind=inner AlertEvidence on AlertId
| extend DateHour=bin(Timestamp,1h)
| summarize make_set(Title),make_set(DetectionSource),dcount(DetectionSource),count() by FileName,AccountUpn,DateHour,EmailSubject,DeviceName,RemoteIP,RemoteUrl,Application
| where dcount_DetectionSource > 1 and set_DetectionSource contains "Custom detection"
| order by count_ desc

This approach enables analysts to:

• Identify duplicated detection signals
• Correlate alerts across multiple sources
• Evaluate the added value of custom detections

🎯 Objective

The DOVE Model aims to help security teams:

• Reduce duplicated alerts
• Improve detection quality and uniqueness
• Minimize analyst fatigue
• Prioritize high-value detections
• Establish a continuous detection review process