Monitoring versus checking
Most product literature uses the two terms interchangeably. The useful distinction is operational, not definitional. File integrity checking is the verification act itself: a comparison against a baseline, often run on a schedule. FIM usually means the continuous discipline around that check: event-driven detection, attribution of the change to a process and a user, alerting, a triage workflow, and reporting suitable for audit. In practice, a FIM deployment includes scheduled verification as one of its modes.
What a FIM control watches
Scope is deliberately narrow. FIM works in proportion to how carefully the protected set is chosen, and that set usually starts from data classification. Monitoring everything produces a change feed nobody can read.
| Asset | Why it is watched |
|---|---|
| System binaries and libraries | Replacement or patching of core components. |
| Configuration files | One edited line can disable logging or widen access. |
| Application code and published web content | The place where injected code reaches users. |
| Persistence locations | Scheduled tasks, services, startup entries, cron definitions. |
| Credential and key stores | Changes here often mean changed access rights. |
| Security agents and their configuration | Disabling the monitor is a standard early step. |
| Immutable records | Logs and archives are valuable only if they stay unchanged. |
Where FIM sits among controls
FIM detects change to files. It does not prevent change, does not judge whether new content is malicious, and does not see activity that never touches a monitored file, such as in-memory techniques, credential misuse, or data copied without modifying anything.
That is why it is paired with access controls and privilege management, endpoint detection for runtime behavior, centralized logging so integrity events survive on a system the changer does not control, and backup and recovery so a detected change can be reversed.
What a change event should contain
A usable event answers more than whether a file differs. It records four things.
Attribution is what turns integrity monitoring into an investigative tool. It answers the question that user activity monitoring asks about people. A configuration change in an approved maintenance window, made by the deployment account, is different in kind from the same change at night from an interactive session.
| Question | What the event records | Why it matters |
|---|---|---|
| What changedFile content, permissions, ownership, or timestamps | Ideally the diff itself, not only a flag | A reviewer can judge the change, not just its existence |
| WhenTime of the write | The time of the change, not only the time of detection | Detection lag can hide the real order of events |
| Who and howAccount and process | The user account and the process that performed the write | Separates a deployment from an interactive session |
| Expected or notChange context | Correlation with change tickets, patch windows, and deployments | Turns an alert into a closed question |
Compliance drivers
FIM is named or implied in most security frameworks and in payment, healthcare, and public-sector requirements. These usually expect two things: critical files are monitored for change, and a person reviews and resolves the alerts. Auditors typically ask for the protected file inventory, evidence of review, and records showing how each detected change was resolved. The documented workflow matters as much as the tool. Keeping that evidence current is the core of compliance monitoring.
Deployment and tuning
Most of the effort in a FIM program is tuning. A deployment that skips the learning period almost always ends up ignored. The baseline is a set of fingerprints of a known-good state, and every alert comes from a comparison against it.
- 1
Build the baseline
Start from a known-good state.
- 2
Run in report-only mode
Stay long enough to learn what changes normally.
- 3
Exclude volatile paths
Caches, temporary directories, logs, and package databases.
- 4
Assign alerts to an owner
Someone triages the remaining alerts.
- 5
Update the baseline in change control
Approved deployments should not arrive as incidents.
Common mistakes
Most failed programs fail in the same few places.
Monitoring everything on day one is the fastest way to get FIM switched off.
- The baseline is never updated, so every approved patch looks like an incident.
- Volatile paths such as caches and logs stay in scope, so the alert feed fills with noise.
- Alerts have no named owner, so nobody reviews them.
Where to start
Start with the files whose change would hurt most: system binaries, security settings, and the logs that prove what happened. Add the rest only after the first alerts have an owner. An unexplained change is one signal among many, so read it alongside insider threat indicators.
Further reading: Mechanisms for ensuring the security of information systems; What are SIEM Systems for Information Security management?.
A changed file is only evidence once someone can say who changed it, and why.
Anexet Team