PCI’s Not-So-Open Global Forum
Written by Stephen AmesStephen Ames, CISA, CISSP, is the Director of Information Security at Shift4, a payment vendor.
PCI’s Global Forum is an open forum in name only, at least as long as it continues to force changes on members that they are not permitted to even know about until someone who has been briefed chooses to tell them. What makes me say that? Let me tell you a story about how PCI really works.
Just wrapped up onsite PA-DSS validations with my PA-QSA this month and a question came up about PA-DSS Requirement 4.2.7, which aligns with DSS Requirement 10.2, which is all about user access. Just so we’re all on the same page, you need to know that none of my company’s PA-DSS applications have a user database. Hence, all of PA-DSS Requirements 3 and 4 are not in scope for us. That’s the way it has been since Visa’s PABP days and beginning with Version 1 of the PA-DSS.
However, my PA-QSA stated that PA-DSS Requirement 4.2.7 is now always in scope, regardless of whether or not there is a user database within the application. He went on to say that Reports on Validation (ROVs) used to be accepted by the PCI SSC with Requirement 4.2.7 marked “N/A” in the absence of any user database, but the SSC apparently recently “reinterpreted” Requirement 4.2.7 and sent guidance out to the assessor community in some newsletter. More on that later.
He gave me a few options to satisfy his checkbox, which actually correlates with PCI DSS 11.5:
Both of these options would cause application vendors (my employer included) to take on more liability. I’ve searched the PA-DSS for a security requirement that aligns with PCI DSS 11.5 – File Integrity Monitoring – and there is none. I’m certain that most application vendors would not take responsibility for file integrity monitoring at merchant sites. And I’m unable to understand why the SSC is forcing that upon application vendors, when they don’t even have that requirement written into the PA-DSS.
I searched the PCI FAQ database and found no reference to a reinterpretation of PA-DSS Requirement 4.2.7 requiring vendors to take responsibility for file integrity monitoring of their PA-DSS applications running in merchant environments. Once again, PA-DSS Requirement 4.2.7 aligns with DSS Requirement 10.2 and user access, not DSS Requirement 11.5.
So, back to that newsletter that I keep hearing about every time I have a dispute with a QSA or PA-QSA. My question is always, “What newsletter?” and the response is always, “The SSC sends out compliance guidance to the assessor community.”
Really? Are we going to have this argument again, PCI Council?
Pages: 1 2
August 1st, 2013 at 3:25 pm
I agree with your premise that the PCI SSC needs to do a better job of communicating with POs.
I don’t agree with your QSAs interpretation of PA-DSS requirements. 4.2.7 is not specific to user accounts with user databases. “4.2 Payment application must provide an audit trail to reconstruct the following events: 4.2.7 Creation and deletion of system-level objects within or by the application.”
The standard interpretation, in my experience, is that the application must provide an audit trail for system events.
Here are the details on what is supposed to be reported in the ROV:
Describe how the payment application was tested to confirm the following is logged:
i. Creation of system level objects within or by the application
ii. Deletion of system level objects within or by the application
Describe the audit log settings observed to log:
i. Creation of system level objects within or by the application
ii. Deletion of system level objects within or by the application
Describe how the observed audit logs include:
i. Creation of system level objects within or by the application
ii. Deletion of system level objects within or by the application
I think that your QSA might not have been doing what he/she should have been doing as part of validation and is now back-tracking. Now maybe this doesn’t apply to your application simply because system events or objects (like error messages or directory containers) don’t exist, but that’s different than N/A because there’s no user database.
August 6th, 2013 at 10:51 am
I received confirmation from the PCI Council’s director of data security standards that my PA-QSA was not exacly spot on with his guidance. Without getting into too much detail, my application in question is compliant with PA-DSS 4.2 out-of-the-box. I’ll be having a conversation with my PA-QSA about this.