PCI Council Tweaks Rules to Clarify Issues Like Scope of Assessment

The PCI Security Standards Council on Thursday gave a sneak peek at planned changes in the Payment Card Industry data-security standard, or PCI. While a Council document outlines 15 planned changes, the proposals are “relatively minor,” according to a news release.

“The No. 1 thing again is greater clarity on the existing requirements,” PCI Council general manager Robert Russo tells Digital Transactions News.

The Council is in the final stages of upgrading PCI version 1.2 in the run-up to so-called community meetings in North America and Europe in September and October with merchants, processors, and others with a stake in the sweeping rules for keeping credit and debit card data safe. If needed, last-minute changes based on feedback from those meetings will be incorporated before the new version, dubbed 2.0, takes effect in January. The Council also is working on an upgrade to the related but separate rules governing payment card software applications, or PA-DSS.

A big part of the main PCI upgrade involves improving the so-called scope of assessment, which means the rules will clarify that all locations and flows of cardholder data should be identified and documented. Doing so is supposed to ensure that all of the pertinent computer and related systems that touch cardholder data comply with PCI to protect them from hackers or other sources of compromise. “We’re going to reinforce the need to carry out some sort of scoping exercise before the [PCI] assessment,” says Russo.

Much of the feedback from the Council’s participating organizations, which include merchants, banks, processors, qualified security assessors (QSAs), technology vendors, and others, on what changes should be made to version 1.2 involves scoping issues, according to Russo. Companies are finding card data “in places we never thought it would be,” he says. For example, QSAs at times have found card data in the inventory-management and human resources sections of segmented company computer networks where the payment card section is supposedly walled off from everything else.

In a related measure, the new rules will update the requirement that vulnerabilities in a card-processing system be ranked and prioritized according to risk. Asked if that means a merchant that didn’t meet just one of the PCI standard’s 200-plus specific rules could be validated as PCI-compliant during an annual assessment if that particular issue was of low risk, Russo says “possibly.” “The QSA could deem it needs to be fixed … possibly give them a pass with the understanding it needs to be done,” he says.

Another planned change would align the PA-DSS’s Requirement 4.4 with Requirement 10.5.3 of the main PCI rule set, which says that card-processing software must have a centralized logging system. Logging systems, which can have more than one location, track usage of the application and play an important role in determining exactly what happened in the event of a data breach. Still another is a clarification to eliminate redundancy and expand examples of developing payment applications using secure software-coding standards. PCI Requirement 6.5 current refers only to OWASP, or Open Web Application Security Project Guide, but there are others such as CWE (Common Weakness Enumeration) and CERT.

About 400 of the PCI Council’s approximately 540 participating organizations have submitted comments, and many commentators submitted multiple suggestions, according to Russo. The PCI Council has already said it will extend the time for releasing new versions of the main PCI standard and the PA-DSS to three years from the current two (Digital Transactions News, June 22).

A document giving more detailed descriptions the planned changes can be found at https://www.pcisecuritystandards.org/index.shtml.