Integrations

Slack Integration

DFIRe's Slack integration turns Slack into a front-end for case collaboration. Each case gets a dedicated channel, and a rich set of /dfire slash commands lets responders update the case without leaving Slack. An AI assistant can answer questions about the case inside the channel.

Channels and message capture

• Automatic channel creation — a dedicated Slack channel is created for each case, named using the configured channel template.
• Message capture — react with the :pushpin: emoji on any message or file to capture it to the case (as a note or attachment).
• App Home — each user's Slack App Home surfaces their current cases, recent actions, and assigned items for quick navigation.
• User linking — Slack users link their account to their DFIRe account with /dfire link so that their actions in Slack (adding notes, closing actions, creating cases) are attributed correctly in the audit log.
• Autocomplete — @mentions inside DFIRe note editors resolve against the linked Slack workspace; mentions survive the round trip to Slack and back.

Slash commands

All /dfire slash commands are context-aware: running them inside a case channel targets that case; running them outside a case channel shows a reduced "caseless" help set. Run /dfire help in any channel to see the commands available there, or /dfire help <command> for per-command usage.

Account & info

• /dfire link — link your Slack account to DFIRe
• /dfire whoami — show your linked DFIRe account
• /dfire status [update] — show case status; for incidents, update opens the CAN (Conditions/Actions/Needs) report editor
• /dfire team — show case team members
• /dfire progress — show overall action progress
• /dfire recent [n] — show recent timeline activity
• /dfire search <query> — search all cases, notes, evidence, and IOCs (global; scoped to cases you have access to)

Actions

• /dfire actions — show the current phase's actions (or all actions for investigations)
• /dfire actions all — show every action grouped by phase (incident mode)
• /dfire take <n> — take (assign to yourself) action n
• /dfire done <n> — mark action n complete
• /dfire skip <n> — mark action n skipped
• /dfire assign <n> @user or me — assign action; picker modal if no user given
• /dfire unassign <n> — remove the assignment
• /dfire action add [description] — add a new action (opens a form, pre-filled if description given)
• /dfire action note <n> [text] — add or edit an action note

Status icons displayed next to each action: ⚪ pending · ⚡ started · ✔️ done · 🚫 skipped.

Phases (incident mode)

• /dfire phase show — current incident phase
• /dfire advance — advance to the next phase
• /dfire set [name] — change phase (form, or direct jump if name matches)

Compliance timers

• /dfire timers — show active compliance timers for this case
• /dfire timer start — start a timer (picker of configured timers)
• /dfire timer stop [id] — stop a timer (picker if no id)

Evidence & IOCs

• /dfire evidence — list evidence items
• /dfire evidence add [name] — add evidence (form)
• /dfire evidence update <n> — edit evidence item n (form)
• /dfire custody <n> — record a chain-of-custody transfer (intake, transfer, released)
• /dfire ioc — list indicators of compromise
• /dfire ioc add <value> — add an indicator (value required up front so DFIRe can check the registry for duplicates)
• /dfire ioc update <n> — edit an indicator (form)
• /dfire ioc enrich <n> — queue enrichment for an indicator

Notes & events

• /dfire note [text] — add a case note (opens a form; Markdown supported, @username translates to Slack mentions)
• /dfire item note <n> [text] — pin a note to a specific evidence item
• /dfire event [subject] — add a timeline event (form; supports adversary-activity flag and custom times)

Case management

• /dfire case — edit case information (form)
• /dfire escalate — escalate an investigation into an incident
• /dfire close — close the case (confirmation modal; investigation report stays editable)
• /dfire reopen — reopen a closed case
• /dfire archive — archive a closed case (write-locks it permanently until unarchived from the web UI)
• /dfire create incident [title] or /dfire create investigation [title] — create a new case from Slack (requires the add_case permission)

AI Assistant

The /dfire assistant command runs an AI Q&A session scoped to the current case, inside a thread in the channel. The assistant is read-only — it can answer questions and summarise findings but cannot change the case.

• /dfire assistant <question> — opens a new thread, the assistant replies inside it. /dfire ask is an alias.
• Thread follow-ups — reply inside the assistant's thread to ask a follow-up. The assistant picks up the reply automatically and continues the conversation with full thread context; you don't need to repeat the slash command.
• Multiple concurrent threads — each /dfire assistant call opens its own thread. You can have several assistant conversations running in parallel in the same channel.
• /dfire assistant summary [topic] — opens a new thread with a preset case-summary prompt; the optional topic narrows the focus (e.g. summary evidence).
• /dfire assistant status — lists every assistant thread you currently have open in the channel, with a first-question excerpt, a permalink, and cumulative token usage per thread.

The assistant honours the case team: only users linked via /dfire link who have access to the case can drive the conversation. Replies from other users in the thread are ignored by the LLM. Every Q&A turn is recorded in the audit log as an AI_CHAT entry (user, model, token counts, via=slack).

Limits: each assistant thread is capped at 50 answers; after that the thread is closed for follow-ups (start a fresh one with /dfire assistant). Threads also expire an hour after the last message. Questions are capped at 10,000 characters.

Jira integration

When Jira integration is configured, an extra command group appears:

• /dfire jira — show linked Jira items
• /dfire jira create <n> — create a Jira ticket for action n
• /dfire jira create case — create a Jira Epic for the whole case

Configuration

Slack integration uses Socket Mode — DFIRe opens an outbound WebSocket to Slack, so no public webhook endpoint is required. Configure the integration under System Settings > Slack Integration with:

