10
Jun 15

Breach at Winery Card Processor Missing Link

Missing Link Networks Inc., a credit card processor and point-of-sale vendor that serves a number of wineries in Northern California and elsewhere, disclosed today that a breach of its networks exposed card data for transactions it processed in the month of April 2015.

ecellarEarlier this week, I heard from a source at one of Sonoma, Calif.’s fancier wineries that their card processor had been breached. On Tuesday, I reached out to Calistoga, Calif. based Missing Link. Today, the company responded that it had begun notifying its customers about the incident, and that it was working with law enforcement and the card associations on an investigation.

“Beginning on May 27, 2015, we began notifying our winery customers that eCellar Systems, our consumer-direct sales platform, had been breached during the month of April, 2015 by an unknown intruder,” the company’s founder and CEO, Paul Thienes, said in a written statement. “To that end, each of our winery clients will be sending out notice of this event to their customers and it is likely that individual consumers may receive a similar notice from multiple wineries.”

“The intruder gained access to customer names, credit/debit card numbers, the related billing addresses, and any dates of birth in our system during the window of April 1st through 30th this year,” Thienes wrote. “The intruder did not have access to any driver license numbers, Social Security numbers, CVV verification numbers, or PIN numbers (data which we would typically not collect anyway). We have identified and secured the method that was used to breach our platform. Additionally, to prevent a future reoccurrence, we are in the process of converting to a ‘token’ system so that credit card numbers will no longer be stored by the eCellar platform.”

Tokenization as a card security solution tends to be most attractive to businesses that must keep customer card numbers on file until the transaction is finalized, such as hotels, bars and rental car services. A January 2015 report by Gartner Inc. fraud analyst Avivah Litan found that at least 50 percent of Level 1 through Level 3 U.S. merchants have already adopted or will adopt tokenization in the next year.

Merchants retain tokens because they need to hang on to a single unique identifier of the customer for things like recurring billing, loyalty programs, and chargebacks and disputes. But experts say tokenization itself does not solve the problem that has fueled most retail card breaches in recent years: Malware remotely installed on point-of-sale devices that steals customer card data before it can be tokenized.

An alternative and far more secure approach to handling card data involves point-to-point encryption — essentially installing card readers and other technology that ensures customer card data is never transmitted in plain text anywhere in the retail environment. But many businesses have chosen tokenization in favor of encryption because it is cheaper and less complicated to implement in the short run. Merchants that adopt point-to-point encryption may also find themselves locked into a single credit card processor, because the encryption technology built into the newer readers often only works with a specific processor.

Chip card technology also will help. Merchants in the United States are gradually shifting to installing card readers that can accommodate more secure chip cards that adhere to the Europay, MasterCard and Visa or EMV standard. These chip cards are designed to be far more expensive and difficult for thieves to counterfeit than regular credit cards that most U.S. consumers have in their wallets. Non-chip cards store cardholder data on a magnetic stripe, which can be trivially copied by point-of-sale malware.

Missing Link Networks offers a variety of products and services through its eCellar line, including point-of-sale technology and database solutions. The company joins a long list of other POS vendors that have disclosed breaches in recent months, including NEXTEPHarborTouch and Signature Systems.

Tags: , , , , , , , ,

