PCI DSS 3.1 expires October 31st this year. But don’t panic. If you don’t have a migration plan for 3.2, yet, you have until Feb 1, 2018 before the requirements become mandatory. For most merchants, the changes are not onerous. If you are a service provider, however, there are more substantial changes, some of which are already in effect. In this post we focus on the requirements for merchants, and present a quick overview of the required changes so that you can identify any gaps you may still need to remediate.
The main changes in PCI DSS 3.2 are around authentication, encryption, and other minor clarifications. We will primarily discuss authentication and encryption in this article.
The PCI council review of data breaches over the years has confirmed that current authentication methods are not sufficient to mitigate the risk of cardholder data breaches. Even though cardholder data is maintained on specific network segments, it is nearly impossible to prevent a data breach if the authentication mechanisms are vulnerable as well. Specifically, the reliance on passwords, challenge questions, etc. only, has been proven to be a weakness in the overall security of cardholder networks.
The new 3.2 requirements now state that multi-factor authentication (MFA) is required for all individual, administrative, non-console, or remote access to the cardholder data environment. The new standard is clear. Multi-factor means at least two of the following:
- Something you know, such as a password or passphrase
- Something you have, such as a token device or smart card
- Something you are, such as a biometric
Multi-factor does not mean a password and a set of challenge questions, or two passwords.
Implementing such multifactor authentication takes time and planning as there are almost 200 different types of multifactor solutions on the market.
Multifactor authentication is also complex because:
- It likely needs to integrate with your single sign-on solution
- Not all IT systems can support the same types of MFA, especially cloud solutions
- MFA resets are more complex (especially if a dongle is lost)
- Most MFA solutions require rollout and management consoles on top of your built-in authentication
In recent years, SSL, the workhorse for securing e-commerce and credit card transactions, has been through the ringer. From shellshock, heartbleed, and poodle to the Man-in-the-Middle AES CBC padding attack reported this May, SSL, openSSL, and all the derivative implementations that have branched from openSSL have been experiencing one high severity vulnerability after another. [SIDEBAR: A list of all vulnerabilities in openSSL can be found here: List of OpenSSL Vulnerabilities, other SSL vulnerabilities can be found on the vendors websites or at the National Vulnerability Database.] Of particular concern are SSL vulnerabilities in Point of Sale solutions and other embedded devices as those systems may be harder to upgrade and patch than general-purpose computers. In response, the PCI council has issued guidance on the use of SSL.
The simplest approach to achieve PCI DSS 3.2 compliance is not to use SSL, or early versions of TLS, period. [SIDEBAR TLS - Transport Layer Security is the name of the IETF RFC that was the follow on to SSL]. In fact, any version of TLS prior to 1.2 and all versions of SSL 1.0-3.0 are considered insufficiently secure to protect cardholder data. As a merchant, you may still use these older versions if you have a plan in place to migrate by June 2018, and a risk mitigation plan to compensate for the risks of using such older versions. Risk mitigation plans might include, for example, additional breach detection controls, or documented patches for all known vulnerabilities, or carefully selecting cipher suites to ensure no weak ciphers are permitted, or all of the above. If you have a Point of Sale or Point of Interaction system that does not have any known vulnerabilities, you may run these systems using older versions of SSL/TLS. The PCI council reserves the right to change guidance if new vulnerabilities associated with a particular POS or POI become known which jeopardize the cardholder environment.
If you are concerned about the risk to your e-commerce or mobile environment with upgrading your SSL to TLS 1.2 or higher, you can ask your online marketing department what the oldest versions of iOS, Android™, Windows® and Mac® are that connect to your systems. Android has supported TLS 1.2 since version 4.1, although it is not enabled by default. As of version 4.4, Kitkat, released Oct. 2013, TLS 1.2 has been enabled by default. iOS 5, has supported TLS 1.2 since Oct. 2011. Windows 8 is the first Microsoft OS to support TLS 1.2 by default. Prior to that, you needed to manually configure TLS 1.2 support. A complete TLS table for Windows is available here: TLS version support. For Mac OS® you need to reach Mavericks, (Oct. 2013) to find a Mac computer with TLS 1.2 enabled by default.
If all this versioning seems daunting, not to worry. Most modern browsers, which auto- upgrade, have been supporting TLS 1.2 for a long time. The net/net is most organizations have nothing to fear with upgrading their secure communications layer to TLS 1.2.
There are some additional nuances regarding the correct cipher suites to use to meet PCI DSS 3.2 requirements, which we will cover in a future post on using managed file transfer in cardholder environments.
If you are a PCI pro, you now have a good overview of the major changes coming in PCI DSS 3.2. Note that we didn’t address the additional changes a service provider needs to comply with, nor did we walk though all 12 requirements of PCI DSS and how they apply to IT organizations. For some of that, you should check out the Simplifying PCI Compliance for IT Professionals White Paper.
Questions about PCI DSS?
If you have questions regarding the latest version of PCI DSS, or what’s generally required from an IT perspective to maintain compliance, we urge you to join in the conversation on THWACK!
 Requirement 8.3
 Requirement 8.2
 PCI DSS 3.2 Appendix 2