mirror of
https://github.com/elastic/kibana.git
synced 2025-04-22 17:04:01 -04:00
f60eaef1fc
# Backport This will backport the following commits from `main` to `8.16`: - [[Security Solution][Detection Engine] Fix importing rules with multiple types of exception lists (#198868)](https://github.com/elastic/kibana/pull/198868) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Marshall Main","email":"55718608+marshallmain@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-11-13T20:01:18Z","message":"[Security Solution][Detection Engine] Fix importing rules with multiple types of exception lists (#198868)\n\n## Summary\r\n\r\nFixes https://github.com/elastic/kibana/issues/198461\r\n\r\nWhen a rule import file has both single-namespace and namespace-agnostic\r\nexception lists, there was a bug in the logic that fetched the existing\r\nexception lists after importing them. A missing set of parentheses\r\ncaused a KQL query that should have read `(A OR B) AND (C OR D)` to be\r\n`(A OR B) AND C OR D`, meaning that the logic was satisfied by `D` alone\r\ninstead of requiring `A` or `B` to be true along with `D`. In this case\r\n`A` and `B` are filters on `exception-list` and\r\n`exception-list-agnostic` SO attributes so that we (should) only be\r\nlooking at the list container objects, i.e.\r\n`exception-list.attributes.list_type: list`. `C` and `D` are filters by\r\n`list_id`, e.g. `exception-list.attributes.list_id: (test_list_id)`.\r\nWithout the extra parentheses around `C OR D`, the query finds both\r\n`list` and `item` documents for the list IDs specified in `D`.\r\n\r\nWhen the `findExceptionList` logic encounters a list item unexpectedly,\r\nit still tries to convert the SO into our internal representation of an\r\nexception list with `transformSavedObjectToExceptionList`. Most fields\r\nare shared between lists and items, which makes it confusing to debug.\r\nHowever, the `type` of items can only be `simple`, whereas lists have a\r\nvariety of types. During the conversion, the `type` field of the\r\nresulting object is defaulted to `detection` if the `type` field of the\r\nSO doesn't match the allowed list type values. Since the related SDH\r\ninvolved importing a `rule_default` exception list instead, the list\r\ntypes didn't match up when the import route compared the exception list\r\non the rule to import vs the \"existing list\" (which was actually a list\r\nitem coerced into a list container schema with `type: detection`) and\r\nimport fails.","sha":"0cc2e5677b46393ffd066ddaa1c548c664af311b","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","sdh-linked","backport:prev-major","v8.17.0"],"title":"[Security Solution][Detection Engine] Fix importing rules with multiple types of exception lists","number":198868,"url":"https://github.com/elastic/kibana/pull/198868","mergeCommit":{"message":"[Security Solution][Detection Engine] Fix importing rules with multiple types of exception lists (#198868)\n\n## Summary\r\n\r\nFixes https://github.com/elastic/kibana/issues/198461\r\n\r\nWhen a rule import file has both single-namespace and namespace-agnostic\r\nexception lists, there was a bug in the logic that fetched the existing\r\nexception lists after importing them. A missing set of parentheses\r\ncaused a KQL query that should have read `(A OR B) AND (C OR D)` to be\r\n`(A OR B) AND C OR D`, meaning that the logic was satisfied by `D` alone\r\ninstead of requiring `A` or `B` to be true along with `D`. In this case\r\n`A` and `B` are filters on `exception-list` and\r\n`exception-list-agnostic` SO attributes so that we (should) only be\r\nlooking at the list container objects, i.e.\r\n`exception-list.attributes.list_type: list`. `C` and `D` are filters by\r\n`list_id`, e.g. `exception-list.attributes.list_id: (test_list_id)`.\r\nWithout the extra parentheses around `C OR D`, the query finds both\r\n`list` and `item` documents for the list IDs specified in `D`.\r\n\r\nWhen the `findExceptionList` logic encounters a list item unexpectedly,\r\nit still tries to convert the SO into our internal representation of an\r\nexception list with `transformSavedObjectToExceptionList`. Most fields\r\nare shared between lists and items, which makes it confusing to debug.\r\nHowever, the `type` of items can only be `simple`, whereas lists have a\r\nvariety of types. During the conversion, the `type` field of the\r\nresulting object is defaulted to `detection` if the `type` field of the\r\nSO doesn't match the allowed list type values. Since the related SDH\r\ninvolved importing a `rule_default` exception list instead, the list\r\ntypes didn't match up when the import route compared the exception list\r\non the rule to import vs the \"existing list\" (which was actually a list\r\nitem coerced into a list container schema with `type: detection`) and\r\nimport fails.","sha":"0cc2e5677b46393ffd066ddaa1c548c664af311b"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/198868","number":198868,"mergeCommit":{"message":"[Security Solution][Detection Engine] Fix importing rules with multiple types of exception lists (#198868)\n\n## Summary\r\n\r\nFixes https://github.com/elastic/kibana/issues/198461\r\n\r\nWhen a rule import file has both single-namespace and namespace-agnostic\r\nexception lists, there was a bug in the logic that fetched the existing\r\nexception lists after importing them. A missing set of parentheses\r\ncaused a KQL query that should have read `(A OR B) AND (C OR D)` to be\r\n`(A OR B) AND C OR D`, meaning that the logic was satisfied by `D` alone\r\ninstead of requiring `A` or `B` to be true along with `D`. In this case\r\n`A` and `B` are filters on `exception-list` and\r\n`exception-list-agnostic` SO attributes so that we (should) only be\r\nlooking at the list container objects, i.e.\r\n`exception-list.attributes.list_type: list`. `C` and `D` are filters by\r\n`list_id`, e.g. `exception-list.attributes.list_id: (test_list_id)`.\r\nWithout the extra parentheses around `C OR D`, the query finds both\r\n`list` and `item` documents for the list IDs specified in `D`.\r\n\r\nWhen the `findExceptionList` logic encounters a list item unexpectedly,\r\nit still tries to convert the SO into our internal representation of an\r\nexception list with `transformSavedObjectToExceptionList`. Most fields\r\nare shared between lists and items, which makes it confusing to debug.\r\nHowever, the `type` of items can only be `simple`, whereas lists have a\r\nvariety of types. During the conversion, the `type` field of the\r\nresulting object is defaulted to `detection` if the `type` field of the\r\nSO doesn't match the allowed list type values. Since the related SDH\r\ninvolved importing a `rule_default` exception list instead, the list\r\ntypes didn't match up when the import route compared the exception list\r\non the rule to import vs the \"existing list\" (which was actually a list\r\nitem coerced into a list container schema with `type: detection`) and\r\nimport fails.","sha":"0cc2e5677b46393ffd066ddaa1c548c664af311b"}},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| handlers | ||
| routes | ||
| saved_objects | ||
| schemas | ||
| scripts | ||
| services | ||
| config.mock.ts | ||
| config.test.ts | ||
| config.ts | ||
| error_with_status_code.ts | ||
| get_space_id.test.ts | ||
| get_space_id.ts | ||
| get_user.test.ts | ||
| get_user.ts | ||
| index.ts | ||
| mocks.ts | ||
| plugin.ts | ||
| types.ts | ||