New PCI Council Rules Call for More Extensive Testing of Card-Accepting Devices

More testing and documentation for payment card-accepting devices that process personal identification numbers are the order of the day under newly revised requirements from the PCI Security Standards Council.

The revisions, dubbed Version 4.0 of the PIN Transaction Security (PTS) Point-of-Interaction (POI) requirements, are the first of three major updates on tap this year from the Wakefield, Mass.-based PCI Council. In October, the Council is expected to release updates to the main Payment Card Industry data-security standard (PCI) and the Payment Application data-security standard (PA-DSS), which governs payment card software.

The PTS standards are the third major set of rules that the PCI Council administers. The POI rules are a subset of them and address security issues on devices that accept PINs. Compliance with the POI rules is a must for point-of-sale terminal makers, value-added resellers, manufacturers of card swipes for mobile devices, and related suppliers since PCI Council certification of their products is required before they can be used to process general-purpose payment card transactions. At the same time, hackers constantly probe card-accepting devices for weaknesses through which they can steal data.

“Certainly the devices are still a target out there for everybody,” says PCI Council general manager Bob Russo.

The new version 4.0 of the POI standards has several major changes from the current version 3.1, including a revised “open protocols” section. Those requirements are meant to ensure that PIN-entry devices using open security protocols and open communication protocols to access public networks and services do not have vulnerabilities that hackers could exploit, according to Russo. In addition, the revised rules address communications issues with such devices that may not involve payment data but could expose such data.

Laboratories that test the devices will be getting more work because the revised rules will require more testing of the open-source software that runs or works in tandem with card-accepting hardware. “They’re using much more open source for execution of the transaction,” says Troy Leach, the Council’s chief technology officer. “There’s been a shift away from proprietary code. He adds that there is “good and bad” in that trend.

The good is that open-source code makes it easier for developers to differentiate their products, and it also brings more people into the vetting process. Still, proprietary code usually is harder for criminals to crack.

The new rules also have “expanded the expectations around the documents that the vendors will provide to the labs,” says Leach. “It will provide more realistic views of the environments in which the vendor anticipates their product will be implemented.”

Labs, not too surprisingly, are gearing up to do more tests. Leach says some labs claim they’ll need 25% more time to evaluate products under the new standard than they do under version 3.1.

Vendors, meanwhile, will be required to provide security policies for their end-user customers under the new standard. These policies must address how to use and install a product in a secure manner, the hope being that such guidance will prevent errors that could compromise card data.

The Council will hold a Webinar at 2:00 p.m. Eastern time Thursday, June 20 to discuss the changes.

n

n