File integrity checking compares the current state of a file with a trusted baseline, usually by verifying a cryptographic hash or similar checksum. It detects unauthorised modification, corruption and tampering. Defenders should baseline critical binaries, scripts and configuration files, then alert on unexpected changes and investigate whether the alteration was approved, malicious or caused by failure.
What file integrity checking is actually comparing
file integrity checking is a comparison problem: the current file is measured against a known-good baseline, and the result tells you whether the content, metadata or structure has changed in an unexpected way. In practice, the baseline is usually a cryptographic hash, but checksum, file metadata validation and rule-based comparisons can also help surface tampering or corruption.
The key point is that integrity checking does not prove a file is safe, only that it still matches the state you expected. That makes the quality of the baseline critical, especially for binaries, scripts, configuration files and other files whose trust depends on stability.
How defenders use baselines and alerts
Good integrity checking starts before anything goes wrong. Teams decide which files matter, record a trusted reference state and then monitor for drift. The highest-value targets are usually executable files, startup scripts, scheduled job definitions, privilege-related configuration and security tooling, because changes there can alter behaviour without being obvious to users.
When the monitor detects a mismatch, the next step is not to assume compromise automatically. Some changes are legitimate maintenance, some are accidental corruption and some are malicious. A useful workflow is to validate change control, identify the owner of the file, compare the current version with the baseline and decide whether to restore, re-baseline or escalate for investigation.
Where integrity checking is strongest, and where it is weaker
File integrity checking is strongest on files that should change rarely and whose approved changes are tightly controlled. It is weaker on files that change frequently, are generated automatically or vary across environments, because noisy baselines produce alert fatigue and make real tampering harder to spot.
It also depends on the watcher itself. If an attacker can modify the baseline database, suppress alerts or tamper with the monitoring agent, the control may still report a clean system while the file set has already been altered. For that reason, integrity checking works best when paired with strong access control, tamper-resistant logging and a separate path for alert delivery.
Risk and Threat Considerations
Integrity monitoring is often a last line of defence for files that directly affect execution, configuration or trust. The main risk is silent drift, where an attacker, buggy deployment or failed update changes a file in a way that is not immediately visible to operators.
Failure mechanism: If the baseline is stale, incomplete or writable by the same identity that changes the file, the comparison can miss real tampering or treat malicious changes as approved.
Impact: Defenders may miss web shell drops, startup persistence, configuration sabotage or compromised scripts that keep running with trusted status until a separate control detects the damage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | File tampering often supports stealth and persistence. |
| Recommendation — Map unexpected file changes to likely evasion or persistence techniques and investigate surrounding execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Directly covers integrity verification for files and system artifacts. |
| Recommendation — Apply SI-7 to verify critical files against trusted baselines and alert on unauthorized modification. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Integrity checking supports detection of unauthorized file drift and compromise indicators. |
| Recommendation — Continuously monitor critical files for unexpected changes and investigate mismatches promptly. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Integrity checking relies on controlled baselines and managed file changes. |
| Recommendation — Control file baselines and approve changes through configuration management. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | File integrity alerts must be logged and investigated reliably. |
| Recommendation — Log integrity events and retain evidence needed to investigate unauthorized file changes. | ||
Practitioner Guidance
What to prioritise: Protect the files whose integrity has the highest operational consequence, not every file equally. Focus first on anything that can change boot behaviour, authentication flow, privileged execution or security telemetry.
What to verify: Make sure the baseline is created from a trusted state, stored separately from the monitored file path and updated only through controlled change processes. If the baseline can be edited casually, the alert has little investigative value.
Common mistake: Treating any hash mismatch as proof of compromise. The useful question is whether the change was authorised, expected and traceable. Without that context, the control creates alerts but not judgement.
Practitioner takeaway: File integrity checking is most valuable when it is narrowly scoped to high-consequence files, anchored to a trustworthy baseline and paired with a clear process for deciding whether change means maintenance, failure or intrusion.