Lessons from a breach

iceberg

In the days following the Target breach, both clarity and objectivity are in short supply. Everything that didn’t already exist became suddenly the cure-all – EMV being one. Retailers bristle, albeit in private – due to the asymmetry in blame they have come to share compared to banks – despite having equal ownership of the mess they have come to call payments. Issuers and Schemes scramble to find an empty deck chair on the Titanic, just to get a better view of the first of the lifeboats capsizing.

Analogies aside, we may never fully eliminate breaches. Given an infinite amount of computing power and equal parts human gullibility – whether its via brute forcing encryption systems or through social engineering – a breach is only a matter of time. But we can shorten the half-life of what is stolen. And ensure that we are alerted when breaches occur – as fraudsters take care to leave little trace behind. Yet today our antiquated payments system offer up far too many attack vectors to a fraudster, that the sophistication in attempts of the likes of what we saw at Target, is the exception and not the norm. But are the retailers absolved of any responsibility? Hardly.

Questions from a breach:

According to Target, malware was found on Target’s PoS – presumably pushed by unauthorized outsiders or via compromised insiders. If so, how is it that unauthorized code managed to find its way to all or most of its PoS terminals? Could this have been uncovered by performing a binary or checksum comparison first, to ensure that files or packages are not tampered with, before they are deployed to the Point-of-Sale? Such a step could have certainly limited the attack vectors to a small group of people with administrative access – who would have the need to handle keys and checksums.

Further, depending on the level of privilege accorded to every binary that gets deployed to the point of sale – Target could have prevented an unauthorized or remotely installed program from performing sensitive functions such as reading consumer data – either in transit or in RAM. That said – I am not sure if PoS manufacturers provide for such layered approach towards granting access and execution privileges to code that is deployed to their systems. If not, it should.

But sure, EMV could have sorted all of that out. Right?

(Update: I was just forwarded this Microsoft Casestudy which goes in to detail how “Windows Server 2008 Datacenter and its Hyper-V virtualization technology” will serve “Target’s entire store server infrastructure…, which will support a total of 15,000 virtual machines running mission-critical applications.” (quotes mine). I am reticent to draw any conclusions from this, but those interested can gather much specifics from the case study linked.)

Where DOES EMV come in?

EMV helps to verify the card – indisputably. Beyond that, it offers no protection to either the consumer or the merchant. The risk of EMV, and it’s infallibility in the eyes of its true believers, is that it can lull the general public in to a sense of false security – much like what we have now under Reg E and Reg Z. With EMV, PAN and PIN continues to be passed in the clear, unencrypted (Update: For clarity read Milos’s comment below) . Retailers could deploy EMV terminals and still be riddled like cheese by fraudsters who can siphon off PANs in transit. Fraudsters who may find it nearly impossible to create counterfeit cards, instead will migrate online where inadequate fraud mitigation tools prevail – and those inadequacies will force both banks and retailers to be heavy handed when it comes to determining online fraud. Friction or Fraud should not be the only two choices.

Solving Card Not Present Fraud:

There are no silver bullets to solve Card Not Present fraud. Even with EMV Chip/Pin, there is an opportunity to put a different 16 digit PAN on the front of the card versus the one that is on the magstripe/chip. (I am told that Amex does this for its Chip/pin cards.) The advantage is that a fraudster using a fraudulently obtained PAN from the chip for an e-commerce purchase will standout to an card issuer compared to the legit customer using a different PAN on the front of the card for all her e-commerce purchases. This maybe one low tech way to address CNP fraud alongside of an EMV rollout.

But if asking a consumer to enter his Zipcode or show his ID was enough for retail purchases, there exists equivalent friction-bound processes online. Authentication services like 3-D Secure are fraught with friction, and unfairly penalize the customer and indirectly – the retailer and issuer, for its blind attribution of trust in a user provided password or a token or a smart card reader. Where it may (in some cases) undeniably verifies consumer presence, it also overwhelms – and a customer who is frustrated with a multi-step verification will simply shop somewhere else or use Paypal instead. Ever had to input your Credit Card Verification code (CVV2 or CVC2) on an Amazon purchase? Me neither.

Fraud in connected commerce:

As connected devices outnumber us, there needs to be an approach that expands the notion of identity to look beyond the consumer and start including the device. At the core, that is what solutions like 41st Parameter – an Experian company, focuses on – which enables device attributes to collectively construct a more sophisticated indicator of fraud in an e-commerce transaction – using 100 or so anonymous device attributes. Further it allows for more nuanced policies for retailers and issuers, to mitigate fraud by not only looking at the consumer or device information in isolation – but in combination with transactional attributes. As a result, retailers and issuers can employ a frictionless, smarter, and more adaptive fraud mitigation strategy that relies less on what could be easily spoofed by a fraudster and more on what can be derived or implied. If you want to know more why this is a more sensible approach to fighting fraud, you should go here to read more about 41st Parameter.

