“SSL has been removed as an example of strong cryptography in the PCI DSS, and can no longer be used as a security control after June 30, 2016.”

Gary Glover, Director of Security Assessments
By: Gary Glover
The PCI DSS has released an unscheduled and important update to PCI DSS requirements: PCI 3.1. While it does include minor clarifications and additions, PCI version 3.1 was primarily released to address the insecurity of Secure Sockets Layer (SSL) and some Transport Layer Security (TLS) encryption protocols.

Still catching up changes from PCI 3.0? Check out our Ultimate Guide to PCI DSS 3.0.

Effective immediately, all SSL and early TLS versions are no longer considered to be strong cryptography.
PCI 3.1 SSL TLS
SSL and TLS encrypt the information sent between web browsers and web servers. Since the release of SSL v3, unfixable vulnerabilities were identified. You may have heard of some of these vulnerabilities in 2014, including FREAK, POODLE, and WinShock.

The point is, the PCI Council has deemed that SSL and early TLS will no longer protect cardholder data.
From April 15, 2015 on, merchants must not implement new technology that relies on SSL or early TLS (version 1.0 and sometimes 1.1, depending on use and implementation). Merchants already using systems and devices that utilize SSL and TLS must discontinue the use of those systems and devices before June 30, 2016.

The PCI DSS v3.1 requirements directly affected are:
  • Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons considered insecure.
  • Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
  • Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
SSL No Longer SecureEach of these requirements will have additional sub requirements or guidance provided in the new PCI DSS 3.1 version.

How will PCI 3.1 affect SecurityMetrics customers?

SecurityMetrics has been scanning for SSL vulnerabilities for over a decade. Specifically, we have been scanning for SSL version 3 vulnerabilities, such as the POODLE vulnerability, since October 2014.

  • SecurityMetrics vulnerability scans do not currently fail merchants using TLS 1.0, but this will happen before the June 30, 2016 deadline.
  • Merchants using SSL version 3 will fail their SecurityMetrics vulnerability scan(s). If there is a hardware or software limitation preventing you from disabling SSL 3.0 or TLS 1.0 and you would like to dispute these vulnerabilities found on your scans, you’ll need to submit documented confirmation that you have implemented a risk mitigation and migration plan, and are working to complete your migration by June 30, 2016. Please contact SecurityMetrics Support if you need to dispute a failing vulnerability.
Read the entire summary of changes from 3.0 to 3.1


What about HTTPS and ecommerce?

Because virtually all ecommerce websites have SSL/TLS enabled for their cryptography, they are at the highest risk from SSL/TLS vulnerabilities. New e-commerce websites must not use or support SSL/early TLS.

The PCI Council also stated that web browsers will begin prohibiting SSL connections in the near future, preventing users from accessing web servers that haven’t migrated to a more modern protocol.


What about my POS/POI terminal?

The PCI Council decided that Point of Sale (POS) or Point of Interaction (POI) devices that aren’t susceptible to all known exploits of SSL and early TLS may be used, even after June 30, 2016.

Merchants who continue using old POS or POI devices should understand that because SSL is outdated technology, it may be subject to future security vulnerabilities. The PCI Council recommends that POI environments update to TLS v1.1 or greater if possible.

How do I know if I’m using SSL/TLS?

SSL and TLS are widely used, so I recommend contacting your terminal providers, gateways, service providers, vendors, and acquiring bank to determine if the applications and devices you use have this encryption protocol. If you’re writing your own software, please check with your development department.

Examples of applications that likely use SSL/TLS
  • Virtual payment terminals
  • Back-office servers
  • Web/application servers

What if I’m using SSL/TLS?

The PCI Council offered great guidance on migrating from SSL and TLS, as well as examples and recommendations on how to deal with this requirement in their Migrating from SSL and Early TLS information supplement.

If you use SSL/TLS, but don’t need to:
If you have existing implementations of SSL and early TLS that you don’t need for regular business operations, immediately remove or discontinue all instances of SSL/TLS. Do not use any new technologies that use SSL/TLS.

If you use SSL/TLS, and need to continue using:
First, remember not to use any new technologies that use SSL/TLS. If you need to continue using SSL/TLS to continue regular business operations, here are some examples of what you can do to replace use of SSL/early TLS:
  • Upgrade to a current, secure version of TLS configured to not accept fallback to SSL or early TLS.
  • Encrypt data with strong cryptography before sending over SSL/early TLS (for example, use field-level or application-level encryption to encrypt the data prior to transmission)
  • Set up a strongly-encrypted session first (e.g. IPsec tunnel), then send data over SSL within the secure tunnel
  • Check firewall configurations to see if SSL can be blocked
  • Check all application and system patches are up to date
  • Check and monitor systems to ID suspicious activity that may indicate a security issue
Please note that organizations with existing implementations of SSL and early TLS must have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describes controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”

You will need to provide your Risk Mitigation and Migration Plan to your PCI assessor as part of the PCI DSS assessment process.

Learn more about the Risk Mitigation and Migration Plan in the PCI Council’s migrating from SSL and Early TLS information supplement.

Will more information about PCI 3.1 be revealed in the future?

More about PCI 3.1 (including new SAQs) will be revealed in the near future.

According to an email I received from the PCI Council, “Corresponding changes to PA-DSS are in progress, and PA-DSS 3.1 will be published shortly. Information on how PA-DSS submissions will be addressed will also be made available at that time.”

In the meantime, merchants have until June 30, 2016 to comply with PCI 3.1.

Need help discontinuing the use of SSL/TLS? Contact our PCI support team.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.

Current Hacking Trends Ebook

3 comments:

  1. Cutting out TLS 1.0 support pretty much cuts out every IE browser before IE 11. This includes Windows 7 and 8. Everything before IE 11 either doesn't support TLS 1.0 or doesn't have it enabled by default.

    Do you have any idea how many users there are out there that have no idea how to enable such an option? IE 8, 9 and 10 comprise of 30% of the market. So to disable a cipher that either isn't even avail in a browser or isn't even enable by default is pretty absurd.

    ReplyDelete
    Replies
    1. 30% of the market will upgrade very quickly when much of the internet no longer works in their ancient browsers.

      Delete
    2. Andrew, I wouldn't be so sure. Anyone who is still running an XP machine will have IE 8. Also, the real issue is mostly large corporations that don't update browsers due to legacy support

      Delete