File Integrity Monitoring

Applies to. 11.5.2 is the home requirement: a change-detection mechanism, with file integrity monitoring tools given as the example, must raise an alert when a critical file is modified, added or deleted without authorisation, and must run its comparison of critical files at least once a week. 10.3.4 applies the same mechanism to audit logs so that existing log data cannot be altered without an alert. 10.7.2 then lists change-detection mechanisms, and 10.7.1 for service providers lists FIM by name, among the critical security control systems whose own failure must be detected and alerted promptly.

Example. A merchant's payment switch runs a FIM agent that hashes its executables, configuration files and log directory each night and compares them with the stored baseline. A patch applied through change control shows up as an expected difference and the baseline is re-taken; an unexplained new file in the executables folder raises an alert that the security team investigates the same day.

Limits. FIM watches the files it has been told to watch and reports that they changed; it does not say whether the change was authorised, so it depends on a change-management process to tell expected changes from suspicious ones. It is not anti-malware: a FIM alert on a new executable is a symptom, and identifying and containing the malware is the anti-malware solution's job. The Council treats FIM as one kind of change-detection mechanism, so 11.5.2 can be met by other change-detection approaches, and the separate change- and tamper-detection mechanism in 11.6.1 covers payment page scripts and HTTP headers as received by the consumer browser, which a server-side FIM does not see.