Compliance Scope

Point to Point Encryption(P2PE) & Scope Reduction

The evolution of credit card payments over the last decade has been staggering and the ability  for merchants to keep up with the ever changing landscape can be quite daunting.   It seems your acquirer/merchant bank is always urging you to change products due to enhanced security or better features.  In a world of ever-evolving technologies, what is the right payment acceptance investment  for your business? Point to Point Encryption, or P2PE could be that solution.

P2PE is a payment security system that instantaneously converts confidential credit card data and information into indecipherable code at the swipe of the card to prevent hacking and fraud.   Credit card data becomes inaccessible at any point to other systems, networks or applications that your organization might be using, significantly reducing the scope of the Payment Card Information (PCI) Data Security Standard (DSS). P2PE alleviates many of the  technical requirements that make it impossible for small to medium size merchants to comply allowing them to narrowing focus on ensuring they have appropriate business process controls in place to mitigate any risk of accidental exposure.

For merchants that qualify, a self-assessment questionnaire or SAQ will be provided by the PCI SSC which will outline only 4 out of the 12 requirements that apply.  These requirements include; requirement 3: Protecting stored cardholder data, Requirement 4: Encryption of cardholder data in transmission, Requirement 9: Restrict physical access to cardholder data, and Requirement 12: Maintain information security policies. More information regarding the SAQ can be found at the PCI SSC website It should be noted, in order to qualify for the SAQ, merchants are required to select a vendor that is approved by the PCI SSC as an approved P2PE vendor.

Upon adoption of P2PE, merchants will have a significant reduction in their compliance responsibilities . Additionally,  credit card payments  become more manageable and certainly more secure. Another advantage of P2PE is that it greatly reduces the amount of manpower involved in PCI compliance. Prior to P2PE,  PCI compliance was  a cross-functional effort that required input across multiple units in an organization  including Human Resources, IT, and Business Process Owners.  With P2PE, compliance can now solely rest on the shoulders of the Business Process Owner that is accepting the payment.

Non-e-commerce organizations that are looking to take advantage of P2PE solution should work with their acquirer/merchant bank in order to select at P2PE solution that will work in their environment.  The acquirer/merchant bank is a key business partner when it comes to PCI compliance.

P2PE is a game changer for merchants as it reduces PCI scope and also increases security around cardholder data.

PCI DSS Segmentation for a Hotel POS System

320px-Hyatt_Fisherman's_WharfDan recently asked the PCI DSS Guru about PCI DSS compliance for a hotel that has a restaurant, reservations system and staff computers:

“I have a hotel with 106 computers on the LAN. I am working on a plan for segmentation of the 37 machines that regularly interact with card numbers. These 37 are comprised of restaurant POS that swipe, front desk PCs that swipe, reservations PCs that hand enter card numbers and accounting PCs that hand enter or can access card info. Now we do tokenize all card numbers.

The other 69 computers have the application installed that allow them to view guest reservations and they could potentially enter a card number though there isn’t a clear business reason why they would. If I physically separate the 37 can the 69 still be considered in scope since they have access to the application where card data is entered/tokenized? Did this make any sense?”

This is a very interesting question, Dan, and it took me a few minutes to form my opinion on this.  I was about to say that, yes, you could probably define the scope of your cardholder data environment as the 37 systems that actually process credit cards and then segment them off from the other systems.  You would then have to treat the other 69 systems as remote access systems and provide a secure connection back to the CDE on an as-needed basis.

However, the more I thought about it, the more I questioned whether a QSA would actually accept this approach.  It seems like a solution where you’re trying to engineer a loophole rather than reflect the actual business environment.  If the systems in the non-card-processing offices are running the same software as the POS systems, they should probably be treated the same way.  I am guessing that there is some sort of thick client connection taking place between those systems and the backend application and, in my opinion, this makes them an inseparable part of the cardholder data environment.

If you truly want to segment these systems, I think that you need to break away from the thick client model for them.  For example, you might be able to build a web application that involves no potential cardholder data and then expose that to the 69 staff systems through the CDE firewall (with appropriate security controls around the web application, of course).  As long as you’re continuing to run the POS application on the staff systems, it is my opinion that you should consider them part of the CDE.

I’m sorry that’s probably not the news that you wanted to hear.  I welcome other opinions.  Feel free to chime in with comments!

  • Free Newsletter

  • Search

  • Copyright © 1996-2010 PCI DSS Guru. All rights reserved.