PCI Blog - Compliance Demystified

Track and monitor all access to network resources and cardholder data

The PCI DSS requirement to enable audit logging is a difficult item to address when read strictly as is. Many people see the word “All” in there so often in terms of what they should log and feel it is impossible to accomplish. Many UNIX administrators have said, “In order to log ALL access I would need to install a kernel-level keystroke monitor” while DBAs have said, “This means I need to enable auditing on the database which will create an audit log larger than the database itself!” These are not the intended extremes the requirement has been interpreted to mean.

The intent of the requirement is stated in the very first lines where it says, “Establish a process for linking all access to system components … to an individual user.” This requirement is mean to show: Who did What and When, in order to (1) alert on suspicious activity and (2) facilitate a forensic investigation. If you can remember this then the rest of the requirement should be clear and straightforward. (Notice I did not say it would be easy.)

This level of logging usually entails aggregating logs from multiple sources in order to track and alert on user access throughout the enterprise. This means aggregating events from the following locations:

• Network (i.e. Routers/switches, VPN, IDS, Wireless, etc.)
• Operating system (i.e. UNIX, WinTel, mid-mainframe, su/su-do logs, etc.)
• Application (i.e. web server, database server, POS application, or proprietary payment application)
• Database applications (in some instances when access cannot be tracked through any of the above three methods.)

The most common audit log to not be present is the application log because many in-house or commercial off the shelf (COTS) applications do not support event logging. Sometimes the audit logs on show critical events such as “application failed [*timestamp*]” as if you needed a log to tell you that. In these instances where the application does not log user access many companies will rely on the database log. This does not mean that you need to log every SQL query into the database; instead you should look to track what events were performed when.

Think about database logging logically. The intent is not to track one individual user to a specific credit card number because what will that give you? Many people within the department or throughout the corporation may have access to the same individual account numbers during the period of a day, week, or month. Even with specific event logging how can such granular access link an individual to the single card compromise. The level of logging should provide accountability at a reasonable level to support the two original goals of audit logging. If you can accomplish these two objectives then you are logging to a sufficient degree.

Similarly the requirement for event log review is to meet one of the original two requirements of “alerting on suspicious activity.” If it is not possible to review all audit logs on a daily basis then either delegate responsibility such that no one individual is responsible for reviewing all event logs or review the logs on a less frequent basis but still one that meets the control objective. Also, consider compensating controls that may exist such as departmental log review independent of the enterprise log review or automated alerts generated based on preconfigured critical event flags. Each of these items may alerts on suspicious activity without the requirement for a daily review of audit logs.

Update: Visa has provided a clarification 10.2-10.3 of PCI DSS v1.0:

The intent of these logging requirements is twofold: 1) logs, when properly implemented and reviewed, are a widely accepted control to detect unauthorized access, and 2) adequate logs provide good forensic evidence in the event of a compromise.

Each and every log does not necessarily have to log all the data as specified in the details under 10.2 and 10.3, as long as the specified log items and events can be easily gathered in the event of a compromise from the various logs and/or logging tools in use.

There is an additional clarification specifically for requirement 10.2.1, which states “Log all individual accesses to cardholder data.” The intent of requirement 10.2.1 is that if an individual (person) accesses cardholder data on their own, with their own user ID, and does not go through an application (or stored procedure, etc.) for this access, that should be logged. This requirement is often confused to mean that if an individual accesses cardholder data through an application, then all application access to cardholder data needs to be logged. It is not necessary to log all application access to cardholder data if the following is true (and verified by assessors):

• Applications that provide access to cardholder data do so only after making sure the users are authorized
• Such access is authenticated via requirements 7.1 and 7.2, with user IDs set up in accordance with requirement 8, and
• Application logs exist to provide evidence in the event of a “compromise.”