File Integrity Monitoring (FIM): Implementation Guide for Security and Compliance
File integrity monitoring (FIM) detects unauthorized modifications to files and directories by comparing current file state to a known-good baseline. When a critical system binary changes without an authorized change ticket, FIM alerts -- whether that change came from a rootkit replacing /bin/ls, a ransomware payload modifying host files, a supply chain compromise altering an application binary, or a misconfigured script overwriting a firewall rule file.
FIM is one of the oldest security controls in the book, but most organizations deploy it badly: they monitor too many paths, generate thousands of noisy alerts from legitimate update activity, exhaust analyst patience within weeks, and either disable the tool or set it to log-only. This guide shows how to scope FIM properly, tune out legitimate change noise, build a meaningful alert workflow, and satisfy the specific compliance requirements that reference FIM.
What FIM Actually Detects and What It Misses
FIM monitors file metadata and content: hash (MD5, SHA-256), permissions, ownership, size, and timestamps. It alerts when any of these attributes change outside of an authorized window.
What FIM catches
- Malware replacing legitimate binaries with trojanized versions (binary modification)
- Rootkits adding or modifying files in system directories
- Web shells written to web application directories
- Configuration file changes that reduce security posture (firewall rules, SSH config, sudoers)
- Application binary tampering in supply chain scenarios
- Ransomware encrypting files (though EDR is faster at this)
- Unauthorized script additions to startup locations, cron directories, or init scripts
What FIM misses
- In-memory attacks that never touch disk
- Changes to files not in the monitored scope
- Attackers who understand the FIM coverage and stage files outside monitored paths
- Process behavior -- FIM does not tell you what process made the change; you need EDR or auditd for that
- Changes within an authorized maintenance window if exemptions are applied broadly
Critical Paths to Monitor by OS
The most common FIM implementation failure is monitoring too many paths. An enterprise Linux server may have millions of files. Monitoring everything produces millions of alerts from routine operations. Monitor the critical minority.
Linux / Unix critical paths
/etc/-- configuration files:/etc/passwd,/etc/shadow,/etc/sudoers,/etc/crontab,/etc/cron.d/,/etc/ssh/sshd_config,/etc/hosts,/etc/ld.so.conf/bin/,/sbin/,/usr/bin/,/usr/sbin/-- system binaries/boot/-- kernel and bootloader files/lib/,/lib64/,/usr/lib/-- shared libraries/etc/systemd/-- systemd unit files (a common persistence location)/var/spool/cron/-- user cron jobs- Web application roots (e.g.,
/var/www/html/,/opt/app/) - Application configuration files containing secrets or connection strings
Windows critical paths
C:\Windows\System32\-- system DLLs and executablesC:\Windows\System32\drivers\-- kernel drivers (a prime rootkit target)C:\Windows\SysWOW64\-- 32-bit system files on 64-bit Windows- Windows Registry hives (FIM tools that support registry monitoring):
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run,HKLM\SYSTEM\CurrentControlSet\Services\ C:\Program Files\andC:\Program Files (x86)\for monitored applications- Group Policy template directories:
C:\Windows\SYSVOL\ - Web server roots and application deployment directories
Paths to explicitly exclude
- Log files and log rotation directories -- change constantly legitimately
- Temporary directories (
/tmp,C:\Windows\Temp\) -- extremely noisy with almost no security value - Package manager cache directories
- Application data directories that change continuously during normal operation (database files, session stores, cache files)
- Files modified during known patch windows (implement scheduled exclusion windows instead of permanent exclusions)
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
FIM Tool Selection
Open source options
Wazuh: The most widely deployed open-source FIM tool. Provides agent-based file monitoring with centralized alerting, SIEM integration, and built-in compliance mapping (PCI DSS, HIPAA, GDPR). The FIM module computes SHA-256 hashes on a configurable schedule and on real-time events via inotify (Linux) and ReadDirectoryChangesW (Windows). Alert output goes to Elasticsearch via Wazuh Manager. Good choice for organizations already using Wazuh as their host-based detection platform.
OSSEC: The predecessor to Wazuh, still widely deployed. Simpler than Wazuh, less active development. The Wazuh fork is preferred for new deployments.
Tripwire Open Source: The original FIM tool (1992). Generates cryptographic baselines and compares on a schedule. Does not provide real-time monitoring; relies on scheduled scans. The open-source version lacks the reporting and compliance features of Tripwire Enterprise.
auditd + auditbeat: Linux auditd provides kernel-level file access monitoring via the Linux Audit System. auditbeat ships auditd events to Elasticsearch. Unlike hash-based FIM, auditd captures the process and user that made the change -- extremely valuable for incident investigation.
Commercial options
- Tripwire Enterprise: Mature FIM with change management workflow integration, compliance reporting for PCI/HIPAA/CIS, and large enterprise scale. High licensing cost.
- Qualys FIM: Cloud-based, agent-deployed, integrated with Qualys vulnerability management. Good for organizations already in the Qualys platform.
- CrowdStrike Falcon FIM: Integrates FIM with EDR; provides process context for file changes (which process touched the file). Reduces the gap between FIM and behavioral detection.
- Illumio / Carbon Black App Control (formerly Bit9): Application control with FIM capabilities; blocks unauthorized file execution as well as alerting on changes.
Building a Tuning Workflow to Reduce Noise
Raw FIM output is unusable in most environments. A patched Linux server may trigger 10,000 file change events during an apt upgrade. The tuning process converts noisy FIM into high-fidelity detections.
Phase 1: Baseline establishment (weeks 1-2)
Run FIM in audit/log-only mode during a representative period (including at least one patch cycle). Do not alert yet. Catalog every change pattern:
- Which paths generate changes, at what frequency?
- What processes create the changes?
- Are the changes predictable (e.g., log rotation at midnight, package updates on Tuesday)?
Phase 2: Change management integration
FIM becomes high-fidelity when integrated with your change management system. Changes with approved change tickets during the change window are automatically suppressed or tagged as authorized. Only changes outside approved windows or without tickets generate alerts.
- In ServiceNow or Jira: webhook from the change management system to FIM before each approved maintenance window, marking the affected hosts and time window
- In Wazuh: use active response rules to suppress alerts for hosts tagged as in-maintenance
Phase 3: Path-level tuning
For each high-volume path, apply one of:
- Remove from scope if it has no security relevance and changes constantly
- Add to maintenance exclusion list if changes only occur during authorized windows
- Increase alert threshold (e.g., alert only on hash change, not timestamp change) for paths with legitimate frequent updates
- Add process allowlisting: alert only when changes are made by unexpected processes (requires auditd or EDR integration)
Phase 4: Alert response SLA
Define response SLAs by severity:
- Critical system binary change (unexpected hash of
/bin/ssh, Windows system DLL): 15-minute response - Configuration file change outside change window: 1-hour response
- Web root file addition (possible web shell): immediate alert + automated isolation
SIEM Integration and Correlation Rules
FIM alerts are most valuable when correlated with other security events. A standalone FIM alert that /etc/sudoers changed is informative; the same alert correlated with an authentication event from an unexpected IP five minutes earlier is an active incident.
Wazuh to Splunk
Wazuh forwards events to Splunk via the Splunk Add-on for Wazuh or syslog. Key FIM fields: rule.id, syscheck.path, syscheck.sha256_before, syscheck.sha256_after, syscheck.uname_after (user that made the change).
Splunk correlation example:
index=wazuh rule.groups="syscheck"
| where isnotnull(syscheck.sha256_after)
| eval changed_by=syscheck.uname_after
| join type=left host [search index=wazuh EventCode=4624 earliest=-15m | table host, src_ip]
| where isnotnull(src_ip)
| table _time, host, syscheck.path, changed_by, src_ip
This surfaces file changes where the same host had an authentication event from an external IP in the prior 15 minutes.
Microsoft Sentinel (KQL)
CommonSecurityLog
| where DeviceVendor == "Wazuh"
| where Activity contains "syscheck"
| extend FilePath = extract("File: (.+?) was modified", 1, Message)
| join kind=leftouter (
SecurityEvent
| where EventID == 4624
| where IpAddress != "-"
| project TimeGenerated, Computer, IpAddress
) on Computer
| where abs(datetime_diff('minute', TimeGenerated, TimeGenerated1)) < 15
| project TimeGenerated, Computer, FilePath, IpAddress
Elastic (EQL)
sequence by host.name with maxspan=15m
[authentication where event.action == "logged-in" and source.ip != null and not cidr_match(source.ip, "10.0.0.0/8", "192.168.0.0/16")]
[file where event.action == "modification" and file.path like~ "/etc/*" or file.path like~ "/bin/*"]
Compliance Requirements That Reference FIM
PCI DSS v4.0 -- Requirement 11.5
Requires deploying a change-detection mechanism (FIM) on all system components within the cardholder data environment (CDE). Specifically:
- 11.5.1: FIM must be deployed to alert personnel to unauthorized modification of critical files, including: system files, application files, content files, and configuration files
- 11.5.2: FIM must perform file comparisons at least weekly
- 11.5.1.1 (new in v4.0): FIM tools must be configured to detect changes to permitted and prohibited scripts for any payment page scripts (web skimming defense)
PCI DSS requires documentation of the FIM scope, the critical files covered, the comparison interval, and the response procedure for alerts.
HIPAA Security Rule
HIPAA's Technical Safeguards (45 CFR 164.312) require audit controls and integrity controls that detect unauthorized alteration of ePHI. FIM satisfies the integrity control requirement for systems storing or processing ePHI. HIPAA does not mandate a specific tool but requires documentation and periodic review.
SOC 2
SOC 2 CC7.1 (Common Criteria for Change Management) and CC7.2 (System Monitoring) cover FIM-adjacent controls. Auditors increasingly expect to see FIM evidence for SOC 2 Type II reports covering infrastructure.
CIS Controls v8
Control 3 (Data Protection) includes Safeguard 3.14: Log sensitive data access, including modifications to FIM-covered files. Control 8.5 requires collecting audit logs from endpoints, which includes FIM events.
The bottom line
FIM works when scoped correctly. Monitor 50-100 critical paths per host rather than thousands. Integrate with your change management system so authorized changes do not generate tickets your team ignores. Pipe FIM events to your SIEM and correlate with authentication and network events to surface the meaningful subset of file changes that indicate active compromise. For compliance, document your scope, coverage, and response procedures -- auditors will ask for all three.
Frequently asked questions
What is file integrity monitoring (FIM) and how does it work?
FIM monitors files and directories for unauthorized changes by computing cryptographic hashes (typically SHA-256) of file contents and metadata (permissions, ownership, timestamps) and comparing them to a known-good baseline. When a file changes and no authorized change ticket exists for that change, FIM generates an alert. Some FIM tools use real-time event monitoring (inotify on Linux, ReadDirectoryChangesW on Windows) for immediate detection; others run scheduled baseline comparisons.
Is FIM required for PCI DSS compliance?
Yes. PCI DSS v4.0 Requirement 11.5 explicitly mandates deploying a change-detection mechanism on all system components within the cardholder data environment. It requires alerting on unauthorized modification of critical files and performing comparisons at least weekly. PCI DSS v4.0 added Requirement 11.5.1.1 specifically for payment page script monitoring to address web skimming attacks. Non-compliance with this requirement is a finding in any PCI QSA assessment.
What is the difference between FIM and EDR?
FIM detects file changes (what changed and when). EDR detects process behavior and can tell you what process made the change and what that process did before and after. FIM is a compliance control that covers a specific requirement; EDR is a detection platform with broader coverage including in-memory attacks, process injection, network behavior, and credential theft. For maximum coverage, deploy both: FIM for compliance and persistent configuration monitoring; EDR for behavioral detection. Some EDR vendors (CrowdStrike) include FIM functionality in their agent.
How do I reduce FIM alert noise without missing real threats?
The three-step approach: (1) Scope reduction -- remove high-volume paths with no security value (log files, temp directories, cache directories) from FIM coverage entirely; (2) Change window suppression -- integrate FIM with your change management system to suppress alerts for hosts during authorized maintenance windows; (3) Process filtering -- where possible, alert only on changes made by unexpected processes (requires auditd or EDR integration for process context). The goal is fewer, higher-fidelity alerts, not maximum coverage.
What are the best open-source FIM tools?
Wazuh is the most widely deployed open-source FIM platform and the recommended choice for new deployments. It provides agent-based real-time monitoring, SHA-256 hashing, SIEM integration, and built-in compliance mapping. OSSEC is Wazuh's predecessor and still functions but receives less active development. For Linux-specific environments, auditd combined with auditbeat provides kernel-level file access monitoring with process context -- complementary to hash-based FIM rather than a replacement.
How often should FIM baselines be updated?
Baselines should be updated after every authorized change: OS patches, application updates, configuration changes made through change management, and approved software installations. The update process should require sign-off from a security team member, not just an automated trigger -- automated baseline updates can be abused to incorporate attacker-made changes. Document each baseline update with the change ticket number and what changed, so auditors can verify the change was authorized.
Does FIM work for cloud environments and containers?
For cloud VMs (EC2, GCP Compute Engine, Azure VMs), FIM agents deploy the same as on-premises. For containers, FIM is less effective because containers are ephemeral -- the baseline resets on each deployment. Container-focused alternatives are: (1) image scanning at build time to ensure the container image matches the approved baseline; (2) runtime security tools like Falco that monitor file access by container processes in real time; (3) read-only filesystem enforcement where possible, making unauthorized file changes impossible rather than just detectable.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.