Changes in PCI DSS Version 3.1: What You Need to Know

PCI DSS Blog Are you up to date with the new PCI DSS version 3.1?

Maybe you thought the race was over. The finish line was in sight. Compliance was in your grasp. But the race goes on. The rules have changed. The finish line has moved ahead of you.

The PCI Security Standards Council released an unscheduled update to its requirements on April 15, 2015. Effective immediately, the new guidelines forbid the use of SSL and TLS 1.0 encryption protocols to protect cardholder data.

The council made these changes in response to several vulnerability disclosures, including the POODLE exploit, which can allow a man-in-the-middle attacker to decrypt messages on SSL 3.0.

Since POODLE cannot be fixed, the PCI Council branded SSL and TLS 1.0 as “vulnerable protocols” in the new version of its security standard.

But that’s not all that’s changed. Below we’ll provide an overview of the changes in PCI DSS 3.1 and what you can do about them.

Major changes in PCI DSS version 3.1

PCI DSS 3.1 is almost identical to its predecessor except for the following. You will have to meet these requirements to maintain PCI compliance:

SSL and early TLS are no longer considered strong cryptography and cannot be used as a security control after June 30, 2016.

Prior to June 30, 2016, all existing implementations of the vulnerable protocols must have a formal Risk Mitigation and Migration Plan in place (more about this in a moment).

New technology implementations must not use SSL or early TLS.

POS/POI terminals that can be verified as not susceptible to known exploits for SSL and early TLS can continue using these protocols.

Minor terminology adjustments were also made to help clarify some PCI DSS requirements. For example, in the section on applicability information, “financial institutions” was changed to “acquirers, issuers.”

A full summary of the changes can be found on the PCI Council website.

PCI DSS requirements affected

The three requirements most affected by these changes:

Requirement 2.2.3 - Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, filesharing, Telnet, FTP, etc.

Requirement 2.3 - Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access.

Requirement 4.1 - Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following: only trusted keys and certificates are accepted; the protocol in use only supports secure versions or configurations; the encryption strength is appropriate for the encryption methodology in use.

What is a risk mitigation and migration plan?

If your business currently uses a vulnerable protocol to protect cardholder data, then you must submit a risk mitigation and migration plan as part of the PCI DSS assessment process.

The document should outline your company’s plan to transition away from the vulnerable protocols. It should also list the steps you will take to reduce the risks surrounding SSL and early versions of TLS until the migration is complete.

According to the PCI Council, a sound risk a mitigation and migration plan should include descriptions of:

How the vulnerable protocols are used and the type of payment channels they’re used in
The data transmitted with the protocols
The number and types of systems using the protocols
Risk assessment results
Risk reduction controls, such as configuring firewalls to permit SSL/early TSL only to known IP addresses
Any implementations that monitor for new vulnerabilities in SSL and TSL v1.0
Changes to control processes that ensure SSL and TSL v1.0 are not implemented into new environments
Overview of the migration plan project and a description of what systems are being migrated to secure protocols

The migration must be completed no later than June 30^th, 2016.

You can learn more in the PCI Council’s document on migrating from SSL and early TLS.

What these changes mean for your business

Simply put -- any POS/POI implementations that rely on SSL or early TSL need to be upgraded or reconfigured to support only secure protocols.

Additionally, all implementations need to be configured so they cannot fallback to the vulnerable protocols.

If you’re currently using a POI/POS implementation that relies on any vulnerable protocols, the PCI Council recommends immediately upgrading to use TLS v1.1 at a minimum. However, it strongly suggest new implementations to use TSL v1.2.

How do I know if I’m using a vulnerable protocol?

If you’re not sure whether or not you’re using an implementation that relies on SSL or early TLS, the PCI Council recommends contacting your software and hardware vendors.

Your vendors will be able to tell whether or not your system is up to date with the new standards, and will be able to provide you with the necessary steps for reconfiguration or upgrading to secure implementations.

Additionally, any system that uses Windows XP or versions of Internet Explorer older than IE 6.0 is a red flag for vulnerable protocol.

The vulnerabilities of SSL and TSL v1.0 pose a serious threat to your business and your customers’ sensitive information, which is why it’s in your best interest to upgrade to secure protocol as soon as possible.