0

We use EMV card readers to automate the payments at the entry and exit to our services. These card readers and the unattended payment terminals are fully PTS complaint and use P2PE encryption. Also, implemented by PCI-DSS complaint service providers. These devices only transmit "Irreversible Hash" into our systems so as to calculate the charges based on entry and exit time stamps. We process more than 2 million transactions per year.

  1. How far we ("the merchant") go in terms of scoping given that we have implemented the physical security requirements for these card readers and the firmware updates etc for the card readers can only done PCI-DSS compliant providers. All these devices are in a separate VLAN.

  2. Going by PCI-DSS 3.2 requirements which talks about the "connected systems" - In our case although there is an internal system which is a connected system, the card readers never transmit clear text PAN out of them to our internal system. Could our internal system ruled out of scope as they talk to only the complaint card readers.

  3. Having discussed with 2 different QSAs, they provide different opinions about how far we need to go with respect to the connect system. We know for sure there is no way that the EMV readers are going to transmit clear text PAN unless they are physically tampered with - For which we have physical controls in place.

  4. We have also ensured that none of the refund processes will need a full text pan to be shared between the customer and the merchant

  5. (or) all the connected systems (and their shared services like monitoring and logging systems) are in scope just because the EMV readers are in our (Merchants) network?

enter image description here

Will be great to know the opinion of the experts.

Cheers

Improve this question
3
  • Unfortunately, the QSAs are the experts. We're just random knowledgable people on the internet. That said, if your QSA says that you're fine, then you should be covered from a liability standpoint - I'd suggest taking the reasoning from the one who says no to the one that says yes, and hiring and working through it with them.
    – Bobson
    Commented Mar 3, 2019 at 0:18
  • One key question which massively affects the exact scoping answer. Is the P2PE solution you are using validated -- i.e. is it listed here pcisecuritystandards.org/assessors_and_solutions/… on the PCI SSC website?
    – withoutfire
    Commented Mar 4, 2019 at 3:10
  • Yes, all the devices we are using are listed on the PCI SSC website (also the exact model numbers have been verified)
    – Kane
    Commented Mar 4, 2019 at 6:46

1 Answer 1

Reset to default
1

I'd suggest putting in a logic control (rather than just the current physical tamper control) to verify no clear text cardholder data is ever received by the connected system environment. If such data is identified, it should raise an alert. Verify the hashing mechanism in use is strong (e.g. SHA2) and uses salts so you're not vulnerable to rainbow table attacks.

You still need to document how cardholder data is protected within the environment but the connected system should be removed from scope in the same way as a system handling truncated data would be, or a system handling encrypted data would be where the entity has no access to the keys which would be used for decryption.

Improve this answer
2
  • Thanks @Andymac. Will a DLP engine between Firewall B and payment terminals sound reasonable? and by doing this will it help to get the Firewall A and Connected system to be totally out of scope?. Appreciate your time on this.
    – Kane
    Commented Mar 4, 2019 at 21:18
  • You could put the DLP there but you could also put it closer to the connected system. If cardholder data is identified, it can be dealt with according to a defined process and any such identification, if any, should be purely incidental.
    – AndyMac
    Commented Mar 13, 2019 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .