Author Archive

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.


Reversing Credit Card Tokenization

Tym recently asked the PCI DSS guru:

“If I have tokenized some credit cards with my current gateway provider and I now want to move to new gateway provider. How can I get the credit card data from current gateway provider and give it to the new gateway provider, making sure the chosen way is PCI compliant?”

As you’re probably aware, Tym, tokenization is the process of replacing credit card numbers with a non-sensitive unique identifier.  This process, performed by your payment gateway, provides you with a value (or token) that you can store without running afoul of PCI DSS requirements.  For more information on tokenization, read What is Tokenization?

In your case, you’re looking to reverse the tokenization process and obtain the real credit card numbers.  You’ve already realized that you can’t do this on your own, as there is no way to compute the card number from the token that the gateway provided you.  Before you go about trying to obtain that information from your gateway, I’d ask you to consider whether you really need the actual card numbers for past transactions?  If you’re attempting to migrate recurring credit card transactions, this may be the case.  If you’re only worried about managing those transactions, perhaps your current gateway would be willing to continue to process refunds on your behalf after you migrate new transactions to another provider?

If you do need to obtain the actual card numbers and the gateway is both willing and able to provide them to you, you will need a secure means to transmit them.  This actually is not very complicated, as you aren’t trying to design a permanent, recurring process. You just need to complete a one-time transfer of sensitive cardholder information.  The easiest way to do this is by asking the gateway to store them in a file and then use strong encryption to protect that file.  For example, you might use WinZip to create an AES-encrypted file.

You’ll need to use a strong password to encrypt the file and then exchange that password in an out-of-band fashion.  This is as simple as authenticating yourself to the gateway’s technical team over the telephone and then agreeing on the document password over the phone.  Since the file is encrypted, they may then simply email it to you without worrying about the document’s security.  Once you receive it, you may decrypt it using the agreed-upon password.

Remember that the credit card numbers you receive are subject to all of the protection requirements of PCI DSS.  You’ll need to make sure that they are appropriately encrypted and that you have proper management over the encryption keys for as long as you retain the card numbers.  My advice would be to use them quickly for the conversion and then destroy any copies as soon as you are done.


  • Free Newsletter

  • Search

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