Query Details

Detection Rule Usefulness Evaluation Based On DOVE Model

Query

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

About this query

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

GitHub