File Integrity Monitoring

File integrity monitoring answers one question: has a file that should not change been changed? The control records a trusted state of selected files, directories, and settings, then reports every later difference together with the time and the account behind it. The value lies less in the detection itself than in turning an unexplained change into a record someone must close, instead of a silent edit that nobody notices.

FIM is built on file integrity checking, the verification act itself. The difference is continuity: a one-off check answers the question once, while FIM keeps asking it and keeps the history of every answer. That history is what an investigator needs when a configuration file changed weeks before anyone noticed.

Each watched path goes through the same loop. A baseline of hashes and attributes is taken from a known-good state. Every later event is compared with that baseline, so the alert reflects what actually differs and names the file, the change, the account, and the time. The quality of the control depends mostly on the baseline and on the discipline of the alert owner, not on the detection engine.

Scheduled comparison re-checks the baseline at fixed intervals and reports drift. It is cheap and easy to audit, but a change made right after a scan stays hidden until the next one. Real-time monitoring reacts to writes, moves, and deletions as they happen, which is why a SOC usually wants it for system binaries, startup scripts, and access rules.

Real-time mode costs more. It needs an agent on the host, produces more events, and needs tuning from the first day. Many teams run both: real-time for the few paths that matter most, and scheduled comparison across the wider estate, so an event the agent missed is still caught by the next full pass. For the broader practice, see continuous monitoring.

On its own, a file-changed alert is thin. It says a path differs from the baseline, but nothing about intent. FIM earns its place when the alert lands in the same pipeline as every other signal, so an analyst reads it next to logins, processes, and the ticket that should explain the change. Teams that already forward events to a SIEM integration can place the file change on the same timeline as logins and connections.

FIM is one of the most frequently named controls in security frameworks, which is why SOC teams deploy it even where no incident has occurred. Most auditors ask for the same evidence: a defined list of critical files, alerts on unauthorized change, and proof that a person reviewed each alert and closed it with a decision.

• PCI DSS requires a change-detection mechanism on systems that process cardholder data, with critical files compared at least once a week.
• NIST SP 800-53, control SI-7, covers the integrity of software, firmware, and information.
• HIPAA's integrity safeguard expects covered entities to have electronic mechanisms that confirm electronic health information has not been altered or destroyed without authorization.
• ISO/IEC 27001 Annex A includes change-management and system-integrity controls that a documented FIM process helps evidence.
• Auditors typically ask for the protected-file inventory, sample alerts, and a review trail showing each alert was closed with a decision, not just generated.

Anexet does not baseline arbitrary system paths or hash every file on a server, so it is not a classic FIM engine. Its console records file operations on workstations and network shares: for files, create, read, write, delete, rename, execute, and permissions change; for folders, a narrower set. Each agent profile selects which operations are recorded. Network shares are covered by file transfer and network share monitoring.

The largest operational risk with FIM is not missing a real change. It is drowning the SOC in noise until every alert is dismissed unread. Containers change the picture: images are rebuilt rather than patched in place, so the baseline moves into the image pipeline. Tuning follows a predictable sequence:

1. 1

   Capture the baseline

   Record it from a known-good build of the system.

2. 2

   Run in report-only mode

   Learn what normally changes on that class of system.

3. 3

   Exclude volatile paths

   Leave out legitimately volatile paths such as caches, logs, and package manager metadata.

4. 4

   Route alerts to an owner

   The owner closes each alert with a recorded reason.

FIM detects that a monitored file changed. It does not judge whether the new content is malicious, and it does not prevent the change. It sees nothing about activity that never touches a watched path, such as in-memory execution, credential misuse, or data copied out without any file being altered.

A mature SOC therefore treats FIM as one detective control among several. It pairs FIM with access controls that limit who can write to protected paths, with log file integrity checking so integrity events survive on infrastructure the attacker does not control, and with backup and recovery so a confirmed unauthorized change can be reversed.

Start with the few files whose silent change would hurt most: system binaries on servers, the configuration of security tools, and the paths that hold protected data. Add more paths only after the owner has explained every alert the first set produced.

Further reading: Mechanisms for ensuring the security of information systems; What are SIEM Systems for Information Security management?.