Take a look at the recently published OWASP “Top 10 for 2010” list of web application security flaws and you’ll realize that software IS the security problem. There truly is no such thing as “safe software” when it comes to approaching the security of payment card data. Real protection from software vulnerabilities and malware threats requires security controls embedded in hardware — e.g. physical and logical security.
I’m a proponent of strong encryption as the best method for protecting payment card data — but you have to employ physical protections and tamper-resistant security modules (TRSMs) to protect the plain text data and cryptographic keys. Simply put, you must encrypt in software and hardware.
TRSMs were introduced with encrypting pin pads to encrypt debit PIN numbers for secure processing and transmission more than 25 years ago, and this proven technology continues to develop as an important layer against physical attacks that breach plaintext data and cryptographic keys. TRSMs serve as a highly-effective tool to diminish exposure and protect the data where and when it’s entered—at the point of swipe.
Different methods and approaches for securing payments at point of sale (POS) are being talked about in the industry right now. There are companies touting that encryption in software only is enough protection for our sensitive data … that software-based encryption is “safe” … that this level of encryption is “better than nothing.”
It is true that software encryption is better than no encryption. However, software always leaves valuable payment card data in the clear somewhere during the lifecycle of the transaction. For example, how are you protecting the data from interception before it’s encrypted? How are you protecting the encryption keys from being accessed by unauthorized actors?
That brings us to a comparison of encryption with tokenization. Tokenization creates a substitute for the real data. I believe in tokenization as a complement to encryption in the payments processing life-cycle—not as a single solution.
Tokenization takes place in the tokenization engine, which is typically located in the computer system of a gateway service provider or the payments processor. How does the card number get to the tokenization engine? If there is no encrypting TRSM to protect the payment card data, the data is transmitted in the clear and susceptible to CPU sniffers, memory sniffers and other types of malware.
The takeaway for IT security professionals — and anyone in the business of payments — is don’t just assume software is enough. A layered approach to security with multiple defenses is required. To send valuable credit card data and consumer information in the clear at any point of the transaction life-cycle is an unacceptable risk. You might be protecting a portion of the transaction, but you are still leaving holes and weak links for the bad guys to get in at some point.
Consider evaluating POS hardware that has encryption and TRSMs inside— certified by the PCI Security Standards Council—that will provide physical protection and can be purchased at a comparable price to non-encrypting POS devices. If anyone attempts to compromise the TRSM inside the POS terminal, the encryption keys are deleted immediately, making the terminal inoperable.
As we work to safeguard the payments ecosystem and protect cardholder data, we must consider new approaches to improve the current system and “status quo,” and take the necessary steps to stop transmitting any card data in the clear. Unless you protect the valuable and sensitive card data in both software and hardware, you are leaving it vulnerable for ongoing attacks.
Steven M. Elefant is the chief information officer at Heartland Payment Systems® (NYSE: HPY), one of the nation’s largest payments processors. Heartland is a leading provider of credit/debit/prepaid card processing, gift marketing and loyalty programs, payroll, check management and related payments solutions to more than 250,000 business locations nationwide. For more information, visit HeartlandPaymentSystems.com and E3secure.com.