Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop
Written by Evan SchumanNow that a PCI lawsuit brought by four restaurants against a POS vendor and a systems integrator has been given class-action status, the case will survive and force a very interesting debate about exactly where a retailer’s PCI liability should start.
The case involves four Louisiana restaurant groups—doing business as Crawfish Town USA, Don’s Seafood and Steakhouse, Picante’s Mexican Restaurant, Mel’s Diner Part II and Sammy’s Grill—suing their POS vendor, Radiant Systems (which owns the Aloha POS systems used by these chains), along with systems integrator Computer World (not to be confused with the publication Computerworld).
The accusation in the lawsuit is primarily that Radiant told customers that its Aloha POS systems were compliant with PCI when in fact that system wasn’t. Computer World is accused of having violated more PCI rules and, as a result, these restaurants were breached. The lawsuit says that Visa had identified Aloha “as a payment application that stored prohibited data, such as full magnetic stripe data (including card verification and PIN data), after a transaction authorization was completed” but that Radiant continued to say that Aloha was PCI compliant.
“After the problems were identified and corrected, Plaintiffs were fined by credit card companies for failing to comply with the PCI Data Security Standards and/or their Payment Application Best Practices (PABP),” the lawsuit says. (OK, we all know that credit card companies can’t fine retailers. The card brands fined the processors, which passed along the fees.)
But when you drill into the details of the lawsuit, it gets more interesting. One of the key accusations against Computer World is that it used vendor default passwords for systems with many of these restaurants, for easier remote administration. The lawsuit correctly points out that PCI bans retailers from using such vendor default passwords.
But that’s the key. It’s the retailers that are not permitted to use these defaults. Was integrator Computer World, in this scenario, acting as an agent of the POS manufacturer—as a reseller—or as an agent of the retailer–as an integrator? If the latter, it means that the restaurants were paying Computer World to handle their IT for them, which would suggest that Computer World would be obligated to abide by PCI retailer rules.
But if you see Computer World as an agent of Radiant (as a reseller, that’s a legitimate interpretation), then the restaurants retained the responsibility. Did Computer World ask for permission from the restaurants to use those default passwords? If yes, did the integrator explain to the restaurants the implications of that question, in terms of both PCI compliance and actual security?
The fact that these retailers were relatively tiny chains will also prove interesting. A McDonald’s or Pizza Hut would be expected to have professional IT expertise inhouse. But Sammy’s Grill? These retailers rely on integrators and consultants for more than counsel and help. They expect these specialists to take over any and all IT functions, which—interestingly enough—could mean that some of the PCI retailer responsibilities might move with them.
Still, PCI rules are clear on this point: If a retailer chooses to accept credit cards, that business is also agreeing to abide by the rules. That responsibility can’t be outsourced. Whether it makes sense for these chains to have the PCI responsibility is a debatable issue. But for now, the PCI rules are clear, as is the responsibility.
-Marc
December 2nd, 2009 at 11:10 pm
There are so many holes in the process it will be difficult to pin blame on just one constituent. It is ridiculous that the technology exists to better secure these transactions (PIN, EMV, etc) yet banks won’t use them. Only the banks or government can force this change, and retailers will suffer until then.
December 3rd, 2009 at 2:02 pm
A major issue in this case will be if the restaurants had any support agreements in place with Computer World and if so what those agreements say. In my experience many single unit/small operators choose to skip the support agreements in favor of a “pay as you go” arrangement. They also will often choose to use other (cheaper) IT services rather than pay the POS VAR to handle “any and all IT functions”. In this scenario I can’t imagine how the POS VAR can be held responsible for a system they don’t own nor exclusively manage.
December 3rd, 2009 at 2:19 pm
There are technologies currently available to remove or greatly reduce the amount of cardholder data (CHD) in the merchant and, more specifically, the POS environment. Many POS vendors ignore the risk of handling and storing CHD in the POS and rely on their PA-DSS certification instead. But, as in this case, the application’s PA-DSS status had very little to do with the merchants overall security or PCI compliance. There is a big difference in having the POS installation guide say “make sure you set this password because the security of your CHD depends on this” vs. a POS application not storing the CHD in the first place. Traditionally only the merchant was liable for breaches and PCI related fees (fines). Maybe dragging some of the vendors into the liability mud fight will open the eyes of some of these vendors.
December 4th, 2009 at 1:11 am
I would add a couple more questions: “did the breach involve the use of the default passwords?” (The story doesn’t say.) And “were the default passwords used by Computer World to remotely administer the store systems?”
Another question is: “where is the PCI auditor in all this?” Did the restaurant group think they didn’t need an audit because Radiant was (mis)representing Aloha as PCI compliant? How is a retailer or even a PCI auditor to know otherwise? A PCI auditor is not necessarily a qualified computer forensic investigator capable of finding the card data on the hard drives. They can only base a decision on information given to them by others.
I think the answers to those questions would be useful to help sort out the lawsuit. If the passwords weren’t involved in the breach, they’re evidence of incompetence, not of culpability. But if they were used by the bad guys, and if Computer World left those passwords in place for their own use, then Computer World should be held to account. Regardless of the PCI wording about “retailers”, remember that PCI rules are only part of a contract, and are not statutory requirements. A judge might reasonably decide that a vendor selling a “secure” system that is using (or permitting the clients to use) default passwords is grossly incompetent.
Regardless of who wins, the case against Radiant for the storage of cardholder data sounds pretty strong, especially if they misrepresented their system as PCI compliant.
December 4th, 2009 at 3:52 pm
Nearly all POS vendors have some version of their software that is not compliant. What is not mentioned here is whether or not the version the merchant was using was PCI compliant.
Having been in POS sales, I can tell you firsthand about merchants opting NOT to upgrade to a compliant version simply because they did not want to spend the money. We had to have a signed letter from the merchant stating that they refused the upgrade. Sad, but true.
Too many unanswered questions here.
December 4th, 2009 at 4:40 pm
Most likely, if the merchants were levels 3 or 4 insize, there was no auditor. It was probably a self-assessment, possibly with the help of the POS vendor.
December 22nd, 2009 at 4:54 pm
I still find it interesting how the media as with many other people use the wrong terminology. Why would a payment application ever state that they are PCI Compliant. Since they are neither a Merchant, financial institution, nor a service provider (Processor). The PCI DSS is clear on who it applies to. Both Radiant and Computer world are required to be PA-DSS validated. There is no such thing as a PA-DSS “Certified” application. They can only be validated against the standard.
The reason for this is that Computer world and Radiant cannot ensure that the customer (being the merchant) will follow every instruction that the vendor requested. It is true that a PA-DSS validated application is not supposed to use the same password for all machines, however if the merchant chose not to enforce it then the vendor has only the ability to advise the merchant that having the same password is a violation of compliance with PCI DSS. They cannot force the merchant to change.
Ultimately it is the merchants responsibility to maintain their compliance with PCI DSS and ensure that their vendors maintain their compliance/validation with their associated standards. Each vendor has to produce documentation to prove that their application or service has been validated against PCI DSS
If Radiant and ComputerWorld produced the documentation to prove their validation, then the software may have be valid.
If in the investigation it is found that the implementation of the software was not done according to the vendor instructions, then fault lies on the entitiy that installed it. But the merchant is still responsible for maintaining their compliance to PCI DSS, not the software vendor.
If the software was installed according to the instructions and someone decided to take a short cut to make life easier, which in turn caused the merchant to fall out of compliance, then that entity is responsible to at least advise the merchant that they are out of compliance and that corrective action is required.
There are many ways to slice this beast, and until more information is revealed, there is no way to understand where and how the breach occured and who the responsible party is.
As a final note I would just like to say that it is important to understand that when someone states a application is PCI compliant it does not mean that a merchant is immediately compliant. This cannot be true since an application cannot provide compliance with all 12 requirements of the PCI DSS. Policy and procedure requirements are one example of how an application cannot be PCI DSS compliant. All other components of the merchant environment (POS app, middleware, pin pad,etc) have their own validations to complete.
It is only a merchant, financial institution or service provider (processor) that can attain PCI DSS compliance. Compliance is accomplished through process, procedure, documentation and technology. There is no silver bullet for PCI DSS, and being PCI DSS does not mean that you will never be breached. It only means that if you were breached, that there is a good chance that whoever the theif is, did not get away with much data, if anything at all.