Summary
Discussion in https://github.com/elastic/security-team/issues/2401 exposed a problem where alert documents can be written and a subsequent ES query fails, throws an error, and causes the rule to fail. In this scenario, actions will not always be scheduled for alert documents that have already been written. We should ensure that when alert documents get written any rule actions are also executed for those alerts.
Details
KQL and threat match rules both search for and create alerts in a loop until max_signals number of alerts have been created. It's possible for alerts to be created in one iteration of the loop and then a subsequent iteration throws an error. At that point, the loop exits and returns the created alerts and a flag indicating failure. The base security rule type only schedules throttled actions if it receives the failure flag - unthrottled actions are not scheduled, even though alerts were created.
Summary
Discussion in https://github.com/elastic/security-team/issues/2401 exposed a problem where alert documents can be written and a subsequent ES query fails, throws an error, and causes the rule to fail. In this scenario, actions will not always be scheduled for alert documents that have already been written. We should ensure that when alert documents get written any rule actions are also executed for those alerts.
Details
KQL and threat match rules both search for and create alerts in a loop until
max_signalsnumber of alerts have been created. It's possible for alerts to be created in one iteration of the loop and then a subsequent iteration throws an error. At that point, the loop exits and returns the created alerts and a flag indicating failure. The base security rule type only schedules throttled actions if it receives the failure flag - unthrottled actions are not scheduled, even though alerts were created.