Create a detection rule

Turn on the Run job switch for the required machine learning job.

Use the filter and query fields to create the criteria used for detecting alerts.

For example, the following rule detects when the vssadmin delete shadows Windows command is executed:

Use the Count field to limit alerts by cardinality of a certain field.

For example, if Group by is source.ip, destination.ip and its Threshold is 10, an alert is generated for every pair of source and destination IP addresses that appear in at least 10 of the rule’s search results.

You can also leave the Group by field undefined. The rule then creates an alert when the number of search results is equal to or greater than the threshold value. If you set Count to limit the results by process.name >= 2, an alert will only be generated for source/destination IP pairs that appear with at least 2 unique process names across all events.

{{#context.alerts}}
  {{#signal.threshold_result.terms}}
    {{value}}
  {{/signal.threshold_result.terms}}
{{/context.alerts}}

Add an EQL statement used to detect alerts.

For example, the following rule detects when msxsl.exe makes an outbound network connection:

Custom query: The query and filters used to retrieve the required results from the Elastic Security event indices. For example, if you want to match documents that only contain a destination.ip address field, add destination.ip : *.

Indicator index patterns: The indicator index patterns containing field values for which you want to generate alerts. This field is automatically populated with indices specified in the securitySolution:defaultThreatIndex advanced setting. For more information, see Update default Elastic Security threat intelligence indices.

Indicator mapping: Compares the values of the specified event and indicator field values. When the field values are identical, an alert is generated. To define which field values are compared from the indices add the following:

You can add AND and OR clauses to define when alerts are generated.

For example, to create a rule that generates alerts when host.name and destination.ip field values in the logs-* or packetbeat-* Elastic Security indices are identical to the corresponding field values in the mock-threat-list indicator index, enter the rule parameters seen in the following image:

Default severity: Select the severity level of alerts created by the rule:

Severity override (optional): Select to use source event values to override the Default severity in generated alerts. When selected, a UI component is displayed where you can map the source event field values to severity levels. The following example shows how to map severity levels to host.name values:

Default risk score: A numerical value between 0 and 100 that correlates with the Severity level. General guidelines are:

Risk score override (optional): Select to use a source event value to override the Default risk score in generated alerts. When selected, a UI component is displayed to select the source field used for the risk score. For example, if you want to use the source event’s risk score in alerts:

Elastic endpoint exceptions (optional): Adds all Elastic Endpoint Security rule exceptions to this rule (see Rule exceptions and value lists).

Rule name override (optional): Select a source event field to use as the rule name in the UI (Alerts table). This is useful for exposing, at a glance, more information about an alert. For example, if the rule generates alerts from Suricata, selecting event.action lets you see what action (Suricata category) caused the event directly in the Alerts table.

Timestamp override (optional): Select a source event timestamp field. When selected, the rule’s query uses the selected field, instead of the default @timestamp field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to Elasticsearch, this avoids missing alerts due to ingestion delays.

Indicator mapping