Adding event data to SIEM alerting actions

[aarju]

Describe the feature:
As a security analyst often use my mobile device to keep an eye on high priority and critical alerts during off hours via slack. I want to have as much information as possible in my slack messages about an alert.

Describe a specific use case for the feature:
In Infosec we currently use watchers to send alerts to slack. Within the watcher context we can access the field values of the events that triggered the watch using the ctx.payload Here are some examples of slack output we currently use in watcher:

This is a generic example from one of our linux process rules:

{{#ctx.payload._value}}\n - {{@timestamp}} - `{{user.name}}` executed `{{process.title}}` on `{{agent.hostname}}` in `{{fields.team}}`\n\n{{/ctx.payload._value}}"

In this example we send Endgame alert information and include a link to VirusTotal and another link to the alert in the Endgame SMP:

{{#ctx.payload._value}}\n - `At {{@timestamp}}` - MalwareScore:`{{endgame.data.malware_classification.score}}` - `{{endgame.data.file_name}}` - `{{endgame.data.file_operation}}` by `{{endgame.data.alert_details.acting_process.exe}}` on `{{host.name}}` <https://endgamesmp/alerts/{{endgame.metadata.message_id}}|SMP Link> - <https://www.virustotal.com/gui/file/{{endgame.data.hashes.sha256}}|VT Link>\n\n{{/ctx.payload._value}}

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[andrew-goldstein]

@MikePaquette we had a similar request from a user today

cc: @spong @ismael-hasan

[rylnd]

I did some cursory investigation here and it looks like adding additional fields should be straightforward.

Input data are currently defined in scheduleNotificationActions which is invoked from the rule/action executor, so we should have everything available in that context.

The registry of available fields is currently independent of the above, but could perhaps be consolidated as part of this. getActionMessageParams is where that code currently lives.

edit: updated links following the rename of the siem plugin.

[rylnd]

Thinking about this a little more, I think it's going to require a bit more work than simply adding arguments to scheduleNotificationActions: we currently only have signals metadata available to actions (# signals created, result link, etc.).

We can make this work, but given that actions are tied to rules and not individual events, we would likely just expose the array of generated signals as context.signals and leave it to the consumer to iterate/navigate their expected structure via the builtin mustache syntax. Given the dynamic nature of those signal fields I'm not sure what we can do in terms of making those discoverable/navigable during action creation.

[rylnd]

I created #68438 to discuss how best to implement/present these variables to the user.

[michael-c-williams]

Related use Case from a customer:

The customer is using Endgame/Elastic Endpoint and wants to customize SIEM email alerts so that they know from the content of the email if the alert is important enough to take action on (without having to take the extra step of opening the alert in the Endgame console or in Kibana). They would like to use various alert fields like the following:

Subject: {{host.name}} {{signal.rule.name}} {{endgame.data.alert_details.acting_process.name}}

Message:

Alert URL: {{rule.reference}}
Hostname / IP : {{host.name}} {{host.ip}}
Source Process: {{endgame.data.alert_details.acting_process.name}}
Prevention / Detection: {{endgame.metadata.type}}
Description: {{signal.rule.description}}
Severity: {{signal.rule.severity}}

This would allow them to produce an email alert that looked like this (with the direct link back to the alert in Endgame):

Subject: CS-Win10x64 Process Injection - Detected - Elastic Endpoint Taihou64.exe

Message:

Alert URL: https://10.1.4.15/alerts/e2e6b894-e91b-4b11-a52c-296078b9f783
etc.

Currently they are limited to a single useful placeholder which is the link to the detection in the SIEM:

Subject: Elastic Endpoint Security Alert

Message:
Alert URL: [Link to Alert]({{{context.results_link}}})

With such limited information, the would need to open the alert link in every email to determine if they needed to take action on the alert which isn't efficient.

[nicpenning]

Being able to add any data from the signal would be greatly beneficial. I agree with @michael-c-williams comment on limitations of the current information alerts can provide.

As a consumer of the product, this would greatly enhance the detection capabilities whether an email gets sent out or the data hits a webhook endpoint to provide crucial details at the fingertips of our analysts no matter where the alert ends up.

[secops4thewin]

I’ll add another use case to the mix.

As a user having the full event data available allows me to use the web hook function to logstash so I can perform SOAR like functions like run another ES search or check a hash on VT or at some stage (if a plug-in is created) close a signal based on a decision tree.

[jaredstewart101]

Is there any update to this issue? I've been looking at adding more meaningful data to the detections from Elastic SIEM, but so far I haven't found a way to do that. As @aarju, mentioned the way you add event data in Watcher does not seem to be available in SIEM Alerts.

If I'm missing something, could someone please point me in the direction of how to do this? I've tried many different methods of referencing the fields from the alert, but nothing seems to pull any data from the actual payload.

Like, @secops4thewin, I'm using the Webhook action to send the alerts to a SOAR we are building, but I'm not able to attach the data we need such as {{host.name}}, {{source.ip}}, {{event.signature}}, etc.

[spong]

Hey there @jaredstewart101, we're hoping to add this functionality in the near-term, but as always, no guarantee on a specific version. Thanks for detailing your use case here though, and please do continue to comment on other issues that help with your workflows as that helps us better prioritize future releases. In the mean-time, stay subscribed to this issue and you'll get notified once we get this functionality in 🙂