Open jpdjere opened 4 months ago
Pinging @elastic/security-detections-response (Team:Detections and Resp)
Pinging @elastic/security-solution (Team: SecuritySolution)
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)
Blocked by ResponseOps in https://github.com/elastic/kibana/pull/183603
Epics: https://github.com/elastic/security-team/issues/1974 (internal), https://github.com/elastic/kibana/issues/174168 Depends on: https://github.com/elastic/kibana/issues/180141 Blocked by: https://github.com/elastic/kibana/issues/187651, https://github.com/elastic/kibana/issues/50216, https://github.com/elastic/kibana/pull/183603#issuecomment-2151513105 Needed for: https://github.com/elastic/kibana/issues/180126
Summary
Use a (currently non-existing) rule migration mechanism provided by the Alerting Framework to migrate detection rules to a new schema that contains the new
ruleSource
field.In Security Solution, as part of the rule customization epic, we need to change the rule parameters from:
to
Semantically, the fields have similar meanings; both the old field and the new field will be used to distinguish prebuilt detection rules from custom rules created by users. However, the new field allows for more flexibility and enables us to build rule customization features on top of it.
Proposed solution
Initially, we proposed to use the Model Version API for this migration in a POC, but the proposal wasn't accepted by the ResponseOps team.
At the moment, we don't have an idea what this solution should be. We depend on the ResponseOps team here, the problem is being tracked in https://github.com/elastic/kibana/issues/187651 by us and in https://github.com/elastic/kibana/issues/50216 by the ResponseOps team. We can contribute to the design of this mechanism, propose any solutions, or open an RFC.
Useful links