Configuration

DFIRe is configured through the web-based System Settings interface. This guide covers all available configuration options, organized by category.

Default Settings: New DFIRe instances are initialized with preconfigured case types, evidence types, workflow steps, compliance timers, and incident phases. You can download the default settings file (JSON) to review the baseline configuration or use it to reset your instance to factory defaults via Settings → Global Settings → Import/Export.

Accessing System Settings

To access System Settings, click the user avatar in the application header and select Settings. Access to the Settings page requires the edit_tenant permission. Superusers have full access to all settings tabs.

Settings are organized into 21 tabs across three categories: System, Integrations, and Case Properties. The tabs visible to you depend on your permissions.

System

Tab Access Level Description
Global Settings Superuser only Organization identity, report customization, configuration import/export
Storage Superuser only File storage backend configuration (Local, S3, SMB)
Single Sign-On Superuser only OIDC identity provider configuration
License & Updates Superuser only License management, activation, and offline licensing
Retention Policy Superuser only Case archival/deletion rules and IOC lifecycle settings
User Accounts Delegatable User management and role editor with permission matrix
Reporting Delegatable Report section templates for investigation and incident reports
Compliance Timers Delegatable Regulatory notification deadlines

Integrations

Tab Access Level Description
Webhooks Delegatable Outgoing and incoming webhook configuration, shared secrets
Slack Integration Superuser only Slack app setup, credentials, and channel settings
Jira Integration Superuser only Jira Cloud connection, issue mapping, sync, and user linking
Log Integration Superuser only Audit log forwarding to external systems (ELK, OpenSearch, etc.)
IOC Enrichment Superuser only Threat intelligence provider configuration and API keys
IOC Sharing Superuser only TAXII 2.1 server, MISP feed, API keys, and collections

Case Properties

Tab Access Level Description
Entities Delegatable Legal entity registry (people, organizations, agencies)
Triage Flags Delegatable Color-coded evidence item flags for triage and warnings
Projects Delegatable Group related cases under projects
Case Types Delegatable Case type schemas with custom fields and action templates
Evidence Types Delegatable Evidence type schemas with custom fields and icons
Evidence Workflow Delegatable Investigation step definitions for evidence processing
Incident Lifecycle Delegatable Incident response phase definitions (NIST-based)

Delegatable means the tab is visible to any user whose role includes the edit_tenant permission. Superusers always have access. See User Management for role and permission details.

Global Settings

The Global Settings tab contains organization-wide configuration organized into two sub-tabs: Identity and Reporting.

Identity

  • Organization Name: Your organization's display name
  • Contact Email: Used for license server communication

Configuration Import/Export

The Identity sub-tab includes Data Portability controls:

  • Export JSON: Download a complete backup of all system configuration (groups, types, flags, phases, webhooks, etc.)
  • Import JSON: Restore or migrate configuration from a previously exported file. DFIRe shows a preview of what will be added, updated, or removed before applying.

Reporting

  • Report Logo: Upload your organization's logo (PNG or JPEG, max 500KB) to display on the title page of printable reports
  • Title Page Disclaimer: Custom text that appears at the bottom of report title pages (e.g., confidentiality notices)

Storage Backend

DFIRe supports three storage backends for file attachments. All files are encrypted with AES-256-GCM regardless of which backend you choose.

Local Filesystem

Stores files on the server's local disk. Always available and requires no additional configuration.

  • Storage Quota (GB): Optional limit on total storage usage

S3-Compatible Storage

Works with AWS S3, MinIO, Backblaze B2, and other S3-compatible services.

  • Endpoint URL: Leave empty for AWS S3, or specify your S3-compatible endpoint
  • Region: AWS region (e.g., us-east-1)
  • Bucket Name: The S3 bucket to use
  • Access Key ID / Secret Access Key: AWS credentials with bucket access
  • Use SSL/TLS: Enable HTTPS connections
  • Verify SSL certificates: Validate SSL certificates (disable only for testing)
  • Storage Quota (GB): Optional limit on total storage usage

SMB/CIFS File Share