• Bot User OAuth Token (xoxb-...) — used for posting messages, creating channels, opening modals, and reading thread history.
• App-Level Token (xapp-...) — used by the Socket Mode client to receive events over the WebSocket.
• Signing Secret — verifies that slash-command requests actually originate from Slack.
• Channel Prefix / Channel Template — names applied to automatically created case channels (e.g. prefix dfire-, template {case_number}-{slug}).

The Collaboration tab on each case is a mirrored view of its Slack channel inside the web UI, so users who don't use Slack still see team communication in context.

Jira Integration

When enabled, Jira integration allows:

• Issue linking - Link cases to Jira issues with clickable references that open directly in Jira
• Issue creation - Create Jira issues directly from incident actions without leaving DFIRe
• Status sync - Sync action status between DFIRe and Jira to keep both systems up to date
• Issue tracking - Track Jira issue keys on case cards and in the case header for quick reference

Configuration

The following settings are required to connect DFIRe to your Jira instance:

• Jira Instance URL - The base URL of your Jira instance (e.g., https://yourorg.atlassian.net)
• API Token - An API token generated from your Jira account for authentication
• Project Key - The default Jira project key where new issues are created
• Issue Type mapping - Maps DFIRe action types to Jira issue types

Cases show a Jira badge in the header when linked to an issue. The Actions tab has a "Sync Jira" button for bulk synchronization and individual "Create Jira Item" links on each action for granular control.

Log Integration

DFIRe can forward the complete application audit log to external SIEM or log management systems. The primary purpose is to ensure the audit log is available even on system failure, and to enable auditing of user actions without risk of log tampering on system compromise.

What Is Forwarded

The audit log is sent in full — all application-level events are forwarded, including case lifecycle events, evidence handling, user actions, and configuration changes. There is no filtering by event type; the entire audit log is forwarded or not forwarded at all. The audit log does not contain system-level log events (e.g., OS logs, container logs).

Transport

Logs are sent as HTTPS POST requests in JSON batch format to a configurable endpoint. Authentication is supported via HTTP Basic Auth or custom HTTP headers (e.g., Bearer tokens). Connection reliability is managed through configurable batch size, timeout, retry count, and circuit breaker threshold.

Threat Intelligence Sharing

DFIRe can share published IOC indicators with external systems through two standard protocols:

TAXII 2.1 Server

DFIRe includes a built-in read-only TAXII 2.1 server that serves published indicators as STIX 2.1 objects. External threat intelligence platforms can subscribe to DFIRe collections to receive indicator updates.

• Standards-based: Full TAXII 2.1 compliance (discovery, API root, collections, objects, manifest)
• Collection-based: Organize indicators into collections for selective sharing
• API key authentication: Secure access with configurable API keys
• TLP enforcement: TLP:RED indicators are never published

MISP-Compatible Feed

DFIRe generates a MISP-compatible JSON feed that remote MISP instances can ingest as a feed source. Tested against MISP 2.4.170+ and 2.5.x.

• Case-as-event model: Each DFIRe case with at least one published non-RED indicator publishes as its own MISP Event. A single global Event covers published indicators that aren’t associated with any case. An indicator appearing in multiple cases publishes as a distinct Attribute in each case’s Event, and MISP’s correlation engine stitches them back together on the consumer side.
• Mixed-TLP events: Every Attribute carries its own tlp:* tag; the Event’s distribution is capped at the strictest TLP present (one AMBER+STRICT attribute caps the whole Event at organisation-only sharing). TLP:RED indicators are never published.
• Revocation semantics: Revoked or expired indicators flip MISP’s canonical deleted: true flag on the Attribute, so consumer MISP instances soft-delete them on the next fetch — removed from correlation, IDS exports, and detection rules automatically.
• Richer context: Each Attribute’s comment field carries a compact enrichment verdict summary from DFIRe’s providers (e.g. “Enriched: 2 malicious, 1 clean”) and cross-case prevalence (“Seen in 4 DFIRe cases”), giving consumers triage signal that MISP has no structural place for.
• Automatic updates: Feed regenerates continuously as indicators are published, revoked, or re-enriched.

See Indicators of Compromise for detailed documentation on IOC sharing, TAXII configuration, and MISP feed setup — including a troubleshooting section for common consumer-MISP configuration quirks.

IOC Enrichment Providers

DFIRe integrates with external threat intelligence services to automatically enrich indicators with additional context. Supported providers include:

• Built-in: DNS resolution, WHOIS lookup (IPs and domains, no API key required)
• Threat Intelligence: VirusTotal, Shodan, AlienVault OTX, URLhaus, ThreatFox, MalwareBazaar, urlscan.io
• Reputation: AbuseIPDB, Google Safe Browsing, GreyNoise, Spur (residential proxy / VPN / Tor / bot detection for IP indicators)
• Your own MISP instance: Live lookup against a configured MISP via /attributes/restSearch, with matching Attributes grouped per MISP Event and a one-click Apply tags to IOC button that copies curated event tags onto the DFIRe indicator.

Any provider can be configured to run automatically when a new indicator is created (per-provider opt-in) — useful for cheap local lookups like MISP, DNS, and WHOIS. Configure API keys and auto-run behaviour under System Settings > IOC Enrichment. See Indicators of Compromise — Enrichment for details on each provider.

Webhook Integration

DFIRe also supports outgoing webhooks for event-driven automation. Webhooks allow you to trigger external workflows, notify third-party services, and build custom integrations based on DFIRe events.

See the dedicated Webhooks documentation for detailed webhook configuration, payload formats, and delivery management.