[Security Solutions][Detection Engine] Removes side car actions object and side car notifications (Part 1) #109722
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FrankHassanabad
changed the title
FrankHassanabad
added
v8.0.0
auto-backport
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
spong
reviewed
Aug 25, 2021
...ecurity_solution/server/lib/detection_engine/rule_types/create_security_rule_type_factory.ts
Outdated
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/signals/signal_rule_alert_type.ts
Outdated
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
...lugins/security_solution/server/lib/detection_engine/routes/rules/create_rules_bulk_route.ts
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/schemas/rule_converters.ts
Outdated
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/schemas/rule_schemas.ts
Outdated
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/rules/install_prepacked_rules.ts
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/rules/delete_rules.ts
Show resolved
Hide resolved
spong
reviewed
Aug 25, 2021
...ecurity_solution/server/lib/detection_engine/rule_types/create_security_rule_type_factory.ts
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
spong
reviewed
Aug 26, 2021
x-pack/plugins/security_solution/server/lib/detection_engine/schemas/rule_converters.ts
Show resolved
Hide resolved
spong
approved these changes
Aug 26, 2021
There was a problem hiding this comment.
Checked out, tested locally, and performed code review. Thank you for taking the time to pair on parts of the review and for helping go through the many different test scenarios and potential issues that could arise from these changes. Love net-negative CR's as well... 🙃😉
Code and functionality changes LGTM, and we now even have what looks to be a path forward for action exports as well! Great stuff here, thanks @FrankHassanabad! 👍 🙂 🚀
spong
approved these changes
Aug 26, 2021
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Aug 26, 2021
…t and side car notifications (Part 1) (elastic#109722) ## Summary Removes the "side car" actions object and side car notification (Part 1). Part 1 makes it so that newly created rules and editing existing rules will update them to using the new side car notifications. Part 2 in a follow up PR will be the migrations to move the existing data. The saved object side we are removing usages of is: ``` siem-detection-engine-rule-actions ``` The alerting side car notification system we are removing is: ``` siem.notifications ``` * Removes the notification files and types * Adds transform to and from alerting concepts of `notityWhen` and our `throttle` * Adds unit tests for utilities and pure functions created * Updates unit tests to have more needed jest mock * Adds business rules and logic for the different states of `notifyWhen`, and `throttle` on each of the REST routes to determine when we should `muteAll` vs. not muting using secondary API call from client alerting * Adds e2e tests for the throttle conditions and how they are to interact with the kibana-alerting `throttle` and `notifyWhen` A behavioral change under the hood is that we now support the state changes of `muteAll` from the UI/UX of [stack management](https://www.elastic.co/guide/en/kibana/master/create-and-manage-rules.html#controlling-rules). Whenever the `security_solution` ["Perform no actions"](https://www.elastic.co/guide/en/security/current/rules-api-create.html ) is selected we do a `muteAll`. However, we do not change the state if all individual actions are muted within the rule. Instead we only maintain the state of `muteAll`: <img width="2299" alt="ui_state_change" src="https://user-images.githubusercontent.com/1151048/130823045-48a9f34b-db23-44e3-b9ed-cbbb57edc3d6.png"> <img width="1163" alt="no_actions_state_change" src="https://user-images.githubusercontent.com/1151048/130823056-3f8953fa-9433-4973-a2d3-6e11263b9619.png"> Ref: * Issue and PR where notifyWhen was added to kibna-alerting * elastic#82969 * elastic#50077 ### Checklist Delete any items that are not applicable to this PR. - [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
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
kibanamachine
added a commit
that referenced
this pull request
Aug 26, 2021
…t and side car notifications (Part 1) (#109722) (#110305) ## Summary Removes the "side car" actions object and side car notification (Part 1). Part 1 makes it so that newly created rules and editing existing rules will update them to using the new side car notifications. Part 2 in a follow up PR will be the migrations to move the existing data. The saved object side we are removing usages of is: ``` siem-detection-engine-rule-actions ``` The alerting side car notification system we are removing is: ``` siem.notifications ``` * Removes the notification files and types * Adds transform to and from alerting concepts of `notityWhen` and our `throttle` * Adds unit tests for utilities and pure functions created * Updates unit tests to have more needed jest mock * Adds business rules and logic for the different states of `notifyWhen`, and `throttle` on each of the REST routes to determine when we should `muteAll` vs. not muting using secondary API call from client alerting * Adds e2e tests for the throttle conditions and how they are to interact with the kibana-alerting `throttle` and `notifyWhen` A behavioral change under the hood is that we now support the state changes of `muteAll` from the UI/UX of [stack management](https://www.elastic.co/guide/en/kibana/master/create-and-manage-rules.html#controlling-rules). Whenever the `security_solution` ["Perform no actions"](https://www.elastic.co/guide/en/security/current/rules-api-create.html ) is selected we do a `muteAll`. However, we do not change the state if all individual actions are muted within the rule. Instead we only maintain the state of `muteAll`: <img width="2299" alt="ui_state_change" src="https://user-images.githubusercontent.com/1151048/130823045-48a9f34b-db23-44e3-b9ed-cbbb57edc3d6.png"> <img width="1163" alt="no_actions_state_change" src="https://user-images.githubusercontent.com/1151048/130823056-3f8953fa-9433-4973-a2d3-6e11263b9619.png"> Ref: * Issue and PR where notifyWhen was added to kibna-alerting * #82969 * #50077 ### Checklist Delete any items that are not applicable to this PR. - [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 Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
1 task
FrankHassanabad
added a commit
that referenced
this pull request
Sep 27, 2021
…stem in a limited fashion (#112869) ## Summary Fixes https://github.com/elastic/security-team/issues/1759 Related earlier PR, #109722, where these were removed to where they could no longer function. This PR adds them back to where they will function for existing users. The end goal is to have users naturally migrate as they update, enable/disable, or create new rules. What this PR does: * Adds back the legacy side car actions `siem-detection-engine-rule-actions` * Adds back the legacy hidden alert of `siem.notifications` * Adds back unit tests where they existed. Both of these systems did not have existing e2e tests. * Re-adds the find feature and functionality which should show the rules with legacy and non-legacy notifications/side car actions during a REST find operation. * Updates the logic for when to show a legacy vs. non-legacy notification/side car action. * Adds a new route called `/internal/api/detection/legacy/notifications` which is only for developer and tests for us to maintain this system for the foreseeable future. * Adds script to exercise creating old notifications `detection_engine/scripts/post_legacy_notification.sh` * Adds a data file for the script to use as an example for ad-hoc testing, `scripts/legacy_notifications/one_action.json` * Adds within `security_solution/server/types.ts` `ActionsApiRequestHandlerContext` so that if we need to directly access actions within plugins we can. I do not use it here, but it should have been existing there and is good to have it in case we need it at this point within REST routes. * When adding back the files and changes, I use the kibana-core approach of prefixing files, functions, types, etc... with the words `legacyFoo`. The files are named `legacy_foo.ts`. Everything has `@deprecation` above them as well. The intent here is all of this should hopefully make it unambiguously clear which parts of the notification system are for the new system/existing API and which ones are only for the deprecated legacy system. There exists some parts of the system that are used within _both_ and the hope is that we can keep the legacy pieces separate from the non-legacy pieces for strangling the legacy pieces. * This adds a new linter rule to prevent users from easily importing files named `legacy_foo.ts` or `foo_legacy.ts` we are using here and can also use for other similar legacy parts of the system we have. This seems to be the established pattern that kibana-core does as well looking through the linters and code base. * Removes some dead import/export code and types instead of maintaining them since they are no longer used. What this PR does not do (but are planned on follow ups): * This PR does not add migration logic in most conditions such as a user enabling/disabling a rule, editing a rule unless the user is explicitly changing the actions by turning off the notification and then re-adding the notification. * This PR does not log any information indicating to the user that they are running legacy rules or indicates they have that. * This PR does not allow the executors or any UI/UX, backend to re-add a legacy notification. Instead only the hidden REST route of `/internal/api/detection/legacy/notifications` allows us to do this for testing purposes. * This PR does not migrate the data structure of actions legacy notification system `siem-detection-engine-rule-actions` to use saved object references. * If you delete an alert this will not delete the side car if it detects one is present on it. * If you update an alert notification with a new notification this will not remove the side car on the update. **Ad-hoc testing instructions** How to do ad-hoc testing for various situations such as having a legacy notification system such as a user's or if you want to mimic a malfunction and result of a "split-brain" to where you have both notification systems running at the same time due to a bug or regression: Create a rule and activate it normally within security_solution: <img width="1046" alt="Screen Shot 2021-09-22 at 2 09 14 PM" src="https://user-images.githubusercontent.com/1151048/134416564-e4e001a7-1086-46a1-aa8d-79880f70cc35.png"> Do not add actions to the rule at this point as we will first exercise the older legacy system. However, you want at least one action configured such as a slack notification: <img width="575" alt="Screen Shot 2021-09-22 at 2 28 16 PM" src="https://user-images.githubusercontent.com/1151048/134417012-58e63709-5447-4832-8866-f82be1b9596b.png"> Within dev tools do a query for all your actions and grab one of the `_id` of them without their prefix: ```json # See all your actions GET .kibana/_search { "query": { "term": { "type": "action" } } } ``` Mine was `"_id" : "action:879e8ff0-1be1-11ec-a722-83da1c22a481",` so I will be copying the ID of `879e8ff0-1be1-11ec-a722-83da1c22a481` Go to the file `detection_engine/scripts/legacy_notifications/one_action.json` and add this id to the file. Something like this: ```json { "name": "Legacy notification with one action", "interval": "1m", <--- You can use whatever you want. Real values are "1h", "1d", "1w". I use "1m" for testing purposes. "actions": [ { "id": "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- My action id "group": "default", "params": { "message": "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId": ".slack" <--- I am a slack action id type. } ] } ``` Query for an alert you want to add manually add back a legacy notification to it. Such as: ```json # See all your siem.signals alert types and choose one GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.signals" } } } ``` Grab the `_id` without the `alert` prefix. For mine this was `933ca720-1be1-11ec-a722-83da1c22a481` Within the directory of `detection_engine/scripts` execute the script ```bash ./post_legacy_notification.sh 933ca720-1be1-11ec-a722-83da1c22a481 { "ok": "acknowledged" } ``` which is going to do a few things. See the file `detection_engine/routes/rules/legacy_create_legacy_notification.ts` for the definition of the route and what it does in full, but we should notice that we have now: Created a legacy side car action object of type `siem-detection-engine-rule-actions` you can see in dev tools: ```json # See the actions "side car" which are part of the legacy notification system. GET .kibana/_search { "query": { "term": { "type": { "value": "siem-detection-engine-rule-actions" } } } } ``` Note in the response: ```json "siem-detection-engine-rule-actions" : { "ruleAlertId" : "933ca720-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "actions" : [ { "action_type_id" : ".slack", "id" : "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "group" : "default" } ], "ruleThrottle" : "1m", <--- Should be the same as the interval in "one_action.json" config "alertThrottle" : "1m" <--- Should be the same as the interval in "one_action.json" config }, "type" : "siem-detection-engine-rule-actions", "references" : [ ], ``` Created a `siem.notification` rule instance which you can see in dev tools as well: ```json # Get the alert type of "siem-notifications" which is part of the legacy system. GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.notifications" } } } ``` Take note from the `siem.notifications` these values which determine how/when it fires and if your actions are set up correctly: ```json "name" : "Legacy notification with one action" <--- Our name from one_action.json "schedule" : { "interval" : "1m" <--- Interval should match interval in one_action.json }, "enabled" : true, <--- We should be enabled "actions" : [ { "group" : "default", "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId" : ".slack", <--- Our actionID "actionRef" : "action_0" } ], ``` And that now there exists a task within task manager that will be executing this: ```json # Get the tasks of siem notifications to ensure and see it is running GET .task-manager/_search { "query": { "term": { "task.taskType": "alerting:siem.notifications" } } } ``` You can double check the interval from the result of the query to ensure it runs as the configuration test file shows it should be: ```json "schedule" : { "interval" : "1m" }, ``` Within time you should see your action execute like the legacy notification system: <img width="876" alt="Screen Shot 2021-09-22 at 2 55 28 PM" src="https://user-images.githubusercontent.com/1151048/134422639-80523abb-f43c-4f7c-abef-a60062bef139.png"> If you go to edit the rule you should notice that the rule now has the side car attached to it within the UI: <img width="1050" alt="Screen Shot 2021-09-22 at 8 08 54 PM" src="https://user-images.githubusercontent.com/1151048/134445265-fa0a330b-3238-48e2-aef3-6042c7e9aa69.png"> You can also look at your log messages in debug mode to verify the behaviors of the legacy system and the normal rules running. Compare these data structures to a 7.14.x system in cloud to ensure the data looks the same and the ad-hoc testing functions as expected. Check the scripts of `./find_rules.sh`, `./read_rules.sh` to ensure that the find REST route returns the legacy actions when they are there. ### 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
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 27, 2021
…stem in a limited fashion (elastic#112869) ## Summary Fixes elastic/security-team#1759 Related earlier PR, elastic#109722, where these were removed to where they could no longer function. This PR adds them back to where they will function for existing users. The end goal is to have users naturally migrate as they update, enable/disable, or create new rules. What this PR does: * Adds back the legacy side car actions `siem-detection-engine-rule-actions` * Adds back the legacy hidden alert of `siem.notifications` * Adds back unit tests where they existed. Both of these systems did not have existing e2e tests. * Re-adds the find feature and functionality which should show the rules with legacy and non-legacy notifications/side car actions during a REST find operation. * Updates the logic for when to show a legacy vs. non-legacy notification/side car action. * Adds a new route called `/internal/api/detection/legacy/notifications` which is only for developer and tests for us to maintain this system for the foreseeable future. * Adds script to exercise creating old notifications `detection_engine/scripts/post_legacy_notification.sh` * Adds a data file for the script to use as an example for ad-hoc testing, `scripts/legacy_notifications/one_action.json` * Adds within `security_solution/server/types.ts` `ActionsApiRequestHandlerContext` so that if we need to directly access actions within plugins we can. I do not use it here, but it should have been existing there and is good to have it in case we need it at this point within REST routes. * When adding back the files and changes, I use the kibana-core approach of prefixing files, functions, types, etc... with the words `legacyFoo`. The files are named `legacy_foo.ts`. Everything has `@deprecation` above them as well. The intent here is all of this should hopefully make it unambiguously clear which parts of the notification system are for the new system/existing API and which ones are only for the deprecated legacy system. There exists some parts of the system that are used within _both_ and the hope is that we can keep the legacy pieces separate from the non-legacy pieces for strangling the legacy pieces. * This adds a new linter rule to prevent users from easily importing files named `legacy_foo.ts` or `foo_legacy.ts` we are using here and can also use for other similar legacy parts of the system we have. This seems to be the established pattern that kibana-core does as well looking through the linters and code base. * Removes some dead import/export code and types instead of maintaining them since they are no longer used. What this PR does not do (but are planned on follow ups): * This PR does not add migration logic in most conditions such as a user enabling/disabling a rule, editing a rule unless the user is explicitly changing the actions by turning off the notification and then re-adding the notification. * This PR does not log any information indicating to the user that they are running legacy rules or indicates they have that. * This PR does not allow the executors or any UI/UX, backend to re-add a legacy notification. Instead only the hidden REST route of `/internal/api/detection/legacy/notifications` allows us to do this for testing purposes. * This PR does not migrate the data structure of actions legacy notification system `siem-detection-engine-rule-actions` to use saved object references. * If you delete an alert this will not delete the side car if it detects one is present on it. * If you update an alert notification with a new notification this will not remove the side car on the update. **Ad-hoc testing instructions** How to do ad-hoc testing for various situations such as having a legacy notification system such as a user's or if you want to mimic a malfunction and result of a "split-brain" to where you have both notification systems running at the same time due to a bug or regression: Create a rule and activate it normally within security_solution: <img width="1046" alt="Screen Shot 2021-09-22 at 2 09 14 PM" src="https://user-images.githubusercontent.com/1151048/134416564-e4e001a7-1086-46a1-aa8d-79880f70cc35.png"> Do not add actions to the rule at this point as we will first exercise the older legacy system. However, you want at least one action configured such as a slack notification: <img width="575" alt="Screen Shot 2021-09-22 at 2 28 16 PM" src="https://user-images.githubusercontent.com/1151048/134417012-58e63709-5447-4832-8866-f82be1b9596b.png"> Within dev tools do a query for all your actions and grab one of the `_id` of them without their prefix: ```json # See all your actions GET .kibana/_search { "query": { "term": { "type": "action" } } } ``` Mine was `"_id" : "action:879e8ff0-1be1-11ec-a722-83da1c22a481",` so I will be copying the ID of `879e8ff0-1be1-11ec-a722-83da1c22a481` Go to the file `detection_engine/scripts/legacy_notifications/one_action.json` and add this id to the file. Something like this: ```json { "name": "Legacy notification with one action", "interval": "1m", <--- You can use whatever you want. Real values are "1h", "1d", "1w". I use "1m" for testing purposes. "actions": [ { "id": "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- My action id "group": "default", "params": { "message": "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId": ".slack" <--- I am a slack action id type. } ] } ``` Query for an alert you want to add manually add back a legacy notification to it. Such as: ```json # See all your siem.signals alert types and choose one GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.signals" } } } ``` Grab the `_id` without the `alert` prefix. For mine this was `933ca720-1be1-11ec-a722-83da1c22a481` Within the directory of `detection_engine/scripts` execute the script ```bash ./post_legacy_notification.sh 933ca720-1be1-11ec-a722-83da1c22a481 { "ok": "acknowledged" } ``` which is going to do a few things. See the file `detection_engine/routes/rules/legacy_create_legacy_notification.ts` for the definition of the route and what it does in full, but we should notice that we have now: Created a legacy side car action object of type `siem-detection-engine-rule-actions` you can see in dev tools: ```json # See the actions "side car" which are part of the legacy notification system. GET .kibana/_search { "query": { "term": { "type": { "value": "siem-detection-engine-rule-actions" } } } } ``` Note in the response: ```json "siem-detection-engine-rule-actions" : { "ruleAlertId" : "933ca720-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "actions" : [ { "action_type_id" : ".slack", "id" : "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "group" : "default" } ], "ruleThrottle" : "1m", <--- Should be the same as the interval in "one_action.json" config "alertThrottle" : "1m" <--- Should be the same as the interval in "one_action.json" config }, "type" : "siem-detection-engine-rule-actions", "references" : [ ], ``` Created a `siem.notification` rule instance which you can see in dev tools as well: ```json # Get the alert type of "siem-notifications" which is part of the legacy system. GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.notifications" } } } ``` Take note from the `siem.notifications` these values which determine how/when it fires and if your actions are set up correctly: ```json "name" : "Legacy notification with one action" <--- Our name from one_action.json "schedule" : { "interval" : "1m" <--- Interval should match interval in one_action.json }, "enabled" : true, <--- We should be enabled "actions" : [ { "group" : "default", "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId" : ".slack", <--- Our actionID "actionRef" : "action_0" } ], ``` And that now there exists a task within task manager that will be executing this: ```json # Get the tasks of siem notifications to ensure and see it is running GET .task-manager/_search { "query": { "term": { "task.taskType": "alerting:siem.notifications" } } } ``` You can double check the interval from the result of the query to ensure it runs as the configuration test file shows it should be: ```json "schedule" : { "interval" : "1m" }, ``` Within time you should see your action execute like the legacy notification system: <img width="876" alt="Screen Shot 2021-09-22 at 2 55 28 PM" src="https://user-images.githubusercontent.com/1151048/134422639-80523abb-f43c-4f7c-abef-a60062bef139.png"> If you go to edit the rule you should notice that the rule now has the side car attached to it within the UI: <img width="1050" alt="Screen Shot 2021-09-22 at 8 08 54 PM" src="https://user-images.githubusercontent.com/1151048/134445265-fa0a330b-3238-48e2-aef3-6042c7e9aa69.png"> You can also look at your log messages in debug mode to verify the behaviors of the legacy system and the normal rules running. Compare these data structures to a 7.14.x system in cloud to ensure the data looks the same and the ad-hoc testing functions as expected. Check the scripts of `./find_rules.sh`, `./read_rules.sh` to ensure that the find REST route returns the legacy actions when they are there. ### 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
kibanamachine
added a commit
that referenced
this pull request
Sep 28, 2021
…stem in a limited fashion (#112869) (#113202) ## Summary Fixes elastic/security-team#1759 Related earlier PR, #109722, where these were removed to where they could no longer function. This PR adds them back to where they will function for existing users. The end goal is to have users naturally migrate as they update, enable/disable, or create new rules. What this PR does: * Adds back the legacy side car actions `siem-detection-engine-rule-actions` * Adds back the legacy hidden alert of `siem.notifications` * Adds back unit tests where they existed. Both of these systems did not have existing e2e tests. * Re-adds the find feature and functionality which should show the rules with legacy and non-legacy notifications/side car actions during a REST find operation. * Updates the logic for when to show a legacy vs. non-legacy notification/side car action. * Adds a new route called `/internal/api/detection/legacy/notifications` which is only for developer and tests for us to maintain this system for the foreseeable future. * Adds script to exercise creating old notifications `detection_engine/scripts/post_legacy_notification.sh` * Adds a data file for the script to use as an example for ad-hoc testing, `scripts/legacy_notifications/one_action.json` * Adds within `security_solution/server/types.ts` `ActionsApiRequestHandlerContext` so that if we need to directly access actions within plugins we can. I do not use it here, but it should have been existing there and is good to have it in case we need it at this point within REST routes. * When adding back the files and changes, I use the kibana-core approach of prefixing files, functions, types, etc... with the words `legacyFoo`. The files are named `legacy_foo.ts`. Everything has `@deprecation` above them as well. The intent here is all of this should hopefully make it unambiguously clear which parts of the notification system are for the new system/existing API and which ones are only for the deprecated legacy system. There exists some parts of the system that are used within _both_ and the hope is that we can keep the legacy pieces separate from the non-legacy pieces for strangling the legacy pieces. * This adds a new linter rule to prevent users from easily importing files named `legacy_foo.ts` or `foo_legacy.ts` we are using here and can also use for other similar legacy parts of the system we have. This seems to be the established pattern that kibana-core does as well looking through the linters and code base. * Removes some dead import/export code and types instead of maintaining them since they are no longer used. What this PR does not do (but are planned on follow ups): * This PR does not add migration logic in most conditions such as a user enabling/disabling a rule, editing a rule unless the user is explicitly changing the actions by turning off the notification and then re-adding the notification. * This PR does not log any information indicating to the user that they are running legacy rules or indicates they have that. * This PR does not allow the executors or any UI/UX, backend to re-add a legacy notification. Instead only the hidden REST route of `/internal/api/detection/legacy/notifications` allows us to do this for testing purposes. * This PR does not migrate the data structure of actions legacy notification system `siem-detection-engine-rule-actions` to use saved object references. * If you delete an alert this will not delete the side car if it detects one is present on it. * If you update an alert notification with a new notification this will not remove the side car on the update. **Ad-hoc testing instructions** How to do ad-hoc testing for various situations such as having a legacy notification system such as a user's or if you want to mimic a malfunction and result of a "split-brain" to where you have both notification systems running at the same time due to a bug or regression: Create a rule and activate it normally within security_solution: <img width="1046" alt="Screen Shot 2021-09-22 at 2 09 14 PM" src="https://user-images.githubusercontent.com/1151048/134416564-e4e001a7-1086-46a1-aa8d-79880f70cc35.png"> Do not add actions to the rule at this point as we will first exercise the older legacy system. However, you want at least one action configured such as a slack notification: <img width="575" alt="Screen Shot 2021-09-22 at 2 28 16 PM" src="https://user-images.githubusercontent.com/1151048/134417012-58e63709-5447-4832-8866-f82be1b9596b.png"> Within dev tools do a query for all your actions and grab one of the `_id` of them without their prefix: ```json # See all your actions GET .kibana/_search { "query": { "term": { "type": "action" } } } ``` Mine was `"_id" : "action:879e8ff0-1be1-11ec-a722-83da1c22a481",` so I will be copying the ID of `879e8ff0-1be1-11ec-a722-83da1c22a481` Go to the file `detection_engine/scripts/legacy_notifications/one_action.json` and add this id to the file. Something like this: ```json { "name": "Legacy notification with one action", "interval": "1m", <--- You can use whatever you want. Real values are "1h", "1d", "1w". I use "1m" for testing purposes. "actions": [ { "id": "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- My action id "group": "default", "params": { "message": "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId": ".slack" <--- I am a slack action id type. } ] } ``` Query for an alert you want to add manually add back a legacy notification to it. Such as: ```json # See all your siem.signals alert types and choose one GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.signals" } } } ``` Grab the `_id` without the `alert` prefix. For mine this was `933ca720-1be1-11ec-a722-83da1c22a481` Within the directory of `detection_engine/scripts` execute the script ```bash ./post_legacy_notification.sh 933ca720-1be1-11ec-a722-83da1c22a481 { "ok": "acknowledged" } ``` which is going to do a few things. See the file `detection_engine/routes/rules/legacy_create_legacy_notification.ts` for the definition of the route and what it does in full, but we should notice that we have now: Created a legacy side car action object of type `siem-detection-engine-rule-actions` you can see in dev tools: ```json # See the actions "side car" which are part of the legacy notification system. GET .kibana/_search { "query": { "term": { "type": { "value": "siem-detection-engine-rule-actions" } } } } ``` Note in the response: ```json "siem-detection-engine-rule-actions" : { "ruleAlertId" : "933ca720-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "actions" : [ { "action_type_id" : ".slack", "id" : "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "group" : "default" } ], "ruleThrottle" : "1m", <--- Should be the same as the interval in "one_action.json" config "alertThrottle" : "1m" <--- Should be the same as the interval in "one_action.json" config }, "type" : "siem-detection-engine-rule-actions", "references" : [ ], ``` Created a `siem.notification` rule instance which you can see in dev tools as well: ```json # Get the alert type of "siem-notifications" which is part of the legacy system. GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.notifications" } } } ``` Take note from the `siem.notifications` these values which determine how/when it fires and if your actions are set up correctly: ```json "name" : "Legacy notification with one action" <--- Our name from one_action.json "schedule" : { "interval" : "1m" <--- Interval should match interval in one_action.json }, "enabled" : true, <--- We should be enabled "actions" : [ { "group" : "default", "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId" : ".slack", <--- Our actionID "actionRef" : "action_0" } ], ``` And that now there exists a task within task manager that will be executing this: ```json # Get the tasks of siem notifications to ensure and see it is running GET .task-manager/_search { "query": { "term": { "task.taskType": "alerting:siem.notifications" } } } ``` You can double check the interval from the result of the query to ensure it runs as the configuration test file shows it should be: ```json "schedule" : { "interval" : "1m" }, ``` Within time you should see your action execute like the legacy notification system: <img width="876" alt="Screen Shot 2021-09-22 at 2 55 28 PM" src="https://user-images.githubusercontent.com/1151048/134422639-80523abb-f43c-4f7c-abef-a60062bef139.png"> If you go to edit the rule you should notice that the rule now has the side car attached to it within the UI: <img width="1050" alt="Screen Shot 2021-09-22 at 8 08 54 PM" src="https://user-images.githubusercontent.com/1151048/134445265-fa0a330b-3238-48e2-aef3-6042c7e9aa69.png"> You can also look at your log messages in debug mode to verify the behaviors of the legacy system and the normal rules running. Compare these data structures to a 7.14.x system in cloud to ensure the data looks the same and the ad-hoc testing functions as expected. Check the scripts of `./find_rules.sh`, `./read_rules.sh` to ensure that the find REST route returns the legacy actions when they are there. ### 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 Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
lykkin
pushed a commit
to lykkin/kibana
that referenced
this pull request
Sep 28, 2021
…stem in a limited fashion (elastic#112869) ## Summary Fixes https://github.com/elastic/security-team/issues/1759 Related earlier PR, elastic#109722, where these were removed to where they could no longer function. This PR adds them back to where they will function for existing users. The end goal is to have users naturally migrate as they update, enable/disable, or create new rules. What this PR does: * Adds back the legacy side car actions `siem-detection-engine-rule-actions` * Adds back the legacy hidden alert of `siem.notifications` * Adds back unit tests where they existed. Both of these systems did not have existing e2e tests. * Re-adds the find feature and functionality which should show the rules with legacy and non-legacy notifications/side car actions during a REST find operation. * Updates the logic for when to show a legacy vs. non-legacy notification/side car action. * Adds a new route called `/internal/api/detection/legacy/notifications` which is only for developer and tests for us to maintain this system for the foreseeable future. * Adds script to exercise creating old notifications `detection_engine/scripts/post_legacy_notification.sh` * Adds a data file for the script to use as an example for ad-hoc testing, `scripts/legacy_notifications/one_action.json` * Adds within `security_solution/server/types.ts` `ActionsApiRequestHandlerContext` so that if we need to directly access actions within plugins we can. I do not use it here, but it should have been existing there and is good to have it in case we need it at this point within REST routes. * When adding back the files and changes, I use the kibana-core approach of prefixing files, functions, types, etc... with the words `legacyFoo`. The files are named `legacy_foo.ts`. Everything has `@deprecation` above them as well. The intent here is all of this should hopefully make it unambiguously clear which parts of the notification system are for the new system/existing API and which ones are only for the deprecated legacy system. There exists some parts of the system that are used within _both_ and the hope is that we can keep the legacy pieces separate from the non-legacy pieces for strangling the legacy pieces. * This adds a new linter rule to prevent users from easily importing files named `legacy_foo.ts` or `foo_legacy.ts` we are using here and can also use for other similar legacy parts of the system we have. This seems to be the established pattern that kibana-core does as well looking through the linters and code base. * Removes some dead import/export code and types instead of maintaining them since they are no longer used. What this PR does not do (but are planned on follow ups): * This PR does not add migration logic in most conditions such as a user enabling/disabling a rule, editing a rule unless the user is explicitly changing the actions by turning off the notification and then re-adding the notification. * This PR does not log any information indicating to the user that they are running legacy rules or indicates they have that. * This PR does not allow the executors or any UI/UX, backend to re-add a legacy notification. Instead only the hidden REST route of `/internal/api/detection/legacy/notifications` allows us to do this for testing purposes. * This PR does not migrate the data structure of actions legacy notification system `siem-detection-engine-rule-actions` to use saved object references. * If you delete an alert this will not delete the side car if it detects one is present on it. * If you update an alert notification with a new notification this will not remove the side car on the update. **Ad-hoc testing instructions** How to do ad-hoc testing for various situations such as having a legacy notification system such as a user's or if you want to mimic a malfunction and result of a "split-brain" to where you have both notification systems running at the same time due to a bug or regression: Create a rule and activate it normally within security_solution: <img width="1046" alt="Screen Shot 2021-09-22 at 2 09 14 PM" src="https://user-images.githubusercontent.com/1151048/134416564-e4e001a7-1086-46a1-aa8d-79880f70cc35.png"> Do not add actions to the rule at this point as we will first exercise the older legacy system. However, you want at least one action configured such as a slack notification: <img width="575" alt="Screen Shot 2021-09-22 at 2 28 16 PM" src="https://user-images.githubusercontent.com/1151048/134417012-58e63709-5447-4832-8866-f82be1b9596b.png"> Within dev tools do a query for all your actions and grab one of the `_id` of them without their prefix: ```json # See all your actions GET .kibana/_search { "query": { "term": { "type": "action" } } } ``` Mine was `"_id" : "action:879e8ff0-1be1-11ec-a722-83da1c22a481",` so I will be copying the ID of `879e8ff0-1be1-11ec-a722-83da1c22a481` Go to the file `detection_engine/scripts/legacy_notifications/one_action.json` and add this id to the file. Something like this: ```json { "name": "Legacy notification with one action", "interval": "1m", <--- You can use whatever you want. Real values are "1h", "1d", "1w". I use "1m" for testing purposes. "actions": [ { "id": "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- My action id "group": "default", "params": { "message": "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId": ".slack" <--- I am a slack action id type. } ] } ``` Query for an alert you want to add manually add back a legacy notification to it. Such as: ```json # See all your siem.signals alert types and choose one GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.signals" } } } ``` Grab the `_id` without the `alert` prefix. For mine this was `933ca720-1be1-11ec-a722-83da1c22a481` Within the directory of `detection_engine/scripts` execute the script ```bash ./post_legacy_notification.sh 933ca720-1be1-11ec-a722-83da1c22a481 { "ok": "acknowledged" } ``` which is going to do a few things. See the file `detection_engine/routes/rules/legacy_create_legacy_notification.ts` for the definition of the route and what it does in full, but we should notice that we have now: Created a legacy side car action object of type `siem-detection-engine-rule-actions` you can see in dev tools: ```json # See the actions "side car" which are part of the legacy notification system. GET .kibana/_search { "query": { "term": { "type": { "value": "siem-detection-engine-rule-actions" } } } } ``` Note in the response: ```json "siem-detection-engine-rule-actions" : { "ruleAlertId" : "933ca720-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "actions" : [ { "action_type_id" : ".slack", "id" : "879e8ff0-1be1-11ec-a722-83da1c22a481", <--- NOTE, not migrated to references yet "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "group" : "default" } ], "ruleThrottle" : "1m", <--- Should be the same as the interval in "one_action.json" config "alertThrottle" : "1m" <--- Should be the same as the interval in "one_action.json" config }, "type" : "siem-detection-engine-rule-actions", "references" : [ ], ``` Created a `siem.notification` rule instance which you can see in dev tools as well: ```json # Get the alert type of "siem-notifications" which is part of the legacy system. GET .kibana/_search { "query": { "term": { "alert.alertTypeId": "siem.notifications" } } } ``` Take note from the `siem.notifications` these values which determine how/when it fires and if your actions are set up correctly: ```json "name" : "Legacy notification with one action" <--- Our name from one_action.json "schedule" : { "interval" : "1m" <--- Interval should match interval in one_action.json }, "enabled" : true, <--- We should be enabled "actions" : [ { "group" : "default", "params" : { "message" : "Hourly\nRule {{context.rule.name}} generated {{state.signals_count}} alerts" }, "actionTypeId" : ".slack", <--- Our actionID "actionRef" : "action_0" } ], ``` And that now there exists a task within task manager that will be executing this: ```json # Get the tasks of siem notifications to ensure and see it is running GET .task-manager/_search { "query": { "term": { "task.taskType": "alerting:siem.notifications" } } } ``` You can double check the interval from the result of the query to ensure it runs as the configuration test file shows it should be: ```json "schedule" : { "interval" : "1m" }, ``` Within time you should see your action execute like the legacy notification system: <img width="876" alt="Screen Shot 2021-09-22 at 2 55 28 PM" src="https://user-images.githubusercontent.com/1151048/134422639-80523abb-f43c-4f7c-abef-a60062bef139.png"> If you go to edit the rule you should notice that the rule now has the side car attached to it within the UI: <img width="1050" alt="Screen Shot 2021-09-22 at 8 08 54 PM" src="https://user-images.githubusercontent.com/1151048/134445265-fa0a330b-3238-48e2-aef3-6042c7e9aa69.png"> You can also look at your log messages in debug mode to verify the behaviors of the legacy system and the normal rules running. Compare these data structures to a 7.14.x system in cloud to ensure the data looks the same and the ad-hoc testing functions as expected. Check the scripts of `./find_rules.sh`, `./read_rules.sh` to ensure that the find REST route returns the legacy actions when they are there. ### 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Removes the "side car" actions object and side car notification (Part 1). Part 1 makes it so that newly created rules and editing existing rules will update them to using the new side car notifications. Part 2 in a follow up PR will be the migrations to move the existing data.
The saved object side we are removing usages of is:
The alerting side car notification system we are removing is:
notityWhenand ourthrottlenotifyWhen, andthrottleon each of the REST routes to determine when we shouldmuteAllvs. not muting using secondary API call from client alertingthrottleandnotifyWhenA behavioral change under the hood is that we now support the state changes of
muteAllfrom the UI/UX of stack management. Whenever thesecurity_solution"Perform no actions" is selected we do amuteAll. However, we do not change the state if all individual actions are muted within the rule. Instead we only maintain the state ofmuteAll:Ref:
Checklist
Delete any items that are not applicable to this PR.