Archive for April, 2014

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.