security-alert-triage

Files (7)

• SKILL.md
• classification-guide.md · references/
• acknowledge-alert.js · scripts/
• es-client.js · scripts/
• fetch-next-alert.js · scripts/
• kibana-client.js · scripts/
• run-query.js · scripts/

SKILL.md (first lines)

# Alert Triage

Prioritize the Elastic Security alert queue by weighted risk and return ranked entity groups — a starting point before
investigation begins, not an investigation itself.

<!-- begin-partial: preamble -->

## Environment Configuration

This skill executes Elasticsearch operations through the `elastic` CLI. If the
[`elastic` CLI](https://github.com/elastic/cli#configuration) is not installed, tell the user what it is needed for. Do
not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., `GET /`, `GET /_cat/indices`, `GET /{index}/_mapping`,
`GET /{index}/_settings/index.mode`, `POST /_query`). The [Operations](#operations) table at the end of this document
maps each shorthand to the equivalent `elastic` CLI command — always use the CLI rather than calling the HTTP API
directly.

<!-- end-partial: preamble -->

## When to use this skill

Use this skill when:

- An analyst asks "what should I focus on right now?" or "which alerts are most urgent?"
- An analyst wants to prioritize the queue for a specific time window (for example, "last 8 hours")
- An analyst provides a set of alert IDs and asks "which of these are most important?"
- An analyst is starting a shift and needs a ranked starting point before investigation begins

Do not use this skill to investigate a single known alert — use the **security-alert-analysis** skill for that. This
skill does not acknowledge alerts, create cases, or gather per-alert context. Those actions belong in the investigation
phase.

## Scoring model

The score for each alert is computed as:

```text
alert_score = base_risk_score + mitre_boost + status_modifier
group_score = MAX(alert_score across group) + entity_risk_boost + asset_criticality_boost
```

The weights, mirroring the Kibana Agent Builder alert-triage skill, are:

| Signal                | Level                                                                   | Boost |
| --------------------- | ----------------------------------------------------------------------- | ----- |
| MITRE tactic          | Exfiltration, Impact, Command and Control, Lateral Movement             | +30   |
| MITRE tactic          | Credential Access, Privilege Escalation, Defense Evasion                | +20   |
| MITRE tactic          | Persistence, Execution, Initial Access                                  | +10   |
| Workflow status       | Alert is `acknowledged`                                                 | −5    |
| Workflow status       | Alert already attached to a case (`kibana.alert.case_ids` is non-empty) | −5    |
| Entity Analytics risk | `Critical`                                                              | +25   |
| Entity Analytics risk | `High`                                                                  | +15   |
| Entity Analytics risk | `Moderate`                                                              | +5    |
| Asset criticality     | `extreme_impact`                                                        | +20   |
| Asset criticality     | `high_impact`                                                           | +12   |
| Asset criticality     | `medium_impact`                                                         | +6    |

Status modifiers are additive: an acknowledged alert already in a case receives −10 total. Entity Analytics enrichment
is best-effort; when the Risk Engine or asset criticality index is absent, both boosts are 0 and scoring continues
normally.

## Process

### Step 1 — Establish scope

Decide:

- **Time window**: default 24 hours, range 1–168 hours.
- **Workflow filter**: `"open"` (default) or `"open+acknowledged"` to include acknowledged alerts.
- **Specific alert IDs**: when the user supplies alert IDs, score exactly those and skip the time-window and
  workflow-status filters so a selected alert is never silently dropped regardless of age or status.

Data needed: time window or alert IDs; workflow scope.

### Step 2 — Fetch and score the queue

Run one `POST /_query` with ES|QL. Elasticsearch computes every score field; no arithmetic is needed after the query
returns.

Queue path (no explicit IDs):

```esql
FROM .alerts-security.alerts-* METADATA _id, _index
| WHERE kibana.alert.workflow_status == "open"
    AND @timestamp >= NOW() - 24 hours
    AND kibana.alert.building_block_type IS NULL
| EVAL tactics = COALESCE(MV_CONCAT(kibana.alert.rule.threat.tactic.name, "|"), "")
| EVAL mitre_boost = CASE(
    tactics LIKE "*Exfiltration*" OR tactics LIKE "*Impact*"
        OR tactics LIKE "*Command and Control*" OR tactics LIKE "*Lateral Movement*", 30,
    tactics LIKE "*Credential Access*" OR tactics LIKE "*Privilege Escalation*"
        OR tactics LIKE "*Defense Evasion*", 20,
    tactics LIKE "*Persistence*" OR tactics LIKE "*Execution*"
        OR tactics LIKE "*Initial Access*", 10,
    0)
| EVAL status_modifier = CASE(kibana.alert.workflow_status == "acknowledged", -5, 0)
                       + CASE(kibana.alert.case_ids IS NULL, 0, -5)
| EVAL alert_score = COALESCE(kibana.alert.risk_score, 0) + mitre_boost + status_modifier
| EVAL entity = CASE(
    host.name IS NOT NULL, CONCAT("host:", MV_FIRST(host.name)),
    user.name IS NOT NULL, CONCAT("user:", MV_FIRST(user.name)),
    CONCAT("ungrouped:", _id))
| KEEP _id, _index, @timestamp, entity, host.name, user.name, kibana.alert.rule.name,
       kibana.alert.severity, kibana.alert.workflow_status, kibana.alert.risk_score,
       mitre_boost, status_modifier, alert_score
| SORT alert_score DESC, @timestamp DESC
| LIMIT 100
```

For the explicit-IDs path, replace the `WHERE` clause with `WHERE _id IN ("<id1>", "<id2>", ...)` and keep all other
stages, but raise `LIMIT` to the number of IDs (maximum 500) so a selected alert is never truncated. This path also
drops the building-block exclusion on purpose: an alert the analyst selects explicitly is always scored, even if it is a
building block. Kibana keeps that filter on both paths.

For `"open+acknowledged"` scope, change `kibana.alert.workflow_status == "open"` to
`kibana.alert.workflow_status IN ("open", "acknowledged")`.

**Query design notes:**

From elastic/agent-skills, Apache-2.0.

More from elastic/agent-skills