-
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] Can't overwrite actions to [] when importing a rule with "Overwrite existing detection rules with conflicting Rule ID" #118166
Comments
Pinging @elastic/security-solution (Team: SecuritySolution) |
@yctercero @jethr0null can you please take a look at this issue and decide which should be the expected behaviour as well as in which version should be addressed? |
To summarize, the the two user scenarios considered here are:
For context, I believe that right now, the following is true:
I would assume that a rule with |
Thanks for the summary @yctercero. I feel like I might be missing some context here. Can you help me to understand why option 2 is being proposed? What would the argument be for changing the existing behavior? |
I think the second scenario is being considered here because that would match the behavior for the other params. And I think I'm trying to understand what the user expectation would be here. If I select |
@jethr0null I could see us taking this as a feature request where a user can specify whether to |
Ignore the PR linked right above (#118221 ) |
Related issue - #93342 |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
@peluja1012 I think this is now more under the rules domain as it's a broader question about the rule override behavior? |
Yeah, I think we should replace the PATCH semantics with the UPDATE semantics, as @yctercero noted in #118166 (comment) and @marshallmain noted in #93342 |
…orting rules (#176166) **Fixes: #93342 **Fixes: #118166 ## Summary This PR fixes not complete existing rule overwrite when importing rules. ## Details When importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule. The fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause. ### Checklist - [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 - [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167))
…orting rules (elastic#176166) **Fixes: elastic#93342 **Fixes: elastic#118166 ## Summary This PR fixes not complete existing rule overwrite when importing rules. ## Details When importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule. The fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause. ### Checklist - [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 - [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167)) (cherry picked from commit 53aaab4)
…hen importing rules (#176166) (#177196) # Backport This will backport the following commits from `main` to `8.13`: - [[Security Solution] Fix not complete existing rule overwrite when importing rules (#176166)](#176166) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Maxim Palenov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-02-19T13:35:32Z","message":"[Security Solution] Fix not complete existing rule overwrite when importing rules (#176166)\n\n**Fixes: https://github.com/elastic/kibana/issues/93342**\r\n**Fixes: https://github.com/elastic/kibana/issues/118166**\r\n\r\n## Summary\r\n\r\nThis PR fixes not complete existing rule overwrite when importing rules.\r\n\r\n## Details\r\n\r\nWhen importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule.\r\n\r\nThe fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause.\r\n\r\n### Checklist\r\n\r\n- [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\r\n- [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167))","sha":"53aaab47322fd15ad232d71a1749fd2df8a5dde4","branchLabelMapping":{"^v8.14.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","impact:medium","Team:Detections and Resp","Team: SecuritySolution","Feature:Rule Management","Team:Detection Rule Management","Feature:Rule Import/Export","v8.13.0","v8.12.2","v8.14.0"],"title":"[Security Solution] Fix not complete existing rule overwrite when importing rules","number":176166,"url":"https://github.com/elastic/kibana/pull/176166","mergeCommit":{"message":"[Security Solution] Fix not complete existing rule overwrite when importing rules (#176166)\n\n**Fixes: https://github.com/elastic/kibana/issues/93342**\r\n**Fixes: https://github.com/elastic/kibana/issues/118166**\r\n\r\n## Summary\r\n\r\nThis PR fixes not complete existing rule overwrite when importing rules.\r\n\r\n## Details\r\n\r\nWhen importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule.\r\n\r\nThe fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause.\r\n\r\n### Checklist\r\n\r\n- [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\r\n- [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167))","sha":"53aaab47322fd15ad232d71a1749fd2df8a5dde4"}},"sourceBranch":"main","suggestedTargetBranches":["8.13","8.12"],"targetPullRequestStates":[{"branch":"8.13","label":"v8.13.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.12","label":"v8.12.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.14.0","branchLabelMappingKey":"^v8.14.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/176166","number":176166,"mergeCommit":{"message":"[Security Solution] Fix not complete existing rule overwrite when importing rules (#176166)\n\n**Fixes: https://github.com/elastic/kibana/issues/93342**\r\n**Fixes: https://github.com/elastic/kibana/issues/118166**\r\n\r\n## Summary\r\n\r\nThis PR fixes not complete existing rule overwrite when importing rules.\r\n\r\n## Details\r\n\r\nWhen importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule.\r\n\r\nThe fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause.\r\n\r\n### Checklist\r\n\r\n- [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\r\n- [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167))","sha":"53aaab47322fd15ad232d71a1749fd2df8a5dde4"}}]}] BACKPORT--> Co-authored-by: Maxim Palenov <[email protected]>
…orting rules (elastic#176166) **Fixes: elastic#93342 **Fixes: elastic#118166 ## Summary This PR fixes not complete existing rule overwrite when importing rules. ## Details When importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule. The fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause. ### Checklist - [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 - [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167)) (cherry picked from commit 53aaab4) # Conflicts: # x-pack/test/detection_engine_api_integration/basic/tests/export_rules.ts # x-pack/test/detection_engine_api_integration/basic/tests/import_rules.ts # x-pack/test/detection_engine_api_integration/basic/tests/import_rules_with_overwrite.ts # x-pack/test/detection_engine_api_integration/security_and_spaces/group1/export_rules.ts # x-pack/test/detection_engine_api_integration/security_and_spaces/group10/import_connectors.ts # x-pack/test/detection_engine_api_integration/security_and_spaces/group10/import_export_rules.ts # x-pack/test/detection_engine_api_integration/security_and_spaces/group10/import_rules.ts # x-pack/test/detection_engine_api_integration/security_and_spaces/group10/import_rules_with_overwrite.ts # x-pack/test/detection_engine_api_integration/utils/get_rules_as_ndjson.ts # x-pack/test/security_solution_api_integration/test_suites/detections_response/default_license/alerts/assignments/index.ts # x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/rule_import_export/trial_license_complete_tier/export_rules.ts # x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/rule_import_export/trial_license_complete_tier/import_rules_ess.ts # x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/rule_import_export/trial_license_complete_tier/index.ts # x-pack/test/security_solution_api_integration/test_suites/detections_response/utils/rules/index.ts
…orting rules (elastic#176166) **Fixes: elastic#93342 **Fixes: elastic#118166 ## Summary This PR fixes not complete existing rule overwrite when importing rules. ## Details When importing a rule and attempting to overwrite an existing rule, if the new rule does not define a field that the existing rule did define then the newly imported rule will include the field from the existing rule. This can cause issues if we want to overwrite a rule with a rule of a different type, e.g. going from saved_query to query we would provide a new rule that doesn't have a saved_id but since saved_id was defined on the old saved_query rule it will be included in the new query rule. The fix simply swaps out the `patchRules()` for `updateRules()`. Patching rules preserves previous field values if an incoming update doesn't have such fields while updating doesn't do that. The diff in `import_rules_utils.test.ts` looks bigger due to removing unnecessary `else` clause. ### Checklist - [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 - [x] Ran successfully in Flaky test runner ([basic/essentials license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5166) and [trial/complete tier license FTR tests](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5167))
Describe the bug
Actions are still exist when import the rule by selecting "Overwrite existing detection rules with conflicting Rule ID" after upgrade the build from 7.15 to 7.16.0
UPD: see for the details #118166 (comment)
Build Details:
Version: 7.16.0 BC3
Build: 45816
COMMIT: acaa761
Browser Details:
N/A
Preconditions
Steps to Reproduce
Actual Result
Actions are still exist when import the rule by selecting "Overwrite existing detection rules with conflicting Rule ID" after upgrade the build from 7.15 to 7.16.0
Expected Result
Actions should not be exist when import the rule by selecting "Overwrite existing detection rules with conflicting Rule ID" after upgrade the build from 7.15 to 7.16.0
What's Working
What's Not Working
Screen-Shot
7.15.0_rule.zip
import_rule.mp4
The text was updated successfully, but these errors were encountered: