Comments on: Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop

By: Robert Spivak

Robert Spivak — Tue, 22 Dec 2009 20:54:32 +0000

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.

By: Steve Sommers

Steve Sommers — Fri, 04 Dec 2009 20:40:20 +0000

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.

By: Chris Miller

Chris Miller — Fri, 04 Dec 2009 19:52:57 +0000

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.

By: A reader

A reader — Fri, 04 Dec 2009 05:11:22 +0000

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.

By: Steve Sommers

Steve Sommers — Thu, 03 Dec 2009 18:19:35 +0000

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.

By: Jim Janke

Jim Janke — Thu, 03 Dec 2009 18:02:28 +0000

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.

By: David Dorf

David Dorf — Thu, 03 Dec 2009 03:10:49 +0000

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.