-
-
Notifications
You must be signed in to change notification settings - Fork 0
Version 2 Preview
Version 2.0.0 was released on 2026-09-04 as
IRIS-NG-v2.0.0:mainis now the version 2 line, published images carry it, and the Changelog documents it. Before upgrading, read Upgrading below — the jump is one-way and a database backup is the only road back. A few validation items were still open at release; they are listed at What was still open at release.
Version 2 is a single large release that adds a detection-to-coordination pipeline on top of the case management IRIS-NG already does: alerts can arrive by email, be grouped into clusters, carry investigation checklists, and — when an incident outgrows a single case — be worked in a shared war room. Around that, the org gains a persistent asset registry, a real notification system, and a personal home page.
It is one release rather than six, because the pieces interlock: mail creates alerts, clustering groups them, flows attach to what clustering produced, and war rooms coordinate what the clusters revealed.
Each area has its own operational page: Mail Rules · Alert Clusters · Investigation Flows · Customer Asset Registry · Notifications · War Rooms. This page stays the tour.
| Area | State |
|---|---|
| Mail ingestion, mail rules, AI mail triage | Code complete — pending a live mailbox test |
| Alert clusters and clustering rules | Code complete — including the cluster triage workspace |
| Investigation flows | Code complete |
| Customer asset registry | Code complete |
| Notifications, Home, Following | Code complete |
| War rooms, situation reports | Code complete |
| Case UI refresh | Largely done — Assets, Indicators, Tasks, Evidence and Summary rebuilt; Notes and Graph pending |
| Settings shell, announcement banners | Code complete |
| Upgrade rehearsal from 1.4.x | Done — full migration chain verified against cloned real data |
| Live AI backend pass | Not yet done |
| Full browser pass | Not yet done |
| Release (bump, images, tag) | Released 2026-09-04 as IRIS-NG-v2.0.0 |
"Code complete" means the feature is built and covered by automated checks and targeted two-account experiments, not that it has been through a full analyst walk-through. See What was still open at release.
Operational detail: Mail Rules.
A mailbox becomes an alert source. IRIS-NG polls IMAP on a fixed interval and turns messages into alerts according to mail rules you define.
- Rules are ordered and first-match wins. Each rule is a set of conditions on the subject, sender, recipient or body (regular expressions, AND-ed together) plus the alert defaults to apply — customer, severity, classification, source, and a title template.
- Actions are create or ignore. A dedicated ignore rule silences vendor digests and auto-replies without them reaching the alert queue.
- Every message is logged, whether it produced an alert, matched nothing, was ignored, was a duplicate, or errored. The ingest log is how you tune rules against real mail.
- Nothing loops. A message that cannot be parsed is recorded and marked seen rather than being retried forever, and a bad regular expression fails closed — it matches nothing rather than matching everything.
- Optional AI triage refines the rule's severity and classification against your live catalogs and extracts indicators from the body. It is advisory: the rule's own defaults apply if the model is unavailable or unsure, and what the model suggested is recorded on the ingest log entry so you can audit it.
Configuration lives on a Mail tab in server settings, with connection tests for IMAP and SMTP and a Poll now button. Mail passwords are write-only — they are stored and used, but never returned by the API or pre-filled into the form; the settings page tells you whether a password is set, not what it is.
Mail uses the Python standard library only. No new dependency, no external service.
Operational detail: Alert Clusters.
Clustering rules describe what makes two alerts part of the same activity: a set of conditions that select which alerts the rule governs, one or more correlation keys (the fields that must agree — a source host, a username, a mailbox), and a time window.
An alert that matches joins the open cluster for its key values, or opens a new one. There is at most one open cluster per rule, customer and key combination, so two alerts arriving at the same instant cannot produce duplicate clusters. When the window lapses, the cluster closes and the next alert starts a fresh one.
Clusters are scoped to a customer by construction — the customer is part of the identity, so one tenant's alerts can never join another's cluster.
A cluster triage narrative can be generated on demand: what the grouped alerts appear to have in common, what stands out, and what to check first. It is cached and can be regenerated or edited by hand; a manual edit is never silently overwritten by a later regeneration.
Rules can be tested against real alerts before enabling and backfilled across existing ones, so you can see what a rule would have caught.
Clusters are worked from their own pages, not just listed:
- The cluster list shows each cluster's severity, owner and status, and counts the open clusters nobody owns yet — the awaiting triage queue.
- Severity is derived from the member alerts' severities, with an explicit override when you disagree; an override is labelled as such rather than pretending to be derived.
- Statuses are open, investigating, dismissed, escalated and closed. At most one active cluster exists per rule, customer and key combination, and reopening a cluster whose key has since produced a newer active one is refused rather than minting a duplicate.
- The detail page carries the member alerts (removable individually), the assets and indicators seen across the cluster — de-duplicated by identity, so the same indicator imported by three alerts is one row — a correlation graph relating alerts, assets and indicators, a timeline, an activity feed with comments and @mentions, and an editable summary document that saves as you type.
- Escalate or merge: a cluster escalates into a new case or merges into an existing one using the same machinery as single-alert escalation, importing the members' indicators and assets. An escalated cluster records which case it became.
- Alerts open pre-expanded when reached from a cluster — a deep link to one alert lands on the alerts page with that alert's detail already unfolded.
Operational detail: Investigation Flows.
An investigation flow is a named checklist with ordered steps, some marked required. Conditions decide which alerts or clusters it attaches to — the same condition builder the clustering rules use.
- Flows attach at ingest, so an analyst opening an alert finds the checklist already there, in the alert's own expanded view.
- A flow can target alerts, clusters, or both. A cluster-targeted flow attaches once, when the cluster is created, not once per member alert.
- Steps are marked done or skipped, with a note and a record of who did it.
- Incomplete required steps are surfaced as an advisory count — nothing is blocked. The checklist is there to make sure the obvious things happen, not to gate the analyst.
- Editing a deployed flow preserves analyst progress. Steps are matched by identity on save, so renaming or reordering a step does not discard the state anyone recorded against it.
Operational detail: Customer Asset Registry.
Assets currently live inside cases. Version 2 adds a persistent registry per customer, so a host is one entity across every case and alert it ever appeared in.
-
Identity is the customer, the normalised asset name and the type. Names are matched
case-insensitively with surrounding whitespace trimmed, but nothing else is normalised —
hostandhost.corp.localare deliberately different machines. - Analyst curation is never overwritten. Criticality, environment, owner and notes are yours; automatic sync only fills what is unset and only ever raises a compromise status from unknown — an explicit "not compromised" stands.
- Sightings are computed live — every case and alert the asset appeared in, filtered to what you are allowed to see, with an explicit count of what was withheld rather than a silently short list.
- Changes are audited in their own log, so "when did this become critical, and who said so" is answerable across the whole registry.
- The registry fills itself in from ordinary work — creating a case asset, escalating an alert, promoting a timeline observation, importing a case. Scan cases backfills it from your existing history in one pass.
- CSV import and export, with per-row errors on import rather than an all-or-nothing failure.
The detail panel shows the asset's overview, its sightings, the master-timeline events it is linked to, and its change history.
Operational detail: Notifications.
A notification system replaces guessing what happened while you were away.
- A global bell in the header, alongside the existing per-case updates bell (Case Notifications). The per-case bell answers "what changed in this case"; the new one answers "what was addressed to me".
- An event catalog covering mentions, task assignment, case assignment and updates, alert assignment and escalation, review requests, war-room membership and messages, and published situation reports.
- @mentions work in every comment surface and in war-room chat. Mentioning yourself notifies you — typing a login is an explicit address, so it is not treated as incidental self-activity.
- Per-user preferences — a matrix on your profile page of in-app and email per event — layered over org defaults an administrator sets. Anything you do not override inherits the org default.
- Email delivery over SMTP, off by default.
Home becomes the default landing page after login: your open alerts, your pending tasks, recent case activity, and what you follow. Following is a star on cases and alerts; the home card lists the objects you follow, and a follower count appears on the case header. Objects you cannot see are never revealed by a count.
An Overview page gives a denser, sortable view of cases than the dashboard tiles.
Operational detail: War Rooms.
A war room is a persistent, multi-case workspace for an incident that has outgrown one case — the first thing in IRIS-NG that is genuinely about several cases at once.
- Membership and roles — lead, responder, observer. The last lead cannot be removed, and members can leave on their own.
- Statuses — open, active, standby, closed. Only a closed room is read-only.
- A stream with chat, replies, topics, pins, polls, slash commands, and tokens that link a case, asset or indicator inline as a chip. Alongside the messages, lanes show activity mirrored from the linked cases and a system lane derived from what actually happened in the room.
- Room tasks on a board, room notes with folders, and timelines — read-only views of the linked cases' timelines plus room-level timelines for coordination annotations. Case data is only ever read; the case pages remain the source of truth.
- Situation reports — drafted, revised and published, with every published version retained as a revision, and Markdown / HTML / print exports.
- AI-drafted situation reports compose a draft from the linked cases' summaries and the room's own activity. The draft lands in the editor as a draft. AI never publishes.
-
Teams — named groups inside a room, so
@ir-leadsreaches everyone in it. Teams group people who are already members; they never grant access.
Membership is not case access. Being in a room does not let you read a case you could not read otherwise — the stream, the correlation view and the cases list all filter per viewer, and a case you cannot see is marked as inaccessible rather than quietly dropped.
The correlation engine is unchanged, and so is every /api/v2/correlation/ endpoint —
existing API clients keep working exactly as documented in IOC Correlation.
What changes is where you work with the results. War rooms gain a discovery panel listing correlated case groups, each with promote to war room — which creates a room, attaches the cases, and seeds the room summary and its first situation report from the correlation narrative you already reviewed and edited. Rooms are never created automatically.
Inside a room the shared-indicator table, the relationship graph, campaign tagging, the STIX export and the MISP campaign push all operate on the room's attached cases. Outbound sharing keeps the same TLP restrictions, including reporting how many indicators were withheld — a partial export never looks complete.
Case pages gain an in-page header carrying the case identity, its customer, owner, classification, severity and state, the follow control, and a compact actions menu. State and severity are editable from the header — and the state control carries the same reviewer-before-close requirement as the rest of the product, described in Case Lifecycle, so it is not a way around it.
The Assets, Indicators, Tasks and Evidence tabs are rebuilt on a shared pattern: a searchable master list beside a detail panel with its own tabs — details, linked objects, the object's timeline appearances, its history, comments — and inline editing for the common fields. Objects can be linked and unlinked from the panel; linked evidence shows what the item actually is — type, size, hash, custody, where the drive physically sits — and flags an item with no hash recorded, because that is a finding. Everything drives the existing machinery: the same endpoints, the same modals as full editors, and the previous table views stay reachable behind a toggle. The Tasks page adds a kanban board and a dependency-tree view beside the flat table, and the Summary page places the AI commentary and the analyst's case summary side by side.
Navigation is re-sectioned — Operations (alerts, alert clusters), Investigation, Intel (the correlation workspace, now its own page) and Manage — and the administration pages gather under a single Settings entry with a shared rail, where mail rules, clustering rules, investigation flows and notification defaults each get their own page. Administrators can also publish announcement banners shown to every user until dismissed.
Everything the case page already does is untouched by this work: the AI executive summary, the case chat bars, the dual timeline and its running analysis panel (Dual Timeline, AI Features), and the artifact imports all behave exactly as they do today.
This is a major version, but the compatibility promises that make IRIS-NG a drop-in fork still hold:
-
The API stays compatible. Existing n8n workflows, modules and API clients keep
working. Everything new is additive under
/api/v2/. See API Reference. - The database is additive only — new tables and new nullable columns, nothing renamed or removed.
- No new permission bits. Every new feature is gated on the permissions you already manage, plus per-customer and per-case scoping.
- Existing AI surfaces are unchanged, and every new AI surface follows the same rules: advisory, cached, editable by hand, and never authoritative (AI Features).
- No new runtime dependencies for mail or notifications.
Version 2 is on main and released as
IRIS-NG-v2.0.0,
with published images and chart 1.0.0 — a fresh install follows
Getting Started unchanged, and a full clone-build-boot of main
has been verified end to end.
To move an existing source install from 1.4.x:
# the only road back — see Upgrading below
docker exec iriswebapp_db pg_dump -U postgres -Fc iris_db > iris_db_pre_v2.dump
docker exec iriswebapp_db pg_dump -U postgres -Fc iris_tasks > iris_tasks_pre_v2.dump
git fetch --all
git reset --hard origin/main
docker compose -f docker-compose.dev.yml up -d --build --force-recreatemain is a sanitized snapshot whose history is replaced on publish, so git pull
can fail on it; git reset --hard origin/main is the reliable update step. If you
had been following the earlier dev-branch preview, that branch is superseded —
move to main the same way.
Migrations run themselves on first boot, and the new features stay inert until you configure mail rules, clustering rules or flows. Returning to 1.4.x means restoring the database backup and checking out a 1.4.x tag — see below for why the backup is not optional.
The upgrade is a single jump from 1.4.x. Schema migrations apply automatically at boot, as they do today, and new tables are created on first start.
The full chain has been rehearsed against a clone of real 1.4.x data: every migration applies in one boot, and every pre-existing row survives. Two things that rehearsal proved are worth planning around:
- Take a database backup first. The jump is one-way — once version 2 has booted, the database is migrated forward and 1.4.x code refuses to start against it. Restoring the backup is the rollback.
-
Rebuild the images (
--build). Part of the interface ships as static assets baked at build time; containers recreated without a rebuild serve the old ones.
The full step-by-step procedure, including verification and the rollback commands, is on Upgrading to Version 2.
Version 2.0.0 shipped with three validation items deliberately still open — worth knowing if you lean on the affected surfaces:
- A live mailbox test — mail ingestion has been exercised end to end against test messages, but not yet against a real IMAP and SMTP server with real credentials.
- A live AI backend pass — the new AI surfaces have been proven with injected test clients (which verifies the plumbing and what gets sent, not model output quality), and two of them — the asset and indicator profiles — have produced real output against a configured backend. The rest have not yet had a live run.
- A full browser pass across every new page. Substantial portions have had screenshot-driven browser review during development; a systematic sweep has not happened.
Everything else — the release itself, image verification, and the upgrade rehearsal — is done.