Security: Changing the ‘Checkbox’ Mindset

Jim Daly

With PCI 3.0, the PCI Council hopes merchants will come to regard data security as “business as usual” rather than just an annoying annual ritual.

Here are just a few of the things you’ll find in the new Version 3.0 of the Payment Card Industry data-security standard (PCI): Revised rules for better management of passwords, prevention of point-of-sale terminal tampering, and more involvement by third-party vendors in assuring that merchants’ payment systems are secure.

What you won’t find are sweeping rules governing mobile payments, which some in the data-protection business think the PCI Security Standards Council ought to issue.

In all, the initial reaction to the new rules governing how merchants, merchant acquirers and other payment processors, and vendors should safely handle general-purpose credit and debit card data is about what you’d expect. There’s stuff to like and dislike. It all depends on your point of view.

Released Nov. 7 after months of input from merchants, processors, technology suppliers, and others, Version 3.0 is the first revision of the rules under the three-year upgrade cycle the PCI Council adopted after it issued Version 2.0 in 2010.

On its surface, Version 3.0 looks much the same as 2.0. It still has 12 main requirements governing everything from computer systems to who in a company should have access to sensitive cardholder information in order to prevent data breaches. There are 242 sub-requirements, though some old ones have been consolidated and some new ones added.

‘User Friendly’

Some of the new rules 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. The Wakefield Mass.-based council also updated the Payment Application data-security standard (PA-DSS), the companion set of rules to the main PCI standard covering card-processing software.

The PCI Council hopes Version 3.0 will spur many merchants to shed their “check-box” mentality in which they are concerned with data security only when it’s time for the required annual PCI audit.

“The main focus is to try and make security and PCI business as usual so people get used to doing this,” says PCI Council general manager Robert Russo. “The approach we’re taking is making it as user-friendly as we can.”

The document mentions “business as usual” several times, though there is no formal rule mandating conformity with such an amorphous concept. Still, the new emphasis is finding favor in some quarters.

“For those of us that are in the security-consulting world, the thing we like about it is they’re really talking about security,” says Chris Bucolo, senior manager at Alpharetta, Ga.-based ControlScan Inc., which provides PCI services. “I see a real concerted effort to match up the requirements with the breach data.”

Adds Karisse Hendrick, program manager, Americas, for the Merchant Risk Council, a Seattle-based organization of nearly 400 mostly large e-commerce merchants: “I think they’re really trying to update them to be adaptive to new technologies, to keep up with the times.”

Hendrick cites as an example of an improvement a requirement that cardholder data flows be diagrammed. “That’s something we already encourage for various reasons,” she says.

Branden R. Williams, executive vice president of strategy at Ireland-based security-services provider SysNet Global Solutions, which has operations in the U.S., agrees that diagramming so that merchants understand where cardholder information goes is a good but overdue addition. “I don’t understand how you do PCI without it,” he says.

Some of the biggest changes involve passwords, which have proven to be more vulnerable than once assumed, and related identification issues. Version 2.0 had outlawed default passwords, a common source of data breaches, but Version 3.0 forbids vendors from 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 multiple breaches, says Troy Leach, the PCI Council’s chief technology officer.

“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.

‘A Weak Link’

While large merchants typically have in-house data-security expertise, small merchants usually rely on their acquirers or third-party technology vendors for security. But the PCI Council says 63% of investigations identifying a security deficiency easily exploited by hackers revealed that a third party was responsible for system support, development, or maintenance.

“Service providers are a weak link,” says Greg Rosenberg, security engineer at Chicago-based Trustwave Holdings Inc., a provider of PCI services and data-breach investigations.

The rules contain new language about when a vendor whose equipment or software is linked to a merchant’s payment system is responsible for protecting card data.

“There already was language, but we’ve beefed it up,” says Leach.

In fact, the rules (Requirement 12.9) for the first time tell service providers to “acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer …” the text reads.

“This one I like quite a bit,” says Rosenberg. “A lot of issues we do see are policy and control and provider agreements.”

Other revisions cover so-called penetration testing and validation segmentation. These topics address when data are or are not “in scope,” or subject to the PCI rules.

“What we were seeing in these breaches, especially large processor breaches … is the potential that the scope was not properly established to begin with,” says Leach.

But some new requirements could add to merchants’ compliance burdens. For example, revised sub-requirement 9.9 tells merchants to check point-of-sale terminals for tampering. SysNet’s Williams says that although the motive behind the requirement is good, merchants, especially large ones, might be in for a lot of new work in carrying it out.

“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.

Some observers take issue less with specific rules and more with general matters involving PCI. Trustwave’s Rosenberg says the primary stakeholders giving input into PCI rule development are large merchants or those working for them, and small merchants have less of a voice.

“I think in many cases smaller merchants get left out of the conversation, but they account for the majority of people using the standard,” he says.

Williams adds that the rules are replete with fuzzy words such as “should” and “periodic.” “One of the jobs was to reduce ambiguity,” he says.

Leach acknowledges that the PCI 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 addressing mobile payments, which many in the security industry expected by now—especially since so many new card-accepting merchants are using their own smart phones or tablet computers for taking transactions rather than purpose-built payment terminals.

The PCI Council has issued guidance documents about mobile payments, but is not validating software applications as compliant with its rules.

“There is not that [much] information around mobile,” says Rodolphe Simonetti, managing director of Verizon Payment Card Industry Services, a unit of New York City-based Verizon Communications Inc. “I guess the council wants to be very general, to be aligned with all those documents.”

The council currently is approaching mobile as another payment technology governed by its 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.”

Like many others in the payment industry, the PCI Council is grappling with the many issues created by the “bring-your-own-device” phenomenon. The council is working with several other technology organizations that are dealing with similar problems in hopes of finding some common solutions, says Leach.

“The challenge,” he says, “is when you introduce equipment that was designed with the consumer in mind, not for taking financial transactions, to have the same level of integrity and trust that we’ve had for decades in accepting payment card data through point-of-sale terminals.”