Remnants from a breach:

Even though the material impact to Target is still being quantified, little doubt remains as to the harm done to its reputation. Target RED card remains largely unaffected, yet it is but a fleeting comfort. Though some, thus had been quick to call decoupled debit a more secure product, those claims choose to ignore the lack of any real consumer protection that is offered alongside of these products. Though Reg E and Reg Z have been largely instrumental in building consumer trust in credit and debit cards, they have also encouraged general public to care less about fraud and credit card security. And this affects more than any other – MCX, whose charter calls for reduction of payment acceptance costs first, and to whom – decoupled debit offered a tantalizing low cost alternative to credit. But when it launches this year, and plans to ask each customer to waive protections offered by Reg E and Reg Z and opt for ACH instead – those consumers will find that choice harder to stomach. Without offering consumers something equivalent, MCX Retailers will find it exceedingly difficult to convince customers to switch. Consumer loyalty to retailer brands was once given as the reason for creating a retailer friendly payment backbone, but with Target’s reputation in tatters – that is hardly something one can bank on these days – pun intended.

Where does this leave us?

To be completed…


You can connect with me on LinkedIn here.

I am the Mobile Commerce and Payments Lead at Experian Global Consulting and I serve Experian's clients in Banking, Retail, Consumer Credit and Payments on strategy, innovation and emerging business models around mobile. I am on the Advisory Board for SimplyTapp and ModoPayments. I am an Affiliate Analyst for Yankee Group focused on Mobile Marketing and Commerce Strategies. Previously I founded DROP Labs, a mobile payments/commerce strategy and advisory practice focused on banking & retail. Tweets here. I'm on LinkedIn here.
Cherian Abraham
View all posts by Cherian Abraham
Tagged , , , , , , , , , ,
  • KP

    Great post Cherian. A few observations/comments :

    - POS Malware could have been due to poor patch management within the IT org. Unattended hole in the system- open for attack. Checksum or bin check would not have helped much.

    - Chip and Pin is no panacea.

    - Harm done to the Target brand is huge ; something that other retailers should review seriously.

    - Consumers should continue to watch their card statements for suspicious charges and, we all ought to continue using payments vehicles of our choices ( e.g. Credit cards).

    Bad people all over history stole cash from the unwary – we did not stop carrying cash. We were more careful and invented credit cards. Now they are stealing credit cards. Look forward to the next innovation!

  • Milos

    “With EMV, PAN and Pin continues to be passed in the clear, unencrypted.”

    This is only the case where EMV is implemented with cutting corners, but it absolutely doesn’t have to be that way

    1. EMV fully supports the offline PIN verification where PIN is provided to the EMV chip application encrypted by the EMV card public RSA key and verified offline. This eliminates any need for it transmittal through and storage in the merchant and acquirer systems. Of course this requires usage of more expensive RSA capable EMV cards – why issuers still opt to DES only cards is beyond my understanding – pure cost cutting. Now we have this and we keep blaming EMV.

    2. EMV standard doesn’t prevent an issuer to implement end to end tokenization inside the EMV chip application. This means that issuers can transparently have provisions where the EMV chip application would provide to POS terminal ‘PAN token’ instead of the real PAN – by having READ DATA APDU behavior changed transparently. The ‘PAN token’ would preserve fully the BIN/IIN (to transparently preserve Acquirer capability to properly route the transaction to the real issuer) and last 4 digits of the real PAN (for merchant use – receipt printing, etc), but everything in between would be dynamically generated by the EMV chip using the key shared between the EMV card and Issuer host. Why this hasn’t been done so far is also incomprehensible to me – obviously again implementation cost cutting.

    By having #1 and #2 in place the Target data breach would be a non-story

    • @jayram_p

      Milos on #1 that works well only for low dollar transactions. That is done quite extensively in EU by all issuers. Or big ticket item it ha o go to the issuer for key verification. Not desired o do it offline. Moreover even in offline data does get reconciled on the back end. Sorry if I am missing your point here.

      On #2 you don’t need EMV for Tokenization. Tokenization when implemented properly in itself is amazingly powerful. I am not taking about merchant level Tokenization solutions. Rather talking about Network spec based issuer Tokenization.

      Cherian nice post. Thanks. I love your language. You have a way to make aboring subject interesting and colorful. @jayram_p

      • Jayram

        Apologies for the typos. Absence of proof reading couple with respinding from mobile device has its downside. @jayram_p