Administration
Audit log
An append-only record of what happened in DFIRe, who did it, and what changed. Open it from the user menu, under Audit Log.
What an entry holds
- Action, such as CREATE, UPDATE or DELETE.
- Record type, the kind of thing the action touched. Cases, evidence items, attachments, notes, timeline events, users, API keys, indicators, settings, backups and webhook deliveries all appear here.
- Description, a readable summary of the change.
- Timestamp, to the second.
- Username of whoever acted.
- IP address, either the client DFIRe saw directly or the value your trusted reverse proxy sent in
X-Real-IP. DFIRe never usesX-Forwarded-Forfor audit identity, because a proxy that appends leaves attacker-supplied entries in it. - Change data, a structured before-and-after for every modified field.
Some system events carry more in their change data. A heartbeat, for example, records database and Redis latency, queue counts, case and evidence totals, active users, storage use, and the running version and uptime. Together they build a history of the installation's health that you can look back through.
A failed audit write blocks the operation. When DFIRe cannot record an action, it refuses the action rather than completing it unrecorded.
Finding entries
The audit log has a free-text search across usernames, actions, labels and content, plus filters for action, record type, username and date range. The record-type filter offers a fixed set: Case, Item, Attachment, TimelineEvent, User, Project, LegalEntity, CaseNote, ItemNote and CaseTimer. Other record types appear in the results and in the free-text search, but cannot be filtered on. Reset clears everything back to the unfiltered view.
Who sees what
Reading the log at all requires the View auditlog permission, granted per role under Settings → Access Roles. Without it a role reaches no audit entries anywhere, including the history shown on an evidence item.
With it, entries are filtered down to what that person could already see.
- Case records. Entries about a case, its evidence, notes, attachments, timeline, compliance timers, custody transfers, indicators and reports appear only for cases the person can reach. A role with global read sees every case's entries.
- Shared records. Entries about projects, legal entities, runbooks, indicators, playbooks and other shared configuration appear only if the role can read that kind of record. A role that cannot open the Legal Entities directory does not see legal entity history either.
- Their own account. Everyone sees their own sign-ins and account changes.
Other people's account activity, API key use, role changes and system configuration history reach superusers and any role that holds global case read (core.view_all_cases), which opens the log in full. The shipped Team Lead role holds it, so a Team Lead reads every entry in the installation.
A filtered entry is hidden, not missing.
Append-only storage and retention
DFIRe never edits or deletes an audit record after it is written. No screen, endpoint or administrator function removes one, and the application raises an error on any attempt to modify or delete an entry.
What that protection covers. The application enforces it, so it holds against everything reachable through DFIRe. It cannot hold against someone with direct access to the database or its backups, because they are past the application entirely.
On a system you host yourself that limit is structural rather than a gap to close with database locks, because whoever runs the installation can change how it works. The way to detect tampering is to keep a copy somewhere they do not control. Forward entries to a separate system as they are written, then compare the two.
DFIRe also never purges old entries. The log grows for the life of the installation. If you need entries archived off the DFIRe database, whether for retention rules, storage cost or an off-site copy, forward them.
Forwarding to an external system
DFIRe can send audit entries to a log aggregator or SIEM as they are written. Configure it under Settings → Log Integration.
This is also how you make the trail hold up to scrutiny. Keep a copy on a system the DFIRe administrator does not control, then compare the two. A discrepancy shows even when the local record looks consistent.
| Property | Detail |
|---|---|
| Transport | HTTPS POST to an endpoint you choose. DFIRe rejects a plain HTTP URL. |
| Payload format | JSON Batch for a generic receiver, NDJSON for Logstash or Fluentd, Elasticsearch Bulk for OpenSearch and ELK, or New Relic. |
| Authentication | HTTP Basic, or custom headers such as a bearer token. DFIRe encrypts the credentials and headers at rest. |
| Delivery | Cursor-based, so each entry goes exactly once and in order. |
| Backfill | On first enabling it, choose whether to send the whole history or start from now. |
| Reliability | Batch size, timeout and retry count are configurable. A circuit breaker opens after a set number of consecutive failures, so a broken endpoint does not get hammered. |
| Delivery log | Recent attempts stay visible with their timing, response code and any error. |
The audit log carries enough detail to satisfy activity-logging and traceability obligations under frameworks such as GDPR and PCI DSS. Forwarding is how you keep that record beyond the DFIRe database.