How to Configure and Review File Integrity Monitoring (FIM)

Overview:

Why a change alert is only useful if you can see what changed

A FIM tool that only tells you "a file changed" forces you to trust that alert blindly. The useful question is never just whether a file changed, it's what changed, who or what process changed it, and whether the new content is something you'd approve. A single MODIFY flag on a config file means nothing without the actual before-and-after content behind it.

The operational problem is usually not detection, it's evidence. Any agent can watch a path and fire an event on write. What separates a trustworthy FIM setup is whether each event carries enough forensic detail, cryptographic hashes, originating process, timestamp, username, to stand on its own during an investigation, and whether you can open the exact line-level diff instead of re-deriving it yourself.

The FIM module treats this as three separate problems solved in order: define which paths matter and where, capture every modification with full forensic context, then let you drill from a trend chart down to the exact line that changed. This guide walks the full workflow end to end: creating a FIM configuration scoped to specific endpoints, reading the resulting events dashboard, inspecting a single event's forensic detail, and using the file version comparison view to see precisely what content changed.

• Scope monitoring precisely: target specific endpoints, categories, and exact include paths rather than watching entire drives.
• Capture forensic context automatically: every event records the originating process, username, PID, and MD5/SHA256/SHA1 hashes, not just a timestamp.
• See the actual change, not just the alert: the file version comparison view shows old versus new content side by side, line by line.
• Track trends, not just single events: date-based trend charts and category breakdowns show whether change volume is normal or spiking.
• Trust the evidence: a MODIFY event is only as useful as the detail behind it, so every event is fully expandable before you act on it.

Prerequisites

Confirm all three before creating your first FIM configuration. Skipping straight to a broad configuration is the most common cause of noisy, low-signal event feeds.

1. Administrator access: your account holds a role permitted to manage the FIM module. Read-only operators can view events but cannot create or edit configurations.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device. A configuration cannot evaluate on a device the agent cannot reach.
3. Target paths identified: know the exact file or configuration paths you need watched (e.g. D:\New folder\textnote.conf) before creating a configuration. Vague or overly broad include paths produce noisy, low-value event feeds.

Architecture: how a configuration becomes a reviewable event

A configuration defines what is watched and where. The agent evaluates that configuration continuously and reports a MODIFY event whenever the target content changes. The event is stored with full forensic context, and any two versions of the file can be opened side by side in the comparison view.

Step 1: Open the FIM module

Get oriented before creating a configuration, so you know where events and configuration each live.

Instructions

1. From the main console, go to Endpoints → FIM.
2. Note the two sections under FIM in the left sidebar: Events and Configuration.
3. Open Events to see the current event feed before creating anything new; a fresh environment shows No data until a configuration exists and a change is detected.

Path: Console / Endpoints / FIM / Events

Result: You're in the FIM module with visibility into the events dashboard before authoring a configuration.

Step 2: Create a FIM configuration

Define a single monitoring rule: what path to watch, on which endpoint, under which category.

Instructions

1. Go to Configuration → Create FIM Configuration.
2. Enter a Name that states what's being watched plainly, e.g. Configuration file monitoring, and toggle Status on.
3. Enter a matching Description.
4. Set Scope to Specific Endpoints, then select the target device under Endpoints, e.g. <ENDPOINT-HOSTNAME>.
5. Set Category to classify the rule, e.g. Config. Previously used categories appear as suggestions (e.g. FIM, Config) so naming stays consistent across configurations.
6. Set Configuration Type to the kind of target this rule watches: Files, Configuration File, or Registry.
7. Enter the exact Include Paths to watch, e.g. D:\New folder\textnote.conf. Leaving this blank blocks saving with a Please enter Include Paths validation message.
8. Optionally set Exclude Paths to carve out sub-paths that shouldn't trigger events.
9. Select Create.

Path: Console / FIM / Configuration / Create FIM Configuration

Console: configuration details

Result: A configuration is created and bound to the target endpoint. The agent begins watching the specified path and will report a MODIFY event the next time its content changes.

Step 3: Review the FIM Events dashboard

Read the event feed as a whole before drilling into any single event.

Instructions

1. Go to FIM → Events.
2. Use the left filter panel to narrow by OS: Windows, Linux, Mac, each showing a live count of matching events.
3. Review File Integrity Monitoring Trends, a bar chart of event counts by date, to see whether change activity is a one-off or a pattern.
4. Review Category wise Event Count, a bar chart breaking events down by category (e.g. Modify) to see what kind of activity is driving the totals.
5. Review the events table: Endpoint, Category, Target Path, Action, Event Time.

Path: Console / FIM / Events

Console: events table (example)

Result: A dated, filterable feed of every detected change, with trend and category charts to spot volume or pattern shifts before reviewing individual events.

Step 4: Investigate a MODIFY event's forensic detail

Expand a single event to see who or what made the change, not just that it happened.

Instructions

1. In the events table, select the row's expand control (>) next to the endpoint you want to investigate.
2. Review Details: Type, Event Time, Process (full path to the originating executable), Category, Username, PID.
3. Review Hashes: MD5, SHA256, SHA1, and the Hashed flag confirming a hash was captured.
4. Review Identifiers: Event ID and Host.

Path: Console / FIM / Events / <row expand>

Console: event detail (example)

Result: A single event now carries enough forensic context, process, user, PID, and three independent hashes, to stand on its own in an investigation without needing to cross-reference other tools.

Step 5: Compare file versions with the diff viewer

Open the exact line-level change behind a MODIFY event instead of inferring it from a hash difference alone.

Instructions

1. From the events table, select the event's Target Path link (or its detail icon) to open the file version comparison view.
2. Review Old version and New version side by side, each showing its own version label, timestamp, MD5, and SHA256.
3. Note the N changes counter at the top right, and use the up/down navigation controls to jump directly between changed lines instead of scrolling the full file.
4. Scroll the line-numbered content on both sides together; removed lines are highlighted on the left, added lines are highlighted on the right, so each edit is visible in context rather than as an isolated fragment.

Path: Console / FIM / Events / <target path>

Console: version comparison (example)

Result: The exact content that changed is visible line by line, confirming precisely what was added, edited, or removed rather than relying on the hash mismatch alone as proof.

Step 6: Track trends over time

Confirm ongoing monitoring health by returning to the dashboard view after investigating individual events.

Instructions

1. Return to FIM → Events.
2. Hover over a bar in File Integrity Monitoring Trends to see the exact date and per-OS breakdown, e.g. Thu, Jul 30, 2026: Windows 2, Linux 0, Mac 0.
3. Use this view on a recurring basis (daily or weekly, depending on change volume) rather than only after an incident, so a spike is caught close to when it happens.

Path: Console / FIM / Events

Result: An ongoing, date-broken-down view of monitored change activity across every OS in scope, ready to catch the next spike early instead of after the fact.

Best practices for file integrity monitoring

Troubleshooting: common issues and resolutions

Frequently asked questions