Stores files on Windows file shares, Samba servers, or NAS devices.

  • Hostname / IP: Server address
  • Share Name: The network share name
  • Username / Password: Credentials with read/write access
  • Domain: Windows domain (or WORKGROUP for local accounts)
  • Storage Quota (GB): Optional limit on total storage usage

Testing Storage

Before activating a storage backend:

  1. Configure the connection settings
  2. Click Quick Test to verify connectivity
  3. Click Full Test (Verify Encryption) to test file upload, download, encryption verification, and cleanup
  4. Once the full test passes, click Set as Active to start using the backend

Important: Changing the active storage backend does not migrate existing files. Ensure all cases are closed and files are backed up before switching backends.

See Storage Backends for detailed backend comparison and migration guidance.

Single Sign-On (OIDC)

DFIRe supports any OpenID Connect (OIDC) compliant identity provider for single sign-on authentication.

Supported Providers

Built-in templates are available for:

  • Google Workspace
  • Microsoft Entra ID (formerly Azure AD)
  • Okta
  • Any custom OIDC provider

Configuration

  1. Click Add Provider and select a template or choose Custom OIDC Provider
  2. Enter the Discovery URL (the .well-known/openid-configuration endpoint)
  3. Click Validate to verify the discovery URL
  4. Enter the Client ID and Client Secret from your identity provider
  5. Copy the Redirect URI shown and configure it in your identity provider's application settings
  6. Select a Default Role for new users created via SSO
  7. Optionally configure the provider Icon and Button Color for the login page
  8. Click Save Configuration

Application Base URL

