Repository Feature
None
Problem Description
Currently the Detection rules in ESQL have hardcoded indexpatterns. This is pointless for large enterprise customers who have different naming standards for index patterns or have cross cluster (the *: before the name)
For instance 3 of our large clients whom we partner work with ONLY use ESQL rules and they have to customise every single rules to fit their standard.
It is much better to have Detection rules have 'VIEWS' (https://www.elastic.co/docs/reference/query-languages/esql/esql-views) which is present from Elastic 9.4.x onwards. That way, the VIEWS can act as a abstract layer for the index patterns and customers can define the views centrally and re-use the detection rules.
Desired Solution
Detection rules with highly flexible views
This is similar to Splunk 'macros' style if possible
`custom_windows_indices`
| WHERE user.name == "adminstrator"
More complex examples
PUT /_query/view/logs-windows
{
"query": """
FROM *:logs-windows*, *:my-custom-windows*
"""
}
Detection rules can be then
from logs-windows // This is a VIEW
| where event.category == "api" and host.os.family == "windows" and
process.Ext.api.name in ("OpenProcess", "OpenThread", "ReadProcessMemory")
| ...
Considered Alternatives
No response
Additional Context
No response
Repository Feature
None
Problem Description
Currently the Detection rules in ESQL have hardcoded indexpatterns. This is pointless for large enterprise customers who have different naming standards for index patterns or have cross cluster (the *: before the name)
For instance 3 of our large clients whom we partner work with ONLY use ESQL rules and they have to customise every single rules to fit their standard.
It is much better to have Detection rules have 'VIEWS' (https://www.elastic.co/docs/reference/query-languages/esql/esql-views) which is present from Elastic 9.4.x onwards. That way, the VIEWS can act as a abstract layer for the index patterns and customers can define the views centrally and re-use the detection rules.
Desired Solution
Detection rules with highly flexible views
This is similar to Splunk 'macros' style if possible
More complex examples
Detection rules can be then
Considered Alternatives
No response
Additional Context
No response