Using DFIRe
Knowledge base
Your team's own documentation, kept beside the cases it supports.
What belongs here
The Knowledge Base holds the material a team needs while working: handling procedures, tool notes, contact and escalation paths, onboarding, decisions worth remembering. It sits apart from case records on purpose. A case documents one investigation, and this documents how you investigate.
It is not a place for case findings. Those belong in case notes and reports.
Organizing it
Content lives in a folder tree of any depth, with pages inside folders. Drag a page or folder to move it, or reorder within a level. Every page has a readable address built from the folder names on its path, which keeps a link meaningful. Breadcrumbs above the page show where you are.
Writing pages
New page asks for a title, an optional description, the destination folder, and whether to encrypt it from the start. It then opens the editor.
Pages are Markdown, written in the same split editor as reports. It gives you a formatting toolbar, your headings as a navigation outline, and source beside a live preview. Tables, task lists, code blocks and links preview exactly as readers will see them.
Saving is explicit, and each save becomes a new version. Edit the title and description in the editor sidebar.
Descriptions
A description is a sentence or two under the title, shown in folder listings and in search results. DFIRe indexes it at all times, including when the page content is encrypted. That makes it the one label by which a protected page can still be found.
Titles and descriptions are never encrypted. They stay readable and searchable on a protected page, by design. Keep passwords, secrets and sensitive detail out of both.
Images
Paste a screenshot straight into the editor, or use the toolbar button. PNG, JPEG and GIF are accepted up to 8 MB each. Images live in the DFIRe database, so backups cover them, and on a protected page they are encrypted along with the content.
Two people editing at once
If somebody saves while you are editing, DFIRe does not quietly write over them. It warns you and lets you choose: keep editing, or save yours as the newest version. Their text stays in the history either way.
Version history
Every save writes a new version recording the content, the title, the author and the time. Versions cannot be edited or deleted on their own. Open the history from the version number in the page header.
Review shows any earlier version beside the list. Restore brings one back by writing a new version carrying the old content and title. The trail of who changed what therefore stays complete.
Deleting a page deletes its whole history with it.
Who sees what
Two mechanisms stack. The Knowledge Base view permissions decide whether a role gets in at all. Access groups then decide which content it sees inside.
Both live in the Role Editor under Collaboration, as Knowledge Base Folders and Knowledge Base Pages. The view capabilities gate reading, and the rest cover creating, editing, moving, reordering, protecting and deleting. See Users and roles.
Access groups
Assign them to a folder or page from its action menu. A node with no groups is visible to everyone who can read the Knowledge Base. A node with groups is visible only to members of at least one of them, plus superusers.
Restrictions inherit down the tree. Limiting a folder limits everything inside it, and a page is visible only when every folder on its path is visible too. Hidden content simply does not appear, in the tree, in folder listings or in search.
That combination gives you room to work. Grant every role the view permission and publish most documentation openly, restrict one folder of sensitive procedures to team leads, and leave a role that has no need for documentation without a Knowledge Base at all.
You cannot hide something from yourself. Whoever created a page or folder keeps access to it, even after restricting it to groups they do not belong to. Restrictions someone else placed on a parent folder still apply.
Password protection
Access groups decide who sees a page. Encryption decides who can read it. For genuinely sensitive material the Knowledge Base offers real encryption, in two forms that behave deliberately differently.
| Protected page | Protected folder (vault) | |
|---|---|---|
| What is encrypted | The page's content and images, across every version in its history | The content and images of every page inside |
| What others see | The page itself, with its title, description, author and version, so a reader knows it exists and can ask for access | A locked node and nothing else. Names, structure and pages are hidden everywhere, search included, until it is unlocked |
| Who can look inside | Anyone holding the page password | Anyone holding the folder password. Superusers included, because nobody bypasses a vault |
| Use it for | One sensitive page in an otherwise open space | A compartment of related sensitive material |
Protect something from its action menu, or turn on encryption as you create a page. A page inside a protected folder can carry its own password as well, and opening it then needs both.
A password you enter stays in your browser's memory for that session only, so reloading asks again. Opening protected content is yours alone and never reveals it to anyone else.
A forgotten password cannot be recovered. The password is the encryption key. DFIRe stores nothing that can decrypt protected content, there is no administrator reset, and this covers every version and image of the page. Treat these passwords as key material.
Protection also locks deletion
Deleting a protected page requires its password first, which proves the person deleting it could read what they are destroying. A folder cannot be deleted at all while anything inside it is protected, so remove the protection or move the content out first.
Superusers are exempt from both rules, for administrative cleanup. They still cannot read the content without the password.
Wrong passwords
DFIRe records failed attempts in the audit log. After ten failures within five minutes it refuses further attempts from that account until the window passes.
Finding and sharing
Knowledge Base pages appear in global search beside cases, evidence and indicators. Titles and descriptions are always searchable, and page content is searchable while it is unencrypted. Results respect the view permission and access groups, and a locked vault's contents stay out entirely until you unlock it.
Any page you can read exports from its action menu. Markdown gives you the raw source for reuse elsewhere. HTML gives you a self-contained file with the images embedded, for sharing outside DFIRe.
Everything, including encrypted material, lives in the DFIRe database and rides along in backups. Encrypted content stays encrypted there.
AI agents
With the MCP server enabled, an agent can read a procedure to apply it mid-case, or draft and update pages from a prompt. It connects with an API key and therefore sees exactly what that key's owner sees. View permissions and access groups apply unchanged, so an agent cannot reach a page its owner cannot.
On a page it can reach, an agent has the same rights the owner has in the application, access groups included. A key whose owner may edit a page can also change or remove the groups restricting it. Give an agent a key holding only the Knowledge Base rights you intend it to have.
Agent edits behave like anyone else's. A change saves as a new version and records the key's owner as the author. An edit that would overwrite a save made meanwhile is refused. Agents cannot delete pages or folders. Every page an agent creates or changes reaches the audit log, marked as arriving through MCP.
Protected content stays out of reach. An agent can list a protected page but cannot read or edit it, and a protected folder keeps its whole contents hidden. DFIRe never sends a password to an agent and never accepts one from it.