Set this to your public URL (e.g., https://dfire.example.com) to ensure correct callback URLs. If left empty, DFIRe will attempt to auto-detect from request headers.

Tip: Access control (who can login) should be configured in your identity provider. DFIRe will accept any authenticated user from enabled providers.

See Single Sign-On for detailed provider-specific setup guides.

License & Updates

The License & Updates tab shows your current license status and allows you to manage your DFIRe license.

License Status

The status card shows:

  • Active License: License is valid and verified, with expiration date and days remaining
  • Trial Period: Operating in trial mode (90 days)
  • License Expired: License has expired, application is read-only
  • Offline License Mode: Using an offline license for air-gapped environments

License Server Connection

For online licenses, the status shows:

  • Registration status with the license server
  • Last check-in time with a manual Check In Now button
  • Installation information transmitted during check-ins (Installation ID, hostname, organization, version, OS)

Activating a License

  1. Obtain a license key from contact@dfire.fi
  2. Enter the license key in the format DFIRE-XXXX-XXXX-XXXX-XXXX
  3. Click Activate

Offline Licensing

For air-gapped environments that cannot connect to the license server:

  1. Copy the Installation ID shown in the Offline License section
  2. Contact contact@dfire.fi to request an offline license
  3. Upload the .dfire-license file provided

Note: Offline licenses are bound to a specific installation and cannot be transferred. There is no extra cost for offline licensing.

Retention Policy

The Retention Policy tab configures automatic lifecycle management for cases and IOC indicators. The retention policy runs automatically every day at midnight.

Case Retention

  • Auto-Archive Closed Cases: Toggle to automatically move closed cases to archived status after a configurable number of days of inactivity
  • Auto-Delete Archived Cases: Toggle to permanently delete archived cases and all associated data after a configurable number of days

Important: Auto-delete permanently removes cases and all associated evidence, attachments, notes, and timeline events. This action cannot be undone. Ensure backups are in place before enabling.

IOC Lifecycle

  • Default IOC Expiration: Number of days until new indicators expire. Set to 0 for no expiration.
  • Auto-Revoke Expired Indicators: Toggle to automatically revoke indicators whose valid_until date has passed
  • Auto-Delete Revoked Indicators: Toggle to permanently delete revoked indicators after a configurable number of days

Timing: Archive timing is based on when cases were closed. Delete timing is based on when cases were archived. IOC revocation is based on the indicator's valid_until date, and IOC deletion is based on the revoked_at date.

User Accounts

The User Accounts tab provides two sub-tabs: Users and Role Editor.

Users

Lists all user accounts with their role, last login time, and linked integrations (e.g., Jira). From here you can:

  • Create new local user accounts
  • Edit user details, roles, and account status
  • View SSO-provisioned accounts (marked with provider badges)

Role Editor

A permission matrix that lets you define which permissions each role has. Permissions are organized by category (Evidence, System, Cases, etc.) with checkboxes for each role. The default roles are:

  • DFIRe Admin: Full access to all features and settings
  • Standard User: Case work permissions without administrative access
  • Team Lead: Case work plus team management capabilities
  • View Only: Read-only access to assigned cases

See User Management for detailed role and permission documentation.

Reporting

Define the sections that appear in investigation and incident reports. Section templates are managed using expandable cards — click a card to expand it for editing. Multiple cards can be open simultaneously for comparison.

Section Template Settings

Each section template has the following configuration options:

  • Order: Determines display order in the report (use gaps like 10, 20, 30 for easy reordering)
  • Section Title: Display name and slug identifier
  • Type: Either Editable (free-form content per case) or Auto-generated (populated automatically from case data)
  • Page Break: Whether to start a new page before this section when printing
  • Report Mode: Configure whether the section appears in incident reports, investigation reports, or both
  • Default Excluded: Hide this section from the final report by default (useful for internal notes or writing guides)
  • Writing Guide: Instructions displayed in the editor to help authors maintain consistency (editable sections only)
  • Default Content: Boilerplate Markdown content pre-filled when creating new reports (editable sections only)

Auto-generated sections include the Title Page, Table of Contents, Timeline, Indicators of Compromise, Evidence Inventory, and Detailed Item Reports. Template changes only affect newly created cases.

AI Generation Settings

When an LLM provider is configured (see AI Integration), editable section templates gain additional AI settings:

  • Enable AI Generation: Toggle to allow investigators to generate content for this section using AI
  • AI Prompt Template: The prompt sent to the LLM when generating content for this section. Supports template variables:
    • {case_data} — Replaced with the minified case data JSON
    • {section_title} — Replaced with the section name
    • {writing_guide} — Replaced with the section's writing guide text
  • Use Default Prompt: Loads the built-in default prompt as a starting point for customization

Note: AI generation is only available for editable sections. Auto-generated sections (Title Page, Table of Contents, Evidence Inventory, etc.) are populated directly from structured case data and do not use the LLM.

CAN Report AI Prompt

At the bottom of the Reporting settings page, administrators can view and customize the AI prompt used for CAN report generation:

  • Built-in System Instructions: Read-only system message that enforces the JSON output format (expandable for transparency)
  • User Prompt: Editable prompt template with a {case_data} variable. Leave empty to use the built-in default. Use "Reset to Default" to restore the original prompt.

Compliance Timers

Define regulatory notification deadlines for incident response cases. DFIRe ships with preconfigured timers for GDPR, NIS 2, DORA, SEC, CIRCIA, and NYDFS regulations. Each timer includes the regulation name, deadline duration, notification authority, and a reference link to the relevant legislation.

See Compliance Timers for details on using timers in cases.

Webhooks

The Webhooks tab has two sub-tabs: Webhooks and Secrets.

Outgoing Webhooks

Send notifications to external systems (SIEMs, ticketing systems, notification services) when events occur in DFIRe. Each webhook can be configured with:

  • Endpoint URL: The target URL to receive webhook payloads
  • Event Types: Which events trigger the webhook (case, evidence, timeline, incident, IOC events)
  • Authentication: None, Basic Auth, Bearer Token, or Custom Headers
  • Payload Template: Custom JSON payload using template variables
  • Value Mappings: Transform field values (e.g., severity levels to ticket priorities)
  • Signing Secret: HMAC-SHA256 signing for payload verification

Incoming Webhooks

Allow external systems (SOAR platforms, monitoring tools) to create cases in DFIRe via authenticated HTTP requests.

Secrets

Store reusable secrets (API keys, tokens) that can be referenced across webhook configurations without duplicating sensitive values.

See Webhooks for detailed configuration examples and event types.

Slack Integration

DFIRe integrates with Slack via Socket Mode for real-time case collaboration, message capture, and team coordination.

Features

  • Automatic channel creation for cases
  • Send messages to case channels directly from the Collaboration tab
  • Message and file capture from Slack to case timeline
  • /dfire slash commands for case management from Slack
  • Pushpin emoji reaction to capture files and images from Slack discussions
  • User account linking between DFIRe and Slack

Setup

The setup wizard provides an app manifest for quick configuration:

  1. Go to api.slack.com/apps and create a new app from manifest
  2. Copy the provided JSON manifest from the Settings page
  3. Install the app to your workspace and authorize it
  4. Generate an App-Level Token with connections:write scope
  5. Enter the Bot User OAuth Token (xoxb-...) and App-Level Token (xapp-...) in the Credentials section

A detailed step-by-step guide is also available within the Settings page for manual configuration.

Channel Settings

  • Channel Prefix: Prefix for auto-created channels (e.g., case creates #case-2026-001-incident-name)
  • Command Channel: Public channel where /dfire create commands are allowed
  • Frontend URL: Your DFIRe URL for generating clickable links in Slack notifications
  • Create private channels by default: Toggle channel visibility
  • Auto-create channels when cases are created: Automatic channel creation

Jira Integration

Connect DFIRe to Jira Cloud to export cases, actions, and evidence items as Jira issues with bidirectional status synchronization.

Jira Cloud only. This integration connects to Atlassian Jira Cloud instances using API tokens. Jira Data Center (on-premise) is not currently supported.

Configuration

  1. Enable the Jira integration toggle
  2. Enter your Instance URL (e.g., https://company.atlassian.net)
  3. Enter the Service Account Email and API Token (generated at Atlassian API Tokens)
  4. Enter your Default Space Key (the prefix in issue keys, e.g., IR) and click Discover Issue Types
  5. Select the Case Issue Type (e.g., Epic) and Action Issue Type (e.g., Task). The case type must be hierarchically above the action type.
  6. Click Test Connection to verify

Sync Settings

  • Sync Interval (Minutes): How often DFIRe polls Jira for status changes (1–1440 minutes)
  • DFIRe Frontend URL: Included in Jira issue descriptions for navigation back to DFIRe

Automation

  • Auto-create Jira Epic when a case is created: Automatically mirrors case structure in Jira
  • Auto-create Jira item when an action is started: Exports actions as Tasks under the case's parent issue when their status changes to Started

Status Mapping

After discovering issue types, you can map DFIRe action statuses to Jira statuses. The mapping applies to both action tasks and case epics for bidirectional status synchronization.

User Mappings

Link DFIRe accounts to Jira accounts by email address to enable auto-assignment when exporting actions. Use the Auto-Map by Email button to automatically match users with matching email addresses.

Log Integration

Forward audit logs to external log aggregation services such as ELK, OpenSearch, Splunk, or any HTTP endpoint.

Privacy: Audit logs contain details of investigations including case numbers, evidence names, user actions, and IP addresses. Ensure your log destination complies with your organization's data handling policies.

Configuration

  • Endpoint URL: HTTPS endpoint that accepts POST requests
  • Payload Format: JSON Batch (single JSON object with logs array)
  • HTTP Basic Authentication: Optional username and password
  • Custom HTTP Headers: Additional headers (e.g., Authorization: Bearer token)
  • Batch Size: Number of log entries per request
  • Timeout / Max Retries / Circuit Threshold: Connection reliability settings

System Heartbeat: Optional toggle to send periodic system health and license metrics to the audit log.

When enabling, you can choose to send all historical logs or only forward new entries going forward.

See Audit Log for details on what events are logged.

IOC Enrichment

Configure threat intelligence providers for automatic IOC enrichment. Each provider can be enabled independently, and enrichment results are cached with configurable TTLs.

Built-in Modules

These work without API keys:

  • DNS Resolution: Comprehensive DNS lookups (A, AAAA, MX, TXT, NS, SOA, CNAME, CAA records). Supports domains, IPv4, and IPv6.
  • WHOIS Lookup: Domain registration, registrar, name servers, and registrant information. Supports domains.

Threat Intelligence Providers

Require free or paid API keys from their respective providers:

  • MalwareBazaar (abuse.ch) — Malware sample database, file hashes, malware families. Supports: File Hash
  • ThreatFox (abuse.ch) — IOC database with malware families and threat types. Supports: IPv4, Domain, URL
  • URLhaus (abuse.ch) — Malware URL database with active threats. Supports: IPv4, Domain, URL
  • AlienVault OTX — Open-source threat intelligence with threat pulses. Supports: IPv4, IPv6, Domain, URL
  • Shodan — Open ports, running services, OS detection, and known CVEs. Supports: IPv4, IPv6, Domain, URL
  • VirusTotal — Multi-engine antivirus scan results and reputation scores. Supports: IPv4, IPv6, Domain, URL, File Hash
  • urlscan.io — Website scanning with verdicts, technologies, and page analysis. Supports: Domain, URL

Shared keys: The three abuse.ch services (MalwareBazaar, ThreatFox, URLhaus) share a single API key, configured once in the shared key group.

Reputation Services

  • AbuseIPDB — IP abuse confidence scores and report history. Supports: IPv4, IPv6
  • Google Safe Browsing — Malware, phishing, and unwanted software detection. Supports: Domain, URL
  • GreyNoise — Identify known internet scanners and malicious actors. Supports: IPv4, IPv6

Webhook Triggers

Define custom response buttons that appear on IOC Intelligence pages. Each trigger fires a webhook event with a unique trigger ID, which can be connected to outgoing webhooks for automated response workflows.

See Indicators of Compromise for details on using enrichment results.

IOC Sharing

Configure sharing of published indicators with external threat intelligence platforms. This tab contains four sections on a single page.

TAXII 2.1 Server

Enable the built-in TAXII 2.1 endpoint at /taxii2/api1/ for sharing published indicators with external threat intelligence consumers.

  • Server Title / Description / Contact Email: TAXII server metadata
  • Default Page Size / Max Page Size: Pagination settings for TAXII responses
  • Share Case Associations: When enabled, TAXII responses include STIX Grouping objects (cases) and Relationship objects linking indicators to cases. This bypasses case-level access control for TAXII clients.

MISP Feed

Enable a MISP-compatible JSON feed at /misp-feed/ for external MISP instances to poll.

  • Organization Name: Shown as the producing organization in MISP Events
  • Feed URL: Auto-generated URL for configuring MISP feed sources (requires Bearer token authentication)
  • Default TLP: Default Traffic Light Protocol marking for new indicators
  • Share Case Associations: When enabled, MISP Attribute comments include case numbers. This bypasses case-level access control for feed consumers.

API Keys

Create authentication keys for TAXII and MISP feed clients. Each key can be scoped to specific collections.

Collections

Define filtered views of your indicator registry. Collections use AND logic for filters — an indicator must match all active filters to be included. TAXII clients see only the collections they have been granted access to via API keys.

See Indicators of Compromise for details on sharing workflows.

Case Properties

The remaining seven tabs configure the data schemas and definitions used across cases and evidence items.

Entities

Manage a registry of people, teams, companies, and agencies that may be involved in cases. Entities can be linked to cases as clients, suspects, witnesses, or other roles. See Entities.

Triage Flags

Define color-coded flags for tagging evidence items during triage. Each flag has a color, label, and description. Default flags include markers like "Contains Evidence", "Malware", "Return to Owner", and "Do Not Return".

Projects

Create projects to group related cases together under a shared context, client, or scope of work.

Case Types

Each case type defines a schema with custom fields and an action template (pre-defined checklist items for incident response). DFIRe ships with 15 preconfigured case types covering common incident and investigation scenarios. See Case Types.

Evidence Types

Each evidence type defines an icon and custom fields specific to that evidence category. DFIRe ships with over 20 preconfigured evidence types covering physical devices, digital artifacts, and document types. See Evidence Types.

Evidence Workflow

Define the stages of your digital forensic evidence processing pipeline. Each step has an order number, name, and description. The default workflow follows the standard forensic process: Identification, Acquisition, Processing, Analysis, Reporting, and Archived/Returned. See Workflow Configuration.

Incident Lifecycle

Define the phases of your incident response process, typically based on the NIST framework. Each phase has an order number, name, description, and color for visual identification. The default lifecycle includes: Preparation, Detection & Analysis, Containment, Eradication, Recovery, Post-Incident Activities, and Resolved. See Incident Response.