Target breach highlights the importance of PCI DSS compliance

While the US retail industry is reeling from what has been declared by some as the ‘worst breach in history’, the payment breach at retail giant Target has put a very real perspective on the importance of PCI DSS compliance within large organisations.

Up to 70 million customers had payment card and personal data stolen from the company's databases in December 2013 (30 million more than first thought). Target reported that hackers took credit card numbers, names, postal addresses, phone numbers and email addresses, implying that Target stored credit card details against PCI regulations. 

With increased scrutiny expected by the payment card brands on POS and payment application security as a result of more stringent standards written into PCI DSS 3.0 and PA DSS 3.0, Target's breach serves as further reminder for why POS systems need to be on US retailers' immediate radar. The US still uses a signature and a magnetic strip to secure transactions rather than an encrypted chip. The introduction of the EMV standard Chip and PIN has radically reduced fraud in many of the countries that have adopted it.

It seems evident that for a hacker to infiltrate Target's network and access the POS application, several PCI DSS and PA-DSS controls were ineffectively implemented. But several Target insiders, who commend Target’s security practices, suggest that it goes further than the POS systems and that some interception must have happened elsewhere in the processing chain. Owing to the sheer scale of the attack during the busiest holiday period, they believe that multiple insiders may have been involved.

Regardless of the intricacies of the Target breach cause, the ultimate lesson is that organisations need to pay greater attention, not only to the POS-related changes put forward by the PCI Security Standards Council, but all areas of security that involves data storage and its access controls.

The overarching theme from the PCI SSC Version 3.0 of PCI DSS is to take a proactive stance when implementing security controls to guard these systems. This will cause merchants to decide that they need to readdress security for their transaction points (POS, online, and contact centres), plus their network, data storage and human access. In the time being, Target is unlikely to be the last breach we see this year.

What’s in a number? Tokenization

Recently, Visa Europe launched its Private BIN (Bank Identification Numbers) range for organisations that want to create internal identifiers. These have the same format as Visa Primary Account Numbers (PANs) but will never be used in the ‘real world’. There are two main reasons to do this:

1. For test purposes – to test a payment system for instance
2. To create tokens which can be used in place of a PAN within internal systems
3. Companies can therefore use these two 6-digit numbers internally, knowing that Visa will never issue them to real entities. The numbers are:

• 468738
• 468739

These 6-digit numbers are important. They represent something quite special in the world of PCI DSS, tokens, and PCI audit de-scoping. It means that when service providers issue tokens (like Eckoh’s OneProx system) we can be confident that by starting the tokens with 468738 or 468739, our clients will know the difference between a payment card number and a token. Even when tokens are Luhn-compliant, they can still be detected as tokens, and not be mistaken for real PANs.

So why is this such a big deal?

Like many applications which use tokens, both OneProx and our CallGuard DataShield software have always been able to issue Luhn-compliant tokens which plug straight into our clients’ existing websites, CRM systems, payment gateways and applications. Luhn-compliant tokens are great, because they can be used in exactly the same systems or processes as card data without requiring any changes to them. And after all, Luhn-compliant tokens will pass any existing client-side Luhn checking functions. However, it’s always been very difficult (or impossible) to determine whether a given number residing in a database field is a token, or a real PAN. So how does a merchant know whether all the card data has truly been flushed out after implementing a token system?

By starting a token with a Visa Private BIN number, Luhn-compliant tokens are easily differentiable from card data. And yet these tokens are NOT cardholder data, so merchants’ systems can be removed from PCI DSS scope.

The Visa Private BIN range also has another important benefit for companies already using data discovery tools. Once the cardholder data discovery companies (such as Ground Labs and Foregenix) ‘lock’ these two magic numbers into their detection systems, companies will be able to run tokens and ‘actual’ cardholder data on the same databases, networks etc. and easily be able to determine which is which. This is great for companies transitioning from ‘live’ cardholder data to tokens over a period of time (not instantly). Of course, there are two important caveats here:

1. Token providers will need to start their tokens with 468738 or 468739. This isn’t always possible, particularly if ‘first 6’ formatting is being preserved.
2. Merchants will need to make sure that the Private BINs are not submitted for processing. (They aren’t the beginning of real card numbers, so they won’t work!)

However, at least the payments industry now has one sensible way of detecting token needles in a haystack of PANs.