The most interesting type of data for cybercriminals is undoubtedly credit card data.
For precisely that reason, a dedicated standard exists – PCI-DSS – created and observed by the payment card industry. The PCI DSS standard is pretty thorough and aims at increasing the security of systems that work with credit card data (or, as it is named in the standard – cardholder data).
Security Measures Companies Take To Protect Cardholder Data
Let’s first discuss the measure that most companies utilize in order to protect their cardholder data – tokenization. Tokenization is replacing the cardholder data with a meaningless token in order to allow storing it in less secure environments. It might be an unpopular opinion, but tokenization is not a security measure, it’s a compliance measure that simply lets you have only part of your databases PCI-DSS certified. It does reduce the attack surface and therefore the compliance surface. There’s also the so-called “stateless tokenization” which allegedly doesn’t store the mapping between the token and the credit card number and instead transforms it on the fly. Unfortunately, that’s in many cases either just marketing or format-preserving encryption, which is weaker than general-purpose encryption.
Tokenization is great for e-commerce, as any website can use a payment provider without working with cardholder data itself, but this is just shifting the security measures to a more protected environment. However, within that environment, data breaches are still possible, especially if PCI-DSS audits are done “on paper”.
Cardholder Security Breaches That Are Often Neglected
Other ways that credit card data can leak circumvent the need to breach the secure cardholder environment and try to get the data before it is sent there. So let’s see a couple of ways that cardholder data can leak:
- Insiders – privileged insiders with access to the token-to-cardholder data database are well-positioned to exfiltrate the data. Numerous measures exist in PCI-DSS to prevent that, including logging, but in reality, a knowledgeable insider can tamper with the logs and cover their tracks and/or block the connection for the log collector. It’s not always possible, of course, but some breaches happen exactly due to privileged insiders.
- Server malware – server malware can do what the privileged insider can. It “only” has to get there. That’s hard, but through a combination of unpatched vulnerabilities, stolen credentials, and a lack of sufficient monitoring, sophisticated malware can get in. That’s rarely employed in reality, but it’s worth mentioning
- Cardholder data in logs – occasionally some developer makes a mistake that gets past review and thousands of credit card numbers end up in logs files. Log files are much less protected than the cardholder database, so attackers can look and sometimes find credit cards in logs files.
- Formjacking – if they can’t get in a secure environment, criminals try to collect credit card data before it enters there. The so-called “magic art” attacks use script injection (via compromised static resources) to collect the data as the user is typing it.
- Phishing – why to bother even attacking a legitimate website when you can impersonate it, send a few hundred thousand emails, and collect cardholder data. This is typical with online banking related phishing – attackers send phishing emails, claiming that the user has to update their online banking profile. However, instead (or in addition) to their credentials, users are asked for their credit card details. And unfortunately, that works.
- Client-side malware – attackers can scrape credit card info not only by compromising website static resources – they can scrape it by using keyloggers. As with phishing, this is entirely a user issue – companies can do very little to prevent that from happening
All of these would be a much smaller issue if 3D secure passwords were widespread. They are effectively a method of 2-factor authentication which adds “something you know” or even “something you have” to the mix, which makes knowing the credit card number and CVV/CVC useless on their own. But the usability aspect of the 3D password is one of the reasons for lower adoption.
What’s The Ultimate Way To Prevent Cardholder Data?
There is no single way to prevent cardholder data breaches. It would certainly help if the data was per-record encrypted, like we do in SentinelDB, in addition to being tokenized, so that even if a malicious actor (insider or outsider, manually or through malware) got access to the database, or to a backup lying somewhere unprotected, the data would be useless. And malicious insiders may be less tempted to dump the data if they could not cover their tracks by tampering with logs. But those measures alone do not protect you from formjacking or phishing your customers. Breach protection requires a holistic view and the appropriate tools at each stage.