Description:
The detection engine's time filter should narrow down the search request's timerange as much as possible, in order to keep scope to just the relevant shards. There can be performance impact when timerange is unnecessarily wide, particularly when involving nodes with slower response profile (warm/cold).
Current behavior:
Detection rules may use open-ended time ranges (relevant section here)
This allows for filters like the following:
"filter": [
{
"bool": {
"should": [
{
"range": {
"@timestamp": {
"from": "2020-12-04T15:19:07.456Z",
"to": null,
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
}
],
"adjust_pure_negative": true,
"minimum_should_match": "1",
"boost": 1
}
},
{
"bool": {
"should": [
{
"range": {
"@timestamp": {
"from": null,
"to": "2020-12-04T15:25:07.456Z",
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
}
],
"adjust_pure_negative": true,
"minimum_should_match": "1",
"boost": 1
}
}
]
Expected behavior:
Apply a more precise time filter, binding from and to based on the configured interval/lookback period, in order to avoid searching open-ended time ranges.
Description:
The detection engine's time filter should narrow down the search request's timerange as much as possible, in order to keep scope to just the relevant shards. There can be performance impact when timerange is unnecessarily wide, particularly when involving nodes with slower response profile (warm/cold).
Current behavior:
Detection rules may use open-ended time ranges (relevant section here)
This allows for filters like the following:
Expected behavior:
Apply a more precise time filter, binding
fromandtobased on the configured interval/lookback period, in order to avoid searching open-ended time ranges.