PCI’s Not-So-Open Global Forum

Written by Stephen Ames
July 22nd, 2013

Stephen 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:

  • Provide detailed instructions in the PA-DSS Implementation Guide on how to perform object-level auditing with all supported operating systems on all program executables and static files associated with the application.
  • Bolt on a COTS or internally developed hashing utility and automatically run periodic CRCs.

    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?

  • advertisement

    2 Comments | Read PCI’s Not-So-Open Global Forum

    1. Marc Says:

      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.

    2. Stephen Ames, CISA, CISSP Says:

      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.


    StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

    Most Recent Comments

    Why Did Gonzales Hackers Like European Cards So Much Better?

    I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
    Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
    A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
    The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
    @David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

    Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.