PCI DSS 10.3.4: File integrity monitoring or change-detection mechanisms is used on audit logs to ensure
PCI DSS v4.0.1 control 10.3.4: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.3.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.3
File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts.
Summary
Watch the log data itself for change, so an alteration raises an alert rather than passing unnoticed.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 10.3.4 | Examine system settings, monitored files, and results from monitoring activities to verify the use of file integrity monitoring or change-detection software on audit logs. |
Defence in depth stated as two controls. 10.3.2 prevents modification; 10.3.4 detects it if prevention fails, which is the case that matters because the person most able to defeat prevention is the one with the most privilege. It is the mechanism from 11.5.2 applied specifically to audit logs, and the procedure looks the same: system settings, monitored files, and results from monitoring activities, so a tool deployed without evidence of it operating is thin. Note that this control is about the log data, not the systems that produce it, and getting the scope right is easier once 10.3.3 has consolidated the logs somewhere central, because then there is one place to monitor rather than every host.
What to prepare
- Where audit log data comes to rest, which is the scope of this control.
- The change-detection configuration covering it.
- Results from monitoring, which the procedure examines.
- Who receives an alert and what they do with it.
How to implement it
1. Monitor the central store, not every host. Once 10.3.3 forwards logs centrally, the copy that matters is in one place and the monitoring scope becomes manageable.
2. Expect rotation and account for it. Log files change constantly by design, so the configuration has to distinguish appending and rotating from alteration or nothing will be readable.
3. Route alerts to someone outside the log administration team. An alert that a log changed, sent to the person who could have changed it, is not an independent check.
4. Keep the monitoring results. They are examined directly and are the difference between deployed and operating.
Where this commonly fails
- A tool deployed against rotating files, producing noise nobody reads.
- Monitoring configured on hosts while the central copy is unmonitored.
- Alerts going to the administrators of the logs themselves.
- Assumed to be covered by 10.3.2, which prevents rather than detects.
Related controls
Others in section 10.3:
| Control | What it requires |
|---|---|
| 10.3.1 | Read access to audit logs files is limited to those with a job-related need |
| 10.3.2 | Audit log files are protected to prevent modifications by individuals |
| 10.3.3 | Audit log files, including those for external-facing technologies… |
← 10.3.3 · All controls · 10.4.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.