American retailer Genesco sues Visa, demands $13m in PCI-DSS data breach fines paid back

Filed Under: Data loss, Featured, Law & order

Just over two years ago, in December 2010, American shoe and clothing retail giant Genesco reported a network intrusion.

At the time, Reuters wrote that:

[Genesco] said the extent of the intrusion [was] not known, but it took immediate steps to secure the affected part of its network...[which] processed card transactions for its United States Journeys, Journeys Kidz, Shi by Journeys and Johnston & Murphy stores, and for some of its Underground Station stores.

Genesco turns over more than $2 billion per year, and operates about 2500 retail stores, so you can imagine why cybercrooks found its payment systems to be an interesting target.

Subsequently, the payment card industry, deeming Genesco to be in breach of its PCI-DSS standards, took more than $10 million off Genesco in penalties.

→ PCI-DSS stands for Payment Card Industry Data Security Standards, a set of non-governmental regulations, for want of a better phrase, imposed by the card issuers on its users. It is enforced by penalties extracted from those who fail to meet the minimum standards, which claim to provide an "actionable framework for developing a robust payment card data security process - including prevention, detection and appropriate reaction to security incidents."

That's a lot of money by any standards, and Genesco decided not to take these privately-levied "fines" lying down.

In what seems to be a legal first, the company is taking Visa to court to try to recover penalties it claims it oughtn't to have had to pay at all.

(Wired has the legal documents conveniently online [PDF].)

The court papers run to a doubtlessly-expensive 49 pages, but the bottom line (literally and figuratively: it's on page 48, just before the signatures) is that Genesco wants its money back:

The company insists upon no less than the resoundingly precise sum of $13,298,900.12, plus "such other and further relief the Court may deem appropriate."

The key point of Genesco's argument is technically rather interesting, and you can find it on page 7.

Naked Security has pointed out before that PCI-DSS's insistence on encrypting credit card data when it is stored has caused the crooks to switch to memory-based techniques for spotting and stealing magstripes.

After all, the data has to be in memory at some point, even if only on an individual point-of-sale computer, and it probably won't be encrypted until it begins its trip across the network, or its journey down onto disk.

And that is the pattern Genesco claims was followed in its intrusion: the crooks installed packet-sniffing software, and may or may not have been successful in using it to pluck credit card data off the network as it passed by.

(Genesco also states, unsurpisingly, that it was "the victim of a sophisticated cybercrime attack," as though that somehow softens the blow or removes culpability.)

So Genesco is admitting that it didn't encrypt its customers' data in transit, but asserting that this was perfectly OK according to PCI-DSS:

Payment card account data required for permitted to be transmitted in unencrypted form during the transaction approval process

Genesco even notes that unencrypted payment card data of this sort "is highly sought after by criminals," yet absolves itself from blame (or at least from PCI-DSS penalties) on the technicality that sending cleartext magstripe data over the network is not actually prohibited.

Risky? Yes. Punishable? No.

This would be a laughable situation if it were not so serious.

Credit card data should be encrypted at rest and in transit, and we all know it.

So let's hope that the world moves that way, no matter how this case turns out, for the simple reason that it's the right thing to do.

, , , , , ,

You might like

2 Responses to American retailer Genesco sues Visa, demands $13m in PCI-DSS data breach fines paid back

  1. Anon · 939 days ago

    I think the point here is that most "banks" aka global payments etc, require the tranmission of the cc in the clear. So although you can have it encrypted in your network, the link to the bank (which unfortunately originates in your network, but not at the PoS) is actually clear text and thus subject to sniffing. There is not a whole lot the company can do in that case.....

    • Actually, there's a fair bit that can be done. Credit card numbers by themselves are fairly useless. What you really need is the CC# and the rest of the track-1 or track-2 data. THIS data should never leave the PoS unencrypted, and stays encrypted when going to the processor. The authentication bits should then be stored encrypted and separate from the rest of the data, linked by a chain of transaction ID and authorization ID.

      PCI is supposed to work so that all the parties involved (PoS device provider, transaction solutions provider, merchant, payment processor, merchant bank, credit company, etc.) only have the information required to validate that the transaction is legitimate -- and that information differs depending on the player involved.

      Of course, if the players are all taking shortcuts to expedite the processing while still being PCI compliant, theory and practice don't line up.

      So, as Paul says, let's hope that the world moves that way, no matter how this case turns out, for the simple reason that it's the right thing to do.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog