Open source incident case management with DFIR-IRIS and Shuffle

Why open source incident case management needs its own record next to automation

Open source incident case management gives a regulated SOC a single place where alerts, decisions and evidence live together, so the case record can be produced later without reconstructing it from chat logs and automation output. In most designs the split is straightforward: DFIR-IRIS holds the case, Shuffle enriches alerts and runs response playbooks, and the SIEM remains the source of detections. TheHive 5 is the other option a team will meet, but it is a commercially licensed product with per-user plans for on-premises use, so it belongs in the cost comparison rather than in the default open source stack.

The reason the record matters more in regulated environments is that automation changes the evidence. A Shuffle workflow may query a threat intelligence source, disable an account or isolate a host within seconds, and the regulator or auditor will ask who approved that action, what data it used and when it ran. DFIR-IRIS keeps notes, tasks, IOCs, assets and evidence in one case with an audit trail, and it verifies evidence with SHA-256 hashes. Before go-live, confirm that each automated action writes its result back to the case, that analyst decisions are recorded separately from playbook output, and that your retention rules apply to the case database, the attachments and the Shuffle execution history.

Plan the integration as a design decision, not an afterthought. Decide which alerts from the SIEM are promoted to a case automatically, which are grouped and triaged in the IRIS alert queue first, and which playbook steps need an analyst sign-off before they touch production systems. Also confirm how DFIR-IRIS is deployed (its Docker Compose stack runs six services, including PostgreSQL and RabbitMQ), who can administer it, and how backups are tested. The later sections of this page cover these choices in detail; the point here is that the case record and the automation are two components that must be designed, tested and evidenced together.

Which requirements the case record must satisfy

This table maps two US rules, the HIPAA Security Rule and the FTC Safeguards Rule, to what the case platform and SOAR layer must record, restrict and retain. Read each row as a question to put to your design: what must be captured, who may touch it, and how long it must survive. The main takeaway is that the case record and the automation logs are themselves evidence, so they need the same access controls as the systems they describe.

Requirement	What the case record and SOAR must do	Where it usually fails
Unique user identification (45 CFR 164.312)	Give every analyst, service account and approver a named identity in DFIR-IRIS and Shuffle, so each case note, task and evidence upload traces to one person.	Shared responder logins, or Shuffle workflows that act under a generic API key with no owner.
Person or entity authentication (45 CFR 164.312)	Require strong authentication for case platform and Shuffle consoles, and confirm the identity source (for example, SSO through the directory) before access is granted.	Local accounts left active after SSO rollout, or admin accounts that bypass the identity provider.
Audit controls (45 CFR 164.312)	Keep the DFIR-IRIS audit trail and Shuffle execution history for each case, and confirm they record who changed what and when.	Automated actions that run without a case reference, so the log cannot be tied back to an incident.
Multi-factor authentication for all users (16 CFR 314.4)	Enforce MFA on every route into the case platform and automation console, including administrator and API-facing accounts where the platform supports it.	MFA applied to the web login but not to direct API tokens or to the database and message queue administration paths.
Logging of authorized user activity (16 CFR 314.4)	Log logins, case edits, evidence access, workflow edits and credential changes, and forward them to the central log store.	Workflow edits and app credential changes that are not logged, so an insider change cannot be reconstructed.
Encryption in transit and at rest (16 CFR 314.4)	Terminate TLS for the case platform, protect Shuffle saved credentials with its encryption key, and encrypt evidence storage and database backups.	Encryption key for Shuffle (SHUFFLE_ENCRYPTION_MODIFIER) stored beside the data it protects, or lost during a rebuild.
Role-based access and separation of duties on response actions	Separate who triages and closes cases from who approves destructive actions such as host isolation or account disablement, and restrict workflow editing to a named group.	One analyst able to build, edit and run a containment workflow with no second approver.
Retention of case records and automation logs	Set retention for cases, evidence and execution logs to match the period your regulator and counsel confirm, and test that restores include them.	Retention set for the case database but not for the Shuffle OpenSearch store or message queue, or backups that expire first.

Which platforms fit a self-hosted incident case stack

A self-hosted incident case stack usually pairs a case record with an automation engine and an analysis engine. The cards below cover the main options, how each one fits, and what to confirm about licensing and run limits before you commit to one.

DFIR-IRIS as the case record

DFIR-IRIS holds alerts, cases, IOCs, tasks and evidence in one record with an audit trail, and it can take SIEM, EDR and REST-fed alerts into one queue that analysts group and promote to a case. Evidence can be verified with SHA-256 hashes, which helps when you need to show that files were not altered. Check the LGPL-3.0 license terms with your legal team and confirm that your alert sources have a supported input path.

