[Request] Update SentinelOne bi-directional response actions instructions with new requirements for setting up the SIEM rule

[paul-tavares]

Description

Update the SentinelOne bi-directional response actions setup with new SIEM rule setup instructions.

The current instructions for setting up SentinelOne restricted the user when setting up the SIEM rule to only use logs-sentinel_one.alert* as the index. With the new changes, any SentinelOne data that contains a sentinel_one.[type].agent.id is now supported.

For example: A user can now use data from the threats, activity and agent (in addition to the current alerts) to promote S1 events to SIEM alerts.

Background & resources

• PRs: [Security Solution][Endpoint] Change SentinelOne response actions to use agent.id instead of observer.serial_number kibana#189535
• Issues/metas: https://github.com/elastic/security-team/issues/9304
• Point of contact: Paul Tavares

Which documentation set does this change impact?

ESS and serverless

ESS release

8.16

Serverless release

Week of August 20 — tracked in PR #5659 (Serverless-pub field emptied on this issue to avoid duplicating)

Feature differences

The setup of the SIEM rule is different now.
also - the observer.serial_number field is no longer supported.

API docs impact

The SIEM rule for SentinelOne can now be setup using any of the following index patterns and agent id fields:

Index Pattern	Agent Id Field
logs-sentinel_one.alert*	sentinel_one.alert.agent.id
logs-sentinel_one.threat*	sentinel_one.threat.agent.id
logs-sentinel_one.activity*	sentinel_one.activity.agent.id
logs-sentinel_one.agent*	sentinel_one.agent.agent.id

Here is an example rule setup that we are using in development:

Prerequisites, privileges, feature flags

No response