Questions To Ask Your System Vendor Or Reseller

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

The National Retail Federation's Big Show is next week, and the exhibition floor will be crowded with vendors offering retailers all types of software applications. As a public service, following is a list of questions all merchants should ask their POS system supplier or reseller based on one QSA's experience—namely mine. The good vendors will be able to address all these questions. The not-so-good ones will hand you a carrier bag or a pen instead.

The theme here is value-added resellers and how to integrate operations with them. VARs play an important role for many small and midsize merchants of all types. Often treated as trusted partners, the vendors in many cases earn this trust. The problem comes when the vendor is not so trustworthy. Due to poor training, sloppy practices or simple incompetence, a vendor can actually increase a retailer's risk of a painful data compromise that can threaten the life of its business.

Every retailer needs to understand that as far as PCI is concerned, they can outsource their processing, but they cannot outsource responsibility. That means while the reseller may be doing the work, the retailer is ultimately responsible. And if there is a data breach, it is the retailer who will bear the costs.

Is the application (and the version) validated against the Payment Application Data Security Standard (PA-DSS)? Both Visa and MasterCard mandate merchants use only PA-DSS validated applications. So using one is not only smart, it is required. A simple "yes" may not be enough, though. Retailers need to ensure the version is "Approved for New Deployments" and not "Acceptable for Pre-Existing Deployments." The difference between these two ratings is important, and you should only consider a version that is approved for new deployments.

Once you know the application is PA-DSS validated, find out when the validation expires. Inquire about plans (and costs) for upgrades.

If you find you have a payment application already and it is no longer approved for new deployments, don't panic. Instead ask the vendor how long it will continue to maintain the application and issue security patches. You may find that the vendor will continue support for some time but ultimately that support will end. Once that happens you have an end-of-life situation, and you will need to upgrade your application. Will the vendor install it according to the PA-DSS Implementation Guide? Obviously, the answer should be "yes." By the way, you need to have a copy of the PA-DSS Implementation Guide, too. Once you have it, don't just put it on a shelf. Read it, and understand what actions you or your vendor need to take to make sure the application is installed and maintained properly. For example, if the application stores cardholder data, what is the process to make sure you change the encryption key(s) at least annually?

If the application is installed and maintained by a reseller, you need to ask: Where is the firewall? Is that included, or do you buy it separately? Any discussion of firewalls has to address the fact that PCI does not require just a firewall; PCI requires a properly configured firewall. What role will the vendor or reseller play to help in configuring the firewall?

Does the application store cardholder data, even for an instant? Many payment applications store electronic cardholder data even though there is no longer a good reason for merchants to store that data. If you are uncertain, the vendor's PA-DSS Implementation Guide should help. When you see a section on encryption and key management, you can be pretty certain the application stores electronic cardholder data. Ask if you can configure the application not to store data. At the very least, minimize the time the data is stored before it is purged. I have seen default settings that retained card data indefinitely, which increases the retailer's risk of a data breach and is, therefore, a very bad idea.

A common misconception is that a PA-DSS validated application is either a guarantee of PCI compliance (it is not) or that it will not store cardholder data (it can). Retailers need to determine both whether their application stores cardholder data and the process to purge that data when it is no longer needed.

What vendor training does the application developer provide, for both its resellers and its customers? If the vendor only trains resellers, can you attend any of that training?

Who specifically will install the application? Who will perform maintenance and upgrades? Have they been through the training? You want to have the name of the individual who will show up on your doorstep to install or maintain your application. A client of mine recently suffered through a vendor's tech rep wasting the better part of a day onsite trying to find the password for the SQL server. A client of mine recently suffered through a vendor's tech rep wasting the better part of a day onsite trying to find the password for the SQL server, then stumbling around trying to execute the upgrade procedure. The tech rep finally left at day's end with nothing accomplished except a promise to come back "soon" to try again to implement the upgrade. You want to avoid a similar experience with an inexperienced tech rep. How will the vendor or reseller maintain, troubleshoot and update the system, including installing security patches? If they maintain the application remotely (which is common), PCI requires both two-factor authentication for all remote access by staff or vendors (Requirement 8.3) and that the merchant control access (Requirement 12.3.9). These requirements mean the retailer needs some basic understanding of the specific remote access and two-factor authentication technologies to be implemented.

Does the vendor offer a hosted (i.e., outsourced) option? In case it is not abundantly clear from the above questions, running your own payment application requires you to take an active role. If firewalls, security patches, upgrades and two-factor authentication scare you, then maybe you should look to outsource your payment processing to a PCI-compliant service provider instead.

Both Visa and MasterCard maintain lists of the larger (Level 1) service providers on their Web sites. Many service providers specialize in a particular industry, so there may be a third-party hosted solution that can work for your business.

Outsourcing is not a panacea; it does not make PCI go away. The retailer is still ultimately responsible, but PCI compliance is simplified and your security is increased greatly with careful outsourcing.

Lastly, get everything in writing. Any promise, any extra feature or customization, any claim, any guarantee, any special deal only counts if it is in the contract. Promises made in meetings by E-mail or on the golf course are fine, but they don't count unless and until they are in writing.

If you encounter resistance to putting a particular promise in the contract, you may want to escalate to a more senior person at the vendor. Failing that, get up and leave the room (and take anybody you like with you).

Small and midsize retailers and merchants of all types are at a disadvantage in the world of payment applications and PCI compliance in general. They focus on what they know best: serving their customers and building sales. Most neither want nor have the ability to manage a technical infrastructure. The bad guys, however, are technically sophisticated, and they increasingly target these same small and midsize merchants.

Events like the NRF show provide great opportunities to meet with competing vendors, learn the latest developments and find solutions that can improve your business. It is also a great opportunity to ask questions.

Do you rely on third parties like value-added resellers and service providers? What has been your experience? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].