| applies_to |
|
||||||
|---|---|---|---|---|---|---|---|
| products |
|
||||||
| description | Create detection rules that trigger on machine learning anomaly detection job results. |
{{ml-cap}} rules generate alerts when a {{ml}} {{anomaly-job}} discovers an anomaly that exceeds a defined score threshold. Unlike other rule types, {{ml}} rules do not require you to write a query. Instead, they rely on {{ml}} jobs that continuously model normal behavior and flag deviations.
{{ml-cap}} rules are the right fit when:
- You want to detect behavioral anomalies that are difficult to express as static queries, such as unusual login times, atypical data transfer volumes, or rare process executions for a given user or host.
- A {{ml}} job is already active (or you plan to enable one) that models the relevant behavior.
- You want adaptive detection that automatically adjusts to changing baselines without manual threshold tuning.
{{ml-cap}} rules are not the best fit when:
- You can define the exact pattern you're looking for. Use a custom query rule or EQL rule instead.
- You need a count-based threshold. Use a threshold rule instead.
- You need to compare events against threat intelligence. Use an indicator match rule instead.
{{ml-cap}} rules require the appropriate {{stack}} subscription or {{serverless-short}} project feature tier, and you must have the machine_learning_admin role in {{stack}} or the appropriate user role in {{serverless-short}}. You also need at least one {{ml}} {{anomaly-job}} active or configured to start.
For an overview of using {{ml}} with {{elastic-sec}}, refer to {{anomaly-detect-cap}}.
{{ml-cap}} rules depend on their associated {{ml}} jobs running continuously. If a job stops, the rule cannot evaluate anomaly results and won't generate alerts. You can manage job status in two ways: from the {{ml}} jobs setting UI or the rule's details page.
{{ml-cap}} jobs associated with {{elastic-sec}} prebuilt rules are managed in a dedicated interface:
- Find {{siem-rules-ui}} in the navigation menu or use the global search field.
- Select the settings menu in the upper-right corner of the page, then select ML job settings.
From there you can view, start, and stop all {{ml}} jobs associated with prebuilt detection rules.
::::{note} You can also create custom {{ml}} jobs in the {{ml-app}} app and reference them when creating custom {{ml}} rules. Custom jobs are managed in the {{ml-app}} app, not the {{siem-rules-ui}} page settings menu. ::::
You can also check and control job status for a specific rule:
- Find {{siem-rules-ui}} in the navigation menu or use the global search field, and select the rule name in the Rules table.
- In the Definition section of the rule's details page, check whether the required {{ml}} jobs are running.
- Use the toggles to start or stop each job.
If a required {{ml}} job isn't running, an error indicator appears in the Last response column of the Rules table. Select the indicator to see which jobs are affected.
The following examples use the detections API request format to show how {{ml}} rules are defined. Each example is followed by a breakdown of the {{ml}}-specific fields. For common fields like name, severity, and interval, refer to the detections API documentation.
This rule monitors a rare-process {{ml}} job for anomalies on Linux hosts.
{
"type": "machine_learning",
"name": "Anomalous process execution on Linux",
"description": "Alerts when a machine learning job detects a rare process execution on a Linux host.",
"machine_learning_job_id": "v3_linux_anomalous_process_all_hosts",
"anomaly_threshold": 75,
"severity": "low",
"risk_score": 21,
"interval": "15m",
"from": "now-16m"
}| Field | Value | Purpose |
|---|---|---|
type |
"machine_learning" |
Identifies this as a {{ml}} rule. No query, language, or index fields are used. |
machine_learning_job_id |
"v3_linux_anomalous_process_all_hosts" |
The ID of the {{anomaly-job}} to monitor. Accepts a single string or an array of strings for multiple jobs. If the job is not running, it starts automatically when the rule is enabled. |
anomaly_threshold |
75 |
Minimum anomaly score (0-100) required to trigger an alert. A score of 75 surfaces only strong deviations. Lower values (25-50) cast a wider net; higher values (75-100) produce fewer, higher-confidence alerts. |
interval / from |
"15m" / "now-16m" |
{{ml-cap}} rules often use a longer interval than query-based rules because anomaly results are produced on the job's bucket-span schedule rather than in real time. |
This rule monitors several login-related {{ml}} jobs and suppresses repeated alerts by user.
{
"type": "machine_learning",
"name": "Unusual login activity detected",
"description": "Alerts when any login-related ML job detects anomalous authentication behavior.",
"machine_learning_job_id": [
"auth_high_count_logon_events",
"auth_rare_source_ip_for_a_user",
"auth_high_count_logon_fails"
],
"anomaly_threshold": 50,
"severity": "medium",
"risk_score": 47,
"alert_suppression": {
"group_by": ["user.name"],
"duration": { "value": 1, "unit": "h" },
"missing_fields_strategy": "suppress"
},
"interval": "15m",
"from": "now-16m"
}| Field | Value | Purpose |
|---|---|---|
machine_learning_job_id |
["auth_high_count_logon_events", ...] |
An array of job IDs. The rule monitors all three jobs and fires when any one produces an anomaly exceeding the threshold. |
alert_suppression.group_by |
["user.name"] |
Groups anomaly alerts by user to reduce noise when the same user triggers multiple jobs or repeated anomalies. Only anomaly-result fields (including influencer fields configured in the {{ml}} job) are available for suppression. |
alert_suppression.duration |
{ "value": 1, "unit": "h" } |
Suppression window of 1 hour. Accepted units are s (seconds), m (minutes), and h (hours). |
The following settings appear in the Define rule section when creating a {{ml}} rule. For settings shared across all rule types, refer to Rule settings reference.
{{ml-cap}} jobs : The {{anomaly-jobs}} whose results the rule evaluates. Select one or more jobs. If a selected job is not active, it starts automatically when the rule is enabled.
Anomaly score threshold : The minimum anomaly score (0-100) above which the rule generates alerts. Only anomalies that meet or exceed this score trigger alerts.
Suppress alerts by (optional) : Reduce repeated or duplicate alerts by grouping them on one or more fields. Only anomaly fields are available for suppression because {{ml}} alerts do not contain source event fields. For details, refer to Alert suppression.