By Dave Faoro
VeriFone
In April 2008, Visa Inc.'s Payment Application Best Practices (PABP) was absorbed into the Payment Application (PA) Data Security Standard (DSS) published by the Payment Card Industry (PCI) Security Standards Council (SSC). For all practical purposes, the new PA DSS requirements will lead to major changes in how POS terminals are certified and sold.
The PA DSS is intended to help software vendors and others develop secure payment applications that do not store prohibited data - such as full magnetic stripe, card verification value 2 (CVV2), PIN or sensitive data - and ensure their payment applications support compliance with the PCI DSS.
In essence, the PCI DSS covers merchants' overall security and the PA DSS covers third-party applications used in those environments. The PCI SSC has qualified organizations known as PA Qualified Security Assessors (QSAs) to validate that these payment applications support PCI DSS.
When a breach occurs, generally a forensic audit is completed by security firms. In this audit, everything is reviewed for compliance - hardware, site, application and communications. These audits result in judgments regarding whether merchant sites meet full PCI compliance.
Acquirers that do business with noncompliant merchants face stiff penalties. Visa, for example, said, "Members are subject to fines, up to $500,000 per incident, for any merchant or service provider that is compromised and not compliant at the time of the incident."
A recent report from Trustwave noted that 92 percent of its forensic audits had involved level 4 merchants, such as neighborhood convenience store merchants who accept less than 1 million transactions annually. Can you really afford to take chances when boarding new merchants?
What we know as stand-alone POS terminals did not fall under the scope of Visa's PABP; with the move to PA DSS, that has changed. Very few POS solutions may still escape the requirements for PA DSS audits. For merchants' payment applications to avoid a PA DSS audit, all of the following on-site conditions must be met:
From a manufacturer's perspective, developing terminals that would only work in those limited environments is not practical - they could not be sold to much of the general market.
Many PAs today are built to run in either a dial or Internet protocol (IP) environment, so they have to comply with the PA DSS. In addition, many merchants are taking it upon themselves to implement IP conversion solutions for traditional dial terminals, so something developed for a noncompliant environment today could end up being converted to PA DSS validation.
While the PCI SSC implements the standards, each card brand and payment processor is responsible for managing enforcement to ensure non-PA DSS payment applications are ultimately outlawed from the payment networks.
Visa, for example, has already initiated its own three-year plan to accomplish this goal (see http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html). Also, major processors have already indicated they will not provide Class A and Class B support to applications that are not PA DSS validated.
The council requires that PAs be subjected to security audits by authorized PA QSAs. Responsibility for submitting an application to PA QSA organizations lies with the software vendor. However, resellers are held responsible by the council to:
Merchants have similar responsibilities with regard to configuration and implementation. They must also maintain PCI DSS-compliant status for both the environment and the application configuration.
While the PA DSS sets some rigid requirements by which terminals can be excluded, the reality is that suppliers have to develop solutions for the greater good, not narrow exceptions. It is the responsibility of manufacturers and resellers to facilitate, not inhibit, PCI DSS compliance.Our downstream customers, whether integrators or merchants, expect us to provide them with secure products.
We shouldn't expect that they can all become security experts and understand all the rules of being PCI compliant. It's also not realistic to expect software developers and solutions providers to develop applications solely for a private-line world when most of the growth is for public-network access.
From our perspective, that means that we have to implement the PA DSS across the board for devices that could be used within the scope encompassed by the standard - the alternative would be to manufacture two versions of the same unit to have PA DSS and non-PA DSS versions. VeriFone has taken a proactive approach to this issue and recently announced an initiative for blanket implementation of PA DSS over applicable devices. Going forward, VeriFone is establishing a universal compliance program for all its applications used in its programmable payment acceptance devices. A universal compliance program takes the guesswork out of the PA DSS. It removes the potential for confusion among the parties regarding who is responsible for what. Ultimately, we're all responsible, and we all need to take steps to ensure we're each doing our part to ensure consumer trust in the payment life cycle.
All of this compliance testing comes at a cost, of course, and security is turning into a major component of payment solutions pricing today. Because each PA used by each bank, processor or acquirer must now be audited for each discrete payment terminal, full PA DSS compliance will result in hundreds of individual audits by qualified assessors.
Various service and solutions providers are now beginning to identify compliance costs as a separate line charge in their pricing to both identify for their customer the value of their efforts, as well as to ensure they can recover costs rather than absorb them.
That's the approach we plan on taking as well - not only does it put the manufacturer's security efforts upfront, but it should also make it easy to compare and contrast what each supplier is doing in that regard and how much it is costing customers. Identifying compliance costs serves a number of purposes:
VeriFone firmly believes security compliance costs should be highlighted to merchants in a separate line item fee. This will enhance their understanding that security is not only incumbent but also an ongoing focus for the solution they have purchased through ISOs.
Security is no longer an option for anyone; it's a benefit that shields merchants from fines, audit costs and loss of consumer trust. It's vital to educate merchants on the need for security. Those who attempt to hide the cost and fail to turn security into a value added service will ultimately be left behind by competitors that take a more proactive approach. At the end of the day, the only method of protecting ISOs from card network penalties in case of security breaches at ISOs' merchant systems is to strictly adhere to all security mandates.
That means updating merchants to PA DSS-approved applications as soon as they become available. Dave Faoro is Chief Security Officer for VeriFone. He can be reached at dave_faoro@verifone.com.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
