PCI DSS version 3.1 will be retired on October 31, 2016, with version 3.2 being the only valid version beginning the 1st of November. From that date, any new validation of PCI compliance will have to be against version 3.2. The new requirements will, however, be considered ‘best practices’ until Feb. 1, 2018 when they will be mandatory.
One of the most important requirements is completion of the migration from SSL and early TLS to the more secure later versions of TLS. Alexander Norell, EMEA director at Trustwave’s Global Compliance and Risk Services, told SecurityWeek that this is designed to mitigate against increasing man-in-the-middle attacks against e-commerce. If an attacker gets access to a merchant, then POODLE or BEAST can gain access to the session.
Norell thinks this migration will be a particular problem for the small merchant that contracts out the entire payment process. Such companies will be accustomed to thinking the service provider is responsible for security; but while you can contract out the process, you cannot contract out the responsibility. Small merchants will still need to take reasonable steps to ensure that their providers are complying with the new regulations; even if their current contracts don’t allow for provider audits.
The SSL migration was originally introduced in PCI 3.1. However, large service providers with thousands of international customers with different SSL and TLS configurations had problems meeting the deadline. The PCI Security Standards Council (PCI SSC), the body that defines PCI DSS, took a decision to extend the deadline by re-introducing the requirement into version 3.2 — effectively pushing the deadline back until February 2018. The PCI Security Standards Council (PCI SSC, which defines the standard) stresses, however, that this should not be seen as an invitation to delay action: SSL and early TLS are vulnerable and continuing to rely on them invites a breach.
SSL migration is not, however, the only new requirement — and since some of these (particularly around multi-factor authentication and penetration testing) will require planning and budgetary approval, it is important to get the ball rolling as soon as possible. Jeremy King, International Director at PCI SSC, suggests that moving to a multi-factor administrator access (MFA) requirement could be time-consuming.
“From Feb 2018,” said King, “administrators must have MFA whenever they access the card data environment. That is quite a significant change. So companies need to read 3.2, understand the impacts, and where necessary get the budgets in place.” One difficulty for large organizations will be locating all administrator accounts and ensuring that all have the new MFA credentials.
Zhang Wanqiao, a Chinese researcher from Qihoo 360, demonstrated at the recent Ruxcon Security Conference that any dedicated attacker could intercept calls and text on any 4G LTE network anywhere in the world. It’s not a new vulnerability, but the exploitation is easier than previously thought. “The phone situation gets challenging with the increase in mobile commerce,” said King. “It’s difficult to say that a transaction conducted on a mobile phone that receives a soft token to the same phone is really multi-factor because it’s all on the same device. If somebody steals or highjacks that phone, they’re getting everything.”
This implies that MFA admin access must not allow the second factor to be delivered to the same device — which is the position taken by NIST in its recent MFA proposals. This does not mean that phone-based SMS authentication is completely ruled out. “If you conduct the transaction from a laptop, and you send the token to a separate phone or other device, then that’s a genuine second factor,” explained King.
PCI DSS 3.2 is not the only major standard coming into force in early 2018 — GDPR will also be required by spring 2018. Both are designed to improve security — one for card and cardholder details, and the other for European personally identifiable information. There is clearly an overlap; but there is a big difference in the way the two standards are phrased. GDPR describes its requirements by what must be achieved; PCI DSS explains how achievement is expected. There is much more hands-on guidance in PCI DSS.
“People come to me and say, ‘How do I achieve GDPR compliance?'” commented King. His reply is to say, “Start with PCI DSS.” Any company that fully and successfully implements PCI DSS 3.2 is likely to be fully GDPR compliant — it’s a case of buy one and get one free.