Governance & Risk Management , Risk Assessments

PCI Update Gets Mixed Reviews

Wait-and-See Experts Say 'The Devil is in the Details'
PCI Update Gets Mixed Reviews
Glaringly lacking, or a positive first step? Both terms have been used to describe the newly-released summary of proposed changes to the Payment Card Industry Data Security Standard.

Although the full draft of the proposal won't be released until mid-September, some payments and security experts call the PCI Security Standard Council's summary "a letdown."

"There's nothing earth shattering, and most of the 'hard work' that many are waiting for is still not done, and is being left to the special interest groups to figure out," says Avivah Litan, a security analyst for the Gartner Group.

The 'hard work' includes: understanding the linkage between PCI compliance requirements and implementations of Chip cards (as opposed to magnetic stripe), tokenization, or point-to-point encryption, and how these rollouts can potentially limit the scope and requirements of PCI audits, Litan says.

"These [groups] are not being held to any particular deadlines, and it's still unclear how their reports will fold into PCI requirements, but word has it that they are aiming to finish their work by the end of 2010," she says. These reports will result in further guidance, rather than clear-cut requirements - "a somewhat justifiable position since there are still no industry standards for tokenization or point-to-point encryption," Litan notes.

Until industry standards are developed for emerging technologies, the standard's revisions appear to be a "positive step" Litan says. "But since the devil is in the still-unpublished details, it's too early to know how positive a step they really are."

Early Returns

According to Bob Russo, general manager of the PCI Security Standards Council, the proposed PCI changes offer "no big surprise" to impacted parties. There are no new requirements - just clarifications and some additional guidance. Some of which will be open to interpretation, observers say.

"The overview of the changes is helpful for us to understand where the council is moving, but most of the change will be driven by interpretation of intent," says Branden Williams, Director of the Security Consulting Practice at RSA, the security division of EMC. On the surface, a significant amount of the change is adjusting the wording to reflect the actual intent of the requirements. This is increasingly important, Williams says, especially in areas that are seeing increased drive and focus on compliance. "As new QSAs are brought up, the changes will help make up for limited nuances that experience will eventually yield."

The centralized logging requirement for PA DSS is very interesting, Williams says, "and may signify a lack of attention to detail by QSAs assessing companies that deploy products capable of complying with PA DSS."

The summary of changes includes clarification that the card issuers or processors are allowed to store sensitive authentication data because of their legitimate business needs. What's glaringly absent however, Litan says, is any enforcement or deadlines for PCI compliance at issuers or their processors.

"While the PCI standards council is not responsible for actually enforcing PCI (the card brands are)," Litan says, "this particular clarification highlights the unequal treatment across the card food chain, as all of the enforcement attention and deadlines are placed on the merchants, merchant acquirers, merchant processors and other card-accepting organizations - with no corresponding enforcement efforts or deadlines on the card-issuing side."

More Change Needed

There's one section in the standard that is more important than any other, says Tom Wills, security and fraud senior analyst at Javelin Strategy and Research. Requirement 6.2 - "apply a risk-based approach for addressing vulnerabilities" - needs to become the over-arching requirement in the entire standard, he says. "This would mean all security controls should be based on carefully assessed risk, and not on following a checklist."

Security that's based on actual risk, not on rote compliance, is the only effective strategy to control against financial losses that result from compromised data. Wills wants to see the PCI council take section 6.2 from the middle of the document and put it in a headline position, with every other requirement rolling up to that. "That would send a clear message to the PCI stakeholders that security does not equal compliance, and that putting security first is what we need."

While there are mild and incremental improvements to the PCI standards with the upcoming release, more has to be done, Litan says. "What is glaringly lacking is progress on the hard and most important issues, including the implications of adopting alternative technologies (e.g. tokenization, chip cards, point-to-point encryption), and getting the card issuers to do their part in upgrading card security."

The three-year cycle of standards revision by the PCI Security Standards Council may look slow, Will says. But glacial progress by standards bodies is par for the course because standards development is a process of compromise and consensus. "The PCI standards council is no exception," he says. "Chip, encryption and tokenization absolutely need to be addressed, but they will be studied, debated and polished first. That all takes many months."

But even with unanswered questions, there are no excuses for sloppy security measures, Wills warns. "Nobody should rely on compliance alone, be it with PCI or any other standard, to secure their information systems," he says. "The correct approach is to perform ongoing risk assessments and apply security controls on that basis."

About the Author

Linda McGlasson

Linda McGlasson

Managing Editor

Linda McGlasson is a seasoned writer and editor with 20 years of experience in writing for corporations, business publications and newspapers. She has worked in the Financial Services industry for more than 12 years. Most recently Linda headed information security awareness and training and the Computer Incident Response Team for Securities Industry Automation Corporation (SIAC), a subsidiary of the NYSE Group (NYX). As part of her role she developed infosec policy, developed new awareness testing and led the company's incident response team. In the last two years she's been involved with the Financial Services Information Sharing Analysis Center (FS-ISAC), editing its quarterly member newsletter and identifying speakers for member meetings.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing, you agree to our use of cookies.