PCI DSS, the Payment Card Industry Data Security Standard, is a set of standards that, more than many regulatory and compliance efforts, has real world relevance. PCI compliance can earn merchants tiered interchange rates and protection from fraud losses, while a lack of compliance can result in monthly fines of thousands or tens of thousands of dollars per month. Unlike some compliance efforts with relatively small penalties that are unlikely to be applied, PCI compliance has significant financial implications with a high probability of impact.
PCI DSS 2.0 is being released today. Earlier, we took a look ahead at some issues around PCI in a piece that you can read here.
So, now that we are on the cusp of a new set of standards, what’s new?
In short, not much. Think evolution more than revolution. While I am sure that there are security purists out there who are screaming and chewing on the carpet over this, the change is probably the right thing to do. The standards are relatively mature and while there is value in improvement there is also value in ensuring that those who have invested considerable time, money, and effort in compliance with previous versions of the standard do not suddenly find themselves out in the cold with 2.0.
That said, there are some genuinely useful clarifications. For example, coming back to virtualization, one of the challenges with Section 2.2.1 is that it called for one primary function per server but did not address virtualization. It was thus left to the individual judgement of the auditor or Qualified Security Assessor (QSA), whether or not multiple virtual machines running on a single piece of hardware counted as multiple distinct servers or because there was but a single piece of hardware if they counted as a single server. This made compliance a bit of a crapshoot. Sure, more reasonable QSA’s would likely view a virtual machine as a distinct system for these purposes, but it was not guaranteed. Clarifications made to Section 2.2.1 in PCI DSS 2.0 specifically state that “Where virtualization technologies are in use, implement only one primary function per virtual system component.”
On firewalls and DMZs, 1.3.5 goes from a somewhat unclear “Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.” to a far more clear “Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet,” which is a useful improvement.
Requirement 12 has been cleaned up, for example 12.3.10 previously read “When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.” and is now a far more pragmatic and reasonable “For personnel accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.”
6.5, the requirement to develop applications on secure coding guidelines, is enhanced by adding references to the SANS CWE Top 25 and CERT Secure Coding in addition to the OWASP reference already in place. These additions are pragmatic, real world additions which will help keep the standard relevant in the future.
There are a number of other changes, but most are clarifications or additional guidance much like the examples cited above. While some may have hoped for greater detail or more specific insertion of standards for encryption, tokenization, virtualization, and even things like the detection of wireless threats, taking a conservative approach is probably the right thing to do here. Some of these are relatively new or quickly evolving technologies and thus are subject to change. It would be unfortunate to unsuccessfully try to hit a moving target, even more so if in trying to do so the faith and trust of the customer were to be lost. The PCI Council has created Technical Working Groups (TWGs) and Special Interest Groups (SIGs) around these top-of-mind topics with additional guidance. Guidance for EMV and P2PE technology is now available, and additional guidance is to be released in November.
Long and short of it is that PCI DSS 2.0 will, in most respects, be better and more useful than PCI DSS 1.2.1. However, the differences are for the most part not that large but they are steps in the right direction. While not perfect, PCI DSS is and has been a useful framework and will be more practical and more relevant with the incremental enhancements in PCI DSS 2.0, which is a good thing because better security in the payment card industry will result in less fraud and in the end lower prices for consumers. For a parting note on this subject, remember that PCI Rocks.