The Old PCI Squeeze Play
Written by Evan SchumanGuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.
We have previously argued that there are far-reaching implications of the Payment Applications Data Security Standards (PA DSS) for the merchant community, as they affect thousands of payment, infrastructure and business management applications. But some concerns raised by Jake Star, technology VP at HEI Hotels and Resorts, take this to the next level.
Star writes, in a letter sent to news media, that he has come across "a new way in which PCI is sapping our limited IT budgets. As a merchant, I’ve got to ensure that the point-of-sale applications I use are PCI certified. So I spent almost $1 million upgrading systems last year. The POS vendor has a .X release each year, so I have a combination of systems on version 1.1 and 1.2. This year, they released 1.3."
His tale continues: "PCI comes out with an update to their standard (PCI DSS is version 1.2, as of October). There are no significant changes in the standard that would make a previous system non-compliant, but the POS vendor [name withheld by StorefrontBacktalk.com, at Star’s request] still needs to certify with the new version. The POS vendor, blaming everything on PCI, says they can only certify their two most recent versions (1.2 and 1.3). Voila! All my 1.1 systems are magically no longer compliant and need to be upgraded."
Star then makes a reasonable guess as to what will happen when the next tweak to PCI is announced. "The POS vendor has just effectively changed the lifecycle of their software from 5-7 years down to two. Combine that with a strategy that requires you to retire older POS terminals in order to use the new version, and they now get 40 percent of the original system cost every two years. The moral of the story is that when companies purchase their software, they should include a clause in the contract that requires the vendor maintain compliance with PCI for a certain period of time or offer free upgrades."
In other words, PA DSS compliance by software vendors will cost the merchant community many thousands of dollars every year. When one considers that PCI 1.2 was labeled as having only minor "clarifying" changes, having to pay for an upgrade to a newly "validated" version seems all the more galling.
From the payment application vendors’ perspective, the picture isn’t any prettier. We have interviewed quite a few applications vendors lately about PA DSS and they are less than thrilled with the review process. None of them objects to being more secure, or having that verified.
Rather, the essence of the complaints is similar to the complaints about the airport security screening process by the U.S. Transportation Security Administration. The concern is that they are paying $10,000 to $30,000 per release (approximately) for testing, plus a listing fee when there are so many customization, integration, installation and administration changes that could affect the effective security of the product as used by the merchant.
Even though the PA DSS testing process specifically mandates simulation of different configuration and use cases, the typical argument from the application vendors is that the nature of the software development process and customization means nearly constant re-testing because the Visa (now PCI SSC) "white list" is by version number. However, all of the vendors have made it clear that they will comply, because not being on the list increasingly translates into not being in the market.
We have also interviewed quite a few PCI assessors about this same issue. Their perspectives are not at odds with the vendors. They completely understand about the customization, integration, implementation and administrative issues.
Their job, when reviewing a payment application, is to make sure that the specified controls are in place at the time of the assessment and under simulated installation conditions that are as accurate as possible and then to review all associated documentation (installation guides, etc.) for compliance. They have to ask the tough questions and search for clear, documented proof of the controls.
But what they cannot do, and what virtually no auditor can do, is find information (e.g., security design flaws) that a vendor is deliberately hiding or is avoiding disclosing because it could keep them from getting on the "white list" for another 90 days and cause the vendor to lose a couple of major deals.
Being on the PCI SSC vendor "white list" takes on increased market/revenue importance, but I expect that upper management of more payment (and payment-related) application vendors will start to build compliance into their business plans and SDLC. That would be great. Either that, or we’ll start to see vendors take more "desperate measures" to make sure they are on the list in time to hit their revenue targets. That would be not-so-great.
Star’s argument offers some very valuable advice to merchants: Make sure that your payment (and related) applications vendors provide and maintain a PA DSS-compliant version for an agreed-on period of time and offer free upgrades as needed to ensure the merchant does not fall out of PCI compliance because their payment applications have fallen off the PA DSS white list.
This is important, not only because it will save the retailer money but also because many retailers, hotel chains, educational institutions, etc., may not have "compliance updates" in their contracts. These are common in financial services, government agencies, healthcare and other more heavily regulated industries. So it’s time to call the lawyers, contracts admin, global sourcing or whatever they’re called and review those contracts.
If you have a question about PCI, PA DSS or any other related topic, you can ask the PCI Knowledge Base panel of more than 75 PCI experts in our discussion forums. We have one specifically focused on "Ask a QSA" and we’re considering adding one just for PA DSS. Let us know if you think that’s a good idea. Also, if you’re a retailer, we want to get you involved in the PCI Best Practices study we’re doing with the National Retail Federation. It’s 100 percent anonymous. Just send us an E-mail at David.Taylor@KnowPCI.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
