Somebody asked me a few days ago: EXACTLY what logging we absolutely MUST do for PCI DSS compliance? Since this is a common question, I am broadcasting it here.
The honest answer to the above question is that there is no list of what EXACTLY you MUST be logging due to PCI or, pretty much, any other recent "compliance thingy" (as we all know, PCI DSS rules are more specific than most others). However, the above does NOT mean that you CAN log nothing.
Is this bizarre or what? Yes, it is :-)
But that is exactly why vendors and consultants tell you what you SHOULD be logging. There is no easy "MUST-log-this" list; it is pretty much up to individual auditor, consultant, vendor, engineer, etc to interpret (again, not simply 'read', but interpret!) the PCI DSS guidance (e.g. Requirement 10 that is dedicated to logging) in your own environment.
Our field engineers do interpret it for our log management platform customers; I provided an interpretation in my PCI book, etc. But, there is still no MUST list; just the following route:
PCI DSS guidance -> consultant, vendor engineer, etc -> your very own logging recommendations.
A few folks wondered: why not ask the auditor? Well, these critters :-) will tell you whether "yours is OK" or "OMG, no!", but will not write your logging policy for you. With them, the best approach is: define your logging policy, then show to auditor, if they are happy - now you know what you MUST do.
As a final word: still, I dislike the above compliance-induced daze as much as the next guy. I much prefer that people think what they want from their logs as well as how they need to use them and then log that!
UPDATE: here are some useful pointers to PCI logging as well, that I mentioned on this blog before.
UPDATE2: really insightful follow-up from Martin here.
9 comments:
Also, auditors will never commit to saying that something "makes them happy;" they always want to reserve the right to write you up for something later on. The most you can get them to do is say "OMG no!" right away, and if they don't do that, then you know you're mostly on the right track.
Thx for the comments!
True - but getting a restrained "you are OK for now" is also not uncommon ...
Also many PCI / SOX auditors are relatively naive, but they are learning.
So just because they were happy last year doesn't mean they'll be happy this year.
Is this an opportunity for you? Give free training to auditors knowing this will lead to more sales in the long term.
Well, we did a little bit of that; especially in regards to those auditors that tend to let anything go for a fee ...
See e.g. http://chuvakin.blogspot.com/2007/08/is-your-pci-auditor-scammer.html
Aww, and you didn't link to my post on audit logging?
http://pcianswers.com/2006/07/31/track-and-monitor-all-access-to-network-resources-and-cardholder-data/
Anton, you're the best.
@Anton,
To quote the recently revised (Feb 2008) Self Assessment Questionnaire (SAQ) "D":
10.2 Are automated audit trails implemented for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data?
10.2.2 All actions taken by any individual with root or administrative privileges?
10.2.3 Access to all audit trails?
10.2.4 Invalid logical access attempts?
10.2.5 Use of identification and authentication mechanisms?
10.2.6 Initialization of the audit logs?
10.2.7 Creation and deletion of system-level object?
10.3 Are the following audit trail entires recorded for all system components for each event:
10.3.1 User Identification?
10.3.2 Type of event?
10.3.3 Date and time?
10.3.4 Success or failure indication?
10.3.5 Origination of event?
10.3.6 Identity of name of affected data, system component, or resource?
Thanks for the tip; indeed, SAQ gives more info and more details, but I still hear the same reaction from people who are really looking for step-x-step directions for each log source ...
With so much doubt about what to log and the numerous places where logging information can be retained at this point in time. I'd suggest gathering information by monitoring (logging) data on the user activiity. A product such as Aristotle (www.provecompliance.com) I've seen work very effectively to provide numerous components of the points that are being blogged and questioned here.
Samples are how to determine what to log; every activity of the user and workstation are logged.
How to recreate a potential incident; informaiton is summarized in very easy to use reports that can help, searches are available to find desired information.
How to know when something undesriable is happening: Reports are automatic and help identify what is normal in an environment. Alerts can be set up to inform on specific elsement of data such as a key word that a company wants to konw has been used, such as suicide or a persons name.
These are a few samples of where it can provide immediate value. It does have a couple minor drawbacks, such as only supporting Microsoft workstations platforms. I'd suggest investigating it further for meeting many of the logging requirements.
Post a Comment