[Security Solution] Relax the rules of handling missing base versions of prebuilt rules #210358
Assignees
Labels
8.18 candidate
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
impact:high
Addressing this issue will have a high level of impact on the quality/strength of our product.
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.
v8.18.0
Comments
banderror
added
8.18 candidate
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
A related discussion we've had in the past: #203315 (comment) |
banderror
changed the title
Initially proposed behaviorWhen the base version of a currently installed or imported prebuilt rule is missing among the
|
|
Thanks @banderror for the detailed description and suggestions! I agree with the first 2 suggestions about marking rules with missing base version as customized. I think the behavior of single rule and bulk rule update should be aligned, let's discuss this. |
|
@banderror @approksiu @ARWNightingale This is a summary of the call we had about handling missing base versions and ways to prevent a user from finding themself in that scenario. Upgrading of prebuilt rules with missing base versionsWe will be moving forward with the proposals @banderror made in the comment above with a slight modification: there will be two different logic flows for updating depending on whether the prebuilt rule is customized or not.
These changes will necessitate some modification of the current diff algorithm logic as well as requiring us to pass down the rule object in order to calculate the Incentivizing the users to upgrade their rules when possibleSince we now only have a max of 4 rule versions in a given package, we need to be more proactive with getting users to upgrade their rules, especially if they want to customize them. This will minimize the chances the base version will be missing when users are customizing or upgrading their rules. The ways to do this will be:
Upgrading workflow in the UISome of the changes to the diff algorithm behavior will have an impact on the way the current workflow UI functions. Now, when a rule has a missing base version:
We are changing the "Update rule" button to a "Review rule" button for rules that require review before upgrading (Rules with unsolvable conflicts and customized rules without a base version). This button will just open the rule upgrade flyout instead of actually updating the rule as it does currently. Other rule types will keep the current "Update rule" button. The rule update table itself will also have another sorting column (and related sorting filter button) for:
This allows the user to have more granularity over the ways they upgrade their rules and allow them ways to not let rules that require updating block them from keeping other rules up to date. |
74 tasks
|
@dplumlee Thanks for the write-up, great summary 👍 Just wanna add a few things we talked about:
We also want to add:
Not exactly the same, as we want to let users bulk upgrade prebuilt rules with solvable conflicts (if they choose to do so), but warn them about this operation being potentially dangerous. Currently, users can only bulk upgrade non-conflicting rules from the UI. We won't allow bulk upgrading rules with non-solvable conflicts. |
|
@dplumlee thanks for the write-up, @banderror thanks for additions ++. |
|
Thanks for the detailed summary of the discussions in this ticket. @banderror @dplumlee |
banderror
added a commit
that referenced
this issue
Feb 14, 2025
…part 1 (#211300) **Epic:** #174168 **Partially addresses:** #202068, #202078, #202079 ## Summary We're cleaning up and refactoring our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, in this PR we're consistently: - Changing the file names and test plan titles. - Adding or expanding test plan summaries. - Regenerating tables of contents using the [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) VS Code extension. No "functional" changes have been made to any test plans, such as adding, removing, or updating any scenarios. This refactoring prepares the test plans for being "functionally" changed and improved in follow-up PRs. For example, we're going to cover the logic described in #210358 and address any other gaps in coverage.
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 14, 2025
…part 1 (elastic#211300) **Epic:** elastic#174168 **Partially addresses:** elastic#202068, elastic#202078, elastic#202079 ## Summary We're cleaning up and refactoring our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, in this PR we're consistently: - Changing the file names and test plan titles. - Adding or expanding test plan summaries. - Regenerating tables of contents using the [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) VS Code extension. No "functional" changes have been made to any test plans, such as adding, removing, or updating any scenarios. This refactoring prepares the test plans for being "functionally" changed and improved in follow-up PRs. For example, we're going to cover the logic described in elastic#210358 and address any other gaps in coverage. (cherry picked from commit 9600de4)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 14, 2025
…part 1 (elastic#211300) **Epic:** elastic#174168 **Partially addresses:** elastic#202068, elastic#202078, elastic#202079 ## Summary We're cleaning up and refactoring our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, in this PR we're consistently: - Changing the file names and test plan titles. - Adding or expanding test plan summaries. - Regenerating tables of contents using the [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) VS Code extension. No "functional" changes have been made to any test plans, such as adding, removing, or updating any scenarios. This refactoring prepares the test plans for being "functionally" changed and improved in follow-up PRs. For example, we're going to cover the logic described in elastic#210358 and address any other gaps in coverage. (cherry picked from commit 9600de4)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 14, 2025
…part 1 (elastic#211300) **Epic:** elastic#174168 **Partially addresses:** elastic#202068, elastic#202078, elastic#202079 ## Summary We're cleaning up and refactoring our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, in this PR we're consistently: - Changing the file names and test plan titles. - Adding or expanding test plan summaries. - Regenerating tables of contents using the [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) VS Code extension. No "functional" changes have been made to any test plans, such as adding, removing, or updating any scenarios. This refactoring prepares the test plans for being "functionally" changed and improved in follow-up PRs. For example, we're going to cover the logic described in elastic#210358 and address any other gaps in coverage. (cherry picked from commit 9600de4)
maximpn
pushed a commit
that referenced
this issue
Mar 5, 2025
…211862) ## Summary Partially addresses #210358 Adds all callouts and logic to incentivize users to upgrade their rules asap. These include: - [x] Showing a callout on the Rule Management page - [x] Showing a callout on the Rule Details page - [x] Letting users open the Rule Upgrade flyout from the Rule Details page - [x] Showing a callout on the Rule Editing page - [x] Showing a callout in the Rule Upgrade flyout if rule has missing base version This PR also adds related updates to the rule diff algorithms in order to facilitate an easier upgrade experience when rules have missing base versions. These include: - [x] When the rule has a missing base version and is NOT marked as customized: - [x] We should return all the target fields from the diff algorithm as NO_CONFLICT - [x] When the rule has a missing base version and is marked as customized: - [x] We should attempt to merge all non-functional mergeable fields (any field that doesn't have consequences with how the rule runs e.g. tags) and return them as `SOLVABLE_CONFLICT`. - **NOTE**: When base versions are missing and the rule is customized, we attempt to merge all mergable, non-functional rule fields. These include all fields covered by the scalar diff array (`tags`, `references`, `new_terms_fields`, `threat_index`). We typically also consider multi-line string fields as mergeable but without three versions of the string, we are currently unable to merge the strings together, so we just return target version. - [x] We should pick the target version for all functional mergeable fields (e.g. `index`) and non-mergeable fields and return them as `SOLVABLE_CONFLICT`. ### Screenshots **Callout on Rule details page w/ flyout button**  --- **Upgrade flyout now accessible from rule details page**  --- **Callout on rule editing page**  --- **Dismissible callout on rule management page**  --- **Callout in rule upgrade flyout when rule has missing base version**  ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 5, 2025
…lastic#211862) ## Summary Partially addresses elastic#210358 Adds all callouts and logic to incentivize users to upgrade their rules asap. These include: - [x] Showing a callout on the Rule Management page - [x] Showing a callout on the Rule Details page - [x] Letting users open the Rule Upgrade flyout from the Rule Details page - [x] Showing a callout on the Rule Editing page - [x] Showing a callout in the Rule Upgrade flyout if rule has missing base version This PR also adds related updates to the rule diff algorithms in order to facilitate an easier upgrade experience when rules have missing base versions. These include: - [x] When the rule has a missing base version and is NOT marked as customized: - [x] We should return all the target fields from the diff algorithm as NO_CONFLICT - [x] When the rule has a missing base version and is marked as customized: - [x] We should attempt to merge all non-functional mergeable fields (any field that doesn't have consequences with how the rule runs e.g. tags) and return them as `SOLVABLE_CONFLICT`. - **NOTE**: When base versions are missing and the rule is customized, we attempt to merge all mergable, non-functional rule fields. These include all fields covered by the scalar diff array (`tags`, `references`, `new_terms_fields`, `threat_index`). We typically also consider multi-line string fields as mergeable but without three versions of the string, we are currently unable to merge the strings together, so we just return target version. - [x] We should pick the target version for all functional mergeable fields (e.g. `index`) and non-mergeable fields and return them as `SOLVABLE_CONFLICT`. ### Screenshots **Callout on Rule details page w/ flyout button**  --- **Upgrade flyout now accessible from rule details page**  --- **Callout on rule editing page**  --- **Dismissible callout on rule management page**  --- **Callout in rule upgrade flyout when rule has missing base version**  ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 461787b)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 5, 2025
…lastic#211862) ## Summary Partially addresses elastic#210358 Adds all callouts and logic to incentivize users to upgrade their rules asap. These include: - [x] Showing a callout on the Rule Management page - [x] Showing a callout on the Rule Details page - [x] Letting users open the Rule Upgrade flyout from the Rule Details page - [x] Showing a callout on the Rule Editing page - [x] Showing a callout in the Rule Upgrade flyout if rule has missing base version This PR also adds related updates to the rule diff algorithms in order to facilitate an easier upgrade experience when rules have missing base versions. These include: - [x] When the rule has a missing base version and is NOT marked as customized: - [x] We should return all the target fields from the diff algorithm as NO_CONFLICT - [x] When the rule has a missing base version and is marked as customized: - [x] We should attempt to merge all non-functional mergeable fields (any field that doesn't have consequences with how the rule runs e.g. tags) and return them as `SOLVABLE_CONFLICT`. - **NOTE**: When base versions are missing and the rule is customized, we attempt to merge all mergable, non-functional rule fields. These include all fields covered by the scalar diff array (`tags`, `references`, `new_terms_fields`, `threat_index`). We typically also consider multi-line string fields as mergeable but without three versions of the string, we are currently unable to merge the strings together, so we just return target version. - [x] We should pick the target version for all functional mergeable fields (e.g. `index`) and non-mergeable fields and return them as `SOLVABLE_CONFLICT`. ### Screenshots **Callout on Rule details page w/ flyout button**  --- **Upgrade flyout now accessible from rule details page**  --- **Callout on rule editing page**  --- **Dismissible callout on rule management page**  --- **Callout in rule upgrade flyout when rule has missing base version**  ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 461787b)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 5, 2025
…lastic#211862) ## Summary Partially addresses elastic#210358 Adds all callouts and logic to incentivize users to upgrade their rules asap. These include: - [x] Showing a callout on the Rule Management page - [x] Showing a callout on the Rule Details page - [x] Letting users open the Rule Upgrade flyout from the Rule Details page - [x] Showing a callout on the Rule Editing page - [x] Showing a callout in the Rule Upgrade flyout if rule has missing base version This PR also adds related updates to the rule diff algorithms in order to facilitate an easier upgrade experience when rules have missing base versions. These include: - [x] When the rule has a missing base version and is NOT marked as customized: - [x] We should return all the target fields from the diff algorithm as NO_CONFLICT - [x] When the rule has a missing base version and is marked as customized: - [x] We should attempt to merge all non-functional mergeable fields (any field that doesn't have consequences with how the rule runs e.g. tags) and return them as `SOLVABLE_CONFLICT`. - **NOTE**: When base versions are missing and the rule is customized, we attempt to merge all mergable, non-functional rule fields. These include all fields covered by the scalar diff array (`tags`, `references`, `new_terms_fields`, `threat_index`). We typically also consider multi-line string fields as mergeable but without three versions of the string, we are currently unable to merge the strings together, so we just return target version. - [x] We should pick the target version for all functional mergeable fields (e.g. `index`) and non-mergeable fields and return them as `SOLVABLE_CONFLICT`. ### Screenshots **Callout on Rule details page w/ flyout button**  --- **Upgrade flyout now accessible from rule details page**  --- **Callout on rule editing page**  --- **Dismissible callout on rule management page**  --- **Callout in rule upgrade flyout when rule has missing base version**  ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 461787b)
maximpn
added a commit
that referenced
this issue
Mar 6, 2025
…213285) **Partially addresses:** #210358 ## Summary This PR implements functionality allowing users to bulk upgrade rules with solvable conflicts. ## Details The main focus of this PR is to allow users to bulk upgrade rules with solvable conflicts. To achieve that the following was done - `upgrade/_perform` dry run functionality was extended to take into account rule upgrade specifiers with resolved value - `upgrade/_perform`'s `on_conflict` param was extended with `UPGRADE_SOLVABLE` to allow bulk upgrading rules with solvable conflicts - UI logic updated accordingly to display rule upgrade modal when users have to make a choice to upgrade only rules without conflicts or upgrade also rules with solvable conflicts - conflict state badges were added to the rule upgrade table It includes changes from #213027 with some modifications. ## Screenshots <img width="1723" alt="Screenshot 2025-03-06 at 12 13 04" src="https://github.com/user-attachments/assets/b786e813-268d-49a2-80cc-81fa95d14e85" /> <img width="1724" alt="Screenshot 2025-03-06 at 12 13 30" src="https://github.com/user-attachments/assets/e5e38bd9-78a3-4026-a7ea-892bd7153938" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 13 51" src="https://github.com/user-attachments/assets/d58872c3-f197-49ad-b4f3-5f45fb1efac2" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 14 04" src="https://github.com/user-attachments/assets/667a6ab2-2fdb-430d-9589-1c4a6e5cdc8b" /> <img width="1722" alt="Screenshot 2025-03-06 at 12 14 17" src="https://github.com/user-attachments/assets/07f4cffe-4398-4fd5-8350-a3a2978d7dcd" />
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 6, 2025
…lastic#213285) **Partially addresses:** elastic#210358 ## Summary This PR implements functionality allowing users to bulk upgrade rules with solvable conflicts. ## Details The main focus of this PR is to allow users to bulk upgrade rules with solvable conflicts. To achieve that the following was done - `upgrade/_perform` dry run functionality was extended to take into account rule upgrade specifiers with resolved value - `upgrade/_perform`'s `on_conflict` param was extended with `UPGRADE_SOLVABLE` to allow bulk upgrading rules with solvable conflicts - UI logic updated accordingly to display rule upgrade modal when users have to make a choice to upgrade only rules without conflicts or upgrade also rules with solvable conflicts - conflict state badges were added to the rule upgrade table It includes changes from elastic#213027 with some modifications. ## Screenshots <img width="1723" alt="Screenshot 2025-03-06 at 12 13 04" src="https://github.com/user-attachments/assets/b786e813-268d-49a2-80cc-81fa95d14e85" /> <img width="1724" alt="Screenshot 2025-03-06 at 12 13 30" src="https://github.com/user-attachments/assets/e5e38bd9-78a3-4026-a7ea-892bd7153938" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 13 51" src="https://github.com/user-attachments/assets/d58872c3-f197-49ad-b4f3-5f45fb1efac2" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 14 04" src="https://github.com/user-attachments/assets/667a6ab2-2fdb-430d-9589-1c4a6e5cdc8b" /> <img width="1722" alt="Screenshot 2025-03-06 at 12 14 17" src="https://github.com/user-attachments/assets/07f4cffe-4398-4fd5-8350-a3a2978d7dcd" /> (cherry picked from commit f2077db)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 6, 2025
…lastic#213285) **Partially addresses:** elastic#210358 ## Summary This PR implements functionality allowing users to bulk upgrade rules with solvable conflicts. ## Details The main focus of this PR is to allow users to bulk upgrade rules with solvable conflicts. To achieve that the following was done - `upgrade/_perform` dry run functionality was extended to take into account rule upgrade specifiers with resolved value - `upgrade/_perform`'s `on_conflict` param was extended with `UPGRADE_SOLVABLE` to allow bulk upgrading rules with solvable conflicts - UI logic updated accordingly to display rule upgrade modal when users have to make a choice to upgrade only rules without conflicts or upgrade also rules with solvable conflicts - conflict state badges were added to the rule upgrade table It includes changes from elastic#213027 with some modifications. ## Screenshots <img width="1723" alt="Screenshot 2025-03-06 at 12 13 04" src="https://github.com/user-attachments/assets/b786e813-268d-49a2-80cc-81fa95d14e85" /> <img width="1724" alt="Screenshot 2025-03-06 at 12 13 30" src="https://github.com/user-attachments/assets/e5e38bd9-78a3-4026-a7ea-892bd7153938" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 13 51" src="https://github.com/user-attachments/assets/d58872c3-f197-49ad-b4f3-5f45fb1efac2" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 14 04" src="https://github.com/user-attachments/assets/667a6ab2-2fdb-430d-9589-1c4a6e5cdc8b" /> <img width="1722" alt="Screenshot 2025-03-06 at 12 14 17" src="https://github.com/user-attachments/assets/07f4cffe-4398-4fd5-8350-a3a2978d7dcd" /> (cherry picked from commit f2077db)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 6, 2025
…lastic#213285) **Partially addresses:** elastic#210358 ## Summary This PR implements functionality allowing users to bulk upgrade rules with solvable conflicts. ## Details The main focus of this PR is to allow users to bulk upgrade rules with solvable conflicts. To achieve that the following was done - `upgrade/_perform` dry run functionality was extended to take into account rule upgrade specifiers with resolved value - `upgrade/_perform`'s `on_conflict` param was extended with `UPGRADE_SOLVABLE` to allow bulk upgrading rules with solvable conflicts - UI logic updated accordingly to display rule upgrade modal when users have to make a choice to upgrade only rules without conflicts or upgrade also rules with solvable conflicts - conflict state badges were added to the rule upgrade table It includes changes from elastic#213027 with some modifications. ## Screenshots <img width="1723" alt="Screenshot 2025-03-06 at 12 13 04" src="https://github.com/user-attachments/assets/b786e813-268d-49a2-80cc-81fa95d14e85" /> <img width="1724" alt="Screenshot 2025-03-06 at 12 13 30" src="https://github.com/user-attachments/assets/e5e38bd9-78a3-4026-a7ea-892bd7153938" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 13 51" src="https://github.com/user-attachments/assets/d58872c3-f197-49ad-b4f3-5f45fb1efac2" /> <img width="1723" alt="Screenshot 2025-03-06 at 12 14 04" src="https://github.com/user-attachments/assets/667a6ab2-2fdb-430d-9589-1c4a6e5cdc8b" /> <img width="1722" alt="Screenshot 2025-03-06 at 12 14 17" src="https://github.com/user-attachments/assets/07f4cffe-4398-4fd5-8350-a3a2978d7dcd" /> (cherry picked from commit f2077db)
maximpn
pushed a commit
that referenced
this issue
Mar 6, 2025
…omized calculation (#213250) **Partially addresses: #210358 ## Summary ### Editing of prebuilt rules with missing base versions **When the base version** of a currently installed prebuilt rule **is missing** among the `security-rule` asset saved objects, and the user edits this rule: - We should mark the rule as customized, only if the new rule settings are different from the current rule settings. - For example, adding a new tag should mark the rule as customized. Then, if the user removes this tag, the rule should remain to be marked as customized. This matches the current behavior. - However, if the user saves the rule without making any changes to it, it should keep its `is_customized` field as is. This is different from the current behavior. ### Importing of prebuilt rules with missing base versions **When the base version** of a prebuilt rule that is being imported **is missing** among the `security-rule` asset saved objects, and the user imports this rule: - If this rule is not installed, it should be created with `is_customized` field set to `false`. - If this rule is already installed, it should be updated. - Its `is_customized` field should be set to `true` if the rule from the import payload is not equal to the installed rule. - Its `is_customized` field should be be kept unchanged (`false` or `true`) if the rule from the import payload is equal to the installed rule.
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 6, 2025
…omized calculation (elastic#213250) **Partially addresses: elastic#210358 ## Summary ### Editing of prebuilt rules with missing base versions **When the base version** of a currently installed prebuilt rule **is missing** among the `security-rule` asset saved objects, and the user edits this rule: - We should mark the rule as customized, only if the new rule settings are different from the current rule settings. - For example, adding a new tag should mark the rule as customized. Then, if the user removes this tag, the rule should remain to be marked as customized. This matches the current behavior. - However, if the user saves the rule without making any changes to it, it should keep its `is_customized` field as is. This is different from the current behavior. ### Importing of prebuilt rules with missing base versions **When the base version** of a prebuilt rule that is being imported **is missing** among the `security-rule` asset saved objects, and the user imports this rule: - If this rule is not installed, it should be created with `is_customized` field set to `false`. - If this rule is already installed, it should be updated. - Its `is_customized` field should be set to `true` if the rule from the import payload is not equal to the installed rule. - Its `is_customized` field should be be kept unchanged (`false` or `true`) if the rule from the import payload is equal to the installed rule. (cherry picked from commit 87e7cd9)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 6, 2025
…omized calculation (elastic#213250) **Partially addresses: elastic#210358 ## Summary ### Editing of prebuilt rules with missing base versions **When the base version** of a currently installed prebuilt rule **is missing** among the `security-rule` asset saved objects, and the user edits this rule: - We should mark the rule as customized, only if the new rule settings are different from the current rule settings. - For example, adding a new tag should mark the rule as customized. Then, if the user removes this tag, the rule should remain to be marked as customized. This matches the current behavior. - However, if the user saves the rule without making any changes to it, it should keep its `is_customized` field as is. This is different from the current behavior. ### Importing of prebuilt rules with missing base versions **When the base version** of a prebuilt rule that is being imported **is missing** among the `security-rule` asset saved objects, and the user imports this rule: - If this rule is not installed, it should be created with `is_customized` field set to `false`. - If this rule is already installed, it should be updated. - Its `is_customized` field should be set to `true` if the rule from the import payload is not equal to the installed rule. - Its `is_customized` field should be be kept unchanged (`false` or `true`) if the rule from the import payload is equal to the installed rule. (cherry picked from commit 87e7cd9)
banderror
pushed a commit
to banderror/kibana
that referenced
this issue
Mar 6, 2025
…omized calculation (elastic#213250) **Partially addresses: elastic#210358 ## Summary ### Editing of prebuilt rules with missing base versions **When the base version** of a currently installed prebuilt rule **is missing** among the `security-rule` asset saved objects, and the user edits this rule: - We should mark the rule as customized, only if the new rule settings are different from the current rule settings. - For example, adding a new tag should mark the rule as customized. Then, if the user removes this tag, the rule should remain to be marked as customized. This matches the current behavior. - However, if the user saves the rule without making any changes to it, it should keep its `is_customized` field as is. This is different from the current behavior. ### Importing of prebuilt rules with missing base versions **When the base version** of a prebuilt rule that is being imported **is missing** among the `security-rule` asset saved objects, and the user imports this rule: - If this rule is not installed, it should be created with `is_customized` field set to `false`. - If this rule is already installed, it should be updated. - Its `is_customized` field should be set to `true` if the rule from the import payload is not equal to the installed rule. - Its `is_customized` field should be be kept unchanged (`false` or `true`) if the rule from the import payload is equal to the installed rule. (cherry picked from commit 87e7cd9)
banderror
added a commit
that referenced
this issue
Mar 10, 2025
…#212817) **Epic:** #174168 **Partially addresses:** #202078, #210358 ## Summary We started to rework and introduce functional changes to our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, this PR: - Creates a new test plan for prebuilt rule upgrade notifications on the Rule Management, Rule Details, and Rule Editing pages. The filename is `prebuilt_rule_upgrade_notifications.md`. - Extracts the existing scenarios for upgrade notifications on the Rule Management page from `prebuilt_rule_upgrade_without_preview.md` to `prebuilt_rule_upgrade_notifications.md`. Also, updates them according to the most recent UI behavior. - Adds new scenarios for upgrade notifications on the Rule Details page to `prebuilt_rule_upgrade_notifications.md`. - Adds new scenarios for upgrade notifications on the Rule Editing page to `prebuilt_rule_upgrade_notifications.md`. The new test plan should be in line with the changes discussed in #210358.
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 10, 2025
…elastic#212817) **Epic:** elastic#174168 **Partially addresses:** elastic#202078, elastic#210358 ## Summary We started to rework and introduce functional changes to our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, this PR: - Creates a new test plan for prebuilt rule upgrade notifications on the Rule Management, Rule Details, and Rule Editing pages. The filename is `prebuilt_rule_upgrade_notifications.md`. - Extracts the existing scenarios for upgrade notifications on the Rule Management page from `prebuilt_rule_upgrade_without_preview.md` to `prebuilt_rule_upgrade_notifications.md`. Also, updates them according to the most recent UI behavior. - Adds new scenarios for upgrade notifications on the Rule Details page to `prebuilt_rule_upgrade_notifications.md`. - Adds new scenarios for upgrade notifications on the Rule Editing page to `prebuilt_rule_upgrade_notifications.md`. The new test plan should be in line with the changes discussed in elastic#210358. (cherry picked from commit da0480b)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 10, 2025
…elastic#212817) **Epic:** elastic#174168 **Partially addresses:** elastic#202078, elastic#210358 ## Summary We started to rework and introduce functional changes to our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, this PR: - Creates a new test plan for prebuilt rule upgrade notifications on the Rule Management, Rule Details, and Rule Editing pages. The filename is `prebuilt_rule_upgrade_notifications.md`. - Extracts the existing scenarios for upgrade notifications on the Rule Management page from `prebuilt_rule_upgrade_without_preview.md` to `prebuilt_rule_upgrade_notifications.md`. Also, updates them according to the most recent UI behavior. - Adds new scenarios for upgrade notifications on the Rule Details page to `prebuilt_rule_upgrade_notifications.md`. - Adds new scenarios for upgrade notifications on the Rule Editing page to `prebuilt_rule_upgrade_notifications.md`. The new test plan should be in line with the changes discussed in elastic#210358. (cherry picked from commit da0480b)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Mar 10, 2025
…elastic#212817) **Epic:** elastic#174168 **Partially addresses:** elastic#202078, elastic#210358 ## Summary We started to rework and introduce functional changes to our existing test plans for prebuilt rule customization, upgrade, and export/import workflows. Specifically, this PR: - Creates a new test plan for prebuilt rule upgrade notifications on the Rule Management, Rule Details, and Rule Editing pages. The filename is `prebuilt_rule_upgrade_notifications.md`. - Extracts the existing scenarios for upgrade notifications on the Rule Management page from `prebuilt_rule_upgrade_without_preview.md` to `prebuilt_rule_upgrade_notifications.md`. Also, updates them according to the most recent UI behavior. - Adds new scenarios for upgrade notifications on the Rule Details page to `prebuilt_rule_upgrade_notifications.md`. - Adds new scenarios for upgrade notifications on the Rule Editing page to `prebuilt_rule_upgrade_notifications.md`. The new test plan should be in line with the changes discussed in elastic#210358. (cherry picked from commit da0480b)
kibanamachine
added a commit
that referenced
this issue
Mar 10, 2025
…ations (#212817) (#213716) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)](#212817) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Georgii Gorbachev","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-03-10T11:50:12Z","message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","test-plan","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Security Solution] Test plan for prebuilt rule upgrade notifications","number":212817,"url":"https://github.com/elastic/kibana/pull/212817","mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/212817","number":212817,"mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Georgii Gorbachev <[email protected]>
kibanamachine
added a commit
that referenced
this issue
Mar 10, 2025
…ations (#212817) (#213717) # Backport This will backport the following commits from `main` to `9.0`: - [[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)](#212817) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Georgii Gorbachev","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-03-10T11:50:12Z","message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","test-plan","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Security Solution] Test plan for prebuilt rule upgrade notifications","number":212817,"url":"https://github.com/elastic/kibana/pull/212817","mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/212817","number":212817,"mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Georgii Gorbachev <[email protected]>
kibanamachine
added a commit
that referenced
this issue
Mar 10, 2025
…cations (#212817) (#213715) # Backport This will backport the following commits from `main` to `8.18`: - [[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)](#212817) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Georgii Gorbachev","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-03-10T11:50:12Z","message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","test-plan","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Security Solution] Test plan for prebuilt rule upgrade notifications","number":212817,"url":"https://github.com/elastic/kibana/pull/212817","mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/212817","number":212817,"mergeCommit":{"message":"[Security Solution] Test plan for prebuilt rule upgrade notifications (#212817)\n\n**Epic:** https://github.com/elastic/kibana/issues/174168\n**Partially addresses:**\nhttps://github.com//issues/202078,\nhttps://github.com//issues/210358\n\n## Summary\n\nWe started to rework and introduce functional changes to our existing\ntest plans for prebuilt rule customization, upgrade, and export/import\nworkflows.\n\nSpecifically, this PR:\n\n- Creates a new test plan for prebuilt rule upgrade notifications on the\nRule Management, Rule Details, and Rule Editing pages. The filename is\n`prebuilt_rule_upgrade_notifications.md`.\n- Extracts the existing scenarios for upgrade notifications on the Rule\nManagement page from `prebuilt_rule_upgrade_without_preview.md` to\n`prebuilt_rule_upgrade_notifications.md`. Also, updates them according\nto the most recent UI behavior.\n- Adds new scenarios for upgrade notifications on the Rule Details page\nto `prebuilt_rule_upgrade_notifications.md`.\n- Adds new scenarios for upgrade notifications on the Rule Editing page\nto `prebuilt_rule_upgrade_notifications.md`.\n\nThe new test plan should be in line with the changes discussed in\nhttps://github.com//issues/210358.","sha":"da0480bde922b82741240a2aeeb1c33bd2497c66"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Georgii Gorbachev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Epic: #174168
Caused by: https://github.com/elastic/security-team/issues/11822, elastic/detection-rules#4150 (comment), https://github.com/elastic/ia-trade-team/issues/552
Related to: #201500
Summary
Since last summer of 2024, we've had multiple incidents in Cloud where Kibana would crash with an OOM because of the installation of the package with prebuilt rules. We've done a lot of work to optimize package installation logic in Fleet and recently re-added all historical rule versions to the package. However, the most recent incident has shown that this wasn't enough. As a quick mitigation, we again reduced the package size to having at most 4 assets per rule in package
v8.17.5. This change is final and we're not going to ever increase this limit.The fact that we're not gonna have many historical rule versions in the package means that the situation of not having the base version for a rule will be pretty normal. It won't be an edge case, as we originally planned. This forces us to revisit our initial reasoning about handling missing base versions during customization, upgrading, and importing prebuilt rules.
Current behavior
When the base version of a currently installed or imported prebuilt rule is missing among the
security-ruleasset saved objects:Screen.Recording.2025-02-11.at.15.54.35.mov
Proposed behavior
Editing of prebuilt rules with missing base versions
When the base version of a currently installed prebuilt rule is missing among the
security-ruleasset saved objects, and the user edits this rule:is_customizedfield as is. This is different from the current behavior.Importing of prebuilt rules with missing base versions
When the base version of a prebuilt rule that is being imported is missing among the
security-ruleasset saved objects, and the user imports this rule:is_customizedfield set tofalse.is_customizedfield should be set totrueif the rule from the import payload is not equal to the installed rule.is_customizedfield should be be kept unchanged (falseortrue) if the rule from the import payload is equal to the installed rule.Upgrading of prebuilt rules with missing base versions
When the base version of a currently installed prebuilt rule is missing among the
security-ruleasset saved objects, and there is a new version available for this rule, and the user tries to upgrade this rule to the latest version, there will be two different logic flows for upgrading depending on whether the prebuilt rule is customized or not.NO_CONFLICT(a change from the current behavior)tags) and return them asSOLVABLE_CONFLICT.index) and non-mergeable fields and return them asSOLVABLE_CONFLICT.These changes will necessitate some modification of the current diff algorithm logic as well as requiring us to pass down the rule object in order to calculate the
is_customizedbranching.There will be an impact on the current rule upgrade UI. Now, when a rule has a missing base version:
SOLVABLE_CONFLICTif the rule is marked as customized andNO_CONFLICTif it isn't customized.Also, we will add a new sorting column and a new filter to the Rule Upgrade table for filtering and sorting:
This allows the user to have more granularity over the ways they upgrade their rules and allow them ways to not let rules that require updating block them from keeping other rules up to date.
Incentivizing the users to upgrade their rules when possible
Since we now only have a max of 4 rule versions in a given package, we need to be more proactive with getting users to upgrade their rules, especially if they want to customize them. This will minimize the chances the base version will be missing when users are customizing or upgrading their rules. The ways to do this will be:
upgrade/_reviewendpoint to take an id or array of ids so that we're not calling the entire endpoint whenever we need to see if a rule has an upgrade. (cc @xcrzx)upgrade/_reviewendpointThe text was updated successfully, but these errors were encountered: