Log and monitor all access
Requirement 10 requires organizations to implement a comprehensive audit trail that tracks all access to system components within the Cardholder Data Environment (CDE). The goal is to ensure that if a security breach occurs, there is an immutable record of who did what, when they did it, and where the activity originated.
What it means
The intent of this requirement is accountability and detection. By logging all access to cardholder data and administrative actions, you create a forensic trail that allows investigators to reconstruct events after an incident. Monitoring ensures that suspicious patterns—such as repeated failed login attempts or unauthorized configuration changes—are identified in real-time or near real-time.
In practice, this applies to every system component that processes, stores, or transmits payment card data, as well as the security systems protecting them. It is not enough to simply generate logs; those logs must be protected from tampering and reviewed regularly to ensure they are serving their purpose.
How to meet it
- Enable detailed logging on all CDE components, including firewalls, servers, databases, and applications, ensuring that user IDs, event types, timestamps, success/failure indicators, and affected resources are captured.
- Implement a centralized log management system or SIEM (Security Information and Event Management) to aggregate logs from disparate sources into one secure location.
- Configure Network Time Protocol (NTP) across all systems to ensure timestamps are synchronized, which is critical for correlating events during an investigation.
- Establish a formal process for the daily review of security logs; this can be achieved through automated alerting for critical events or manual sign-offs by designated personnel.
- Restrict access to log files and the logging server to only those with a documented business need, using file integrity monitoring (FIM) or similar tools to alert you if logs are modified or deleted.
- Define and implement a log retention policy that keeps audit trails available for at least one year, with at least three months immediately available for analysis.
Evidence an auditor asks for
- Configuration screenshots or exports showing the specific logging parameters enabled on servers, firewalls, and databases.
- Sample log entries demonstrating that all required data fields (user ID, timestamp, event type, etc.) are being recorded correctly.
- Logs of the review process, such as a ticketing system history or a signed daily checklist proving that logs were actually monitored.
- Evidence of NTP configuration across the environment to prove time synchronization.
- Access control lists (ACLs) for the log repository showing that only authorized administrators can access them and that no one has "delete" permissions on historical logs.
Common pitfalls
- "Log and Forget": Collecting massive amounts of data but failing to implement a review process, meaning breaches go undetected despite being recorded.
- Clock Drift: Failing to synchronize system clocks, which makes it impossible to prove the sequence of events during an audit or forensic investigation.
- Local Storage Only: Storing logs only on the local machine they monitor; if an attacker gains root access, they can simply delete the logs to hide their tracks.
- Insufficient Detail: Logging that a "system error" occurred without capturing which user triggered it or what specific resource was accessed.