New

The executive guide to generative AI

Read more
About usPartnersSupport|Login
« Detection engine overview Using logsdb index mode with Elastic Security Serverless »
Elastic Docs ›Serverless ›Elastic Security Serverless ›Detection engine overview

Detections requirements

edit

Detections requirements

edit

To use the Detections feature, you first need to configure a few settings. You also need the appropriate role to send notifications when detection alerts are generated.

Additionally, there are some advanced settings used to configure value list upload limits.

Enable and access detections

edit

To use the Detections feature, it must be enabled and you must have either the appropriate predefined Security user role or a custom role with privileges to access rules and alerts. If your role doesn’t have the privileges needed to enable this feature, you can request someone who has these privileges to visit your Kibana space, which will turn it on for you.

For instructions about using machine learning jobs and rules, refer to Machine learning job and rule requirements.

Custom role privileges

edit

The following table describes the required custom role privileges to access the Detections feature, including rules and alerts. For more information on Kibana privileges, refer to Custom roles.

Action Cluster Privilege Index Privileges Kibana Privileges

Enable detections in your space

manage

manage, write, read, and view_index_metadata for these system indices and data streams, where <space-id> is the space name:

  • .alerts-security.alerts-<space-id>
  • .lists-<space-id>
  • .items-<space-id>

All for the Security feature

Enable detections in all spaces

NOTE: To turn on detections, visit the Rules and Alerts pages for each space.

manage

manage, write, read, and view_index_metadata for these system indices and data streams:

  • .alerts-security.alerts-<space-id>
  • .lists-<space-id>
  • .items-<space-id>

All for the Security feature

Preview rules

N/A

read for these indices:

  • .preview.alerts-security.alerts-<space-id>
  • .internal.preview.alerts-security.alerts-<space-id>-*

All for the Security feature

Manage rules

N/A

manage, write, read, and view_index_metadata for these system indices and data streams, where <space-id> is the space name:

  • .alerts-security.alerts-<space-id
  • .lists-<space-id>
  • .items-<space-id>

All for the Security feature

NOTE: You need additional Action and Connectors feature privileges (Management → Action and Connectors) to manage rules with actions and connectors:

  • To provide full access to rule actions and connectors, give your role All privileges. With Read privileges, you can edit rule actions, but will have limited capabilities to manage connectors. For example, Read privileges allow you to add or remove an existing connector from a rule, but does not allow you to create a new connector.
  • To import rules with actions, you need at least Read privileges for the Action and Connectors feature. To overwrite or add new connectors, you need All privileges for the Actions and Connectors feature. To import rules without actions, you don’t need Actions and Connectors privileges.

Manage alerts

NOTE: Allows you to manage alerts, but not modify rules.

N/A

maintenance, write, read, and view_index_metadata for these system indices and data streams, where <space-id> is the space name:

  • .alerts-security.alerts-<space-id>
  • .internal.alerts-security.alerts-<space-id>-*
  • .lists-<space-id>
  • .items-<space-id>

Read for the Security feature

Create the .lists and .items data streams in your space

NOTE: To initiate the process that creates the data streams, you must visit the Rules page for each appropriate space.

manage

manage, write, read, and view_index_metadata for these data streams, where <space-id> is the space name:

  • .lists-<space-id>
  • .items-<space-id>

All for the Security and Saved Objects Management features

Authorization

edit

Rules, including all background detection and the actions they generate, are authorized using an API key associated with the last user to edit the rule. Upon creating or modifying a rule, an API key is generated for that user, capturing a snapshot of their privileges. The API key is then used to run all background tasks associated with the rule including detection checks and executing actions.

If a rule requires certain privileges to run, such as index privileges, keep in mind that if a user without those privileges updates the rule, the rule will no longer function.

« Detection engine overview Using logsdb index mode with Elastic Security Serverless »

On this page

Was this helpful?
Feedback