FIM Compliance Explained: The Suitability and Limits of Open-Source HIDS Tools

Within the technical requirements of PCI DSS v4.0.1, file integrity monitoring (FIM) maps to Requirement 11.5.2. Its purpose is to ensure an organisation can detect abnormal changes to servers, endpoints, and critical system directories as they happen. The standard explicitly requires a change-detection mechanism covering critical system files, configuration files, and content files, with comparisons performed at least weekly. Industry practice generally favours continuous monitoring over scheduled comparison alone, so that tampering, deletion, or unauthorised additions surface promptly. Beyond detection itself, an assessment gives equal weight to whether a complete audit trail is retained — evidence that lets you trace malicious tampering, backdoor implants, or policy violations after the fact.

Consultant's note: Requirement 10.3.4 governs the integrity monitoring of audit logs themselves. Its scope differs from the system and configuration files covered by 11.5.2, but the underlying principle is the same: if a retained record is tampered with, that must be detected immediately, not discovered long afterwards when the data can no longer be trusted.

Meeting FIM requirements does not depend solely on buying commercial security appliances or software licences. For small and mid-sized businesses, public-sector tender suppliers, and startups working to contain deployment and operating costs, open-source HIDS (host-based intrusion detection system) tools such as OSSEC and WAZUH are legitimate options to bring to an assessment, and they support the baseline capabilities FIM compliance calls for. How much of the requirement they actually cover, however, still has to be assessed case by case against your environment, rule configuration, and ongoing operational capacity.

What Does FIM Compliance Actually Require?

In our experience preparing clients for assessment, many organisations stop at surface-level monitoring — installing the tool, enabling the default rules, and assuming that constitutes compliance, only to find the gaps during the assessment itself. A FIM mechanism that genuinely meets the intent of 11.5.2 needs all three of the following:

• Detection: active monitoring of critical system files, configuration files, and core business directories, capturing additions, modifications, deletions, and permission changes.
• Alerting: an alert record generated as soon as abnormal behaviour is triggered, stating clearly who acted, when, and what changed.
• Log retention: complete preservation of every file-change record, supporting after-the-fact forensic review and satisfying traceability requirements.

Open-source HIDS tools were architected from the outset to cover endpoint security monitoring and file integrity detection, so they can implement part of the above. Whether they fully cover the requirement depends on how they are deployed and how the rules are configured.

PCI DSS Requirement 11.5.2 — The Key Points

Per the PCI DSS v4.0.1 standard, Requirement 11.5.2 states that a change-detection mechanism (for example, a file integrity monitoring tool) must be deployed to alert personnel to unauthorised modification, addition, or deletion of critical system files, configuration files, or content files, with critical file comparisons performed at least weekly. The related audit log protection requirement sits separately at Requirement 10.3.4, which requires that file integrity monitoring or change-detection mechanisms ensure existing log data cannot be altered without generating an alert.

Source: PCI DSS v4.0.1, Requirements 11.5.2 and 10.3.4. For the authoritative wording, refer to the version published by the PCI Security Standards Council. The above is our consulting team's summary, not a verbatim translation of the requirement text.

OSSEC and WAZUH: Two Common Open-Source FIM Tools

Several open-source options can deliver FIM; we cover two of the most common here. OSSEC is an open-source host-based intrusion detection system established in 2004, with file integrity monitoring built in, freely available and supporting mainstream platforms including Linux and Windows. WAZUH is a project that forked from the OSSEC source in 2015 and has been developed and maintained independently since, adding a visual management console, alerting, log analysis, and compliance report export on top of the original FIM core.

Where Each One Fits

• OSSEC: lighter to deploy with a smaller resource footprint, commonly seen on legacy servers and low-specification endpoints where operations are kept lean. It should satisfy baseline FIM requirements.
• WAZUH: offers a visual interface, alerting, and compliance report export, making it the more common choice where routine auditing, external assessment support, or management of a large server estate is required.

Common to both: each is an open-source project with no licensing cost. Whether either belongs in your FIM compliance approach, and whether it passes assessment, depends on your actual configuration, rule design, and ongoing operational management — and ultimately on meeting the PCI DSS requirement. Organisations should assess adoption against their own needs, or run them alongside a commercial solution.

Configuration Concepts for Open-Source FIM Tools (principles, not a step-by-step deployment guide)

What follows describes the configuration logic of FIM in OSSEC and WAZUH, to help you understand the technical points that matter at deployment. Rule design, monitoring scope, and exception handling should still be reviewed before go-live by a consulting team with practical PCI DSS experience — poorly set rules produce alert noise, and an incomplete scope leaves critical paths outside the requirement.

