Open banderror opened 1 month ago
Pinging @elastic/security-detections-response (Team:Detections and Resp)
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)
Pinging @elastic/security-solution (Team: SecuritySolution)
@banderror thanks for writing this up!
I think there are a lot of outstanding questions here, but a few high-level ones that come to mind:
file
plugin (which cases
uses for file upload), but that needs to be verified.The above questions have been discussed with @rylnd and @jpdjere.
Epics: https://github.com/elastic/security-team/issues/1974 (internal), https://github.com/elastic/kibana/issues/174168
Summary
With https://github.com/elastic/kibana/issues/180168, we're going to introduce additional logic to the import endpoint for calculating the rule source object. Some of this logic will be run once for a given import call, some of it will be run multiple times for each rule being imported. Some of it can be IO-heavy (installing the package, fetching historical rule versions and ids), some of it can be CPU-heavy (calculating a diff for each rule).
Based on our prior observations, the rules import endpoint times out when importing a large number of rules. I think the number can be around 2-3k rules. Now, with the additional logic, the endpoint is going to be even heavier and can start timing out with a lower number of rules in the ndjson payload.
In order to address this issue, our idea was to add an asynchronous rules import API. This API:
We also need to figure out how switching to this async API can affect the import UI on the Rule Management page.