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.
PCI Guru 
Should we expect to see 3DES fall off of the supported list by vendors and be a non-compliant encryption setting any time soon? I was curious if P2PE might eliminate the use of 3DES in one of the upcoming PCI updates?
Now that Cloud providers are providing the capability of cracking “weak” encryption, NIST is again sounding the warning that it is not a question of “IF” but a question of “WHEN” 168-bit 3DES is broken. 56-bit and 112-bit have been broken for years, but 168-bit hung in there because of the limitations of gathering the necessary computing power to crack it. But with the Cloud, it has become cheap to put together that computing power to break even the 168-bit form of 3DES. Whether or not anyone is working on breaking 168-bit 3DES is open for discussion, but I have to believe if some researcher is not attempting to break it, there is at least one attacker that is making an attempt.
A brute-force break on 2 key TDES has _never_ been demonstrated. It has academically been broken for some time, but then technically so is three key TDES and AES 256. You have to understand the difference between an academic break – an academic break simply means that the best attack to recover the key is less than the expected work effort based on the bit size of the key.
All of which is to say that I don’t expect any cloud service to break two key TDES any time soon, let alone three key TDES. Worry about your key management and modes of operation, worry about your implementation and vulnerability to side channel, code lifting, and general key extraction attacks. Don’t worry about TDES being demonstrably broken.
I did a 10 minute presentation to an audience of small business owners last week about PCI DSS, I asked the question how many of them had heard of PCI DSS, only 1 hand went up out of 45 attendees.
Surprising as you would think the word has truly gotten out. Thanks for sharing this insight.
Your time and efforts are very much appreciated!
In reference to a statement in the Outsource paragraph above regarding web redirects and securing a website, you noted “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.”
I was in a discussion with a QSA regarding web redirect servers and authentication servers recently– This QSA was representing a third party vendor we had contracted with a few years ago– this QSA made the statement “that it’s all based on interpretation and my institution couldn’t expect third party vendors to change their processes because of one line in the standard (referring to the PCI Scope paragraph on page 10 below)”.
It’s frustrating when QSA’s disagree and I would look to the PCI SSC for further training and clarification on “Interpretation” and “it depends on your appetite for risk”. I am thankful we have contracted with a QSA firm that is on the conservative side and does not “interpret” the standards based on appetite for risk, but rather on the standards and reporting instructions. It’s been a difficult process educating our Service Providers to our level of due diligence, and we have changed vendors in some instances.
Thank you for your posts! I always learn something!
Best,
Page 10, PCI DSS:
“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.
Examples of system components include but are not limited to the following:
Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE”.
Just as a client’s personnel cannot agree on what level of risk to accept, every QSA Company (QSAC) and even QSAs within a given QSAC have differing levels of risk acceptance which is where the problem lies. That is human nature in action and I’m not sure how the Council or anyone else is going to take that out of the process.
Right now we are working on scoping using the Open PCI Scoping Toolkit as a framework. I can tell you that there have been some interesting and, at times, heated discussions about the risks presented by allowing certain systems to access others. Our discussions are heated because each of us has differing risk tolerance levels. It is likely going to take us a while to work through this and come up with something workable. However, this is why the Scoping SIG collapsed a number of years ago.
That said, QSAs need to do a better job explaining WHY they are recommending certain scope, solutions, etc. based on a discussion of risk. That is how I present issues to my clients. So I might provide three different solutions – one requiring a high tolerance of risk, and two with varying moderate levels of risk and then let the client decide what they are willing to accept. All will be PCI compliant, but some may have additional controls to be implemented and monitored above and beyond the basic controls required to be compliant.
This is the problem any organization faces with security and privacy discussions. Everyone has their own opinion of risk and how much risk they are willing to accept. Until everyone can come close on that discussion, then you will continue to see what you see.
Thanks! We also utilize the Open PCI Scoping Toolkit as a framework– and yes we’ve had heated discussions as well. Thanks again.
Ahhh, web redirection scoping. At first scoping was fuzzy and left to be interpreted by the QSA for Level 1 Merchants. Then the “clarifying” scoping statements came out for SAQ users, giving non-Level 1 Merchants “a way out” by utilizing a fully outsource hosted payment page. (even though you and I know this does nothing for the protection of the actual redirecting server). 🙂
Long story short, QSAs are now reluctant to confirm scoping guidance around web redirection servers for Level 1 Merchants, hoping they can offer their clients a way out IF the above mentioned “clarifying” statements, can and ever will apply to Level 1 Merchants.
The SSC has been aggravatingly very quiet around this since releasing their SAQ guidance back in March. (probably because they know it doesn’t do anything to protect the underlying issue).
Unfortunately looks like I’m going to have to wait for the PCI Community Meeting in Sept, to corner the Council in providing clarity for Level 1 Merchants. At this point, I don’t care what the SSC says about web redirection servers, I know what the point of protecting the redirecting servers is for and understand as such. The problem is, our budget people won’t provide funds for a build out because we have no official requirements to do so.
I’ve read what the Guru has said on this, however we don’t have the Guru as a QSA. So, kinda stuck here.
This topic was actually discussed at last year’s Community Meeting in the QSA session before the public meetings. The Council chastised the QSAs for not doing more regarding the eCommerce information supplement and redirects. However, as a number of us pointed out to the Council, QSAs are loath to go out on a limb without discussion and clear guidance from the Council which was why a lot of us dragged our heels in doing something. As a result, we went back and developed a position paper on the topic and share that with clients and prospective clients to explain this topic.
Thank you for the information! So, just how much does encryption limit scope? Our CISO believes that the 3DES encryption method our machines are using is not secure enough. We are upgrading our remote locations with firewalls and VPNs directed to a PCI environment. Obviously, it is a secure method, but do you think that is necessary seeings how our swipe machines encrypt the data and we do not have access to the keys?
See my post on encryption and scope – https://pciguru.wordpress.com/2013/03/07/encrypted-cardholder-data-out-of-scope/
As to your CISO being concerned about 3DES, that is a valid concern. 3DES 168-bit is the only form left that has not been broken and NIST keeps warning that it is just a matter of time before that form is also cracked. Granted they have been warning about this for around the last 10+ years. But with the computing capabilities of the cloud, it’s possible that their warnings should be heeded.
As a result, a lot of vendors of terminals and secure transaction communications are heading to the advanced encryption standard (AES) for their encryption solutions.
Triple DES is fine for payments. Every PIN you have ever entered into any device has been encrypted with TDES, using a 112 bit key. If you have 2^40 plaintext/ciphertext pairs, you can reduce the operations required to break this down to 2^40, but this has never been practically demonstrated _anywhere_ and is impractical for payment messaging anyway. I would be much more concerned about your PKI implementation, key and certificate management, and advances in factorisation that are making RSA less and less secure. Until the new version of ISO9564 is ratified, we _cannot_ use AES for PINs, and doing so will require changes to messaging formats like ISO8583 anyway.
Thank you for the clarification.
I was thinking of 3DES when used to encrypt telecommunications, not PIN blocks.
Still OK for messaging in payments, not just PINs. Much more likely that problems will be found in your PKI or key management than TDES is broken.
Oh ye of little faith. LOL!
A PKI implementation messed up? Highly likely.
Great part 2. Thanks for taking the time to write this informative articles.
As an ex-Security Manager in a previous career I understand all of this. Now as a small independent retailer with some web sales, it is all TOO MUCH! sorry to shout 🙂
75% of business in the UK is small business. We just want a solution provided to us along with the card processing package. We don’t want to be that solution!
The card payment part of running a business is just one tiny part of our very busy lives, for the PCI people it is a daily job, they don’t seem to understand retailers are not that excited about being bossed around, blamed, responsible, a risk etc. We just want to take cards in the same way our customers use cards. If its all so difficult its a pity the card companies don’t own up to the public and give up.
I love this site and do take it seriously – honest! But I suspect my thoughts above are how most small businesses really feel. Just waiting for someone clever to come along and offer an alternative.
PCI is unfortunately required because, unlike you, merchants large and small, were NOT diligent in ensuring that payments were performed securely.
If you use a terminal such as Verifone or Ingenico either through a phone line or 3G/4G cellular, you should be fine and PCI compliance should not be a problem. Same with outsourcing eCommerce to Amazon, eBay or similar merchant sites can significantly reduce scope and improve security if implemented properly.
I agree that the current card paradigm is broken and we need to come up with a new one. However, Visa and MasterCard need to recoup their investment in EMV and so until that happens, we will stay the course.