DFIR-IRIS pre-release status

The repository marks v3.0.0-beta.1 as not recommended for production, so a production deployment should target the latest stable line. Plan upgrades as a controlled change, with a tested database backup and a staging instance that mirrors your Docker Compose stack. Ask your implementation partner how they will handle version pinning and the pull of images from ghcr.io.

Shuffle for enrichment and response

Shuffle runs enrichment and response playbooks against the case record, with apps built from OpenAPI specifications or written with the Python SDK. Its code is AGPL-3.0, and all features are available in the open-source edition. Paid tiers differ in limits, scaling and support, and app runs drive that licensing, so count the actions your playbooks will execute before you size the deployment.

TheHive 5 as a commercial option

TheHive 5 is distributed under commercial plans: Community is free for 2 users, while Gold and Platinum are priced per user. A fresh on-premises install starts a 14-day Platinum trial, after which the platform goes read-only until a valid license is applied. Compare the per-user cost with your analyst headcount, and confirm the TheHive stack of Cassandra and Elasticsearch fits your operations team.

Cortex for analysis and response

Cortex runs analyzers that enrich observables and carry out response actions, and it is a fully open-source project with no license fee. Its repository is licensed under AGPL-3.0, so review what that means for any changes you distribute. Confirm which analyzers your threat intelligence sources need and whether each one requires an API key that must be stored securely.

TheHive 3 and 4 status

TheHive 3 and TheHive 4 have not been maintained, distributed or publicly accessible since 2023, and their repositories are archived. Do not build a new case stack on those versions, and check that any existing deployment has a migration path with a supported release. Ask any partner to confirm how they plan to move historical cases and audit records.

How alerts flow from the SIEM into a case and a playbook

The key design point is that the SIEM or EDR raises the alert, DFIR-IRIS decides what becomes a case, and Shuffle does the enrichment and response work that the case record then documents. A single alert from Wazuh or Security Onion should reach the DFIR-IRIS alert queue through its API or a connector, where responders group related alerts, triage them and promote the group to a case. Shuffle workflows are triggered either from the alert queue or from the case, and each workflow calls enrichment apps such as VirusTotal or MISP. Confirm in your own environment which alert fields your SIEM version sends, which REST endpoint or connector your DFIR-IRIS release expects, and whether your chosen Shuffle trigger can receive the DFIR-IRIS webhook payload without custom code.

Illustrative example: a Wazuh rule fires on repeated failed logins followed by a new scheduled task on one Windows host. The alert enters the DFIR-IRIS queue, an analyst groups it with two related alerts from the same user, and promotes the group to a case. A Shuffle workflow then looks up the source IP in MISP and the file hash in VirusTotal, and writes the results back as IOCs and timeline events on the case. The case record stays the system of truth for decisions, evidence and status. Shuffle keeps its own execution logs, which record each workflow run, the apps called and the outputs, so the reviewer can see how an enrichment result was produced. Those logs live in Shuffle's OpenSearch store, so decide early which of them must be copied into the case as evidence and how long Shuffle retains them.

Plan for failure in both directions. If the webhook or API call from DFIR-IRIS to Shuffle fails, alerts must still be visible in the queue and the case must not depend on a workflow having finished. Save credentials for MISP and VirusTotal carefully, because Shuffle encrypts saved app credentials with a secret that must not change, and an unmanaged change breaks every saved authentication. Test the full path with sample alerts from a non-production SIEM before connecting live sources.

Deployment patterns for regulated SOCs

A fully self-hosted build keeps the Shuffle backend, frontend, OpenSearch document database and Orborus workers inside your data center or cloud account. Shuffle documents four deployment architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud, and Kubernetes with Helm charts. DFIR-IRIS runs as its own Docker Compose stack of six services (a Flask API, a Celery worker, PostgreSQL, RabbitMQ, nginx for TLS and a SvelteKit frontend), with images pulled from ghcr.io.

Single server first: Docker Compose on one host suits a pilot, but it is a single point of failure for both the case record and the automation.
Swarm or Kubernetes for scale: Shuffle's docs recommend scaling the backend and frontend across all servers, which requires shared files through NFS when several backends run.
Image provenance: Pull DFIR-IRIS images from ghcr.io through your registry mirror and pin tags, so upgrades are deliberate changes.
Credential key custody: Record the SHUFFLE_ENCRYPTION_MODIFIER value in your secrets manager before first run, because the docs warn that losing or changing it breaks every saved app authentication.
Upgrade cadence: Shuffle recommends the latest Docker tag for stable releases, so set a change window for each upgrade.

