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 two 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.

Malware, short for malicious software, is any software program designed to damage or execute unauthorized actions on a computer system. Examples of malware include viruses, worms, Trojan horses, adware, scareware, and spyware. Some malware, such as viruses, can severely damage a computer’s hard drive by deleting files or directory information. Other malware, such as spyware, can obtain user data without their knowledge.

Malware may be stealthy and appear as legitimate executable code, scripts, active content, and other software. It is also often embedded in non-malicious files, non-suspicious websites, and standard programs — sometimes making the root source difficult to identify. If infected and not resolved promptly, malware can cause irreparable damage to a computer network.

For information on how to enable malware protection on your host, see Malware Protection.

To determine if a file is malicious or benign, a machine learning model looks for static attributes of files (without executing the file) that include file structure, layout, and content. This includes information such as file header data, imports, exports, section names, and file size. These attributes are extracted from millions of benign and malicious file samples, which then are passed to a machine-learning algorithm that distinguishes a benign file from a malicious one. The machine learning model is updated as new data is procured and analyzed.

A malware threshold determines the action the agent should take if malware is detected. The Elastic Agent uses a recommended threshold level that generates a balanced number of alerts with a low probability of undetected malware. This threshold also minimizes the number of false positive alerts.

Ransomware is computer malware that installs discreetly on a user’s computer and encrypts data until a specified amount of money (ransom) is paid. Ransomware is usually similar to other malware in its delivery and execution, infecting systems through spear-phishing or drive-by downloads. If not resolved immediately, ransomware can cause irreparable damage to an entire computer network.

Behavioral ransomware prevention on the Elastic Endpoint detects and stops ransomware attacks on Windows systems by analyzing data from low-level system processes, and is effective across an array of widespread ransomware families — including those targeting the system’s master boot record.

For information on how to enable ransomware protection on your host, see Ransomware protection.

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:

To learn how your rules and alerts are affected by using the logsdb index mode, refer to Using logsdb index mode with Elastic Security.