At Azure Sentinel we take pride in the ability to ingest data from a variety of sources(learn more).
However, data ingestion time may vary for different data sources under different circumstanc...
Updated Jan 12, 2021
Version 2.0
Blog Post
romarsia This is a very interesting article, thank you for the effort.
Few doubts :
1.
Azure Sentinel scheduled alert rules are delayed by 5min.
This allows data types with a smaller delay to be ingested on time for the scheduled run.
For more information, please visit our documentation.
--> Does this 5 min delay mean that if I set the alert to run every 5 mins and lookup data from past 10 mins, it actually looks up data from the last 15 mins?
If so does this not bring about duplication as discussed above.
Could you please share the link to the documentation that is mentioned above that discusses this in detail?
2.
let ingestion_delay= 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > (rule_look_back)
In this query,
ingestion_time() returns a date time object (like 1/14/2021, 2:26:07.477 PM) and rule_look_back is in minutes,
Ex:
| where ingestion_time() > 5min
When I tested this this comparison operation shows an output set of rows but does not filter correctly probably due to mismatch in data type.
3.
So do we need to design all our analytic queries with the above query conditions in mind ?
Also when setting the rule logic, does the rule_look_back set in the query take precedence over the lookup data from field set in UI ?
4.
Instead of applying such modifications per rule, would it not solve these issues if the Azure Sentinel platform considers Ingestion time for alert generation and not TimeGenerated. Would it not remove the need to keep track of the delay and per table type query modification.