To follow up on a potential class-action lawsuit against POSitouch and its reseller, CC Productions , DataBreaches.net spoke with the founder of Brew HaHa!, one of the clients in the possible lawsuit. Brew HaHa! is a 10-store espresso chain in Delaware and Pennsylvania, and the breach has not been previously reported anywhere. Another client, who has yet to go public about their breach, is a well-known pub and restaurant in New York City.
According to Brew HaHa! founder and owner Alisa Morkides, she purchased POSitouch version 5.27 at the end of 2005. By the time it was installed by CC Productions, POSitouch had already released version 5.29. The difference in versions is important, as version 5.27 stored full card data while 5.29 did not. Morkides alleges that no one from CC Productions informed her at the time of installation that there was a more current version available or advised her to update or upgrade, and at no point after purchasing the system did she ever receive any advisories or warnings about her system no longer being compliant with evolving standards. “I spent $121,000 on the system and have a service contract with CC Productions and no one even tells me that there’s a newer system or upgrade that I should make?” says Morkides.
To make matters worse, she alleges, when CC Productions installed the system, they enabled remote desktop software so that they could manage it but did not change the default user logins and passwords and did not advise her to change them. A forensic examination of the system performed by TrustWave reportedly noted the default configuration use of usernames and passwords such as “POSI” and “master.” Morkides says that the report also stated that the firewall had “excessive” ports open and that a keylogger had been installed in 2009. Trustwave also found that full cardholder data going back to 2007 was stored in the system, corresponding to the time Brew HaHa! first began accepting credit cards. POSitouch vendor Restaurant Data Concepts says that they have a tool to delete stored cardholder data, but Morkides claims that CC Productions never used the tool or advised her to use it.
On February 1, Morkides received a call from Mercury Payment Systems alerting her that the Pike Creek shop appeared to be the common point of purchase in a number of fraud reports. Morkides immediately stopped accepting credit and debit cards in that shop, posted a letter to her customers to alert them to the breach, and ordered stand-alone terminals for all stores. She estimates that her business dropped by about 10% because she was not accepting cards. In addition to lost business, she has also incurred other costs. Since being notified of the breach, she has already paid $11,000 in forensic fees to comply with the mandated forensic evaluation and she took a loan to cover $60,000 to purchase a new system and $12,000 for Vendor Safe.
Morkides doesn’t know the total number of customers who had their cards replaced or who had fraudulent charges show up on their statements, but says that Wilmington Trust informed her that at their bank alone, 20-30 customers had fraudulent charges show up from overseas, for a total of about $27,000. Although she has not spoken with anyone from the Secret Service, the bank told her that they had contacted them and that the breach appeared to originate in Russia.
Because Morkides’ contract was with the re-seller and not the vendor, it would seem that most of her claims are against them. As Restaurant Data Concepts spokespeople informed DataBreaches.net, they have no contracts with the merchants, and do not do any direct mailings to customers. As standards have evolved, the company has complied by producing more formal implementation guides and it runs seminars each year for its resellers to keep them abreast of developments and issues, but in a conversation with DataBreaches.net, they strongly deny any responsibility for what happened to Morkides or any other clients. “The industry has a big hole in the middle of it,” Peter Lipton, CTO Restaurant Data Concepts told DataBreaches.net, with more and more responsibility being pushed onto the merchants. Lipton would like to see more readily available support for Level 4 merchants, such as bundled services that might be offered by payment processors that could include regular scans of the merchant’s network, etc.
While most of Morkides’ anger is directed at CC Productions, she is also angry at Mercury Payment Systems for signing her up in the fall of 2008 and never telling her that her application was not compliant. “Mercury acts like I’m this horrible person for having a breach, but I had to fill out forms when I signed up with them. Why did they sign me up if my software wasn’t compliant? Why didn’t they tell me? This could all have been avoided.” On October 1, 2008, Visa implemented Phase III of its Data Security Compliance Plan:
Acquirers must only board new Level 3 and Level 4 merchants that are PCI DSS compliant or utilize PABP-compliant applications. PABP does not apply to applications developed for inhouse use only or to hardware terminals.
Phase III mitigates acquirer risk associated with boarding new merchants that are not PCI DSS compliant or that rely on payment applications that are not PABP-compliant. Further, Phase III reinforces acquirer compliance efforts by preventing merchants from migrating from one acquirer to another in an attempt to avoid compliance requirements.
According to Morkides’ attorney, Charles Hoff, if Mercury signed her up on or after October 1, 2008 without notifying her that her software was not compliant, they will be sued, too. At the very least, he says, they should not be allowed to pass along any fines they might incur.
“I accept responsibility for being PCI-DSS compliant,” Morkides told DataBreaches.net, “but I feel like the partners that I hired at great cost let me down. They’re the experts and they had an obligation to tell me. Mercury Payment even charged me an additional $940.50 for ‘PCI Comp’ and still didn’t tell me that my system wasn’t compliant. When I questioned the charges, they told me that they were upgrading their system to be more compliant. This was supposed to help the merchants.”
As of the time of this publication, CC Productions has not responded to a request made on Friday for a statement or interview about the allegations.
This is the second situation of this kind in the past year where we have allegations of an exclusive reseller not properly installing a system that should result in a compliant system (although in Morkide’s case, there are other issues as well). According to Hoff, the lawsuit against Radiant settled earlier this year. The terms could not be disclosed due to a nondisclosure agreement, but he says that the two cases and many other reports of breaches around the country raise significant questions about who is actually ensuring that resellers are installing applications properly. Hoff asks, “If vendors have exclusive arrangements with resellers, should they be held liable if their authorized and exclusive reseller takes what should result in a compliant system and turns it into a non-compliant one? Or should vendors be de-certified if they use resellers who repeatedly leave gaping security holes in the merchants’ defenses?” In this case, Restaurant Data Concepts says that CC Productions is not an exclusive reseller, although they do have protected territory. They also maintain that changing Windows passwords is the customer’s responsibility.
Many merchants, like Morkides, work 60-hour weeks. They have neither the time nor energy nor technical expertise to wade through technical security materials even though they know they are responsible. The merchants believe that the vendors and re-sellers will be there if there’s a problem, but the contract they sign is with the reseller. Restaurant Data Concepts says that they have a simple policy: once a customer purchases a POSitouch system, there is never any charge by the vendor for an updated or upgraded system. The reseller might charge the customer for performing any updates or upgrades, but the vendor doesn’t charge anything. Ironically, then, Morkides could have had a compliant application — if she had only realized that her existing application was no longer compliant.
Whether Morkides’ claims against the reseller are settled or go to court remains to be seen. But given how many times we read stories like this, isn’t it long past the time to put more responsibility on those who take the merchants’ money to let them know when their application needs to be upgraded?