File integrity monitoring
Configuring watch paths on a fim-kind policy, reading the change-feed panel, and every real limitation of the sensor-side watcher: a bounded poller, no who-data, no Windows owner resolution, no diffing past 64 MB.
File integrity monitoring watches a set of paths you name and reports every add, modify or delete it sees to a change feed. It is configured as the fim policy kind — a fifth kind alongside prevention, sensor update, response and exclusions — assigned to host groups the same way every other policy is. This article covers configuring a watch, reading the change feed, and, in detail, what the sensor-side watcher actually can and cannot see.
Configuring watch paths on a fim policy
The FIM policy kind is the one policy kind with its own structured editor in the console, rather than the generic Settings JSON box every other kind uses. Selecting fim as a policy's kind on the Policies panel swaps in a per-watch-path editor with these fields, one row per path:
| Field | Meaning |
|---|---|
| Watch path | The root path to monitor, e.g. /etc/ssh or C:\Windows\System32\drivers\etc. |
| Recursive | Whether subdirectories under the path are watched too. |
| Realtime | Shortens the poll interval for this path from the 30-second default to 5 seconds. It does not switch to an OS-level notification mechanism — see the limitations below. |
| Who-data | Requests actor attribution on a change. Honoured for every other field; the actor fields themselves are not populated yet — see below. |
| Ignore patterns | Comma-separated patterns matched against both the file's basename and its path relative to the watch root. |
| Diff cap (KB) | The maximum size of a reported unified diff for a modified file, before the sensor omits the diff rather than sending an oversized one. |
The FIM policy panel is cross-linked with the change-feed panel on the same consolidated page: Author a watch policy and View FIM change feed anchor back and forth between the two so you can go from configuring a watch to seeing what it has reported without leaving the page.
Everything else about how this policy resolves — precedence between host groups, the tenant-wide fallback — works exactly as for any other policy kind. See Policy objects and host groups.
The change-feed panel
The File integrity monitoring panel is a read-only table of every reported change: path, change kind (Added, Modified, Deleted), actor and when it occurred. A baseline endpoint exists behind it as well, returning the latest known state per path (excluding any path whose latest reported state is a delete), which is what the platform would call the current inventory of monitored files.
Every reported change raises exactly one alert, unconditionally, tagged MITRE ATT&CK T1565 (Data Manipulation). The server does not filter or de-duplicate what it receives — it trusts that the sensor only reports what the current bundle's watch list actually names. That means the sensor's own watch-policy application is the only thing standing between a sensible change feed and an alert storm; see the rate-limiting note below.
Severity is derived from the kind of change: a delete is high, a modify is medium, an add is low.
What the sensor-side watcher actually does — read this before you rely on it
| Limitation | Detail |
|---|---|
| No who-data / actor attribution | Requesting whodata: true on a watch path is honoured for every other field the sensor reports. The actor_user and actor_process fields simply come back empty, even when who-data was requested. This is not implemented — it needs correlating a file change with a concurrent ETW (Windows) or auditd (Linux) event stream, which does not exist yet. |
| Owner/group resolution: Linux and macOS only | The reported owner and group are resolved to names on Linux and macOS. On Windows, owner and group are not resolved — those fields come back empty there. Resolving an owning SID to a name needs a security-descriptor read that was deliberately not built this wave. |
| Files over 64 MB are hashed but never diffed | A file above 64 MiB is still hashed (so an add, modify or delete is still detected and reported), but no diff is ever generated for it, regardless of the diff cap you set. |
| Diffs are also skipped for binary content or anything over the diff cap | The diff itself is bounded by the watch path's diff cap (default 8 KiB) and skipped for content that looks binary or for anything larger than the cap, even under 64 MB. |
| Events are rate-limited to 200 per cycle | Excess events in one poll cycle are dropped, logged as a count rather than silently lost, and the next cycle's baseline still reflects the true end state — so nothing is permanently missed, but a true event storm in one cycle is not reported change-by-change. |
None of this is a hidden defect — it is the same trade-off the platform's other file and process collectors already make (see What the sensor collects): a userland poller with no kernel module and no driver, in exchange for missing anything that happens and fully reverses inside a single poll interval, and for the who-data gap above. If per-write fidelity or actor attribution is a hard requirement for a specific host, that is not what this feature delivers today.
What to read next
- Policy objects and host groups — how a FIM policy resolves against a host through host-group precedence.
- The signed policy bundle — FIM is one of the bundle sections a sensor genuinely enforces, unlike prevention or exclusions.
- Security configuration assessment — the other new fact-collection surface delivered through the same bundle.