PCI DSS 10.2.1.4: Audit logs capture all invalid logical access attempts
PCI DSS v4.0.1 control 10.2.1.4: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.2.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.2
Audit logs capture all invalid logical access attempts.
Summary
Failed login attempts are logged, not just successful ones.
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.2.1.4 | Examine audit log configurations and log data to verify that invalid logical access attempts are captured. |
The cheapest of the seven to satisfy and one of the most useful, because a run of failures is the clearest early signal a log can carry. Note the wording: all invalid logical access attempts, not all invalid passwords. A denied authorisation, a rejected API token, a blocked file access and a failed sudo are all invalid logical access attempts. It works with 8.3.4, which locks an account after no more than ten failures: the lockout is the control and this is the record that shows it operating, and shows the nine attempts that did not reach it.
What to prepare
- Configuration for each system class showing failures are logged as well as successes.
- Real entries for a failed attempt on a sample of systems.
- Whatever consumes them, since a failure log nobody reviews still satisfies this control but nothing else.
How to implement it
1. Check that failures are on. Some platforms log successes by default and failures only when asked, which produces a log that looks healthy and is missing the interesting half.
2. Go past passwords. Authorisation denials, rejected tokens and permission failures are all in scope on the wording, and they are what shows an account probing beyond its rights.
3. Alert on the pattern, not the event. One failure is noise. A run against many accounts, or against one account from many sources, is what this data is for.
4. Keep the source address. A failure record without an origin tells you something happened and nothing about where from.
Where this commonly fails
- Success-only logging left at a platform default.
- Authentication failures captured while authorisation denials are not.
- Failures logged and never alerted on, so the record exists only for the post-incident review.
- Application-level failures missing because only the directory logs them.
Related controls
Others in section 10.2:
| Control | What it requires |
|---|---|
| 10.2.1 | Audit logs are enabled and active for all system components and cardholder data |
| 10.2.1.1 | Audit logs capture all individual user access to cardholder data |
| 10.2.1.2 | Audit logs capture all actions taken by any individual with administrative access… |
| 10.2.1.3 | Audit logs capture all access to audit logs |
| 10.2.1.5 | Audit logs capture all changes to identification and authentication credentials… |
| 10.2.1.6 | Audit logs capture… |
| 10.2.1.7 | Audit logs capture all creation and deletion of system-level objects |
| 10.2.2 | Audit logs record the following details for each auditable event… |
← 10.2.1.3 · All controls · 10.2.1.5 →
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.