Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Security Solution] Write an RFC for customizing prebuilt rules #171309

Closed
Tracked by #174168
banderror opened this issue Nov 15, 2023 · 4 comments · Fixed by #171856
Closed
Tracked by #174168

[Security Solution] Write an RFC for customizing prebuilt rules #171309

banderror opened this issue Nov 15, 2023 · 4 comments · Fixed by #171856
Assignees
@jpdjere
Labels
8.14 candidate Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.

Comments

@banderror
Copy link
Contributor

banderror commented Nov 15, 2023 •
edited
Loading

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168

Summary

We've been designing and implementing the new workflows of installing and upgrading prebuilt rules, keeping in mind that the upgrade rule workflow should support upgrading those prebuilt rules that the user will customize. The gaps as of today are:

  • While the current implementation of the rule upgrade workflow was made with rule customization in mind, it doesn't have everything to be able to upgrade customized prebuilt rules correctly.
  • We don't have a clear understanding of how the rule customization workflow itself should work: from the technical standpoint, the requirements standpoint, and the UI standpoint.

We need to come up with an understanding of how this all should work and cover the gaps mentioned above.

Todo

Do software design for:

  • The rule customization workflow.
  • The leftover adjustments needed for the rule upgrade workflow to support rule customization.

Document this software design in an RFC. The RFC should answer the following questions:

  • Data model
    • What adjustments to the rule schema and mappings we should make?
    • Any adjustments to other saved objects, such as security-rule?
    • How are we going to implement data migration considering the fact that SO migrations for alerting rules do not work atm and not going to work for rule params in any foreseeable future?
  • API
    • How we're going to support customizing prebuilt rules in the rules CRUD and bulk CRUD endpoints?
    • How we're going to support customizing prebuilt rules through the bulk actions endpoint?
    • Are we going to allow exporting original or customized prebuilt rules?
    • Are we going to allow importing original or customized prebuilt rules?
    • What changes to the upgrade/_review and upgrade/_perform endpoints we should make? In terms of both their API contract and internal implementation.
  • UI
    • How the Rule Editing page is going to work and look for prebuilt rules?
    • Are any additional changes needed on the Rule Details, Rule Management, or MITRE Coverage pages?
    • Are any additional changes needed for the bulk actions UI on the Rule Management page?
    • How the interactive diffs are going to work and look for customized and non-customized prebuilt rules?
  • Rule fields
    • What rule fields will be customizable and for what fields we will disable customization?
    • How are we going to handle various fields in the rule upgrade workflow?
    • What concrete diff algorithms for what rule fields we will need to write?
    • How we're going to handle rule type changes in the API and UI? (related ticket)

Misc:

  • Find a place for permanently storing the RFC document. It could be the Kibana repo, it could be internal dev docs of our team, it could be something else. It should be easy to access and consult with the RFC frequently -- this will be especially important for the engineers who will be working on Milestone 3 in the next few release cycles.

Prior art

For context, please refer to the following previously written artifacts:

RFC

The RFC is being worked on in #171856. We will need to find a place for permanently storing it in some docs and having an easy way for accessing it.
@banderror banderror added Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detection Rule Management Security Detection Rule Management Team Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules 8.12 candidate labels Nov 15, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@jpdjere
Copy link
Contributor

jpdjere commented Nov 15, 2023 •
edited
Loading

RFC draft link: https://docs.google.com/document/d/1uUkcCGo7wgI7CjQauZrk7EE7tqN6OhOMRm-1I10eAEg/edit (internal)

UPDATE: moved to PR

@jpdjere jpdjere mentioned this issue Nov 27, 2023
Merged
This was referenced Jan 3, 2024
Open
Closed
@banderror
Copy link
Contributor Author

banderror commented Apr 2, 2024 •
edited
Loading

@jpdjere Just checking what items from the Todo section have been already addressed in the RFC:

Do software design for:

  • The rule customization workflow.
  • The leftover adjustments needed for the rule upgrade workflow to support rule customization.

Document this software design in an RFC. The RFC should answer the following questions:

  • Data model
    • What adjustments to the rule schema and mappings we should make?
    • Any adjustments to other saved objects, such as security-rule?
    • How are we going to implement data migration considering the fact that SO migrations for alerting rules do not work atm and not going to work for rule params in any foreseeable future?
  • API
    • How we're going to support customizing prebuilt rules in the rules CRUD and bulk CRUD endpoints?
    • How we're going to support customizing prebuilt rules through the bulk actions endpoint?
    • Are we going to allow exporting original or customized prebuilt rules?
    • Are we going to allow importing original or customized prebuilt rules?
    • What changes to the upgrade/_review and upgrade/_perform endpoints we should make? In terms of both their API contract and internal implementation.
      • I think this hasn't been fully answered, but we can specify important details (e.g. how we should change the API contracts) when creating implementation tickets for Milestone 3.
  • UI
    • How the Rule Editing page is going to work and look for prebuilt rules?
    • Are any additional changes needed on the Rule Details, Rule Management, or MITRE Coverage pages?
    • Are any additional changes needed for the bulk actions UI on the Rule Management page?
    • How the interactive diffs are going to work and look for customized and non-customized prebuilt rules?
  • Rule fields
    • What rule fields will be customizable and for what fields we will disable customization?
    • How are we going to handle various fields in the rule upgrade workflow?
      • The RFC suggests several diff algorithms for handling various types of rule fields.
    • What concrete diff algorithms for what rule fields we will need to write?
      • The RFC doesn't propose a concrete diff algorithm for every single rule field, but this should not be needed at this point. We will need to figure this out during the work on Milestone 3.
    • How we're going to handle rule type changes in the API and UI? (related ticket)
      • The RFC doesn't answer this question.

Misc:

  • Find a place for permanently storing the RFC document. It could be the Kibana repo, it could be internal dev docs of our team, it could be something else. It should be easy to access and consult with the RFC frequently -- this will be especially important for the engineers who will be working on Milestone 3 in the next few release cycles.

jpdjere added a commit that referenced this issue Apr 4, 2024
@jpdjere
[Security Solution] RFC for Prebuilt Rules Customization - Milestone 3 (
de25d7c 
#171856)

Resolves: #171309

## Summary

- Creates an RFC for Milestone 3 of the Prebuilt Rules Customization,
including:
  - rule schema changes
  - mappings
  - migration strategy and technical implementation
  - exporting and importing rules
  - schema-related changes needed in endpoints
- calculation of `isCustomized` field on endpoints that update/patch
rules.
- additional changes needed to `/upgrade/_review` and
`/upgrade/_perform` endpoints
  - concrete diff algorithms
  - UI Changes

- Creates
`x-pack/plugins/security_solution/docs/rfcs/detection_response` folder
and adds it to CODEOWNER file, with owners the Detection Engine and Rule
Management teams.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jpdjere jpdjere

Labels
8.14 candidate Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Security Solution] RFC for Prebuilt Rules Customization - Milestone 3 jpdjere/kibana
3 participants
@jpdjere @banderror @elasticmachine