• Enable the core FIM module: edit the agent-side ossec.conf to enable the syscheck file detection module (off by default — it must be turned on manually) and switch on integrity checking. The system generates a checksum fingerprint for each monitored file, then compares fingerprint changes to determine whether a file has been tampered with.
• Configure the directories compliance requires: set core monitoring paths against the areas an assessment focuses on, covering both critical system files and core business files.
  Linux: the /etc system configuration directory, boot startup directories, service configuration directories, and application directories.
  Windows: core system configuration directories, the Registry, application deployment directories, and critical configuration files.
  Enable realtime="yes" for live monitoring and check_all="yes" for full-attribute detection, so that changes to content, permissions, ownership, and modification time are all recorded.
• Turn on forensic tracing and alerting: where the scope demands fuller traceability, consider enabling whodata mode, which uses the operating system's audit subsystem to record who changed a file, through which process, and when — useful for satisfying the audit traceability expectations of PCI DSS and comparable standards.
• Log retention and report export: WAZUH ships with a visual back end that consolidates FIM exceptions automatically, supporting alert statistics, change-record queries, and compliance report export. OSSEC requires a separate log platform (a SIEM, for example) to retain logs for the required retention period.

Where Open-Source Tools Fit — and Where They Stop

Deploying OSSEC or WAZUH for FIM monitoring can support the following compliance objectives to a degree:

• Addressing PCI DSS file change detection and security control requirements.
• Meeting ISO 27001 controls covering information security and change traceability.
• Surfacing malicious tampering, backdoor implants, internal policy violations, or virus-driven file modification earlier.

Open-source tooling is not, however, an install-and-pass solution. We have seen plenty of organisations deploy it and still be written up at assessment — because rules were never tuned to the environment, because alerts were never routed to anyone for action, or because the monitoring scope missed critical directories. FIM is a foundational host security control and a frequent source of assessment findings. Alongside commercial products, OSSEC and WAZUH are genuinely viable options to bring to an assessment; but before committing, have a consultant with hands-on assessment experience confirm that your monitoring scope, rule logic, and retention period actually fit your compliance scope and audit needs.

Closing: The Secure Vectors View

FIM looks like a single technical control, but on assessment day it is often one of the clearest indicators of how mature an organisation's overall security management really is. However finely the rules are tuned, without a matching alert-handling process and the people to run it, you will not meet the requirement's intent of prompt notification. If you are evaluating FIM tooling, or need to understand the gap between your current monitoring and what PCI DSS v4.0.1 asks for, talk to the Secure Vectors consulting team.

Glossary

• FIM (File Integrity Monitoring): a mechanism that detects unauthorised addition, modification, or deletion of critical system files by comparing changes in file fingerprints (hash values).
• HIDS (Host-based Intrusion Detection System): a detection system installed on an individual host or endpoint that monitors system activity, file changes, and abnormal behaviour.
• syscheck: the built-in FIM module in OSSEC and WAZUH, responsible for file integrity comparison and change detection.
• whodata: an advanced monitoring mode that combines the operating system audit subsystem to record the user, process, and time behind a file change, strengthening traceability.
• Change-detection mechanism: the PCI DSS term for any technical means of detecting and alerting on unauthorised file changes; a FIM tool is one such implementation.

Frequently Asked Questions

Q1: Can a smaller business pass a PCI DSS assessment using only open-source FIM tools?
Open-source tools carry the baseline capabilities FIM compliance requires, so in principle they can form part of the evidence. Whether you actually pass depends on rule configuration, monitoring scope, and the completeness of retained records — not on the tool's licensing model. Have a consultant review the configuration against the requirement before you go to assessment.

Q2: Does FIM comparison have to run weekly?
Weekly is the minimum frequency set by PCI DSS v4.0.1 Requirement 11.5.2. Industry practice favours real-time monitoring as the better approach, particularly for internet-facing systems or those handling cardholder data, because it shortens the gap between an anomaly occurring and being noticed.

Q3: Should we choose OSSEC or WAZUH?
They genuinely differ in positioning. Organisations with limited resources, few servers, and a lean technical team should consider OSSEC first; those needing routine audit reporting, a visual management interface, or management of a large server estate will find WAZUH closer to what the work requires. Decide against your own server scale, operational capacity, and audit reporting needs.

Q4: Does FIM only need to cover servers?
No. Any system component within the cardholder data environment (CDE) — including configuration files on endpoint devices and network equipment — should be in scope for FIM monitoring wherever critical system files or configuration files are involved.