17120318_sIn the nine years since the PCI DSS emerged as a consensus industry standard for the major credit card vendors, it has spawned an entire industry populated by security technology firms, auditors, consultants and service providers who promise to help firms comply with PCI DSS’s many requirements.

PCI DSS succeeded wildly in the job that it was initially intended to perform: setting the bar for data and network security at organizations that handled sensitive credit card information on behalf of customers. In some areas – such as the use of endpoint security, encryption and network monitoring technology - the effect of PCI DSS has been profound.

However, the success of PCI DSS in some areas highlighted others in which the standard had little to say or created perverse incentives—rewarding “compliance” over real security. Subsequent updates have attempted to right those wrongs.

This week, the Payment Card Industry Security Standards Council (PCI SSC) released a preview of changes that will be coming to its Data Security Standard (PCI DSS) and the companion Payment Application Data Security Standard (PA DSS). The 3.0 updates, due out in November 2013, are the first major update to the PA-DSS since Version 2.0 in January, 2012. They will raise the bar considerably on secure application development practices. That’s a good move – and one that is long overdue.

At a high level, Version 3 of the PCI DSS is intended to shift the focus of both the PCI DSS and the PA DSS from “compliance” (passing audits) to “security” (preventing breaches).

Most important: the PCI Council added guidance for organizations to maintain compliance as part of “business as usual” practices. That’s a key change intended to move organizations past the notion that PCI compliance is a once a year affair designed to satisfy auditors and then soon be forgotten.

Changes in the Version 3.0 update emphasis the importance of “education and awareness” – explaining the “why” of security controls rather than just the “what” and emphasizing the importance of proper implementation of those controls.

The Council also made changes designed to give PCI-bound organizations more flexibility in meeting the requirements of its data security standards. In many cases, proscribed methods or technologies (“full disk encryption” is one example) that had been written into the standards have been rewritten to allow for alternative methods and tools that achieve the same results.

When it comes to application security, the Council will change some key requirements of the PA-DSS, according to a preview document released by the PCI SSC. Among them:

  • Requirement 5: this requirement governs development of secure applications. In Version 3.0, it will include enhanced requirements for system (read that “application”) development processes. Most important: PA-DSS version 3.0 will mandate periodic security reviews and require application threat modeling techniques and step to verify the integrity and security of application source code before an application is released to customers.The list of common vulnerabilities that application publishers must test against will also be brought into alignment with the latest version of common vulnerabilities from groups like OWASP, NIST, SANS, and so on, to make sure that that PA-DSS is aligned with current and emerging threats.
  • Requirement 7: this governs application requirements and testing procedures. It has been updated to make it clear that vendors must include release notes with each application update to help merchants determine whether the version of an application that they’re using is on the PA-DSS list of approved applications.
  • Requirement 14: this is a new requirement for the PA-DSS that will require training of integrators, resellers and vendor personnel.

pci-guideThese may sound like minor changes but, as with most other changes to the PCI DSS standards, their impact will be felt far and wide. There are good reasons for this: PCI DSS applies to any organization that accepts or helps process credit card transactions. That means it impacts a wide swath of organizations in the U.S. and abroad. And, unlike many public sector efforts to mandate security, the Payment Card Industry has been explicit in its requirements and the consequences for non-compliance (monetary penalties or, possibly, a suspension of the right to accept credit cards. The standards are so universally recognized that one state, Texas, proposed using them for its own state data security laws.

The latest updates almost certainly won’t end the practice of insecure application development. Nor will they necessarily achieve the goal of thwarting successful attacks on payment applications. But Version 3 puts the PCI Council on record supporting better and more thorough application audits and testing, and that’s bound to pay dividends in the future.

Read more about PCI 3.0 here. (https://www.pcisecuritystandards.org/documents/DSS_and_PA-DSS_Change_Highlights.pdf)

About Paul Roberts

Paul Roberts is an experienced technology writer and editor that has spent the last decade covering hacking, cyber threats, and information technology security, including senior positions as a writer, editor and industry analyst. His work has appeared on NPR’s Marketplace Tech Report, The Boston Globe, Salon.com, Fortune Small Business, as well as ZDNet, Computerworld, InfoWorld, eWeek, CIO , CSO and ITWorld.com. He was, yes, a guest on The Oprah Show — but that’s a long story. You can follow Paul on Twitter here or visit his website The Security Ledger.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.