Alert Clusters

Alert Clusters

Since IRIS-NG-v2.0.0, related alerts group themselves into clusters — one row for "this activity", instead of forty rows for forty emails from the same campaign. Clusters get their own list and a full triage workspace, and escalate into cases using the same machinery as single alerts.

Clustering rules

A clustering rule (Settings → Clustering Rules) describes what makes two alerts part of the same activity:

• Conditions select which alerts the rule governs — the same condition builder investigation flows use.
• Correlation keys are the fields that must agree for two alerts to share a cluster: a source host, a username, a mailbox, or several at once.
• A time window bounds the cluster. When the window lapses, the cluster closes and the next matching alert starts a fresh one.

Clustering runs at ingest, synchronously, so a new alert is already in its cluster when it appears in the queue. Rules can be tested against real alerts before enabling, and backfilled across existing alerts to see what a rule would have caught.

Two identity guarantees are enforced in the database, not just in code:

• At most one active cluster exists per rule, customer and key combination — two alerts arriving at the same instant cannot mint duplicates.
• Clusters are customer-scoped by construction. The customer is part of the identity, so one tenant's alerts can never join another's cluster.

Backfill is all-rules, first-match. Running a backfill evaluates alerts against the full rule set, not just one rule — on an instance with broad "catch-all" rules and a large alert history, expect it to create many clusters. Tighten conditions first.

The cluster list

The list shows each cluster's derived severity, owner, status and member count, headed by "N total — M awaiting triage": the awaiting-triage queue is the open clusters nobody owns yet. Filters cover status, severity, owner and customer.

• Severity is derived from the member alerts' severities — ranked by meaning, not by internal id — with an explicit per-cluster override when you disagree. An override is labelled as an override rather than pretending to be derived.
• Statuses are open, investigating, dismissed, escalated and closed. Open and investigating are the active states; reopening a cluster whose key has since produced a newer active cluster is refused rather than minting a duplicate.
• Assigning a cluster notifies the new owner (Notifications).

The triage workspace

Each cluster has a detail page with seven tabs:

• Summary — an editable triage document that saves as you type, alongside the AI triage panel and any attached investigation-flow checklists.
• Alerts — the members, each removable individually. Opening an alert from here deep-links to the alerts page with that alert's detail already expanded.
• Assets and IOCs — everything seen across the cluster, de-duplicated by identity: the same indicator imported by three member alerts is one row, with the alerts it came from.
• Correlation — a graph relating the member alerts, assets and indicators. The graph, the tabs and the counts are built by the same server-side code, so they cannot disagree with each other.
• Timeline — the members over time.
• Activity — a comment feed with @mentions.

Cross-tenant reads return not found, not forbidden — a cluster's existence is itself customer data.

AI triage narrative

With an AI backend configured, a cluster narrative can be generated on demand: what the grouped alerts appear to have in common, what stands out, and what to check first. The usual AI-surface rules apply (AI Features):

• it is cached, and regenerating is explicit;
• a manual edit is never silently overwritten — regeneration over an edited narrative is refused unless you explicitly discard the edit;
• a failed generation is reported as a failure, never stored as if it were content.

Escalate or merge

A cluster escalates into a new case or merges into an existing case using the same paths as single-alert escalation — the members' indicators and assets are imported, and the cluster records which case it became (status escalated). Closing the loop from "forty alerts" to "one case" is the point of the feature.

Notes

• Alerts that match no clustering rule simply stay unclustered; nothing forces membership.
• Deleting a cluster's last member currently leaves an empty cluster behind — dismiss or close it by hand.
• The API is additive under /api/v2/alert-clusters/ (API Reference); existing alert endpoints and clients are unchanged.