Confirm with your platform team which orchestrator you already operate and who owns backups for OpenSearch and PostgreSQL.

Why TheHive 5 is now a commercial choice

TheHive is no longer a free, community-maintained option for most SOCs, so treat it as a commercial product when you compare it with DFIR-IRIS. TheHive 3 and TheHive 4 have not been maintained, distributed or publicly accessible since 2023, and the archived TheHive 4 repository was licensed under AGPL-3.0 with its last release, 4.1.24, published on September 13, 2022. TheHive 5 is distributed under StrangeBee's commercial plans. The Community plan is free for 2 users, while Gold and Platinum are priced per user. Since version 5.3, Community users must also request a Community license from the StrangeBee license portal instead of simply installing and running the product.

Installing TheHive on-premises starts a 14-day Platinum trial. When the trial ends without a valid license, TheHive switches to read-only mode, so analysts can still view cases but cannot work new ones. Plan for this in any pilot: confirm which plan your team needs, how many named users it covers, and who holds the license keys after the trial. DFIR-IRIS, by contrast, is licensed under LGPL-3.0, so the license question does not block a production rollout the way it can with TheHive 5.

The deployment load is also heavier than a single application. A TheHive deployment runs TheHive, Apache Cassandra and Elasticsearch, each on the JVM with its own heap configuration. StrangeBee recommends 100 GB of storage for most use cases, so size the Cassandra and Elasticsearch volumes, backup jobs and patch windows before you commit. Confirm current plan terms, per-user pricing and license-portal steps directly with StrangeBee's pricing page and the TheHive 5 license documentation, because these terms change over time and this page does not set them.

How the rollout moves from one alert source to production playbooks

This sequence takes DFIR-IRIS and Shuffle from scoping to a monitored production service, proving each layer with one alert source before more playbooks and integrations are added. Each phase closes with a written output that the client can review and sign off.

Scope alert sources and case types
The engagement starts with a workshop where the SOC lead, detection engineers and DeployOpen agree which alert sources feed the case queue first, which case types the team will open (for example, phishing, malware or identity misuse), and who owns each decision. The team also records which systems the playbooks may touch and which actions need human approval. The output is a written scope document listing sources, case types, owners and out-of-scope actions, which is the baseline for every later phase.
Stand up DFIR-IRIS and Shuffle in test
DeployOpen deploys DFIR-IRIS and Shuffle in a non-production environment inside the client's own infrastructure, using the deployment options each product documents. For DFIR-IRIS this includes its Docker Compose stack, PostgreSQL, RabbitMQ and TLS termination at nginx. For Shuffle, the team selects the architecture that matches the expected load and configures the SHUFFLE_ENCRYPTION_MODIFIER secret and identity provider settings, with that secret stored in a managed vault. The output is a working test environment with documented versions, backup of configuration, and a login check through the approved identity provider.
Connect one SIEM alert source
The team connects a single alert source, typically the SIEM that already produces the highest-volume detections, to the DFIR-IRIS alert queue through its supported ingestion path or REST API. Test alerts are sent from the SIEM so the team can confirm field mapping, severity, deduplication and how alerts are grouped before promotion to a case. The output is a documented alert mapping and a short test log showing that alerts arrive, group and promote to cases as expected.
Build and test enrichment playbooks
DeployOpen builds two or three enrichment playbooks in Shuffle, such as indicator lookups against MISP or VirusTotal and asset context from the CMDB, writing results back to the DFIR-IRIS case. Each app connection is tested with separate credentials, and every workflow is run against replayed historic alerts before anyone relies on it. The output is a set of versioned workflows, a test record showing expected and actual results, and a list of known gaps for the SOC to accept or fix.
Add approval gates for destructive actions
Any action that changes state, such as isolating an endpoint, disabling an account or blocking an address, is placed behind a manual approval step that a named responder must confirm inside the case. The team documents who can approve, what evidence the approver sees, and how the decision is recorded. The output is a tested approval path for each destructive action, with a rollback procedure and a confirmation that a rejected or timed-out approval stops the workflow.
Validate evidence hashing and audit exports
The team uploads sample evidence files to a test case and confirms that DFIR-IRIS records SHA-256 hashes and that the hashes still verify after export and re-import. It also exports the case audit trail and the Shuffle execution history, then checks that the exports show who acted, what ran and when. Compliance and legal reviewers should confirm the format meets their own evidence requirements. The output is a validation report with the test steps and results that the client can retain as evidence.
Operate with run limits and version pinning
Before go-live, DeployOpen configures monitoring for Shuffle app-run consumption against the licence terms, since the Shuffle pricing article counts actions that actually execute, and sets alerts when usage approaches the agreed limit. Container image tags for DFIR-IRIS and Shuffle are pinned to tested versions, and upgrades are applied to the test environment first. The output is a production runbook covering run-limit monitoring, version pinning, upgrade steps, backup schedules and named owners for each playbook.

