In 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:
These 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)