There are two opposite views on the best way to protect sensitive retail data from cyber thieves, including payment card, CRM, inventory, pricing and payroll data.
There are two opposite views on the best way to protect sensitive retail data, including payment card, CRM, inventory, pricing and payroll data. The first is the vault approach, where you try and throw as many high-quality firewalls locks as you can and then place all of your goodies in that protected space. The second approach is minimisation, where you store the data in as many different secure places as you can, so that if anyone breaks in, they can only access a tiny portion of your data from that single attack.
Retailers very much want to believe in the first approach—and to find legitimacy in the vendor hype pushing it—because it’s so much easier and cheaper. But the only sound security approach has always been: assume the bad guys will break in and then make all of your decisions from that assumption. I mention this because recent mobile payment efforts—and especially the latest strategy outlined by Google Wallet—seem to be dangerously embracing the vault strategy.
Even worse, it’s embracing a vault integrated with cloud strategy, which seems to be the tech equivalent of waving a red cape at the cyberthief bulls, daring them to charge for your customers’ PII (personally identifiable information).
The Google approach is to place very high-end security on its secure element within the shopper’s phone and to then save other data to secure Google servers through the cloud. First off, from what we can see of the secure element, it’s security is very well thought-through and that secure element is indeed probably the best choice to save such data. But that’s not the point.
Throughout the history of technology, every security approach has been defeated by highly-motivated thieves. These global hoodlums tend to have the best equipment, plenty of people and the luxury of time. Social engineering—exploiting the weak security link that is your call center and store personnel, who can be tricked into saying a lot more than you think—on top of that equipment, people and money makes it easy for them to ultimately break through, especially when many cyberthieves are getting quite experienced at this sort of thing.
Lesson One: Never assume that your top security can’t be beaten. It’s foolhardy at best and reckless at worst.
The real problem is that the wallet approach—not just with Google Wallet, but with PayPal, ISIS and the many other mobile wallet contenders—creates a hole that could allow thieves to take advantage of the way fraud alerts are handled in retail today.
Visa, MasterCard and AmericanExpress have gotten impressively good at fraud detection, correctly identifying purchasing pattern deviations that flag possible fraud. And then, depending on what the software is seeing, either cancel the account and contact the cardholder or call the cardholder first and find out if it’s really fraud or not. But either way, a confirmed fraud instance cancels that card and theoretically halts further fraud.
The Google Wallet doesn’t transmit a card number to the terminal, it transmits a Wallet ID number of the identical number of digits. Instead of representing just one card, that number represents every card in that customer’s wallet. If a cyberthief is able to replicate a Google Wallet and then steals that single Wallet ID, the fraudster can then place charges on any card he or she chooses.
Here’s where the detection hole kicks in. Once those fraudulent patterns are detected and fraud is confirmed, the card used is shut down. But courtesy of the Wallet ID, the thief can move to the next card and then the next card, dramatically increasing the thief’s potential profit.
The hole, then, is that today’s fraud system is designed to protect a card, not a wallet. None of this will be a problem if that Wallet ID is sufficiently protected in the phone’s secure element. But if cyberthief gangs figure out a way around the protections, they’ve just handed a fraud means that could be five to ten times as profitable.
This problem is similar to recent arguments about hardening PIN Pad security and, frighteningly enough, token strategy.
The security token arguments have been compelling on paper. The essence of the token business case is to not protect the card data as much as make it useless to a thief. That’s a good notion, but it suffers from the reality that a token has to have a way to be reversed, to support efforts such as chargebacks. That’s why PCI can’t ever fully take tokens out of scope. (By the way, here’s another frightening thought that a colleague here suggested: What happens if your token vendor goes bankrupt?)
There’s actually another approach to retail security, which doesn’t actually protect the data better but does make it no longer your problem (which, for many IT execs, is perfectly acceptable). It’s where the retailer simply accepts far less data, getting a third party to accept it instead. This is the argument behind some of what Square is doing
In short, all of the third-party schemes have the shoppers giving the third-party vendor their credit card information and then simply using the third-party as a go-between. A deal that Starbucks just announced with Square, for example, has the customer showing the Square app on their mobile phone to a Starbucks associate, who scans a 2-D barcode on the phone. The POS takes it from there and Square handles the transaction. If any data gets stolen, it’s Square’s problem, not Starbucks. (At least for transactions that used Square, of course.)
A Burger King deal with another third-party player operates similarly, only the restaurant chain uses a static QR code instead of a barcode and there’s more back-and-forth communications between the retailer and the third-party vendor.
Security strategies are already hard enough. Let’s make it a little easier by first assuming that everything we create will be defeated. In security, that’s invariably the best place to start.