Evidence an auditor or regulator asks for from the case stack

This table maps each evidence type an assessor or regulator may request to the component that produces it in a DFIR-IRIS and Shuffle stack. Read each row as a question to answer before go-live: what is recorded, where it lives, and who must confirm how long it is kept. The main takeaway is that the case record, the automation history and the approval trail are separate sources, and each needs its own retention decision.

Evidence	Produced by	What to confirm
Audit trail of case changes	DFIR-IRIS case audit trail and timeline	Which edits, deletions and status changes are logged, and whether the log is exported off the server
Evidence files with SHA-256 verification	DFIR-IRIS evidence store with SHA-256 hashes	Hash check at intake and at export, and where the original files are kept under legal hold
IOC and timeline records	DFIR-IRIS IOCs, tags, enrichment results and investigation timeline	Whether enrichment results from VirusTotal or MISP are stored with timestamps and source
Role assignments and access logs	DFIR-IRIS role-based access control, reverse proxy and host logs, SIEM for login events	Who approves role changes, and how often access is reviewed against the directory
Shuffle execution history and credential handling	Shuffle workflow execution records in OpenSearch, encrypted app credentials	How long execution records are kept, and who holds the SHUFFLE_ENCRYPTION_MODIFIER secret
Approval records for response actions	Shuffle approval steps, ticket or chat records linked to the case	Whether approvals are captured as case entries that name the approver and the action taken
Alert source records	SIEM such as Wazuh, with alerts passed into DFIR-IRIS	Whether original alert payloads are retained in the SIEM after promotion to a case

What buyers ask before choosing an incident case platform

What drives the total cost of an open source incident case setup?

Most of the cost is people time, not software. DFIR-IRIS and Shuffle are licensed under LGPL-3.0 and AGPL-3.0, so the platform fees are zero at the license level, but the total still includes hosting, backups, staff time for playbook upkeep and any connectors you buy or build. Shuffle's paid tiers are priced on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, so run volume is the figure to model. One-time costs include the initial build, integration work and testing. Recurring costs include infrastructure, upgrades, connector maintenance as vendor APIs change and analyst time spent reviewing automated actions. Ask any partner for a quote that separates these lines and states which ones recur.

How long does a first incident case build take?

The duration depends on scope, and no fixed figure applies to every SOC. The main drivers are how many alert sources feed the queue, how many enrichment sources you connect, whether MISP or VirusTotal lookups are required, how many playbooks you automate first and how much approval logic you need. Identity integration and change control on response actions often take longer than the platform install itself. A fixed-scope engagement agrees the deliverables and timeline in writing before work starts, so ask for the schedule and the assumptions behind it, including which systems the team must provide access to during the build.

What does the build need from our own team?

The build needs named owners from several teams. Typically that includes identity administrators for SSO and role mapping, SIEM administrators who can export or forward alerts in a documented format, EDR or ticketing owners for any response action, and a SOC lead who approves which actions may run without a human. Expect to provide test data, a staging environment and a list of destructive actions that require approval gates. Ask the partner to name each dependency in the scope so that delays are visible early.

Can a small team run DFIR-IRIS and Shuffle without a partner?

A small team can run both tools alone if it has Linux, container and database skills and time to maintain them. DFIR-IRIS's Docker Compose stack runs six services, including PostgreSQL, RabbitMQ and an nginx TLS layer, and Shuffle adds an OpenSearch backend and Orborus workers. Upgrades, backups and the encryption secret used for saved app credentials need a documented process, because losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks every saved app authentication. Most teams weigh the in-house path against a partner that handles hardening, playbook engineering and support retainers. Ask which tasks the partner will hand over and which stay with your staff.

Does DFIR-IRIS replace TheHive 5 in existing workflows?

DFIR-IRIS covers similar ground for alerts, cases, IOCs, evidence and timelines, but it is a different product and does not replace TheHive 5 without migration work. TheHive 3 and 4 have not been maintained since 2023, and TheHive 5 is commercially licensed: its Community plan is free for 2 users, while Gold and Platinum are priced per user. Cortex is a separate open-source analysis engine. Before switching, map your case templates, custom fields, observables, analyzers and integrations, and test how existing MISP exchanges and automation will behave in IRIS. Confirm the migration path with the vendor and your partner rather than assuming a direct import.

