Query Details

Detection Rule Usefulness Evaluation Based On DOVE Model

Query

**Detection Rule Usefulness Evaluation based on DOVE Model**

**Description:** Creating multiple detections without reviewing them over time to ensure they’re still effective can easily turn them into pure noise, adding nothing but fatigue to our day-to-day incident analysis.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):

**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.

The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.

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

Explanation

This KQL query is designed to evaluate the effectiveness of detection rules in a security monitoring system by identifying potential overlaps in alerts. Here's a simplified breakdown of what the query does:

  1. Data Joining: It starts by joining two tables, AlertInfo and AlertEvidence, based on a common field called AlertId. This combines information about alerts with evidence related to those alerts.

  2. Time Binning: The query groups the data into hourly intervals using the Timestamp field. This helps in analyzing alerts that occur within the same hour.

  3. Summarization: For each hour, it collects and summarizes information about alerts, including:

    • The titles of the alerts (Group_Alert_Tittles).
    • The different sources of detections (Different_Detection_Sources).
    • The count of unique detection sources (Number_Detection_Sources).
  4. Filtering: It filters the results to focus on situations where:

    • There is more than one detection source involved (Number_Detection_Sources > 1).
    • At least one of the detection sources is a "Custom detection".
    • There is relevant information available, such as user account, IP address, email subject, device name, URL, or application.
  5. Ordering: Finally, it orders the results by the number of detection sources in descending order, highlighting cases with the most overlap.

In essence, this query helps identify alerts that may be redundant or overlapping, particularly focusing on custom detections. By doing so, it aims to reduce noise and improve the overall effectiveness of the detection system by ensuring that alerts are meaningful and not just repetitive or redundant.

Details

Sergio Albea profile picture

Sergio Albea

Released: May 4, 2026

Tables

AlertInfoAlertEvidence

Keywords

AlertInfoAlertEvidenceAlertIdTimestampTitleDetectionSourceDateHourAccountUpnEmailSubjectFileNameDeviceNameRemoteIPRemoteUrlApplication

Operators

joinextendbinsummarizemake_setdcountwherecontainsisnotemptyorder by

Actions