PCI 3.1: What is New

For those businesses that have to be PCI compliant, another important PCI DSS date happened on July 1, 2015. Before we get into what this date entails, let us back up a bit. The Payment Card Industry Data Security Standard (PCI DSS) is an open information security standard for organizations that handle branded credit cards. It is run by the Payment Card Industry Security Standards Council. PCI standards apply to every organization that touches credit card information, such as merchants, banks and other financial institutions. PCI DSS 3.0 went into effect January 1 of this year, to help combat crippling data breaches and the ever-increasing sophistication of attacks. PCI DSS 3.0 included some phased requirements, which became mandatory on July 1, 2015.

PCI31squarePhased Requirements:

PCI DSS version 3.0 was officially retired on June 30, 2015, with version 3.1 effective from April 2015. While PCI 3.1 includes minor clarifications and additions, PCI version 3.1 was primarily released to address known vulnerabilities with addressing security concerns related to the Secure Sockets Layer (SSL) protocol and early Transport Layer Security (TLS) protocol, also known as “poodle/ beast” attacks. This revision states that SSL and early versions of the TLS protocol are no longer considered examples of strong cryptography and put payment data at risk. The move by the Security Standards Council follows the National Institute of Standards and Technology (NIST) identifying SSL as not being acceptable for data protection purposes due to “inherent weaknesses.”

Effective immediately, new implementations must not use SSL or early TLS. Existing implementations that use SSL and/or early TLS must have a formal risk mitigation and migration plan in place. Companies have until June 30, 2016, to update to a more recent version of TLS.  For a complete overview of all the changes, the PCI council provides a summary of changes from PCI DSS v3.0 to PCI DSS v3.1.

“The fact that the PCI Security Standards Council saw fit to release an out-of-band update underscores the threat recent SSL and TLS vulnerabilities pose to payment security,” said Brendan Rizzo, technical director, HP Security Voltage. “Companies must begin planning now in order to make sure that they do not overrun this liberal transitional period. If companies do not start to formalize a plan for appropriate security upgrades right away, any breach that they might incur could result in tough questions being asked and, ultimately, in significant reputational damage – even if it occurs before the PCI Council’s implementation deadline.”

The Difference Between Compliance and Validation

“It is important to know the difference between compliance and validation,” says Matt Getzelman, PCI Practice Director at Coalfire Systems, an independent IT Audit and Compliance firm. In a recent webinar, Understanding Security Tokenization and PCI Compliance, Matt addresses the vulnerabilities that can put payment data at risk.

“Compliance,” Matt continues in the webinar, “means that all organizations must adhere to the entire PCI DSS standard, regardless of size or number of transactions processed.” Validation is done once a year on an anniversary date, to validate your compliance, and is separate from being compliant. “You are expected to be compliant at all times regardless of your validation date. Organizations with any PCI DSS obligations must meet all the applicable standards now, regardless of their validation deadline,” counsels Matt. Therefore, if your validation date is any time after July 1, you are still required to meet all the standards that went into effect with 3.1 by July 10th.

Is Compliance Enough

Complying with the PCI DSS standards is a good start for securing cardholder data that is stored, processed and/or transmitted by merchants and other organizations. However, it is not enough. Gaps exist between systems and applications that are highly vulnerable to attack. Just because a company follows all the PCI DSS standards does not mean that the data is secure. Standards organizations are slow to develop these standards, which can quickly become outdated, and they are not comprehensive. Many organizations recently suffering major data breaches had complied with the then-current PCI DSS standards, yet still suffered massive theft of sensitive data.

Best Practices for Protecting Data

Sensitive data must be protected at rest, in use, and in motion. The best way to do this is to use a data-centric security approach using format-preserving encryption and tokenization technologies.  For end-to-end data security and PCI compliance, encrypt credit card and e-commerce transactions data from card swipe or browser entry through pre-authorization processes, and tokenize PAN data so that post-authorization back-end systems use tokens—surrogate values—instead of live data.

Tokenization is a method for protecting payment card data by substituting a card’s Primary Account Number (PAN) with a surrogate value. The HP Secure Stateless Tokenization (HP SST) solution is an advanced, patented data security technology that uses a set of static, pre-generated tables containing random numbers created using a FIPS random number generator. These static tables reside on vir­tual “appliances” – commodity servers – and are used to consistently produce a unique, random token for each clear text Primary Account Number (PAN) input, resulting in a token that has no relationship to the original PAN. No token database is required with HP SST technology, thus improving the speed, scalability, security and manageability of the tokenization process.

“The biggest benefit with tokenization is that it helps merchants remove payment card numbers from systems that don’t need it,” says Terence Spies, Chief Technologist at HP Security Voltage. Because HP SST technology preserves the data format and can selectively preserve sub-fields (such as the last 4 digits of your credit card), back-end business applications can operate on the tokenized data and no live credit card data needs to be stored in the merchant environment at all. This means every back-end application handling the tokenized data, including systems such as fraud analysis and loyalty programs, may be removed from PCI scope, enabling PCI compliance with greatly reduced management and compliance costs.


Find out more about HP Secure Stateless Tokenization, with HP SecureData Payments and HP SecureData Web, for a complete payments data protection solution that accelerates compliance initiatives, reduces PCI DSS audit scope, and supports best practices.

Leave a Reply

Your email address will not be published. Required fields are marked *