How are MFA and SSO enforced for the case platform?

Enforcement happens at the identity provider, and the case tool and Shuffle must accept its assertions. Shuffle supports OpenID Connect since version 1.0.0 and SAML since 0.9.16, with per-tenant SSO enforcement, and it is deprecating SAML on Shuffle Cloud in favor of OpenID Connect. Keycloak is a common choice because it supports OpenID Connect, SAML 2.0 and Active Directory federation, and the MFA policy is configured there, not in each tool. Confirm with your partner whether DFIR-IRIS's own login flow can be placed behind the same OIDC provider, how local admin accounts are kept for break-glass access, and how MFA evidence is exported for auditors.

What evidence will auditors expect from the case workflow?

Auditors usually sample the incident record, so the platform should keep a complete trail of who opened, changed and closed each case. DFIR-IRIS keeps an audit trail per case, stores evidence with SHA-256 verification and supports role-based access control. Shuffle keeps execution records for each workflow run. Ask the partner to show, before build starts, how case records map to your incident procedure, how automated actions are logged and where the logs are retained. This page does not cover certification; independent auditors decide what satisfies a given framework.

Questions to put to an implementation partner

Start with the field mapping, because every later question depends on it. Ask the partner to show, in writing, how each alert source and the case fields in DFIR-IRIS map to your incident taxonomy: which severity values, incident categories and regulatory flags are set at case creation, and which are filled in later by an analyst. Ask who owns the mapping file, how a new category is added without breaking existing cases, and whether the partner has tested the mapping against a sample of past incidents from your own records. A partner that answers with a generic template has not yet looked at your classification rules.

Next, ask how Shuffle workflows are tested before they touch production. A credible answer names a separate Shuffle instance or Docker Compose stack for testing, replayed alerts from your SIEM, and a sign-off step for every change to a playbook that can isolate a host, disable an account or send a notification. Ask where the workflows are stored, how they are versioned, and who approves a promotion. On credentials, ask where the saved app keys and API tokens are encrypted, which setting holds the SHUFFLE_ENCRYPTION_MODIFIER secret, and where the partner keeps the backup of that value. Losing or changing it breaks every saved app authentication, so ask the partner to demonstrate a restore into a test environment rather than simply describe one.

Finally, pin down the operating model. Ask how the partner estimates app-run volume from your alert history, since Shuffle counts actions that actually execute, and how many Orborus nodes and backend servers that volume requires for the high availability the Shuffle configuration docs describe. Ask who repairs a connector when your SIEM or EDR upgrades, how that work is scoped and priced, and whether it is covered by a retainer. On TheHive, ask for a written comparison of the TheHive 5 license tiers, the 14-day trial behavior and the Community license request process against DFIR-IRIS, and ask who in your organization will sign the license decision. Request the answers before signing a fixed-scope agreement.

How DeployOpen scopes and supports this incident case stack

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For incident case management, that means a DFIR-IRIS case record and a Shuffle automation layer that are scoped, built and tested against your own alert sources and reporting obligations before they go live.

How we scope

Engagements are fixed-scope, with alert sources, playbooks, integrations and deliverables agreed in writing before work starts
We map which SIEM, EDR and REST-fed alert sources reach the DFIR-IRIS queue and which ones stay out of scope
The written scope names the MISP, VirusTotal and webhook integrations to build, and any that the client will run itself
Quotes follow from the written scope, so the scope should list hosting location, identity provider and sign-in method

How we build

We deploy the DFIR-IRIS stack and the Shuffle server and workers in the client's environment, with TLS, role-based access and SSO configured
Playbooks are built as versioned Shuffle workflows, with saved app credentials stored under a managed encryption secret
We test alert promotion, indicator enrichment and case timelines against sample alerts before any playbook touches production systems
Destructive response actions are built with approval steps where the client's change control requires them

How we hand over

Handover includes configuration documentation for the case record, alert queue, Shuffle workflows and worker placement
We document the secret recovery procedure, since losing the Shuffle encryption secret breaks saved app authentications
Runbooks cover case lifecycle, evidence handling with SHA-256 verification, and how automated actions appear in the audit trail
Clients receive a list of open items, owners and the upgrade path for DFIR-IRIS and Shuffle releases

How we support

Ongoing support, upgrades and continuous testing are available as retainers
Retainers can cover playbook maintenance when connected tools change their APIs or authentication methods
Security testing of the case stack, including its APIs and integrations, can be scoped separately under the same written process
Confirm the response times, coverage hours and escalation path with DeployOpen in the written retainer scope