Detections and alerts

Use the detection engine to create and manage rules and view the alerts these rules create. Rules periodically search indices (such as logs-* and filebeat-*) for suspicious source events and create alerts when a rule’s conditions are met. When an alert is created, its status is Open. To help track investigations, an alert’s status can be set as Open, Acknowledged, or Closed.

In addition to creating your own rules, enable Elastic prebuilt rules to immediately start detecting suspicious activity. For detailed information on all the prebuilt rules, see the Prebuilt rule reference section. Once the prebuilt rules are loaded and running, Tune detection rules and Add and manage exceptions explain how to modify the rules to reduce false positives and get a better set of actionable alerts. You can also use exceptions and value lists when creating or modifying your own rules.

There are several special prebuilt rules you need to know about:

If you want to receive notifications via external systems, such as Slack or email, when alerts are created, use the Kibana Alerting and Actions framework.

After rules have started running, you can monitor their executions to verify they are functioning correctly, as well as view, manage, and troubleshoot alerts (see Manage detection alerts and Monitor and troubleshoot rule executions).

You can create and manage rules and alerts via the UI or the Detections API.

Cold and frozen data tiers hold time series data that is only accessed occasionally. In Elastic Stack version >=7.11.0, Elastic Security supports cold but not frozen tier data for the following Elasticsearch indices:

Elastic Security does NOT support either cold or frozen tier data for the following Elasticsearch indices:

Using either cold or frozen tier data for unsupported indices may result in detection rule timeouts and overall performance degradation.

Indicator match rules provide a powerful capability to search your security data; however, their queries can consume significant deployment resources. When creating an indicator match rule, we recommend limiting the time range of the indicator index query to the minimum period necessary for the desired rule coverage. For example, the default indicator index query @timestamp > "now-30d/d" searches specified indicator indices for indicators ingested during the past 30 days and rounds the query start time down to the nearest day (resolves to UTC 00:00:00). Without this limitation, the rule will include all of the indicators in your indicator indices, which may extend the time it takes for the indicator index query to complete.

In addition, the following support restrictions are in place:

Detections requirements provides detailed information on all the permissions required to initiate and use the Detections feature.

Depending on your privileges and whether detection system indices have already been created for the Kibana space, you might get one of these error messages when you open the Alerts or Rules page: