What You Need to Know about the New PCI Standard

In April 2015, the Payment Card Industry Security Standards Council (PCI SSC) released PCI Data Security Standard (PCI DSS) version 3.2, the latest update of the widely accepted policies and procedures governing the security of credit, debit and cash card transactions and protecting cardholders from the misuse of personal information. This version becomes the official standard on November 1, 2016.

As with every prior release, version 3.2 includes many minor clarifications and clerical changes. But there are also some significant changes for which new processes or additional technologies will need to be deployed. And while some of the requirements of the new standard won’t become effective until 2018, these changes may take months or years to implement, so many organizations could find themselves out of compliance for an extended period, due to the complexity and detail of the work required.

Major Changes

These are changes affecting all merchants, for which new processes or additional technologies may need to be deployed:

#1: Multi-factor authentication

(The term “multi-factor authentication” replaces “two-factor authentication.”) Effective immediately, multi-factor authentication (MFA) must be used for all remote access (originating from outside the organization’s network), including users, administrators and third parties. Effective February 1, 2018, multi-factor authentication will be required for all administrative access to the cardholder data environment (CDE), even when connecting from an internal corporate network. Additionally, because many organizations were using internal MFA as a compensating control for other gaps, once MFA becomes a requirement, it is no longer “above and beyond” the standard and therefore doesn’t meet the requirements of a compensating control – thus, a new compensating control will need to be put in place. The latter requirement is the one that may be the most disruptive.

#2: File-integrity monitoring (FIM)

PCI DSS 3.2 removes the phrase “within the cardholder data environment” from the security systems and process testing requirement (11.5.a.). This is a significant change for organizations that do not have FIM or other change-detection solutions deployed on all systems connected to the cardholder environment — point-of-sale or administrative workstations, for example.

#3: Change management

This is an area in which many organizations have had difficulty properly implementing a process and successfully documenting changes. The new requirement (6.4.6) adds steps to existing change management controls. Organizations are now required to verify and document all PCI DSS requirements affected by the change and to verify that they are still being met.

Changes for Service Providers

The following requirements suggest that the PCI Security Standards Council (PCI SSC) is placing an increased emphasis on service provider data controls and compliance — a shift consistent with the trend toward third-party, cloud-based financial technology (fintech). Service providers will need to assess these changes and remediate any gaps.

#4: Security controls monitoring

Service providers are required to monitor and report on failures of critical security systems. Specific failures may vary according to the function of the device or technology in use. Typical failures might include a system ceasing to perform its security function or not functioning in its intended manner; for example, a firewall erasing all its rules or going offline.

Incident response/problem management processes need to be updated as applicable. Critical systems include, but are not limited to:

• Firewalls
• Intrusion detection/intrusion prevention
• FIM
• Anti-virus
• Physical access controls
• Logical access controls
• Audit-logging mechanisms
• Segmentation controls (if used)

In addition, the following processes need to be added to the incident response/problem management program:

• Restoring security functions
• Identifying and documenting the duration (date and time, start to end) of the security failure
• Identifying and documenting the cause(s) of failure, including the root cause, and documenting remediation required to address the root cause
• Identifying and addressing any security issues that arose during the failure
• Performing a risk assessment to determine whether further actions are required as a result of the security failure
• Implementing controls to prevent the cause of failure from reoccurring
• Resuming monitoring of security controls

#5: Executive management responsibility

Service providers are now required to assign PCI compliance responsibility to a C-level executive, board member or individual of comparable authority. While service providers were previously required to have a designated executive sign the attestation of compliance (AOC), version 3.2 formally documents the responsibility.

#6: Operational reviews

Service providers are required to perform quarterly reviews of operational processes. These include but are not limited to:

• Daily log reviews
• Firewall rule set reviews
• Application of configuration standards to new systems
• Response to security alerts
• Change management processes

#7: Penetration testing

Service providers are now required to test segmentation controls (if segmentation is used to reduce scope) at least every six months, compared to at least annually in v3.1.

#8: Cryptographic architecture

Service providers are required to create a documented description of the cryptographic architecture used in the CDE. This document must include details of all algorithms, protocols and keys used for the protection of cardholder data, including key strength and expiration date; a description of the usage for each key; and an inventory of any hardware security modules and other secure cryptographic devices used for key management.

Other notable items

Migration from the now-vulnerable Secure Socket Layer (SSL) and early Transport Layer Security (TLS), to a more secure cryptographic encryption cipher has been an area of increasing priority over the past few years. Most organizations should have completed, or at least begun, the process by now. The PCI SSC released a bulletin on this in December 2015, extending the migration cutoff date to June 30, 2018 (previously June 30, 2016). This update is reflected in PCI DSS v3.2.

Also, effective immediately, online merchants who are redirecting customers to third-party payment pages will become subject to a handful of existing PCI DSS controls addressing the potential for vulnerabilities and fraud on the merchant side of the redirect process — including the ability for hackers to change the redirect and capture credit card data. These requirements were already part of the standard but were not previously applicable to merchants using hosted payment pages.

For these merchants, six controls, drawn from PCI DSS Requirement 2 (changing default passwords and implementing an incident response plan) and Requirement 8 (unique user ID and strong password, disabling access for terminated users and not using group or shared passwords) will be added to the Self-Assessment Questionnaire A, which must be completed annually. As controls go, these are pretty light duty — certainly much lighter than the hundreds of controls required of merchants that collect and hold card data. They are easy to address, and they are things merchants should probably already be doing.

Key Dates and Deadlines

 PCI DSS v3.1 was retired on October 31, 2016.

Seven changes have an effective date of February 1, 2018. These changes impact the following requirements:

• 3.5.1 – Documenting cryptographic architecture
• 6.4.6 – Assessment of PCI DSS requirements impacted by each change
• 8.3.1 – Multi-factor authentication for all access to CDE
• 10.8, 10.8.1 – Detecting and reporting failures in critical security control systems
• 11.3.4.1 – Penetration testing segmentation controls at least every six months
• 12.4 – Executive management responsibility for protecting cardholder data
• 12.11, 12.11.1 – Quarterly reviews of operational processes

Migrating from SSL and early TLS has been pushed to June 30, 2018 although service providers must already offer TLS 1.2 or higher as an option for customers. Newly certified payment applications (under the PCI PA 3.1 or higher standard) cannot use SSL or early TLS.

Finally, organizations should review the summary of changes, downloadable from pcisecuritystandards.org, determine which changes will affect them, conduct a gap analysis and begin developing a remediation plan for compliance. Be on the lookout for any controls that have increased in frequency or controls that now have frequency requirements, as such items are easy to miss.