Will PCI DSS 3.2 Make Payments More Secure?

The latest iteration of the payment standard, which includes multifactor authentication, made its debut, but some security experts don't think it goes far enough.

WEBINAR:
On-Demand

Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

~~Watch~~→

The latest iteration of the Payment Card Industry Data Security Standard—PCI DSS 3.2—adds new requirements and clarifies others.

PCI DSS is a compliance specification that is typically a requirement for any organization that handles payments, including online and traditional brick-and-mortar retailers.

Among the biggest changes in the PCI DSS 3.2 standard—the successor to the PCI DSS 3.1 standard announced in April 2015—is the wider applicability for requirement 8.3, which details the use of multifactor authentication. The PCI DSS 3.0 standard, released in November 2013, required the use of multifactor authentication only for remote network access. With the PCI DSS 3.2 standard, all personnel with non-console administrative access to the cardholder data environment are required to have multifactor authentication.

"Previously, this requirement applied only to remote access from untrusted networks," PCI Security Standards Council CTO Troy Leach said in a statement. "A password alone should not be enough to verify the administrator's identity and grant access to sensitive information."

The expanded requirement for multifactor authentication is a good thing for payment card security, said John Bambenek, threat intelligence analyst at Fidelis Cybersecurity. "Doing two-factor authentication for all access will be time-consuming, but straightforward, in my opinion," Bambenek told eWEEK. "For those organizations that have to do penetration tests that will mean dedicating more time and, likely, more money."

Beyond the expanded use of multifactor authentication, PCI DSS 3.2 also adds focus on making sure that organizations stay compliant after they change things in their IT environment. In PCI DSS 3.2, the 6.4.6 requirement is a new control that requires organizations to make sure that change control processes include verification of PCI DSS requirements, which could be affected by a change. The basic idea is to help organizations avoid falling out of PCI DSS compliance as a result of a change.

For organizations moving from PCI DSS 3.1 to PCI DSS 3.2, the biggest challenge will be the internal overhead and increased costs they will incur to be compliant to the new standard, said Brian NeSmith, CEO at network security startup Arctic Wolf Networks. "The standard requires more frequent testing and assessments, and this only benefits the PCI compliance-services vendors," NeSmith told eWEEK. "It does not remove the burden of figuring out what method or device to use to ensure continuous security between the compliance tests and assessments."

With the volume of high-profile retail breaches in recent years, PCI DSS doesn't exactly have a spectacular track record in the eyes of many in the security community.

"Every company that has been spectacularly hacked in the last three years has been PCI-compliant. Sony, Target, Anthem, pick your favorite," Mark Longworth, CEO of mobile security startup Shevirah, told eWEEK.

Fidelis' Bambenek noted that compliance-driven security often doesn't move anywhere near as fast as the risks. The gap between compliance and actual risks is also a real concern for NeSmith. Overall, the new PCI DSS 3.2 standard misses the mark by focusing on detecting and reporting security control failures rather than protecting against threat detection use cases, he said.

"If a thief gets into your house through an unlocked door, adding another lock on the door doesn't make you safer," NeSmith said. "What you really need to do is make sure to lock the door, but if you forget, you need to be able to detect the break-in and make sure the police show up before the thief gets away."

Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.