Investigate¶

Security operations: search the event stream, spot abnormal behaviour, and automatically contain abuse. This whole group needs the Pro tier (OpenSearch); on Core the pages are dormant.

Why Pro

The Investigate group reads the SIEM projection: every governance event normalised and indexed into OpenSearch for fast search and aggregation. OpenSearch is what makes free-text search, field facets, and large-window analytics practical, and it also becomes the audit system of record on this tier. Turn it on with aim.siem.enabled (the standalone.pro.yml overlay). Internals: SIEM.

SIEM¶

Where: Investigate ▸ SIEM · Who: VIEW_SECURITY to view; MANAGE_GATEWAY to manage rules · Editions: Pro

SIEM ▸ Events. A match-expression search and time range drive the over-time chart, a group-by visualization (here severity), and a triage list. The same query grammar powers detection rules, SOAR, and notification routing.

A query-agnostic explorer over the normalised event stream, in three tabs.

Events¶

A search bar and a recursive query builder (the same ALL / ANY / NONE match editor used by detection rules; visual or raw JSON).
An events-over-time histogram with 24h / 7d / 30d presets and a custom date range.
Field facets and a chart that re-renders for any group-by (source / severity / event / model / org / action) × metric (count / spend / tokens / entities) × chart type (bar / line / donut).
A per-request trace to drill into one request's events.

How to query¶

You build a match expression: a tree of conditions combined with ALL (and), ANY (or), and NONE (not). Each leaf matches a field from the event catalogue (source, category, an attribute, outcome). The same grammar powers the SIEM search, detection rules, SOAR rules, and notification routing, so what you learn here transfers everywhere.

{
  "all": [
    { "field": "category", "equals": "guardrail.triggered" },
    { "field": "attributes.action", "equals": "BLOCK" },
    { "any": [
      { "field": "attributes.category", "equals": "SECRET" },
      { "field": "attributes.category", "equals": "PII" }
    ]}
  ]
}

That reads: guardrail events that blocked, where the category was SECRET or PII.

Detection rules and Sigma rules¶

Detection rules are per-tenant rules that watch the stream and fire when a match expression crosses a count threshold over a window. They compile to OpenSearch Alerting / Security Analytics.
Sigma rules let you bring standard Sigma detections; they compile to the same backend.

Detection rule: repeated blocked secrets from one key

Match: category = guardrail.triggered AND action = BLOCK AND category = SECRET
Group by: the offending key
Threshold: count ≥ 5 within 10 minutes
Then: raise a siem.detection event (which you can route to a notification channel, or have SOAR act on).

This catches an application (or a leaked key) repeatedly trying to exfiltrate secrets, without alerting on a single stray match.

UEBA¶

Where: Investigate ▸ UEBA · Who: VIEW_SECURITY to view; MANAGE_GATEWAY to change · Editions: Pro

User and Entity Behaviour Analytics learns a baseline of normal behaviour per entity and flags deviations. Two tabs:

Anomalies. The ueba.anomaly events: the profile that fired, the offending entity (a key or an IP), a grade, and the time.
Sensitivity. A rail of detection profiles, each off by default:
- Key risk (a virtual key behaving unlike its own history)
- Source risk (an IP/source behaving abnormally)
- Admin risk (admin-plane behaviour)
Each profile has an on/off toggle and a grade-threshold slider, with a live "how many would fire" preview and an explanation of the signals it watches. Saving a profile provisions its detector at once.

How a profile turns events into an anomaly:

flowchart LR
    EV["Events for an entity<br/>(a key or an IP)"] --> BASE["Baseline<br/>(its own normal, over a window)"]
    BASE --> SCORE["Score the deviation<br/>(volume, mix, timing, novelty)"]
    SCORE --> GRADE{"Grade ≥ your threshold?"}
    GRADE -->|no| QUIET["No alert"]
    GRADE -->|yes| ANOM["ueba.anomaly event<br/>(shown on Anomalies; routable to alerts / SOAR)"]

