File Integrity Monitoring (FIM)

File Integrity Monitoring (FIM) is a security control that monitors and detects changes to files, directories, and system configurations. It creates a baseline of known-good file states (typically using cryptographic hashes) and periodically rechecks files to identify any deviations. FIM is a foundational control for compliance (e.g., PCI DSS Requirement 11.5) and for detecting unauthorized modifications, such as those made by malware, attackers, or insider threats.

The FIM process follows these steps: 1. Baseline Creation: During initial deployment, FIM scans designated files/directories and computes a cryptographic hash (e.g., SHA-256) for each file. It also records metadata like file size, permissions, and last modified timestamp. This baseline is stored in a secure, often immutable, database. 2. Scheduled Scanning: At regular intervals (e.g., hourly, daily), FIM rescans the same files and recomputes hashes. 3. Comparison: The new hashes are compared to the baseline. If any hash differs, or if metadata changes (e.g., permissions changed from 644 to 755), FIM generates an alert. 4. Alerting & Response: The alert is sent to a SIEM or SOC. Analysts investigate the change to determine if it was authorized (e.g., a software update) or unauthorized (e.g., malware modification).

Attackers may attempt to bypass FIM by: - Modifying the baseline: If the baseline database is writable, an attacker could replace hashes to match malicious files. Countermeasure: Store baseline on read-only media or in a database with strict access controls. - Disabling the FIM agent: Attackers may stop the agent service. Countermeasure: Use agent self-protection (e.g., Tripwire's kernel module) and monitor agent heartbeats. - Timing attacks: Attackers modify files between scans. Countermeasure: Use real-time FIM (e.g., Linux inotify, Windows Change Journal) or increase scan frequency. - Hash collision attacks: Though SHA-256 collisions are not feasible, older algorithms like MD5 or SHA-1 are vulnerable. Countermeasure: Use SHA-256 or stronger.

Linux: Using `sha256sum` to manually verify integrity

sha256sum /etc/passwd > baseline.txt
# Later:
sha256sum -c baseline.txt

Wazuh (Open Source FIM) Configuration snippet for monitoring /etc:

<syscheck>
  <directories check_all="yes">/etc</directories>
  <frequency>3600</frequency>
</syscheck>

Windows: Using `Get-FileHash` in PowerShell

Get-FileHash C:\Windows\System32\drivers\etc\hosts | Format-List

FIM tools typically forward alerts via syslog or API to SIEM platforms (e.g., Splunk, ELK). Alerts include:

Scenario 1: Ransomware Detection

A SOC analyst receives a FIM alert from an endpoint protection platform indicating that multiple .docx files in a user's Documents folder have changed hashes within minutes. The analyst checks the SIEM and sees that the changes originated from a process named 'encryptor.exe' running from a temp directory. The analyst immediately isolates the endpoint using the EDR tool and initiates ransomware response procedures. The FIM alert was the first indicator of compromise, detected before the ransomware could encrypt network shares. The correct response was to act on the alert quickly; a common mistake would be to dismiss it as a false positive because the user was actively working on documents.

Scenario 2: Insider Threat Modification of a Configuration File

A FIM alert on a critical web server shows that the file /etc/httpd/conf/httpd.conf has been modified. The analyst checks the change management system and finds no corresponding ticket. Further investigation reveals that the change was made by a system administrator who added a redirect to a malicious site. The analyst escalates to the incident response team, and the administrator is interviewed. The FIM tool's logging showed the exact time and user account that made the change. The common mistake here would be to assume that all administrator actions are authorized; FIM provides the necessary audit trail to detect malicious insiders.

Scenario 3: Compliance Audit Preparation

A company undergoing a PCI DSS audit must demonstrate that FIM is in place for all cardholder data environments. The security team deploys a FIM solution scanning all servers handling credit card data. They configure weekly scans and store baselines in a write-protected database. During the audit, the assessor reviews FIM reports and verifies that alerts are being reviewed. The team shows a documented process for updating baselines after authorized changes. The common mistake is failing to update baselines after software updates, causing false positives that lead to alert fatigue and missed real threats.