/kibana-cases

name: kibana-cases
description: >
  Manage investigation and incident cases across Elastic Security, Observability,
  and Stack Management — create, search, update, and enrich cases with comments, alerts,
  events, and observables (IOCs). Use when tracking incidents, correlating alerts
  to a case, adding investigation notes, updating status or severity, or managing
  triage output.
metadata:
  author: elastic
  version: 0.2.0
  universal: true
compatibility: Kibana 8.x or 9.x with matching Elasticsearch — self-managed, Elastic
  Cloud Hosted, or Elastic Cloud Serverless. Cases are partitioned by solution owner
  (`securitySolution`, `observability`, or `cases`). Observables (IOCs) require a
  9.x Kibana. Requires `elastic` CLI with the `kb cases` command group.

Kibana Cases

Create, search, update, and enrich Elastic cases across Security, Observability, and Stack Management. You have full read **and write** access — never claim read-only access. Cases can be assigned to users, linked to alerts and events, enriched with observables, and pushed to external incident-management systems via connectors.

<!-- 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 -->

Solution context — highest-priority rule

Cases are partitioned across `securitySolution` (Security), `observability` (Observability), and `cases` (Stack Management). A user works in exactly one. Operating in the wrong solution — or fanning out across all three — is always a bug.

**Before any cases operation, the solution `owner` must be set**, sourced ONLY from the user naming it in plain language ("in Security", "obs cases", "Stack Management", etc.) in the current or an earlier message. Topic-keyword inference does not count. If the owner is unset, your only valid action is to ask, verbatim:

> "Which Elastic app is this in — Security, Observability, or Stack Management?"

Once set: pass it as `owner` on every create and as the `owner` filter on every `_find`; treat it as fixed unless the user explicitly switches. Never:

• Call `_find` (or any read) with multiple `owner` values to "cover all three" — this is the most common failure.
• Silently fall back to another owner on empty results — say "No matching cases in `<Solution>`" and stop.
• Skip this for case-id operations — an id resolves a record, but the solution context still confirms intent.

Examples:

• "find the case about the failing payment service" → ask first.
• "investigating a Suricata alert in Security — find related cases" → `securitySolution` (named directly).
• (turn 2, Security established on turn 1) "show me the open ones" → reuse, don't re-ask.
• "close case abc-123" with no prior context → ask first.

Solution profiles

| Solution | Typical triggers | Observables (IOCs) | `critical` severity means | | ------------------ | ------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------- | | `securitySolution` | SIEM detection rules, threat hunts, manual triage | **Primary use case** — proactively track IPs, domains, file hashes, URLs | active attack in progress | | `observability` | APM errors, SLO violations, metric/log anomalies | Rarely relevant — do not proactively suggest | complete service outage | | `cases` | General-purpose, no domain assumptions | Rarely relevant | — |

Domain notes: `status` flows `open` → `in-progress` → `closed`. `assignees` are user profile UIDs, not usernames. `severity` is one of `low`, `medium`, `high`, `critical`.

Process

1. **Establish solution context, then classify the task.** Confirm the `owner` per the rule above. Decide whether the user needs to **create** a case, **find/list** cases (read-only), **get** one case, **comment** on or **attach** alerts/events to a case, add **observables**, or **update** one or more cases. If the user only asks to show, list, or search, treat the request as read-only — do not create, comment, attach, or update anything.

2. **Check for an existing case before creating one.** When triaging, first search so you do not create duplicates. Call `GET kbn:/api/cases/_find` filtered to the owner, or `GET kbn:/api/cases/alerts/{alertId}` to see whether a specific alert is already attached to a case.

• **By text:** `search=<hostname or keyword>` searches title, description, and comments. Add `status=open` to limit

to active cases.

• **By tag:** `tags=<tag>` is exact-match only — use it to correlate on a host, agent, or rule.

Report the exact `total` count and each matching case verbatim. Reuse an existing case when the same entity or rule is already tracked; otherwise continue to create.

3. **For create tasks, build the payload.** Call `POST kbn:/api/cases` with `title`, `description`, `tags`, `severity`, the resolved `owner`, a `connector` (use the `none` connector unless the user asks to wire an external system), and `settings.syncAlerts` (default `true`). Confirm the create with the user before writing, then report the returned case `id` verbatim.