The PCI Council Unveils Its ‘User-Friendly’ Version 3.0 of the PCI Security Rules

Better management of passwords and prevention of point-of-sale terminal tampering are just two features of the new Version 3.0 of the Payment Card Industry data-security standard that the PCI Security Standards Council unveiled Thursday.

On its surface, Version 3.0 looks much the same as the previous edition, 2.0, which the Wakefield Mass.-based PCI Council introduced in 2010. It’s still got 12 main requirements governing everything from computer systems to who in a company should have access to sensitive payment card data. And there are still more than 200 sub-requirements, though some old ones have been consolidated and some new ones added.

The Council, which administers PCI and its affiliated standards, also updated the Payment Application data-security standard (PA-DSS), the companion set of rules to the main PCI standard covering card-processing software.

Some of the new sub-requirements in the PCI rulebook are significant enough that they won’t take effect until July 2015 even though the main rules become official Jan. 1 and mandatory a year later. But the Council has delayed implementation of bigger changes before in order to give merchants and processors time to prepare for them, notes general manager Robert Russo. According to Russo and the Council’s chief technology officer, Troy Leach, the goal is to make the revised rules as palatable as possible for those who have to abide by them—any merchant or processor that processes, transmits or stores general-purpose payment card data.

“The main focus is to try and make security and PCI business as usual so people get used to doing this,” Russo tells Digital Transactions News. “The approach we’re taking is making it as user-friendly as we can.”

Several changes involve Requirement 8, which addresses identification of system users and passwords. Version 2.0 had outlawed default passwords, a common source of data breaches, but Version 3.0 forbids using a single password that could give a hacker access to more than one merchant’s system. Common passwords used by security vendors and obtained by hackers have led to breaches, says Leach. “We’ve gone the next step and we’ve required that service providers not only use unique passwords, but they use unique passwords for each and every customer,” he says.

The changes are generating both praise and trepidation by security professionals who work with merchants and payment card processors to prevent data breaches. “I see a real concerted effort to match up the requirements with the breach data,” says Chris Bucolo, senior manager of security consulting at Alpharetta, Ga.-based ControlScan Inc., which provides a range of PCI and related services.

But others wonder just how burdensome some of the new requirements might be. For example, revised sub-requirement 9.9 requires merchants to check point-of-sale terminals for tampering. Branden R. Williams, executive vice president of strategy at Ireland-based security-services provider SysNet Global Solutions, which has operations in the U.S., hadn’t seen the final draft of Version 3.0 when he spoke to Digital Transactions News earlier this week, but he said an earlier draft indicated that merchants, especially large ones, might be in for a lot of new work. “I think that’s going to be the biggest headache for merchants,” he says.

Leach, however, says terminal monitoring will not be onerous. Since PCI-compliant terminals have internal tamper-prevention technology, the revised rules will ask merchants to take pictures of their terminals, know cable connections and sticker placements, and in general be familiar enough with the devices on the outside to know if tampering has occurred. “What we’re looking for here is common-sense business checks,” he says.

Williams also says the rule set is replete with fuzzy words such as “should” and “periodic.” “One of the jobs was to reduce ambiguity,” he says.

Leach acknowledges that the Council received many complaints about vague terms such as “periodic” as it drafted Version 3.0 and tried to remove as many as possible. But he says wording is a balancing act since some people in the security business, such as risk managers, want as much flexibility as possible while others, such as Qualified Security Assessors (QSAs), who do inspections, want very specific terminology. “We are sensitive to those that want to have a clear-cut process,” he says. “The only challenge for me is that security is qualitative, not quantitative.”

Version 3.0 does not have sweeping new rules to address the still-small but fast-growing sector of mobile payments, which many in the security industry expected the PCI Council to have produced by now. Instead, the Council is approaching mobile as another payment technology that will be governed by the main rules.

“We’ve always tried to remain, with these particular standards, technology-agnostic to the best of our ability,” says Leach. “You won’t see anything specific [regarding mobile] within the DSS standard, but that is very intentional because that is a higher-level standard that should apply to mobile, cloud computing, virtual servers, any type of new technology. We hope that the standards are written in a way that can address the new types of form factors.”

Version 3.0 can be downloaded through this link.