META - [RAM][SECURITYSOLUTION][ALERTS] - Integrate Alert summary inside of security solution rule page

[XavierM]

As an user I would like to to use the new Alert Summary from response ops in the security solution rule creation/update page.

API:

• Validate all API on the detection engine to allow the new attributes frequency in the actions object to be passed. We think that we will need to separate these tasks in two categories, one where we take care of routes that are reading rules and another one where we do some kind of persistence on the rules.
  Reading APIs

  • Find rules
  • Export rules
  • Read rule

  Persistence APIs

  • Bulk actions
  • Bulk create rules
  • Bulk patch rules
  • Bulk update rules
  • Create rule
  • Import rules
  • Patch rule
  • Update rule

• Remove conditional logic in rule client to pass back the attribute frequency [Security Solution] Fix workarounds for migrating from rule-level notifyWhen/throttle to action-level  #148414

• Create/Update new API integration test to valid this work on the detection engine

UI:

• Integrate the new alert summary component inside of the rule page
• Update the rule form to allow frequency to be pass back in the API
• Update the bulk action UI to integrate the new alert summary component
• Show warning that custom action intervals cannot be shorter than the rule's check interval [SECURITYSOLUTION][ALERTS] - Show warning that custom action intervals cannot be shorter than the rule's check interval #155502

Actions per alert:

• Add support to generate per-alert actions [RAM][Security Solution][Alerts] Support the ability to trigger a rule action per alert generated #153611

Some research:

When we know everything work as expected, it will be nice to do some research if we can use directly the alerting framework API directly.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[e40pud]

Hi @XavierM, I had a chat with @banderror today and we wanted to clarify couple questions before the release of this feature.

In order to be compatible our rule's APIs should support rule level throttle parameter. Since we gonna have per-action frequency field there are two questions about conversion between those two:

1. It is possible through current API to modify rule level throttle field. What does it mean for per-action frequency? Are we going to apply passed throttle to each action.frequency?
2. It is possible that user will modify the per-action frequency via new UI changes that I am integrating and have different throttle per-action. What value will rule level throttle field hold inside in this case? Are we going to apply one of the per-action frequencys to rule level throttle (like first action frequency or last modified frequency throttle)?

cc @marshallmain

[banderror]

Hey @XavierM, one more question from my side is about the action's context.

If an action is configured as "trigger me per each generated alert" (as opposed to the current "trigger me per all alerts generated during the rule execution"), how the user is going to access this alert via the placeholders that can be used in the action's body?

Are we going to introduce a new property like context.alert (a single value)? Are we going to keep the same context.alerts property (an array), but populate it with only one value? Any other option? How are we going to explain it to the user (hints in the UI, docs)? We'd need to take into account backward compatibility with existing rules as well.

Previously, I asked a related question here, but it's kinda orthogonal.

[e40pud]

One more question about the message we would like to show to user for "For each alert" option. We show 'Rule {{context.rule.name}} generated {{state.signals_count}} alerts' for "Summary of alerts", but it might not work "For each alert" action's frequency.

cc @peluja1012

[e40pud]

Last week we discussed that there will be some breaking changes. Here is the overview of what is going to be different which also covers my questions above.

It is possible through current API to modify rule level throttle field. What does it mean for per-action frequency? Are we going to apply passed throttle to each action.frequency`?

It is possible that user will modify the per-action frequency via new UI changes that I am integrating and have different throttle per-action. What value will rule level throttle field hold inside in this case? Are we going to apply one of the per-action frequencies to rule level throttle (like first action frequency or last modified frequency throttle)?

Currently, rules can have two states in alert framework:

1. Rule level throttle and notifyWhen are undefined and all actions have frequency attribute.
2. Rule level throttle and notifyWhen set to one of the allowed values and all actions DON'T have frequency attribute.

With the new changes, we will make sure actions are always switched to the new format with the frequency attribute set. There are several possible cases here:

1. If actions have frequency attribute set, we just use those values. On security Solution side, the rule level throttle will be set to either existing value which was set during the interaction with the older version kibana or to the value converted from the first action: actions[0].frquency.
2. If actions do not have frequency attribute set, then we will convert rule level throttle and notifyWhen into action level frequency attribute.
3. If for some reason the state is broken (both rule level throttle and notifyWhen, and action level frequency attributes are not set), we will set action frequency attribute to default value: { summary: true, throttle: null, notifyWhen: 'onActiveAlert' } for all the actions.

Above changes, will introduce breaking behaviour for the users who use the Rule APIs via external tools:

1. Users, cannot rely on the rule level throttle and notifyWhen values. Those attributes won't represent the accurate actions frequencies state (because each action will have own frequency).
2. When user adds actions via bulk update, only those actions will reflect passed throttle. The frequency attribute of the existing actions won't be changed in this case. This means, that old behaviour where user could update throttle for all actions via bulk update won't work after these changes.

@XavierM @peluja1012 @marshallmain

[e40pud]

Regarding the question from @banderror about accessing the alert in action's body, there is an alert object which we can use for that. I tried to use {{alert.id}} and it worked as expected.

cc @ymao1

[e40pud]

@XavierM closing this ticket. Short interval UI will be addressed in 8.9 here #156644