Alerts

Alerts is a tab on Security posture. Alerts come from Elastic Security or any detection system that writes to an alert index. The gateway ingests them, adds a one-line summary to each, and tracks a disposition shared by the team. Ingest and dispositions are free; alert investigation is paid.

Ingest sources

Ingest configuration at the bottom of the page offers two sources, which can run together. With polling, the gateway tails the alert index on an interval, so the delay is about one interval. With the webhook, a Kibana detection rule calls the gateway as it fires, with no delay.

Each ingested alert costs one model call for its summary. When a push runs past the summary time budget, the remaining alerts are stored without a summary and Ingest configuration shows how many.

Set up polling

Prerequisites

• The alert index is in the index whitelist, RST_INDEX_WHITELIST.
• ES_USER can read .alerts-security.alerts-* and the backing indices .internal.alerts-security.alerts-*.

Steps

1. Under Ingest configuration > Polling, enter the read alias in Alert index, for example .alerts-security.alerts-default. Do not enter a .internal.* backing index.
2. (Optional) Change Poll interval (seconds). The default is 10.

The first pull reaches back by RST_ALERT_INGEST_LOOKBACK (default 1h), then follows a cursor. If the index already holds weeks of detections, set it to a value such as 7d. Clear Alert index to turn polling off.

Set up the webhook

Steps

1. Under Ingest configuration > Webhook, set an Auth secret.
2. In Kibana, create a Webhook connector with URL https://<hostname>/api/alerts/ingest and header X-RST-Alert-Token: <secret>.
3. If the gateway sets RST_GATEWAY_SHARED_SECRET, add the header X-RST-Gateway-Token as well, or every push gets a 401.

One push carries up to 200 alerts. Without a secret, /api/alerts/ingest returns 403.

Ingest parameters

Alert overview

Alert overview shows the alerts in the window, the critical and high count, and the handled and false-positive count. Below them are the Alert rate chart (1 hour, 6 hours, 24 hours, 7 days) and the noisiest rules in the window.

Work the feed

New alerts appear at the top of the Alert feed. Scrolling down pauses the feed; returning to the top resumes it. With Group on, alerts with the same rule and subject fold into one row. To keep a filter combination, select Save current under Views.

The dispositions are Open, Handled, False positive, and Escalated, shared by the team. Select several rows, then select Mark handled, Mark false positive, or Reopen; the change can be undone. Handled and false-positive alerts are hidden until you select Show handled / false positives.

Select a row to open the alert details: AI summary, rule, subject, Raw JSON, and the Asset context (business name, criticality, owner, and so on) matched from the Asset inventory. Select Send to triage to hand the alert to Triage.

Alert investigation

An investigation gathers evidence around the alert's subject (host, IP, account) within a time window: asset and identity enrichment first, then several rounds of retrieval, then a verdict. It usually takes 30 to 60 seconds. To start one, select Investigate in the alert details.

At the bottom of the report you can change the Disposition, select Make a detection rule to hand off to Detection rules, select Push the conclusion to send it to Outbound channels, or export a Markdown report from Export / share. Every investigation is archived in Investigations.

The 10.30.x.x in the screenshot comes from cloud masking mode, which replaces IPs and accounts before they reach the model. Air-gapped and private modes show real values.

Alert push

New alerts above a severity threshold are pushed to Feishu, DingTalk, WeCom, Teams, Slack, or email. Set the threshold and destinations in Outbound channels.