AIDE: Advanced Intrusion Detection Environment | Paytia

What AIDE actually does

AIDE — Advanced Intrusion Detection Environment — is a file integrity monitoring (FIM) tool that's been around since the late 1990s. It's open source, lives on Linux and BSD systems, and does one job very well: it tells you when a file on a server has changed when it wasn't supposed to.

The mechanics are simple. You install AIDE, point it at the directories you care about (system binaries, config files, anything inside your cardholder data environment), and it builds a database. That database stores cryptographic hashes — SHA-256 by default these days — plus file metadata like ownership, permissions, size, and inode numbers. From then on, you re-run AIDE on a schedule and it compares the live filesystem against the stored snapshot. Anything that's been added, deleted, or modified shows up in the report.

That's it. It's not antivirus, it's not an EDR platform, and it doesn't try to block anything in real time. It's a tripwire — and that's exactly what the PCI DSS auditor is looking for.

Why PCI DSS asks for it (Requirement 11.5)

PCI DSS Requirement 11.5 — in v4.0.1, the current version of the standard — says you must "deploy a change-detection mechanism (for example, file integrity monitoring tools) to alert personnel to unauthorized modification of critical files, and configure the software to perform critical file comparisons at least once weekly."

The standard doesn't name AIDE specifically. It says "for example," and any FIM tool that does the same job qualifies. But because AIDE is free, well-maintained, ships in the default repositories of every major Linux distribution, and produces the audit-friendly output that QSAs are used to seeing, it's the default answer for thousands of merchants and service providers.

The other commonly named options are commercial tools like Tripwire (the paid product, not the original Tripwire from the same era as AIDE) and OSSEC. We'll come back to the comparison below.

What files does AIDE actually monitor?

Out of the box, the default AIDE config on most Linux distros watches:

• /bin, /sbin, /usr/bin, /usr/sbin — system binaries
• /etc — configuration files
• /boot — kernel and bootloader
• /lib, /lib64 — shared libraries

For PCI scope, you'd extend that to anything inside the cardholder data environment: web server document roots, application code directories, the database server's config, anything that handles or touches payment data. The point is that an attacker who roots the box and replaces a binary or drops a webshell into /var/www should trigger an alert the next time AIDE runs.

How AIDE works under the hood

The database

AIDE's database is a flat file — usually at /var/lib/aide/aide.db — that stores one row per monitored file. Each row records whatever attributes you've asked it to track. The most common set is:

• Cryptographic hash (sha256, sha512, or both — md5 and sha1 are still supported but you shouldn't use them for PCI work in 2026)
• File size
• Permissions (mode)
• Owner UID and group GID
• Inode number
• Number of links
• Modification time (mtime), change time (ctime), and access time (atime) — though atime is usually ignored because it changes every time anyone reads the file

The config file

aide.conf controls everything. It uses a custom syntax that defines groups of attributes (rules) and then applies those rules to paths. A typical rule for a binary directory might be "track everything except access time and inode number," because inodes can legitimately change during package upgrades.

The check run

You run aide --check on a schedule — usually as a cron job — and it walks the filesystem, recomputes the hashes, and produces a report showing added, removed, and changed files. After a legitimate change (a kernel update, an application deploy, a config tweak), you run aide --update to rebuild the database so it reflects the new baseline.

Where AIDE fits with the rest of your PCI controls

File integrity monitoring is one of about a dozen technical controls a payment merchant needs to have in place. AIDE plugs into the wider picture:

• Logging (Requirement 10): AIDE's reports should be shipped to your central log server so they're tamper-resistant and reviewed daily.
• Vulnerability scanning (Requirement 11.2 and 11.3): AIDE catches changes after they happen; vulnerability scans catch known weaknesses before they're exploited. You need both.
• Change management (Requirement 6.5): Every authorised change should be paired with an AIDE database update so you're not chasing legitimate noise.
• Scope reduction: The fewer systems are in PCI scope, the fewer servers you need AIDE running on. DTMF masking is the most effective way to shrink scope on the telephone payment side, because the cardholder data never reaches your servers in the first place.

AIDE vs commercial FIM tools

The honest answer is that AIDE does the same core job as any commercial file integrity tool. The differences are operational:

• Commercial tools typically offer a central management console, agent-based deployment, real-time monitoring (rather than scheduled checks), and built-in reporting templates that QSAs recognise.
• AIDE needs you to roll your own — usually with config management (Ansible, Puppet, Chef), a central log aggregator, and a ticketing integration for alerts.

For a small merchant with three or four servers in scope, AIDE plus a sensible cron job and email alerts is perfectly adequate. For an enterprise with hundreds of payment-handling hosts, the management overhead of running AIDE manually starts to outweigh the licence cost of a commercial tool.

Common AIDE pitfalls in PCI audits

Running it daily but never reviewing the output

This is the classic finding. AIDE runs every night, generates a report, emails it to an inbox nobody reads. PCI DSS 11.5.2 requires that the change-detection mechanism is configured to alert personnel — which means a human has to actually look at the output and act on it.

Failing to update the database after legitimate changes

If you patch the kernel on Tuesday and don't update the AIDE database, Wednesday's report shows thousands of "changes" and the operator starts ignoring it. Every authorised change needs to be paired with a database update — usually automated as part of the change management workflow.

Forgetting the database itself is a target

An attacker who can edit aide.db can edit the binaries first and then update the database to hide the change. The database should be stored on read-only media, on a separate host, or — at minimum — its hash should be signed and verified independently.

Only monitoring system files, not application files

The default config watches /bin and /etc but ignores /var/www and your application directories. For PCI scope, the application code is at least as important as the system binaries.

AIDE on different operating systems

AIDE ships in the package repositories of every major Linux distribution — Debian, Ubuntu, RHEL, CentOS, Rocky Linux, Alma Linux, Arch — and is available on FreeBSD and OpenBSD. On Windows, it doesn't run natively; Windows shops typically use the built-in System File Checker (sfc /scannow) plus a commercial FIM product, or run AIDE inside WSL if they only need to monitor a specific subset of files.