File Integrity Checking

A baseline is a record of how files should look: a cryptographic fingerprint of each file's content, together with its size, permissions, owner, and timestamps. Every later check compares the current state with that record. The question is therefore not whether a file looks suspicious, but whether it still matches the baseline.

The same idea is called file integrity monitoring (FIM) when it runs continuously across a set of servers and workstations. The underlying check is identical. What changes is how often it runs and who reads the results.

The comparison is exact. A hash changes completely when one byte changes, so there is no partial match and no doubt about whether content is identical.

The method runs in five stages, and each stage builds on the one before.

1. 1

   Baseline creation

   The files to protect are cataloged. For each one, a cryptographic hash of the content is stored with metadata: size, permissions, ownership, and timestamps.

2. 2

   Verification

   On a schedule or in response to events, the values are recalculated and compared with the baseline.

3. 3

   Reporting

   Differences are reported as change events, showing what changed and when.

4. 4

   Triage

   Each change is matched against expected activity: an approved patch, a configuration deployment, an application update, or something unexplained.

5. 5

   Baseline update

   Legitimate changes are absorbed into a new baseline, so the reference stays current.

Scheduled checking walks the protected set at fixed intervals. It is simple and predictable in resource use, but it is blind between runs: a file can be changed, used, and restored before the next pass.

Real-time checking uses file-system events and reports a change the moment it happens. This shortens detection time and adds the identity of the responsible process and user. The cost is constant agent activity and more noise to filter.

Teams usually protect a short list of targets, chosen for the damage a silent change would cause.

The same mechanism serves several purposes. It detects unauthorized change (the security use), confirms that approved changes deployed as intended (the operations use), confirms that stored archives have not degraded through media faults (the preservation use), and shows that records were not modified after the fact (the evidentiary use). The last matters most for sensitive data that carries retention duties.

Checking a downloaded program against a published hash applies the same idea to a single file at a single moment.

The Anexet administrator console keeps hash banks in the agent profile. The File system tab lists the banks applied to file system monitoring, with the number of files and hashes each one holds. The statistics window shows when a bank was last updated and when it was last checked.

1 / 2

• 
• 

The method has five practical limits. A change made by an insider threat with legitimate access looks like any authorized change, so the check alone is not enough. Its value depends on someone triaging each report promptly.

• Change volume: without tight scoping, noise buries the reports and they stop being read.
• Detection, not prevention: a report shows a change but does not stop it. Blocking has to come from a separate control such as data loss prevention.
• Baseline trust: a baseline taken from a compromised system treats the compromise as normal.
• Content-blind: the check shows that a file differs, not whether the difference matters.
• Runtime and in-memory attacks: attacks that never touch a monitored disk file are out of scope.

Despite these limits, most security frameworks and payment and sector standards require integrity checking, and it is a common part of compliance monitoring.

It is cheap to run and gives unambiguous evidence. It is one of the few controls that can prove a negative: that a critical file has not changed since the last verified state.

Further reading: Mechanisms for ensuring the security of information systems; Encryption, coding and hashing – what is the difference?.