Microsoft
MicrosoftI have done some testing on creating custom detection rules in Defender XDR using both XDR data and using Sentinel analytics data. From my understanding it works fine to include Sentinel analytics data as part of a custom detection rule in XDR, as long as the detection rule includes result from at least one Defender XDR table. However, creating a custom detection rule in XDR using only Sentinel data does not work.
The reason is that a custom detection in XDR requires a valid value for ReportId in combination with Timestamp to find the event in question, and in Sentinel data tables the ReportId field does not exist. Custom detection rules in XDR require ReportId to be projected, and although it is possible to e.g. set ReportId to blank, this will work fine when running the query in advanced hunting, but fail when the custom detection rule in XDR is supposed to trigger. Meaning the rule runs successfully when there is no results in the result set, but as soon as there are results then it will fail. Further, selecting a ReportId and Timestamp from a random XDR event can work, but then the detection rule will show the data from that specific event, not the query result. The query result in that case is just joined with that event, which becomes very confusing for an analyst and thus can't be used for detection.
So either there is a workaround here for ReportId field when using Sentinel analytics data (as ReportId doesn't exist in Sentinel analytics data such as SigninLogs), or it is not possible to create a custom detection rule in Defender XDR using only data from Sentinel analytics tables? If the latter is the case, then this blog post and the reference in the first question under FAQ is a bit misleading.
My observations are supported by this Microsoft article: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-microsoft-defender
, which state the following as a known limitation in Defender XDR Custom Detection rules: "Custom detections aren't available for KQL queries that don't include Defender XDR data.
MicrosoftHello!
Custom detections support Sentinel only data (this is a new enhancement). No need for XDR data anymore. When XDR data is not involved - we don't require report id and other required columns. The documentation should be updated - thanks for letting us know! will work to update it ASAP.
If you still experience issues with creating custom detections on Sentinel only data - please open a support ticket and we will make sure to address soon.
MicrosoftHi again!
The reason is, probably (I didn't debug since can't tell sure sure) that the required columns should come only from XDR tables (and all from the same XDR table). It's explicitly explained here: Create custom detection rules in Microsoft Defender XDR - Microsoft Defender XDR | Microsoft Learn.
So - it's not that all results must be from XDR tables as you wrote, but specifically the required columns should indeed come from XDR tables.
We are aware that the demand to project "required columns" from the same XDR table introduces challenges, and we are thinking how to improve the experience and potentially lower the requirements for specific columns.
If my suggestion doesn't help - I encourage you to open a support ticket so that we can further investigate.
Thanks a lot for your quick reply Noa :-)
I have done some more testing just now and can confirm that there is in fact changes as you mentioned. For Sentinel tables there is no longer a need for ReportId and other required columns, and detections that use either Sentinel only tables or XDR only tables work just fine.
However, my testing shows that there still appears to be major limitations when it comes to detections using Sentinel data. A custom XDR detection rule that looks at Sentinel data will only be successful if the query has no reference to an XDR table, for example in the form of a join or union. A custom detection rule that refers to both a Sentinel table and an XDR table will fail if results come from the Sentinel table, and give the error "No events match the given event identifiers (a combination of ReportId, AlertId, BehaviorId, or DeviceId and Timestamp). Edit the query's aggregation expressions for these columns and try again."
This means that even though you can have a XDR detection rule that looks as Sentinel data, it must be ONLY Sentinel data in that rule, and no reference to XDR tables.
Two super simple examples just to demonstrate the error follow. Both of these queries are successful in Advanced Hunting, but fail when run as XDR Custom Detection Rules.
Example 1: Leftouter join (e..g for enrichment) - always fails:
let timeframe = 1h;
SecurityEvent
| where ingestion_time() > ago(timeframe)
| where EventID == 4688
| where CommandLine contains "test evil"
| extend DeviceName = Computer
| join kind = leftouter (DeviceProcessEvents | take 1) on $left.Computer == $right.DeviceName // simulate enrichment just to replicate error
Example 2: Union with XDR and Sentinel table:
let timeframe = 1h;
let MDE = DeviceProcessEvents
| where ingestion_time() > ago(timeframe)
| where ProcessCommandLine contains "test evil";
let Sentinel = SecurityEvent
| where ingestion_time() > ago(timeframe)
| where EventID == 4688
| where CommandLine contains "test evil"
| extend DeviceName = Computer;
union MDE, Sentinel
This query does a union with a XDR table and a Sentinel table. It will be successful if results are only from the XDR table, but always fail if there is any results from the Sentinel table.
Both of these examples are successful in advanced hunting, but still fail as detection rules. So seems like as long as there is a reference to any XDR table in the query, it defaults over to "XDR-mode" and expects ReportId etc in each result in the result set, otherwise fails.