-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution] Handle rule deprecations within Prebuilt Rule upgrade workflow #118942
Comments
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Hey @Mikaayenson, is there a reason why you removed the labels? |
Glitch in the matrix. (I think when I pruned other issues I made a mistake and removed these) although I don't recall seeing this. I've added them back. |
Ok cool, thanks for getting them back 🙂 |
Was just discussing this with @terrancedejesus as they've been seeing some deprecated rules being reported in telemetry multiple version past their deprecation (since they'll just keep rolling forward with each version upgrade). So it would be nice to get some part of this worked so users can know within the app that they shouldn't be using these rules anymore (whether that's a |
Thanks for sharing @spong. To put some perspective on this from Telemetry, the Unusual Process Execution - Temp detection rule was deprecated prior to the release of 8.4. However, in the last 60 days, we have ~192 clusters reporting security alerts for this rule with ~4m security alerts in total across these client stacks. 75% of these ~4m security alerts are from stacks where this rule would not exist if removed because it was deprecated. |
Hi All, I think this initial design could belong here. |
A current limitation of the Prebuilt Rule upgrade workflow (whether loading from filesystem or the Fleet
Prebuilt Security Detection Rule
integration) is that we don't support the deprecation or removal of prebuilt rules. As a result, when a rule is deprecated, has its'id
changed, or is flat out removed from future distributions, previous versions of the installed rule will stick around whether or not they were enabled by the user, and with no indication of why or what rule may have superseded it. This issue is for discussing a deprecation workflow, and what functionality may need to be added in support of it (deprecatedVersion
/deprecatedMessage
fields, delete-on-update functionality for the pre-packaged rules route, etc).Note: This information can usually be found either in the Prebuilt Rule Reference documentation, or directly within the detection-rules repo, but is not accessible from within the Security Solution application at the moment.
The text was updated successfully, but these errors were encountered: