Welcome to Delicate template
Header
Just another WordPress site
Header

On New PCI Point-to-Point Encryption Solution Requirements

October 10th, 2011 | Posted by Dominic Schulte in Compliance | PCI

In case you missed it, the PCI Security Standards Council (SSC) published the initial release of the much anticipated Point-to-Point Encryption Solution (P2PE) Requirements document last month.  Many of you are probably asking, “Why do I care?” – a good question in a day and age with so much information and noise.  If you’ll allow me, I’d like to answer two better questions!  But first, to answer, this document is significant because it is at the heart of the fiery topic of PCI scope.

Now, on to better question numero uno: “Can I use encryption to reduce PCI scope?”  The answer to that question has been – and still is – “no,” with one key exception.  In the PCI SSC’s FAQ entitled, “Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?” the SSC presents their reasoning for why encrypted cardholder data needs to be in scope.  The abbreviated version is that encryption only ensures confidentiality if you don’t have the keys.  If someone can gain access to the decryption keys, then they can get the cardholder data.  By keeping the encrypted data and the systems and segments on which it resides in scope, the organization is forced to implement and maintain all of the controls that protect access to those keys.

“So, what’s the exception?” you ask.  Great question!  In the FAQ, the Council states an organization may deem encrypted data out of scope “if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.”  In other words, you may treat encrypted cardholder data as out of scope if you use a managed solution from a service provider that encrypts the cardholder data before it touches your environment and the service provider maintains sole possession of the key to decrypt it.  The most basic example of this scenario is an encrypting card reader.

Prior to the release of the new requirements document, no real guidance for service providers and merchants existed on how to implement a compliant solution to this exception.  This document provides the needed guidance and makes some significant changes to the PCI program in the process, including the following:

  • The development of a new P2PE Requirements Standard (the document referenced above)
  • P2PE QSAs to validate the P2PE solutions
  • P2PE PA QSAs to evaluate applications on PCI-approved POI devices for point-to-point encryption solutions
  • A training and certifications process for P2PE QSAs and PA QSAs and their companies

The Council plans to roll out these new programs, training and certifications throughout the remainder of 2011 and 2012.

The P2PE solution requirements have the greatest impact on the service providers who have already rolled out P2PE solutions.  Merchants who are using or considering such solutions should also stay tuned.  Now that the requirements have been released, some providers may decide their P2PE solutions are not worth the annual audit compliance costs they must incur for merchant use.

Unless there are any more questions, I’ll close with that!

Dominic Schulte

Dominic Schulte

Dominic Schulte currently serves as the Managing Director of Security Services & Consulting at TRUE, where he is responsible for the execution of a wide range of security and regulatory compliance services. Previously, Dominic worked with the National Security Agency (NSA) as a Global Network Exploitation and Vulnerability Analyst in the National Security Incident and Response Center (NSIRC). He holds CISSP, QSA and CNSS 4011-4015 certifications.

More Posts

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

2 Responses

  • Interesting post. But if I follow your thoughts correctly, a payment terminal that is already “P2PE Ready”, in other words which is certified PCI PTS v3.x and has a HSM module, is already encrypting the data and the merchant does not have the keys at all.

    Would it then be correct to say that the exception is met, and that the internal network between the payment terminal used to reach the acquiring bank is out of scope even though there is no certification available as of today ? :-)

  • Anonymous says:

    Thank you, Stephane!

    As long as there aren’t any other card entry points, that is a fairly safe assumption. It is always good to work with your QSA and/or acquiring bank to confirm such assumptions, particularly if you are required to validate using a QSA.



Leave a Reply