You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the introduction of using custom rule directories, users have the option to exempt out of query validation as well as to defined the local stack-schema-map how they see fit. The problem is that it currently only supports static references to ECS, Beats, or integration schemas, built in to the repo.
We need to update this to allow users to bring their own schema and define the mapping accordingly.
I think the easiest way to do this would likely be updating the usage of the map file to also take explicit paths, where a schema is defined
ex:
"8.12.0":
beats: "8.12.2"<- version strings point to built-inecs: "8.11.0"<...>: "schemas/custom/arch-packages.yaml"<- points to a relative path of the schema
As far as the keys (<...>), we will need to figure out portability here as well, since they are hard coded for certain situations (vs defining for a subset of rules). The easiest way would be to likely tap into the integration schema workflow and treat this as a custom schema, where the index pattern parses as normal.
A blocker is that the integration validation needs refactoring. To avoid more tech debt, we should consider that first.
A few issues closely related to this that may also be solved are:
Note: this work will target the DAC-feature branch
related to #3407
With the introduction of using custom rule directories, users have the option to exempt out of query validation as well as to defined the local
stack-schema-map
how they see fit. The problem is that it currently only supports static references to ECS, Beats, or integration schemas, built in to the repo.detection-rules/detection_rules/etc/stack-schema-map.yaml
Lines 88 to 106 in 303a64e
We need to update this to allow users to bring their own schema and define the mapping accordingly.
I think the easiest way to do this would likely be updating the usage of the map file to also take explicit paths, where a schema is defined
ex:
As far as the keys (
<...>
), we will need to figure out portability here as well, since they are hard coded for certain situations (vs defining for a subset of rules). The easiest way would be to likely tap into the integration schema workflow and treat this as a custom schema, where the index pattern parses as normal.A blocker is that the integration validation needs refactoring. To avoid more tech debt, we should consider that first.
A few issues closely related to this that may also be solved are:
The text was updated successfully, but these errors were encountered: