In Part 1, the key to keeping things as simple as possible is to avoid any storage of cardholder data. Period. End of discussion.
I also covered mobile payments because more and more small merchants go to those solutions because of the cheap interchange fees on transactions. However, few small merchants truly understand the risks that these solutions present because they are offered by seemingly trustworthy providers.
So what else can you do to keep things simple?
Outsource
When consultants typically mention outsourcing, huge amounts of money typically float past people’s eyes. However, PayPal is outsourcing and its fees are not too bad. There are a number of similar services for eCommerce out there for conducting payments. There used to be concerns about abandoned shopping carts because of a separate Window pop up, but as online shoppers have gotten used to PayPal like services, that has diminished.
Your bank may also have a partnership with one or more payment vendors, so it is worth it to talk to them first to find out what options they may have to offer. If they do partner with a payment solution, a lot of times they can offer reduced fees/expenses and other incentives to use their partner(s).
The key thing to understand is that even when you invoke PayPal or similar services from your Web site, you still have a responsibility to ensure the security of your Web site. This is because your Web site is the system that directs your customer to the payment service you have chosen. If an attacker changes that redirect to “The Guru’s Payment Process”, that is not PayPal’s problem, that is your problem. This was clarified in the PCI SSC’s Information Supplement on eCommerce back in January 2013 when the Council declared that even Web sites that redirected to a payment service still were in scope, albeit a very reduced scope. The ramifications of this supplement have been discussed repeatedly with QSAs since then, but in my experience that message is still not being consistently presented to QSAs’ customers.
No Choice But To Store Cardholder Data
So you have found a solution that does exactly what your business needs, but it stores cardholder data (CHD). The first question you should ask the vendor is, “How does your solution secure the stored cardholder data?”
For vendors that use data encryption, the answer to this question should be either triple DES (3DES) 168-bit or advanced encryption standard (AES) 128-, 192- or 256-bit encryption. DES and 3DES 56- and 112-bit are no longer considered secure, so any vendor using those is not meeting the PCI encryption requirements. Anything else and you should consult with a QSA as to whether or not the encryption algorithm is acceptable.
For vendors using encryption, the next question you should ask them is, “How does your solution perform key management?” Preferably, someone other than someone in your organization manages the encryption keys such as the vendor. However, I have seen some solutions where the key management is done by the merchant through a sophisticated key generation solution in the application so that the merchant never actually knows or has access to the encryption key(s). The questions you need answered are all in requirements 3.5 and 3.6 of the PCI DSS. If the vendor cannot address these requirements, then you need to find a new solution vendor that can provide answers.
For vendors that use one-way hashing, the preferred algorithms used should be SHA-2 or SHA-3 with a salt value. MD5 and SHA-0 have known security issues that make them no longer secure. SHA-1 has a potential security issue that could cause data to also be insecure, but a lot of software vendors still use SHA-1 with a salt value. If you are going to use a solution that relies on SHA-1, the vendor should have additional controls in place to monitor access to the data and alert on any access where the data is being accessed in bulk. If not, find another vendor.
Tokenization
Do not give up hope if your preferred solution stores cardholder data (CHD). You may be able to use a processor that tokenizes the PAN. Once tokenized, the PAN is no longer considered CHD, so the solution would not being storing CHD.
Proper tokenization is a form of encryption or hashing in that the token does not have any true one-to-one relationship with the PAN it replaces. However, this is a fact you need to confirm with the transaction processor to ensure that their tokenization process is secure. If they are not representing their token as secure, you need to move on to another processor.
Tokenization can occur at the swipe/dip of the card at the point of interaction (POI) or as the byproduct of the successful completion of a transaction (the most common occurrence).
Tokens can also be generated for eWallet situations where you want to encourage customers to come back and shop at your eCommerce site and store their cardholder information for ease of subsequent transactions. In these instances, the processor generating the token also stores the CHD and then translates the token to that stored CHD when your system submits it and then sends the CHD for approval for payment.
This is how ExxonMobil Speedpass and open road toll collection systems work. The RFID device is the token and the payment system recognizes the serial number of the RFID device and translates that to the customer’s stored CHD for payment processing.
There are more than enough ideas presented in these two posts to vastly simplify any merchant’s PCI compliance exposure. If these solutions will not solve your issues, then you are either making your business too complex or your business model truly needs some expert advice to address your compliance challenges.
