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 https://www.pcisecuritystandards.org/documents. 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.

Sample PCI DSS Policy Updated

We’ve recently updated our sample PCI DSS policy to reflect the changes in PCI DSS version 3.2.  You may view the sections of the sample policy at:

If you’d like to get a free license to use this policy in your organization as well as a downloadable copy in Word format, simply subscribe to our free newsletter.

Do I Have to Remediate PCI DSS Vulnerabilities?

In a recent question to the PCI DSS Guru, David asked:

“In PCI DSS Vulnerability Scanningyou mention in the audit section that all high vulnerabilities must be addressed. Is this the external scan only, or do all internal scan highs also need to be addressed. We have many layers including a WAF to protect from the outside.”

The bottom line, David, is that yes, you must remediate all high vulnerabilities identified in the internal scan.  For verification of this, see the audit procedure that a QSA will follow when determining whether you comply with PCI DSS requirement 11.2.1.b.  It reads:

Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved. 

This is written in a very clear-cut manner.  You must remediate those vulnerabilities in order to meet the letter and intent of the requirement.  If you have difficulty meeting this requirement, you may consider applying for a compensating control, but this is subject to the review and approval of your assessor.  To be an acceptable compensating control, the measure(s) you put in place must satisfy three tests:

1. They must meet the intent and rigor of the requirement that you are compensating for.

2. They must mitigate the same risk.

3. They must be “above and beyond” other PCI DSS requirements.

If you are using a web application firewall to satisfy PCI DSS requirement 6.6, attempting to use the WAF as a compensating control for vulnerability remediation would most likely fail the third test.

Amazon Web Services and PCI DSS Firewall Compliance

In a recent question to the PCI DSS Guru, Chris asked:

“I am building an e-commerce application that must be PCI DSS compliant.  Our company has chosen to use Amazon Web Services (AWS) for our hosting.  Does using security groups in AWS meet the stateful inspection requirements of PCI DSS?”

That’s a great question, Chris.  As you probably already know, Amazon Web Services is a validated PCI DSS service provider.  Of course, this does not mean that you are automatically PCI DSS compliant because you are using AWS.  It does mean, however, that you may use AWS as one of the building blocks of your PCI DSS compliance program.  You are able to rely upon those AWS services that are part of the certification scope as components of your infrastructure.  These include, for example, EC2, S3, Glacier, RDS and VPC, some of the major services you are likely to use.  For a full list, read the AWS PCI DSS FAQ.  (BTW, if you understood all of those TLAs strung together, you qualify for a master’s degree in acronyms!)

Your specific question revolved around the firewall requirements of PCI DSS and, in particular, the provisions of PCI DSS requirement 1.3.6, which states that you must

“Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)”

If you are using security groups and VPCs, the good news is that, yes, AWS security groups do perform stateful inspection and, when properly configured to meet your business and security requirements, can be used to fulfill requirement 1.3.6.  For background on this, see the Amazon VPC Documentation, which contains a list of the basic characteristics of VPC security groups.  One of those reads:

“Responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa (security groups are therefore stateful).”

So it looks like you’re covered for this requirement.

I do strongly suggest that you obtain more information from Amazon about their PCI DSS compliance status.  Amazon has a PCI DSS Compliance Package available that was prepared by their Qualified Security Assessor (QSA) and contains all of the details you need to know to implement your PCI DSS activities within AWS in a compliant manner.  The package is not available on the web, but may be obtained directly from an AWS sales representative.

SSL Encryption Key Management and PCI DSS

Frank recently asked the PCI DSS guru the following question:

“I have a large number of Linux servers that are in scope for PCI in my environment. One example would be a SSL Web server that receives inbound messages. Another one would be an application server that may need to decrypt PGP-encrypted files. The SSL certificate and the PGP key both have strong passwords (an 18 character combination of alphanumeric  characters and symbols) .

Per PCI requirements, I have to protect these passwords and not stored them in plaintext.

These servers are periodically restarted during regular patching maintenance. And during restart, the applications need to be able to obtain the unencrypted  password without manual intervention. Therefore these passwords must be stored on disk where they are accessible by the Linux servers.

What is the best practice to protecting these passwords while they are stored on disk?”

Frank, you’ve stumbled upon one of the most difficult aspects of PCI DSS: managing your encryption keys.  You are absolutely correct that you cannot store your encryption keys in plaintext on your web server, as this would violate PCI DSS requirement 3.5.2, which gives you three options for protecting private keys:

  • Encrypt them with a key-encrypting key that is at least as strong as the data-encrypting key and stored in a separate location
  • Store them within a secure cryptographic device
  • Store them in two pieces

Things can get really complicated, really quickly.  In my opinion, it’s best to turn to commercial technology for this purpose.  Don’t try to roll your own key management solution.  Instead, look at some of the products currently available on the market, such as RSA Key Manager, StrongAuth, and Alliance Key Management.

  • Free Newsletter

  • Search

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