Baselines take time

UEBA compares against a learned baseline window, so it is most useful after it has seen normal traffic for a while. Start with profiles off, watch the preview, then enable at a threshold that does not drown you. Internals: SIEM / UEBA.

SOAR¶

Where: Investigate ▸ SOAR · Who: VIEW_SECURITY to view rules; MANAGE_GATEWAY to edit rules; the Actions feed is platform-admin · Editions: all, including Core - containment needs no OpenSearch. Rules matching a finding (detection / correlation / anomaly) need Pro, because that is where those events come from.

SOAR ▸ Rules. A WHEN (match + count-over-window) / THEN (reversible action) builder. Permanent revoke stays manual, so automation can never irrecoverably cut off a tenant.

SOAR is automated abuse containment: when a pattern fires over the event stream, it takes a reversible action. Two tabs:

Rules. Per-org rules in a rail-plus-editor: a match (source / category / attribute) plus a count-over-window (threshold / window / cooldown) plus an action. Actions are alert, quarantine (put the offending key into a reversible SUSPENDED state), and throttle (tighten the scope's rate limit temporarily). There is an apply recommended starter set.
Actions. The containment-action review (platform admin; the feed is global): filter by disposition, mark an action CONFIRMED or FALSE_POSITIVE, and un-suspend a quarantined key.

What a SOAR rule can match¶

Two kinds of event, offered as chips under the match editor so you do not have to know the category names:

Observations — what happened. Guardrail hits, LLM calls, admin logins, config changes. Available on every tier.
Findings — what the platform concluded. A detection, a correlation, or a UEBA anomaly. These come from OpenSearch, so they need the Pro tier; a rule on one contains the subject the finding names.

Matching a finding is how a detection becomes action, not just a line in a list: "when the exfil-pattern correlation fires for a key, quarantine it".

You cannot write a rule on a response — SOAR's own containment actions — and they are not offered. SOAR would be reacting to itself, so such a rule could never fire; to be told when containment happens, route the security.action category on the Notifications page instead.

Why a quarantine does not cascade

A containment is recorded as an event like anything else, so it is fair to wonder whether one quarantine can trigger another. It cannot: the platform tracks what each event was derived from and refuses to feed its own conclusions back into detection. The event detail panel in SIEM ▸ Events shows this as Derived — which observation started the chain, and what directly caused the event you are looking at.

Reversible by design

Automated actions are deliberately reversible: quarantine suspends a key (you can un-suspend it), and throttle auto-reverts. Permanent revoke stays manual, so an automated rule can never irrecoverably cut off a tenant. The throttle action surfaces on the Rate limits page as the amber banner. Internals: SOAR.

SOAR rule: quarantine a key on a guardrail-block burst

Match: category = guardrail.triggered AND action = BLOCK
Group by: the offending key · Threshold: ≥ 10 in 5 minutes · Cooldown: 30 minutes
Then: quarantine the key. The key goes SUSPENDED, a SecurityActionTaken event is recorded and routed to alerts, and an admin can review and un-suspend it from the Actions tab.

SOAR rule: contain on a detection (Pro)

Match: category = detection AND rule = secret-exfil-burst
Group by: the offending key · Threshold: ≥ 1 · Cooldown: 1 hour
Then: quarantine. The detection rule does the pattern work in OpenSearch; the SOAR rule turns its verdict into containment. Threshold 1 is reasonable here because the detection has already counted the burst — do not count it twice.

How long each kind of event is kept

Telemetry is voluminous and findings are not, so they age out separately: 90 days of observations, a year of findings and containment records, by default. That means an investigation can still see what was concluded about a key long after the individual calls have gone. An org can shorten its own searchable window on Settings ▸ Retention; that setting governs telemetry, and findings keep the longer window.

Next: Settings & Profile →, or back to the section map.