Forwarding detection alert status changes (acknowledged / closed) to an external system

Elastic Security SIEM
1

Hello,

We forward Elastic Security detection alerts to an external system through a Webhook connector configured as a rule action. That works well for new alerts. However, the receiving side also requires every subsequent status change of an alert to be transmitted, for example when an analyst sets it to acknowledged or closed, together with the timestamp of the change.

As far as we can tell, rule actions only fire on rule executions that generate alerts. Changing kibana.alert.workflow_status afterwards does not trigger the rule's actions again, and the Kibana event log shows no further connector execution after the status change.

What is the recommended way to achieve this? Options we are considering:

  • Elastic Workflows, if there is a trigger for detection alert status changes (we found triggers for cases, but not for detection alerts)
  • Periodically querying the alerts index for changes to kibana.alert.workflow_status and forwarding them from an external process, but this doesn't seem ideal

Is there a native mechanism we are missing? We're on Kibana 9.5.4, Elastic Cloud Enterprise.

If there is no such mechanism, would it be a doable feature request?

Use case:
Some regulated environments require a provider to forward security alerts to a central external SIEM, and to transmit every status update of each alert, so that the receiving party can verify that alerts are assessed and closed within defined deadlines. Forwarding the initial alert works through a Webhook connector as a rule action today. There is, however, no native way to forward the later status changes an analyst makes in Kibana, so the external system never learns when an alert was acknowledged or closed.

Kind regards,

Willem D'Haese

2

As far as I know there is nothing native to sync the status of alerts, you can sync the status of Cases, but no individual alerts.

So I think you could use a scheduled workflow to query the alerts that changed status and then send their status to an external endpoint.

3

Thanks @leandrojmp , that confirms what we saw.

A scheduled workflow is a workable interim solution, but for this use case it has some drawbacks. Status changes are only picked up at the next run, so the external system learns about them with a delay. The workflow has to keep track of what it has already forwarded to avoid duplicates. And if an alert changes status more than once between two runs, for example acknowledged and then closed, the intermediate change is only visible if the query reconstructs it from the alert history. When the receiving side has to verify that every status change was transmitted, those gaps matter.

Since alerts already have a well-defined workflow status, and cases already support syncing status changes, a native trigger on detection alert status changes seems like a natural addition. Either an action frequency on the rule ("on status change") or an event-driven workflow trigger for alerts would cover it, with the previous and new status, the timestamp, the user and the closing reason available as variables.