44 comments

  1. Nicholas Weaver

    The wineries pretty much have to use tokenization and not Point-to-point encryption for this.

    Small wineries are very dependent on wine club sales, where a customer signs up on a subscription basis to receive X bottles every Y months. Many of these sales also end up having to be card-not-present transactions, as customers call up to change their records.

    The chip-card, point-to-point encryption model doesn’t work well for these usages.

    • Point-to-point encryption is not an alternative to tokenization. It is an additional protection.

      The wineries should definitely get tokens back from their authorizations, but when swiping the credit card and passing it to the bank for the authorization they should use point-to-point encryption so that the raw credit card number is never available on their hardware or their network.

  2. Hey Brian, big fan. Are there any plans for another malware or darkode/similar sites expose any time soon?

  3. VPN Hong Kong

    The United States should have moved to Chip & Pin, ten years ago then maybe we wouldn’t be in all this mess with all these ongoing breaches

    • Yes, US are last remnants of stone age technology. But not only chip&pin, merchants and third party processors have to have at least things PCI reccomends.
      “But many businesses have chosen tokenization in favor of encryption because it is cheaper..” – it is wrong assumption that if you have tokens you cannot have any encruption. You may have.

      “because the encryption technology built into the newer readers often only works with a specific processor.” – do you suggest that many merchants in US are installing nonstandart solutions?

      • You are almost right. Non standard comes thru the old debate on platform used. If you are older, you may remember the old debate between amd and Intel? Which processor gave the correct awnser? And rounded up, Intel rounded down? In pgp , if it is an encrypted message, with a sum of four(4), one machine gave a 3.9, the other gave a 4.1, neither was correct. Meaning a garbled message. Both Intel and and solved this thru a software solution. Being software it can be compromised. The latest update, applied thru MS, just had an and software update. Just wondering if the Intel’s had one lately.

      • Tokenization and E2E encryption are certainly not mutually exclusive, they serve different uses. Tokenization secures post transaction, stored data, E2E protects the data during the transaction.

        E2E ties you to a single processor (bank), because the processor provides the service. The card data is encrypted at the card swipe in store, and the retailer does not have the keys to decrypt it, only the processor does, once the transaction gets to the processor it is decrypted. And Brian is dead on, the reason its not used more, is because the processor / bank charges the retailer on a per transaction basis to provide E2E, which is cost prohibitive to small retailers and retailers on thin margins. My company hasnt implemented it because it was going to cost us millions per year.

        The PCI Council is supposed to release a new e2e standard soon, that allows the retailer to manage the e2e process, only decrypting the transaction at the very last point before it is sent to the processor / bank. However, right now, the banks and the big companies that make the card swipe devices (verifone, ingenico, etc) are doing their best to block this option, making it too costly to implement, so that you will use THEIR solution, so they can charge you the per transaction fee, instead of your bank. This solves the issue of being tied to a single processor, but doenst solve the cost issue.

        But glad to see that these items are finally getting more discussion.

        • While I agree with your comments (E2EE protects card data before authorization; tokenization protects stored card data for recurring use), “vaultless tokenization” is throwing a wrench in things. I consider the only real tokens to be tokens where there is no mathematical relationship, and they are irreversible outside going back to the original table of token to real data – but other people are talking about using “tokenization” which is more like encryption, creating all sorts of problems.

        • Another big reason E2E or P2PE is not used is that only two companies have solutions that pass QSA muster. If you want a certified solution; you only have two companies to choose from. Can you say $$$$$$$?

  4. HA ! Now we know what the missing link at this corporation is. Do I need to say it ? = Þ

    Sometimes, its simply a name that intruders will go after. I think its much like Target. Have a name that instills just a additional fraction of motivation to hack a website? It might just be their demise.

  5. Something wrong with your email notification system?
    Got five or so emails this morning notifying me that ” new” posts were available here.

    • Yeah, sorry. We had a glitch with the mailer and a lot of subscribers didn’t get notifications of new posts for the last 10 days or so. I think we’ve fixed the glitch, but the fixing caused all the backlogged emails to be delivered at once.

  6. A bit unrelated, but did anyone take notice of the company”AeroGrow” getting hacked? They sell the popular “AeroGardens.” It does not seem to be making the headlines.

    I only found out when I received a letter in the mail dated June 2, 2015.

    Add this one to your LONG list of companies that are getting hacked.

    I wonder how many other small companies are getting compromised. Are they all falling victim to the same exploitation?

    • There are 2 types of companies, those that have been breached, and those that don’t know they have been breached.

      As far as the small companies, when it comes to the smaller retailers, yes, many of them are being hacked the same way, they are finding insecure remote access into their systems (go to my PC, etc for remote support), they then are using the backoff maleware. And I am sure many small companies get hit this way. When you don’t have onsite IT (and even sometimes when you do) you have to provide a way to remotely provide support, and if that isn’t done securely, its an invitation to hackers. In fact, not to long ago, Brian mentioned that there is a dump online of remote access credentials to hacked businesses.

  7. “The intruder gained access to customer names, credit/debit card numbers, the related billing addresses, and any dates of birth in our system during the window of April 1st through 30th this year,” Thienes wrote. “The intruder did not have access to any driver license numbers, Social Security numbers, CVV verification numbers, or PIN numbers (data which we would typically not collect anyway).”

    That doesn’t sound right. If it was a POS reseller breach as running in line with the other ones……track1 and track2 was probably stolen UNLESS these were CNP (e-commerce transactions). I do not believe they would have gotten PIN in either scenario.

    • It sounds like this was an online ecommerce hack. They were, at the least, storing card data, along with other details, for rebilling and such, it sounds like. Aside from the fact that this is a blatant violation of PCI (unless it was encrypted and they blew securing the encryption), I just don’t see WHY people are still storing card data. The fact that they mentioned that they are moving to tokenization, would seem to imply that this was NOT a POS breach, rather a database breach, where track data was stored. And that, makes me want to punch myself in the face!!!!

      I suspect that many smaller businesses, that have branched out to ecommerce, are finding a local web developer to create their ecommerce site. And its just the nature of business, that when you go to a smaller, local web developer, you may get a great site, but security is likely overlooked.

      • It would only be a PCI violation if they were on a shared server. Otherwise, if it’s a private network, they can store the card #, name and expiration date without violation.

        ““The intruder did not have access to any driver license numbers, Social Security numbers, CVV verification numbers, or PIN numbers.”

        No PAN data, no CVV , no PIN = No use for the crooks

        Who cares if it is even plain text, if it’s on a secure private network this would be PCI compliant.

        • I don’t believe that is correct. PAN=primary account number, which was breached. From the PCI DSS 3.1:
          3.4
          Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

          One-way hashes based on strong cryptography, (hash must be of the entire PAN)

          Truncation (hashing cannot be used to replace the truncated segment of PAN)

          Index tokens and pads (pads must be securely stored)

          Strong cryptography with associated key-management processes and procedures.

          • Was PAN data stolen? Going off the press release that Krebs posted they are saying only credit card #’s. Not PAN Track 1/2 data. Unless they updated this statement, this would still be considered a pointless breach since the crooks can’t do anything with what they stole besides a phishing scam.

            • You are getting your terminology confused. This is PCI 101. PAN = Credit Card Number. If you read the article, the credit card number has been breached, along with customer name and address. Hence this event is being treated as a breach. Track 1 magstripe data has NOT been breached.

  8. The problem with P2PE is that both ends, the swipe and the bank, have to support it. I had high hopes for using the Self Assessment Questionnaire SAQP2PE-HW, as it is much easier than SAQ-C. However, there weren’t any end to end solutions on the PCI SSC’s list that the bank we were looking at supported.

    • Hey John, just curious who your bank and/or processor is? I work with one of the approved P2PE providers and we try to have any connections a merchant would want – that way they can switch merchant services providers at any time, without a hitch.

  9. I’m wondering how serious anyone is about chips. I’ve got a fair number of cards from Visa, MC, and AmEx, and none of them has a chip. I can understand it for older cards, but I’ve received two or three new cards without chips this year.

    • What are they going to do with a credit card #? Without PAN data, CVV codes, and/or PIN, this is a pointless breach.

      • The lack of CVV data does limit where the card numbers can be used, but there are still online stores that may not require CVV.

    • Over the next two years all the credit/debit cards in the US should be replaced with a chip card. Depends on which bank you have.

    • October 2015 is when the Chip/Pin compliance takes effect, and merchants will be responsible for eating fraudulent transactions if they don’t use EMV pinpads (we’re not talking about online transactions). I can tell you that there is still a lot of churn in this area for the US as financial companies and pinpad vendors try to fit EMV into their processes (they may have it in Europe, Asia, etc., but different rules apply here). It also didn’t help that the EMV governance for the US came very late, and many providers (equipment and processors) were in a limbo for a long time. That could be why we don’t see many of these chipped cards out there yet.

      Furthermore, some are also allowing “Chip and Signature”, which (IMHO) is a half-hearted measure to address this and is not very different from what we are doing today without the chip.

      • I didn’t think anyone in the U.S. was doing Chip and PIN. I thought it all was going to be Chip and Signature.

        • Correct. Only debit and travelers cards will offer Chip & PIN cardholder verification methods. All else will be chip and sign so don’t let your credit card out of sight!

          • And even many travelers cards will be Cip & Signature. Foreign systems do typically support it fine, although the person behind the counter typically do look surprised when the paper spits out …

  10. I think we just need to accept as Brian’s excellent post from the other day said that all our information is out there and start locking down end points (i.e. security freeze type activities) as much as possible.

    We’ve pretty much lost the battle of trying to prevent these attacks in an awesome way, so now we need to come up with how to be operate as a society knowing pretty much everything is breached a good deal of the time. This is a question which currently doesn’t have any good answers except “encrypt everything all the time.” At the moment individuals bare little responsibility for bad security as financial institutions make many people whole, (not corps always, but yes if you deal with a bank like Chase which offers businesses the same protections as individuals). At a certain point these institutions will not be able to foot the bill, and then what happens next is an interesting question.

    I believe that a major world shift in power is underway and it’s not necessarily a good one. Power is moving from the centralized model to decentralized chaos (physically and virtually too). Another question is at one point do governments essentially lose control completely? When our own government can’t even keep top secret data secret, it doesn’t bode well for the future.

    I hope things improve. I can envision a scenario where a very bad rogue actor takes control of critical systems and holds it ransom not for money, but some darker purpose.

  11. Are you planning to write anything about the TV Monde hack which French authorities have attributed to APT28? Or are you suspicious that they’re misattributing that attack?

  12. PAN = primary account number. Having the number alone is sufficient to require full PCI compliance.

  13. why would you say chip cards are more secure? did you not have enough time to write this article? I generally support your writing but your really broad reader base now can’t be told that chip cards are “more secure” what does that even mean? I’m sure you have a thick skin by now but anyway i generally support your work and thank you for this piece.

  14. Just a few responses to what I think are misconceptions around Tokenization and P2PE…

    – “many businesses have chosen tokenization in favor of encryption” – This makes it seem like merchants select P2PE or Tokenization, when I believe they work best hand-in-hand. P2PE conceals all card data at the point of entry and protects from POS malware attacks, and then once the data enters the network or an application, it is stored as an irreversible token.

    – “…because it is cheaper and less complicated to implement” – I really think the cost of P2PE is misinterpreted. I work at a company that injects its own PCI-validated P2PE application on Ingenico terminals. The cost of the P2PE terminal is around $15 more than the basic one. When you think of the reduced burden from a PCI compliance standpoint (i.e. moving from a SAQ D to SAQ P2PE HW), P2PE can actually be considered a big cost saver.

    – The line about being locked into a single credit card processor is untrue if you’re using a processor-neutral gateway that is providing the P2PE solution. I’m not sure how our peers on PCI’s P2PE list handle this, but our clients have no hassle switching process. They obviously want to maintain leverage in negotiating processing fees – adopting tech that creates extra stickiness would of course be troublesome.

    And just have to say thanks, Brian! Big fan of your work. Glad you bring much-needed attention to these events – it’s surprising how much of this gets swept under the rug.

  15. I blame the St Louis Cardinals