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.

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] Migrate security rules encrypted saved objects to new schema with ruleSource field (BLOCKED) #184113

Open
Tracked by #179907
jpdjere opened this issue May 23, 2024 · 4 comments
Labels
blocked 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

@jpdjere
Copy link
Contributor

jpdjere commented May 23, 2024

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168
Depends on: #180141
Blocked by: #187651, #50216, #183603 (comment)
Needed for: #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:

type RuleParams = {
  immutable: boolean;
}

to

type RuleParams = {
  rule_source: {
    type: 'internal' | 'external'; // <- this can be derived from the existing 'immutable' field
    is_customized: boolean;
  }
}

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 #187651 by us and in #50216 by the ResponseOps team. We can contribute to the design of this mechanism, propose any solutions, or open an RFC.

Useful links

@jpdjere jpdjere added triage_needed 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 labels May 23, 2024
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

@banderror
Copy link
Contributor

Blocked by ResponseOps in #183603

@banderror banderror changed the title [Security Solution] Migrate security rules encrypted saved objects to new schema with ruleSource field [Security Solution] Migrate security rules encrypted saved objects to new schema with ruleSource field (BLOCKED) Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked 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
Development

Successfully merging a pull request may close this issue.

5 participants