It was announced this week that the Michaels retail stores breach was much larger than originally thought. However, to those of us in the PCI business, this breach should not have been a surprise. This sort of breach has been going on for quite a while.
Now before everyone goes out and pillories Michaels for their bad luck, I would like all of you to consider how you would have detected such a situation? The bottom line is that for most of you, you would have been just as clueless until the FBI and Secret Service turned up at your doors. So be careful about getting too sanctimonious. More on how to detect these attacks later.
Regardless of what the PCI SSC has said in the past, credit card terminals are not the “dumb” devices as portrayed by the PCI SSC. With the introduction of the PA-DSS v2.0, there was an indication that the PCI SSC had finally come to their senses and recognized this fact by having the software that is used in credit card terminals finally certified under the PA-DSS standard. Let us face it, certain credit card terminals are just as sophisticated as netbooks, use a Linux or Windows Embedded OS as a base and have their own software development kits (SDK). Not exactly the specification for a “dumb” device.
Another point that should not have been a shock is the fact that the terminal was used as the attack vector. Those people advocating end-to-end encryption fail to remind people that wherever the endpoints are will become the new attack points. As a result, the Michaels attacks will become a very popular attack vector once end-to-end is implemented.
Wait a minute, the terminal will become more popular for attacks? After all of last year’s belly who about end-to-end encryption, I can tell you that merchants are under the impression that end-to-end encryption gets them out of being breached. It is people like Bob Carr, CEO of Heartland Payment Systems, that are the biggest neglectors of explaining the whole story behind end-to-end encryption. End-to-end encryption just moves the attack points, in this case out to the terminal at the merchant’s location. Worse yet, it also makes security of the merchant’s endpoint even more difficult than it already is because the techniques used in doctoring terminals can easily go unnoticed.
Early attacks on terminals were crude and, for the most part, remain this way. Typically, USB thumb drives are soldered into the terminals. This attack approach requires the criminals to swap out the doctored devices periodically to obtain their contraband. Fortunately the “electricians” used to doctor these terminals are usually not good at their tasks. As a result, only a few of the doctored terminals actually work and collect usable track data. To get their doctored terminals into retail locations, the criminals hire on as night custodians or other overnight stock help and swap the devices during that time.
But times change. The criminal element gets smarter and begins doctoring terminals using software, not hardware. After all, these devices are just small computers. So now the device is programmed to collect the data and then transmit it during the overnight to a server on the Internet or, worse yet, a server that has been compromised on your own network.
So what can a merchant do to counteract such attacks? Actually, quite a bit.
- Put serialized security tape on all of the seam openings on your card terminals and check it at least daily to ensure that it is still in place and that the serial numbers match. When the tape becomes worn, replace it and record the new serial numbers. If you ever notice the tape missing or the serial numbers do not match, take that terminal out of service. Contact your acquiring bank or processor and obtain a terminal directly from them to replace the potentially tampered with unit.
- Use only reliable card terminal vendors. I know that merchants are under tremendous cost pressures, but are these savings really in your best interest when you are leaking cardholder data on every transaction? Probably not, particularly when customers start complaining and your legal costs start ramping up. However, even trusted vendors can become a bad source of equipment, so keep this in mind.
- Do not trust anyone that just shows up to replace your card terminals. If you did not ask for service, no acquiring bank or processor is going to be proactive replace terminals unless they notified you. Be very skeptical of any service person that appears out of nowhere to “fix” your terminals.
- If your terminals are on your network, monitor your terminals for when they are disconnected. In most organizations, terminals are rarely disconnected, so any such alert would be an indication that something abnormal has occurred and should be investigated.
- Monitor your external network connections and connections from the terminals to devices that should not be in your cardholder data environment (CDE). Any traffic from the terminals outside your network or to devices not in your CDE is probably someone leaking cardholder data from your terminals for their criminal use. If you see such activity, notify your local FBI office immediately and ask them if you should stop the traffic. At this point, you should also probably get a computer forensic analyst involved to begin gathering documentation on the attack.
These are just some ideas on how to address this situation. You may have additional options available to you because of the way your organization is configured. However, you need to begin considering this new attack vector as one that will only get worse.
PCI Guru 
End to end encryption still hugely reduces the surface area of an attack to a point where there is a) more potential physical management in the merchant to counter skimming and deception b) less data to siphon over the course of the data’s life cycle. In addition, this post doesn’t acknowledge the huge changes between devices in retail reaching their end of life which are more likely to be tampered with (eg pre PCI PTS 1.0 devices) and more contemporary PCI PTS 3.0, SRED etc requirements.
In any scheme – no matter what – where data in the clear needs to be presented to an interface for translation to a secure protocol or system, there is risk of exposure or manipulation at that interface. The question is how big is the risk and what is the cost benefit for the attacker ? In the Michael’s case, how many cards are at risk now – in the thousands. Contrast that to prior attacks at a processor or network layer – tens of thousands to million of cards at risk. Quite a big difference and different attack costs and risks.
The PCI SSC has created anti-skimming guidance, and most contemporary devices have more intense tamper detection methods and active defenses (destruction of keys for example in an SCD boundary inside the payment device) to help maximize the cost barrier to a successful attack, and to potentially render intercepted devices impossible to use – and thus detectable.
It will always be possible – at a given cost and risk profile – to replace a physical device with something that skims irrespective of scheme – imposters, fake devices and all manner of elaborate scams are the way of the sophisticated criminal past and future if the investment is sufficient for the return. The challenge is to make is so expensive and unattractive with the risk of being caught much higher as a defensive strategy until in the much longer term the payment schemes themselves evolve to more dynamic and scam resistant methods.
In the meantime end to end encryption – especially that implemented in a secure tamper detection enabled device which is outside the scope of the OS and logical compromise – will be a very effective way to reduce the risk of compromise in no uncertain terms.
Is there an alternative ? No.
Disclaimer: I work for an encryption company – but what I describe above isn’t specific to a vendor.
I agree with your comments. The problem I see is that E2EE proponents do not discuss the fact that there is still a risk. Ask any merchant about E2EE and they think they are totally off the hook and that just is not true. There is still a risk that needs to be mitigated by procedures to ensure that their end of the chain is secure and remains secure. However, given the propensity of attackers to find new ways to get at the data, I am sure that we will be shown even more ingenious ways to take E2EE down and we’ll start all over again on a new scheme to secure our data.
Here it is. Our area had a large number of fraudulent card transactions in the past few months. They initially were pinned on a local restaurant, but there seemed to be too many. It did not pass a smell test. At a local group we have where people from different organizations meet to discuss fraud they’re seeing, the law enforcement rep said the focus has moved from the restaurant itself to their point-of-sale software. Yes, you read that correctly. They believe the PoS software may have been tampered with at the vendor before it was shipped to their customers. (No, they would not release the name of the software.)
It’s similar to the process of infecting thousands of websites with malicious code. You either do it one web server at a time or you infect the common point, their banner ad provider. You want to grab a ton of numbers? Compromise the PoS software before it’s shipped.
PA-DSS? They’re not storing anything they shouldn’t. File Integrity Monitoring? No problem. We install the new software, baseline it as OK and it’s still malicious. Ant-virus? Useless for custom software. End-to-end encryption? Bzzzt, wrong answer. Next contestant, please.
If this turns out to be accurate, the focus will move to how the software companies protect their source code. Do they off-shore or outsource any of their work? Do they use independent contractors working out of their homes? Lowest cost wins again.
This whole process is like squeezing a balloon. As soon as we squeeze off an attack vector one place, it blows up in another. TSA puts in body scanners that won’t penetrate the skin, so the terrorists think about putting explosives in bodies surgically. Poof. More millions of dollars in ineffective, reactive controls gone up in smoke.
There is a move afoot to address this potential problem. However, the method to be used will drive the cost of software significantly upward. The process involves using two different development teams given the same requirements and then test each solution to see if they both work the same. This is the process certain “three letter agencies” in the US government use to develop their software.
PA-DSS was developed to ensure that software was developed to secure cardholder data, not to ensure that the software didn’t send it to Timbuktu at the same time it was sending it to the processor. This is the same for all of the PCI standards or any standards. There is an assumption will all standards that individuals of good character will obey the accepted norms of society and do their jobs. Unfortunately, there are individuals that do not want to follow the rules and it is those that we need to weed out of software development and other sensitive positions, if we can.
The terminal should be secure. The whole point of buying a terminal from a reputable supplier is that the terminal is practically immune to tampering. Skimming card data is hard to fight, but PIN compromise within the terminal, if that happened, is unforgivable. Maybe Michaels did not have PCI compliant terminals like they should, in which case unfortunately liability lies with them. If the terminals were PCI compliant, there is almost certainly a liability question for the terminal vendor. Also, if the terminal is at fault then Michaels is likely only the tip of the iceberg if the same terminal is being used elsewhere with other retailers, and therefore with the same vulnerability
I have not heard that there were any PINs compromised and, really, who would need the PIN? Once you have the track data from either a credit/debit card, they can all be cloned and used as a credit card.
Is this a natural consequence of the switch to self-checkout lines to save paying minimum wage to teenagers? The criminals observe that the discount stores have less staffing to reduce costs and that leaves the payment terminals without the physical protection of a cash register operator?
I do wonder just how they pick the stores, though. Only one in my state was reported as compromised despite there being many stores within twenty miles of each other. Or is the compromise happening at the repair centers and it’s just the luck of the draw?
In the Michaels case, the terminals may have been doctored at a central point such as a repair facility or central supplier which is why you see the broad distribution. In a number of other cases I am aware, the terminals were located in a cluster around the criminal gang that was doctoring the terminals. And it is not like the terminals are not locked down and secured with video. However, when you have everything keyed the same and the switching is done by someone working the overnight crew, it really does not matter.