New PCI DSS 3.2: What You Need to Know and Why Security Comes First

The Payment Card Industry Security Standards Council (PCI SSC) released version 3.2 of its payment card requirements recently as promised.  This release is arguably more significant for the way it is being introduced and the underlying message than for the changes themselves, which are few and have been recommended security best practices for some time.

With fewer changes in this release and a longer-than-usual runway for the changes to take effect, PCI Security Standards Council Chief Technology Officer Troy Leach said he believes the updated version gives organizations a chance to plan for and implement security processes that help militate against cyberattacks.

Approaching the PCI standard from a security perspective is the desired strategy and in fact, if you have been practicing a security-first, "business as usual" approach with your PCI compliance, you may have already considered implementing some of these changes.

On the other hand, maintaining a secure posture in the face of today's cyberthreats is never easy. The potentially devastating and unexpected nature of new threats is one of the reasons the PCI SSC cited for moving away from its previous three-year cycle for releasing updated versions. The council has even removed from the standard specific references to technologies being "strong" and "secured." As we learned with SSL vulnerabilities like Heartbleed, today's strong and secured technology is tomorrow's weak link.

Let us take a look at the highlights of PCI DSS 3.2 and their impact on you:

·         Key Dates

·         PCI DSS 3.2 is now available for PCI assessments, although you can continue to submit a PCI DSS 3.1 assessment until Oct. 31 of this year.

·         All new requirements within PCI DSS 3.2 have a longer grace period, taking effect Feb. 1, 2018.

·         Timelines for migration from SSL and TLS 1.0 remain as last communicated.

·         All service providers must provide a secure offering by June 2016

·         All entities must cease use of SSL and TLS 1.0 as a security control by June 30, 2018

·         Some point-of-sale (POS) or point-of-interaction (POI) terminals may be subject to exemption as described in Appendix A2

·         Additional PCI DSS Requirements for Entities using SSL/early TLS

What's New in 3.2 for the Enterprise?

Here are key new requirements in PCI DSS 3.2:

·         Requirement 3.3 updates specifications around displaying primary account numbers (PANs) to ensure that only the minimum numbers of digits are displayed as necessary to perform a specific business function.

·         Requirement 6.4.6, which goes into effect on Feb. 1, 2018, is designed to ensure that security controls are in place following changes to the cardholder data environment.

·         One of the more significant changes is focused on multifactor authentication in Requirement 8.3. It updates the language from "two-factor authentication" and expands the requirement from personnel with remote access to all personnel with non-console administrator access to card data and systems.

·         8.3.1, which goes into effect Feb. 1, 2018, requires an individual to present a minimum of two separate forms of authentication (such as a password, a smart card or a fingerprint) before access to the cardholder data environment is granted. This extra layer of authentication means that a password alone is not enough and provides additional assurance that the individual attempting to gain access is who they claim to be. With multifactor authentication, an attacker would need to compromise at least two different authentication mechanisms, which increases the difficulty of compromise and thus reduces the risk.

·         Authentication weaknesses leave systems highly vulnerable. The need for multifactor authentication and the risks of not employing it are so concerning that your organization should be moving as quickly as possible to implement it, regardless of the compliance requirement.

What else do you need to know?

>>Update Your SSL and TLS Communication Channels ASAP

One of the reasons the PCI council gave for releasing version 3.2 now instead of waiting until fall is to be clear about the extended deadlines for replacing SSL and TLS 1.0 protocols. Despite the 2018 deadline, you should move to replace these protocols as quickly as possible.

>>Evolving Requirements for Service Providers

New requirements for third-party service providers are focused on additional security best practices and their documentation, as well as penetration testing on segmentation controls at least every six months and quarterly reviews to confirm personnel are following security policies and operational procedures. Of the 12 core requirements of the PCI DSS, there are five new sub-requirements for service providers within requirements 3, 10, 11 and 12. These requirements (3.5.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1) are considered "best practices" until they go into effect on Feb. 1, 2018.

>>Best Practices for Implementing PCI DSS into "Business as Usual" Processes

PCI DSS 3.2 clarifies that some continuous "business-as-usual" controls may be requirements for certain entities, such as those defined in the Designated Entities Supplemental Validation (DESV) in Appendix A3. As the PCI DSS notes in relation to the new appendixes, including the DESV, "All organizations should consider implementing these best practices into their environment, even where the organization is not required to validate to them."

Get Help

You can reach out to Consultants to can help you complete your PCI DSS assessment or begin your preparation for PCI DSS 3.2. In either case, the changes announced in version 3.2 are security best practices that you should begin implementing regardless of the standard.

Written by Peter Ejiofor, CEO, Ethnos IT Solutions