It’s not everyday you get to see yourself in print, this is why we blog. It takes a special kind of self-interest to maintain a blog, and an almost blind faith in what you are saying. That’s why I always invite feedback from everyone, and try to ask a question in my posts these days to start things off. I’ve been really impressed with the quality of answers we’ve had in the last week or so.
In line with some comments I made about First Data yesterday, we may need to make it easier to comply, either by making it more technically comprehensible or cheaper to comply. Perhaps both.

I’ve said before that PCI could be split into 2 separate documents, one for techies and one for the business people. I had a couple of comments yesterday saying that PCI is easy to comply with, but the financial side is too great. Some people seem to think it is hard to comply at all, and don’t really care about the financial side at this stage. I could take a guess which side of the company each of these types comes from. I think mostly we have Security people reading this however, which is an interesting blend of both. I consider myself more on the business side now, but up until 6 months ago I would have said I was a techie. Interesting how that works.

So my question of the moment: is integrity of your logs and data something that is important to you? Is it something that PCI should cover, or is it a step too far?

If you comment, please let me know if you are business or technical, or if you are security focused, whether you consider yourself more leaning towards one or the other. I’m interested to find out the different sides of the argument as I think this is where a lot of problems in PCI stem from, and hence a lot of the headaches for us security guys in the first place.

Popularity: 29% [?]

The September 2006 issue (PDF) of (IN)SECURE Magazine they has articles on PCI compliance. One is titled “PCI Demystified” talking about the standard itself and shedding some light on the nuances; the other is titled “Log Management in PCI Compliance” that discussed tools for handling audit logs with respect to PCI.

Regarding audit log management please remember the article posted earlier.

Popularity: 15% [?]

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.”

Popularity: 29% [?]