Introducing iris-ng: A MISP-Native, AI-Assisted Fork of DFIR-IRIS

DFIR-IRIS has long filled an important gap in the incident response ecosystem: a free and open-source platform for managing investigations, sharing technical details, tracking evidence, documenting timelines, and collaborating across active cases. The official DFIR-IRIS project describes itself as a collaborative incident response platform designed to help teams streamline investigations and work together in real time.

I have been using DFIR-IRIS as a practical foundation for incident response workflows, automation, and case documentation. Over time, I found myself wanting tighter integration between case management, threat intelligence, MISP, analyst notes, evidence, tasking, and AI-assisted review. That led to iris-ng, my community fork of DFIR-IRIS.

Repository: https://github.com/zach115th/iris-ng

What is iris-ng?

iris-ng is a community fork of DFIR-IRIS v2.5.0-beta.1 focused on continuing practical incident response platform development while preserving compatibility with existing IRIS-style workflows, integrations, and operational patterns. The fork’s README describes the project as a DFIR-IRIS fork with native MISP integration, MISP nomenclature alignment, and an in-tree AI assistant layer.

The goal is not to replace the original DFIR-IRIS project. The goal is to build on it in a direction that supports modern incident response operations: structured casework, threat intelligence exchange, analyst augmentation, evidence provenance, and automation-friendly APIs.

Why fork DFIR-IRIS?

DFIR-IRIS is a strong foundation, but my use case needed faster movement around several areas. Incident response platforms should not just store case data — they should help analysts connect case facts, threat intelligence, indicators, evidence, tasks, and timelines into an operational picture.

The fork rationale notes that iris-ng was forked from DFIR-IRIS tag v2.5.0-beta.1, preserving the original LGPL-3.0 license and attribution to Airbus CyberSecurity and the DFIR-IRIS community. It exists to continue platform evolution while preserving compatibility with the existing IRIS API surface and on-disk database, so existing workflows, custom modules, and external integrations can continue working without major changes.

That compatibility matters. Many teams build automation around their case management platform. Breaking those integrations just to add features would defeat the purpose.

Native MISP synchronization

One of the most important changes in iris-ng is native MISP synchronization.

The fork adds a native MISP sync module under source/iris_misp_sync_module/. The intended mapping is straightforward: IRIS cases map to MISP events, and IRIS IOCs map to MISP attributes. The IOC’s TLP drives MISP distribution and tagging behavior.

That matters because incident response casework and threat intelligence are often separated by tooling. Analysts may track the investigation in one platform, publish indicators in another, and then maintain separate notes or spreadsheets to reconcile what moved where. iris-ng aims to reduce that friction.

In practical terms, the objective is:

• A case can become a MISP event.
• An IOC can become a MISP attribute.
• TLP handling can influence sharing behavior.
• Case context and threat intelligence can stay aligned.
• Analysts can spend less time manually copying indicators between tools.

MISP nomenclature alignment

MISP has its own attribute types, conventions, and taxonomies. DFIR case tools may describe indicators differently. iris-ng addresses that by aligning IOC types to MISP terminology through IocType.type_taxonomy, with AI fallback support for cases where there is no clean one-to-one mapping.

This is a small architectural detail with a large operational impact. If a case platform calls something one thing and MISP expects another, every sync operation becomes a translation problem. Done poorly, that creates bad attributes, weak tags, inconsistent enrichment, and analyst cleanup work. The purpose of this alignment is to make MISP synchronization less brittle and more useful.

AI-assisted incident response workflows

iris-ng adds an in-tree AI assistant layer under source/app/iris_engine/ai/. The README lists several AI-assisted features, including executive case summaries, case-scoped chat across case-detail tabs, per-event AI analysis, MITRE ATT&CK and Unified Kill Chain phase suggestions, IOC extraction from note text, AI-suggested evidence types, and AI-suggested case templates.

The intent is not to replace analysts. It is to reduce repetitive cognitive load. Good incident response still depends on evidence, context, and professional judgment. AI can help summarize, classify, suggest, and surface relationships, but it should not invent facts or silently make decisions. In iris-ng, AI assistance is treated as an analyst-support layer, not an authority.

The executive summary feature is especially important. The README describes it as a multi-pass map-reduce summary panel designed to handle larger cases without exceeding local-model context windows. That design choice matters because local models are useful for privacy-sensitive DFIR environments, but they often have practical context limits. A map-reduce approach makes AI summarization more realistic for large cases.

The Executive Case Summary panel — AI-generated, cached, and stamped with model, prompt version, generation time, and content hash. The map-reduce approach handles large cases without hitting local-model context limits.

Case-scoped AI chat

Another major feature is case-scoped chat across six case-detail tabs:

• Notes
• Timeline
• Assets
• IOC
• Tasks
• Evidence

Each area of a case has different analytical requirements. A timeline question is not the same as an evidence question. A tasking question is not the same as an IOC question. By scoping the assistant to the relevant case area, iris-ng can support more focused analysis and reduce irrelevant context. That is important for both usefulness and hallucination resistance.

The Notes Assistant panel on the Notes tab. Pre-built prompt suggestions help analysts ask the right questions quickly. The assistant cross-references timeline, IOCs, and assets when needed.

Event-level analysis

The fork also includes a per-event AI analysis right drawer. This is useful because investigations are often built one event at a time. Analysts need to know whether an event is routine, suspicious, related to another artifact, or part of a larger attack chain. Event-level assistance can help with first-pass interpretation, triage comments, and timeline enrichment. The analyst remains responsible for validation. The AI layer should help analysts move faster, not encourage them to skip verification.

The Timeline Analysis panel gives a structured cross-event narrative: what the timeline tells us, what remains uncertain, and where to investigate next. Generated by Claude Sonnet 4.6.

