The Skinny on PCI 3.0 Compliance Changes

Earlier this month the PCI Security Standards Council (PCI SSC) released drafts of version three of the PCI DSS and PA-DSS which includes six new requirements that are to be considered best practices until they officially become compliance requirements in mid-2015.

The six new requirements cover:

6.5.6 – Insecure handling of PAN and SAD in memory

6.5.11 – Broken authentication and session management

8.5.1 – Unique authentication credentials for Service providers with access to customer environments

9.9 – Protecting of point-of-sale (POS) devices from tampering

11.3 – Developing and implementing a methodology for penetration testing

12.9 – Additional requirement for service providers on data security

To gain better insight into some of the changes PCI DSS 3.0 has in store, we reached out to Jeff Hall, a senior security consultant and qualified security assessor (QSA) with FishNet Security. Hall has over 30 years of information technology and security experience, and is also the QSA behind the PCI Guru blog.

Hall provided some intriguing feedback on most of the new requirements listed, but decided it best to hold off on discussing the others for now until he has had more time to review their possible implications.

“I am not going to discuss 6.5.6 until I have a better understanding of how the PCI SSC expects QSAs to test that memory is being managed properly,” Hall said. “And I am avoiding 11.3 altogether because it is enough for an entire article of its own. But the others can be addressed now.”

Hall said he was somewhat amazed at first that some of these issues actually had to be codified at all because they are thoroughly addressed through a number of other requirements. “But having run into numerous instances where I have encountered these situations, I understand why the PCI SSC felt the need to explicitly codify them,” he said.

For requirement 6.5.11, the guidance provided states that “secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.”

Hall said this requirement is focused on issues surrounding botnets and Trojan attacks, such as we have seen with malware like Citadel and Zeus.

“The problem here is that these are attacks on the end user, not the merchant. As a result, what this new requirement is going to likely be looking for is to require the merchant to use methods to secure authentication and communications such that man-in-the-middle, man-in-the-browser and similar attacks are minimized or even eliminated,” Hall stated. “It will be interesting to see how the PCI SSC expects this to be accomplished.”

As for requirement 8.5.1, which calls for service providers with access to customer environments to use a unique authentication credentials for each unique customer environment, Hall says this is long overdue.

“Most QSAs have encountered this situation and we never like it when managed service providers and software vendors use the same authentication credentials for all of their customers,” Hall said. “While one can appreciate why this occurs, it does create a problem should those common credentials become known outside of the organization which has been the case in a number of breaches.”

Hall says that requirement 9.9 was developed to explicitly address a best practice that has been implemented by a large number of merchants – taking measure to prevent POS devices from being tampered with or substituted with a corrupt unit.

“A number of merchants have experienced the tampering of card terminals over the years, typically in the form of soldering a USB thumb drive or SD card into the terminal to collect data, and then replacing a good terminal with the doctored terminal at the point of sale,” Hall explained.

“This threat is typically mitigated by video monitoring of terminals as well as the use of serialized security tape or tamper-evident seals over a terminal’s case seams that should be checked at least daily to ensure that terminals have not been changed out or tampered with.”

Given that security in other aspects of the PCI data chain have improved significantly, there has been a corresponding increase in the number of POS-oriented attacks against merchants, and so Hall believes that more vigilance in this matter is definitely in order.

And finally, requirement 12.9 stipulates that service providers explicitly acknowledge in a document that they will maintain compliance with the PCI DSS for all relevant services.

“Apparently the existing requirements in 12.8 were not providing enough assurance that service providers were complying with the PCI DSS,” Hall pointed out. “So now we are going to require that all service providers acknowledge in writing that they will maintain compliance with all relevant PCI DSS requirements for all services provided to their customers.”

Hopefully the assurances provided will be worth more than the paper they are printed on.