The next version of card data security standard PCI DSS could land as soon as next month, replacing the expected November release as the only update in 2016, according to the PCI Security Standards Council (SSC).
The council’s CTO, Troy Leach, explained that the standard is moving towards a system of smaller, more incremental modifications to address things like the EMV roll-out in the US, rather than larger, wholesale updates.
“When making changes to the standard, in addition to market feedback, we look closely at the threat landscape, and specifically what we are seeing in breach forensics reports as the trending attacks causing compromises,” he argued.
“With this in mind, for 3.2 we are evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.”
Leach was at pains to point out that any updates will still be succeeded by a sunrise period prior to them taking effect in order to let complying organizations complete their assessments and validate the new requirements.
Changes to PA-DSS are also planned and will be published in the month following the release of PCI DSS 3.2, he added.
“It is a healthy practice for any company to regularly evaluate how it accepts payments and whether it can reduce the risk to its customers and its organization by changing business practices for cardholder data exposure; evaluating newer payment technology like tokenization and encryption; and confirming its third party service providers understand the importance of the upcoming changes as well,” Leach concluded.
“The revision of PCI DSS is as good a time as any to re-evaluate how to minimize effort while improving security posture.”
The PCI SSC has released guidance for firms looking to address migration from SSL/early TLS here.
SOURCE: Phil Muncaster