The per-event AI analysis right drawer — triggered from any timeline event. Surfaces what the event implies, suggested ATT&CK mappings with confidence ratings, and related events already in the case.

ATT&CK and Unified Kill Chain suggestions

iris-ng includes MITRE ATT&CK and Unified Kill Chain v1.3 phase suggestions when creating or editing events. This helps standardize how analysts describe activity. During an incident, different responders may use different language for the same behavior. Mapping activity to recognized frameworks gives the team a common vocabulary — one that also helps later when producing executive summaries, technical reports, lessons learned, and detection engineering follow-up.

The working timeline view. Events are tagged with MITRE ATT&CK technique IDs. Promote, Reject, and Explain actions on each event let analysts triage and annotate directly from the timeline.

The Explain AI panel for a scheduled-task LOLBIN event. It describes what the detection covers, reconstructs what likely happened based on the log data, and gives a concrete triage hint — verify whether the binary was signed and check Task Scheduler for persistence flags.

IOC extraction from notes

Analyst notes often contain indicators before they are formally promoted into an IOC table. iris-ng includes IOC extraction from note text with type validation and a noise-flag affordance. During an investigation, analysts may paste logs, URLs, IP addresses, file hashes, usernames, hostnames, or email addresses into notes. Some are meaningful indicators. Some are noise. A useful platform should help identify candidates while letting the analyst decide what belongs in the case record.

The IOC editor showing provenance back-links: which note the IOC was sourced from, using backfill substring match. The MISP Report tab is also visible — each IOC can be reviewed in context of its MISP sync state.

Evidence, provenance, and relationships

A case management platform becomes much more useful when relationships are explicit. iris-ng adds Asset-to-Evidence linking and IOC-to-Note provenance back-links, complementing the existing IOC-to-Asset relationship.

That is important for defensibility. If an IOC appears in a case, an analyst should be able to answer:

• Where did it come from?
• Which note mentioned it?
• Which asset is associated with it?
• What evidence supports it?
• Was it extracted, manually entered, enriched, or imported?

Provenance is not just a nice feature. In incident response, it directly supports confidence, reviewability, and reporting.

The Assets table. Compromise status, linked IOCs, and tags are all visible at a glance. The inline detail pane below shows the full asset record without requiring a modal open.

Asset-to-Evidence and Asset-to-IOC relationships in the asset editor. WS-FIN-07 links directly to its disk image evidence and the phishing IOC — both relationships navigable from the asset record.

The evidence editor showing Linked Assets — the evidence item links back to the asset it pertains to. Hash, size, and type are all captured for chain-of-custody documentation.

Better task relationships

iris-ng also introduces Jira-style task linking, including blocks, is blocked by, depends_on, and is depended on by, with advisory cycle-detection warnings.

For small cases, a basic task list is enough. For larger cases, task dependencies become important. One analyst may need disk artifacts before another can finish timeline review. Containment may depend on asset identification. Reporting may depend on evidence validation. Task relationships help make those dependencies visible.

Jira-style task linking in the task editor. Task #2 is blocked by and depends on Task #1 (already Done). The relationship type dropdown and task picker let analysts build dependency graphs without leaving the case workspace.

Admin-editable AI backend settings

AI configuration should not require rebuilding the platform or editing environment variables every time a backend changes. iris-ng adds admin-editable AI backend settings at /manage/settings, including URL, API key, model, and confidence threshold.

The README notes that the AI assistant can be configured to work with a local LM Studio endpoint and that the AI surfaces are tuned against the free openai/gpt-oss-20b model. That makes the project more realistic for lab environments, private DFIR workflows, and teams experimenting with local models.

Deployment model

iris-ng uses a containerized stack with five main services:

• app — Flask, SocketIO, and Celery
• db — PostgreSQL
• rabbitmq — message broker
• worker — Celery worker
• nginx — front-end web server

The README describes this five-container stack and points to the architecture document for the layered backend design, which is organized around blueprints, business logic, data management, models, and Alembic migrations.

For local testing, the README provides a development compose workflow:

git clone https://github.com/zach115th/iris-ng.git
cd iris-ng
bash scripts/generate_dev_certs.sh
bash scripts/iris_helper.sh --init
docker compose -f docker-compose.dev.yml up -d --build

The development UI runs at https://localhost, with an initial administrator account and the generated password available from the app logs.

Project status

iris-ng should be treated as an active community fork and development project, not a polished commercial product. The repository currently documents no published releases, and the project is still evolving.

That is intentional. The immediate purpose is to build, test, and refine practical features for DFIR workflows:

• Case-to-MISP event synchronization
• IOC-to-MISP attribute synchronization
• AI-assisted case summaries
• AI-assisted event analysis
• Better case provenance
• More useful task dependencies
• Local-model-friendly analyst assistance
• Continued compatibility with existing IRIS-style operations

Why this matters

Incident response is not just about collecting artifacts. It is about managing uncertainty under pressure. A useful DFIR platform should help teams answer:

• What happened?
• Which systems are affected?
• Which indicators matter?
• What evidence supports our conclusions?
• What tasks are blocked?
• What needs to be reported to leadership?
• What can be shared with partners?
• What still needs validation?

iris-ng is my attempt to push DFIR-IRIS further in that direction while preserving the parts that already make it useful: open-source accessibility, case-centric workflows, analyst collaboration, and extensibility.

Final thoughts

iris-ng is still early, but the direction is clear: make DFIR case management more connected, more intelligence-aware, and more useful to analysts during real investigations. The project builds on DFIR-IRIS, preserves attribution and licensing, and adds features aimed at operational incident response teams that need MISP integration, AI-assisted review, evidence provenance, and automation-friendly workflows.

View the project:

https://github.com/zach115th/iris-ng

Feedback, testing, and practical DFIR use cases are welcome.