PCI Playing Mobile Limbo

Attorney Mark D. Rasch is the former head of the U.S. Justice Department's computer crime unit and today serves as Director of Cybersecurity and Privacy Consulting at CSC in Virginia.

Given the very nature of PCI, it does horribly when dealing with new technologies. That is, of course, the exact area where PCI needs to be really strong. When technology is new, that's when PCI guidance is most needed. Six months after everyone has deployed is not the best time to weigh in with advice. Giving retail chains a choice of either holding back or not complying with PCI is hardly the best move for an industry that needs to constantly grow and evolve.

The punitive response options from the PCI Council were designed for chains that violate current PCI guidelines, in that those businesses engaged in explicitly forbidden behavior. But the rules have no standard way to deal with new technology. A new payment system, unanticipated by the rules, is neither PCI Approved nor PCI Rejected. It is, frankly, PCI Limbo.

The irony of all of this is that it suggests only one legitimate retail course: Proceed with the technology anyway, without waiting for guidance. Take the current PCI situation with mobile payment rules. After however many months it takes, the council will eventually issue its guidance.

And if it follows historic patterns, the council will give a generous amount of time—maybe 12 to 18 months—for retailers to abide by the new rules. Heck, in PCI 1.2, the council gave retailers two years to ditch WEP, even when WEP was considered to be highly insecure.

Even at 12 months, that amount of time—on top of the months the PCI Council will still take to decide—will likely mean that retailers will be ready by then to move to the next generation of mobile platforms. Therefore, it's quite safe (PCI-wise) to move ahead right away with mobile plans. But you still need to be careful about how you make that move. Making sure your mobile payment approaches are as secure and bulletproof as you can possibly make them will go a long way to avoiding PCI fireworks.

There is, however, a bigger issue at play here. Technology moves at the speed of the Web. Law moves at the speed of lawyers. And slow, deliberate and ponderous lawyers at that. As a merchant seeking to adopt new technologies—particularly in the mobile payment arena—should you wait until there are final binding rules (under PCI-DSS) for the security of a particular new application or just blaze forward, cross your fingers and hope for the best? Are you in breach of contract when the contract is silent on the new technology? And what are your duties to your acquiring bank, the payment card industry generally, your shareholders and customers where the DSS standards are silent? The quick answer is, "don't move forward to fail, but don't fail to move forward." In other words, proceed—but proceed with caution.The PCI-DSS model imposes contractual obligations on merchants to meet a series of policy, procedural, technical and administrative security standards wrapped around the protection of cardholder data. The primary goal of all of these contractual requirements is to ensure that card data—principally card number, cardholder information and validation information—that could be used to facilitate either identity theft or credit card fraud remains confidential.

The security standards, if followed, have other laudatory consequences: they promote consumer acceptance of the payment card industry; they protect the reputation of the merchant; they protect the confidentiality of transaction information (what the consumer purchased); and they promote the integrity and availability of the payment card system (and those networks that make up or are attached to it). These rules are frequently perceived by merchants to be regulations, but they are, in fact, nothing more than a contractual obligation between the merchant and its acquiring bank—albeit a contract that does not allow for negotiation.

What the PCI-DSS rules do not do, or do not do very well, is to promote the adoption of new cutting-edge technologies. The rules are designed for what we know, and what we already do—a standalone or networked POS terminal in a brick-and-mortar store or attached to a Web-based online purchasing system that is connected to a conventional network. The problem for early adopters of new, innovative and potentially game-changing technologies is not that these technologies are not secure (they may be, they may not be). The problem is that they have not been assessed or evaluated for security. Thus, early adopters are proceeding on a high-wire, without the net that PCI compliance may provide.

Let's say you adopt one of these new mobile payment technologies and the technology has met the standards for PCI compliance. You invest heavily in the technology, its deployment, security, testing, training, integration, marketing, etc. Everything is up and running well, and you are at the leading edge. Competitors are drooling as your sales increase, costs decline and efficiencies increase. Indeed, because you have invested heavily in testing the new technology, you are convinced that it is secure—well, at least as secure as the technology it replaced.

But now you learn that the PCI Council has withdrawn approval of the new technology. Or at least given notice that, some time in the future, it intends to withdraw such approval. Usually these things take at least six months to a year. What do you do?

Do you immediately cease all operations, rip the wiring out and take a huge loss (oh, and fire the engineer whose bright idea it was to adopt the new technology)? Do you circle the wagons, get the lawyers involved and fight the PCI Council tooth and nail to reverse its decision? Most importantly, do you continue to use the technology that is, shall we say, marginally approved in the interim?The PCI-DSS rules require merchants to be in compliance. This means using compliant technologies in a complaint manner. Generally, compliant comports with reasonably secure. Many technologies associated with payment systems have never been tested and may never be tested for compliance, but they nonetheless make up a part of the overall chain of a payment card network.

If you fail to use a compliant technology, you run the risk of being in breach of the contract with your acquiring bank. In many cases, the non-compliant or, more frequently, the unevaluated technology may be safer than the compliant technology. Of course, if there is a data breach involving the non-compliant technology, you run the risk of liability for not only the breach costs themselves but fines under PCI-DSS.

The best way to avoid that liability is to avoid the data breach itself. Indeed, to a great extent, you should never make PCI-DSS compliance your goal. Securing card data is the goal. Compliance with PCI-DSS (and with the terms of the contract) may (and sometimes may not) be the consequence of being secure. Remember though, nothing you read online is legal advice, and your mileage may vary.

So, should you pull the plug on technology that has not been given the Good Housekeeping seal of approval by the PCI-DSS Council? My best advice is to keep using the technology if—and only if—you can demonstrate that it is reasonably secure (hardware and software testing, penetration testing, red-teaming, the whole megillah) and if you develop a plan B. And ready both the engineers and that team of lawyers for a fight.

The overall objective of PCI-DSS is to provide reasonable protection to the security of payment card information. Indeed, even if there were no contract, tort law would likely require a merchant, as the fiduciary of customer data, to provide such reasonable protection irrespective of the stated standard to meet. If there is no standard, because the PCI Council has not yet adopted one, then you should be able to do anything that reasonably protects the security of the data. If the council rejects something you have adopted, don't panic; a new technology will be just around the corner.

If you disagree with me, I'll see you in court, buddy. If you agree with me, however, I would love to hear from you.