PCI DSS 3.2 – Are You Up on What’s Changed?

By Smrithi Konanur —
January 19, 2017

The Payment Card Industry Security Standards Council (PCI SSC) has published a new version of the industry standard of requirements to protect sensitive payment cardholder data as it flows through different payment ecosystem applications. Any company that processes, stores, or enables payment transactions through any channel have to follow these requirements to ensure the security of sensitive customer information and prevent security breaches. The PCI Council periodically updates these standards not only to ensure they continue to protect against old exploits that are still causing problems, but also to addresses new exploits, as well as provide greater clarity for implementing and maintaining PCI DSS controls.

The previous version – PCI DSS 3.1 – expired on October 30, 2016; however, the PCI Council has provided some time for organizations to implement the new version 3.2, which will become mandatory on February 1, 2018. Be aware, though, that the PCI Council advises that companies should still try to adopt the new changes as soon as possible to prevent, detect and respond to cyberattacks that can lead to breaches.

Detailed differences based on the previous version (PCI DSS 3.1) have been published by the PCI Council. Here is a quick summary based on my analysis:

Much more stringent processes have been specified in this version for Service Providers which have also been listed in a separate section – PCI DSS Supplemental Designated Entities Validation (DESV). New requirements for Service Providers, such as the need to detect and report on failures of critical security control systems and perform penetration testing on segmentation controls for at least six months. These requirements emphasize the importance of frequency in the testing of security controls.

Service Providers are also required to maintain a documented description of the cryptographic architecture and key management controls. Maintenance of change control processes that include the verification of PCI DSS requirements.

Multi-factor authentication required for accessing the cardholder data environment – which is already in place for remote access – has been extended to include local access.

Reinforcement of SSL/early TLS migration and timeline for the migration has been extended to June 30, 2018, which is the timeframe when migration to TLS is mandated.

Rules around displaying card numbers and guidance on common masking scenarios.

How do these changes apply to our payments solution? From our product perspective, there are not many changes since our cryptographic operations already follow the rules around card number masking. We have also migrated HPE SecureData appliance access to TLS 1.2 and enabled the ability to remove older SSL protocols to meet this requirement from the PCI Council.

Compliance Does Not Equal Security
Security requirements in PCI DSS require basic protection of card data, but meeting compliance does not protect a company from breach risks. Given today’s advanced threat landscape, organizations need to look beyond basic compliance to more contemporary, data-centric defense strategies to secure all personal and sensitive data including credit card details. Otherwise it is highly likely there will eventually be another breach at the expense of the customer. The good news is data-centric security can be implemented quickly with much more attractive economics than dealing with the cost of a breach, even in e-commerce ecosystems.

The first assessment was to identify the potential impact to the number of PCI DSS 3.2 controls applicable to merchants using encryption solutions based on HPE SecureData Payments. The second assessment was on the HPE SecureData Mobile solution and the particular requirements it addresses within PCI DSS 3.2 scope. The third assessment describes the HPE SecureData Web solution and the particular requirements it addresses within PCI DSS 3.2 scope.