PCI SSC Announces the End of SSL Usage for the Payment Card Industry

The Payment Card Industry Security Standards Council (PCI SSC) released a special bulletin on February 13, 2015 announcing impending revisions to the Payment Card Industry Data Security Standard (PCI DSS) (Version 3.1 was published on April 15, 2015) as well as the Payment Application Data Security Standard (PA-DSS) (Version 3.1 was released in May 2015). The stated purpose of this bulletin is to inform the payment card industry that the PCI SSC has determined that the Secure Sockets Layer (SSL) protocol is no longer an acceptable solution for the protection of data based on the PCI SSC’s definition of “strong cryptography.”

In addition to publicaction of PCI DSS Version 3.1 on April 15^th, 2015 official guidance was issued to  Approved Scanning Vendors (ASVs), which states that effective immediately, existing implementations that use SSL and/or early versions for TLS must have a documented formal risk mitigation and migration in place. Entities shall be required to present their ASV documentation to be included under “Exceptions, False Positives, or Compensating Controls.” This is in effect until June 30, 2018, where after this date, “entities that have not completely migrated away from SSL/early TLS will need to follow the Addressing Vulnerabilities with Compensating Controls process.”

The PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms v3.0 provides the following definition for strong cryptography:

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices.

The PCI SSC basically follows the guidelines for cryptographic algorithms, key-strength, and key management from the National Institute of Standards and Technology (NIST) set forth in a series of Special Publications. In particular, NIST SP 800-52: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (Revision 1) which prohibits the use of TLS 1.0, SSL 2.0, and SSL 3.0 to protect Federal information because of the reliance on cryptographic algorithms that are not approved.

How does this impact PCI DSS?

The PCI DSS has a long standing practice of listing examples of acceptable or preferred security protocols in those requirements that call for the use of strong cryptography – and SSL has always been on the list. The following requirements which currently reference SSL and/or strong cryptography are the most likely impacted:

1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

Impact: The use of services, ports, or protocols associated with SSL will fall under scrutiny. Organizations will likely be required to demonstrate or prove that SSL is not enabled for any of these services or protocols over the known ports.

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, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Impact: The reference to SSL was dropped in this requirement. Organizations will have to demonstrate or prove that SSLv2,SSLv3, and "early TLS" (effectively TLSv1.0) is not available for use with any of the services, protocols, or daemons used in to, within, or out of the cardholder data environment. PCI DSS v3.1 makes this effective immediately, but is allowing a grace period until June 30, 2018 for remediation of existing implementations. New implementations may not have SSLv2, SSLv3, or early TLS (TLSv1.0) enabled.

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

Impact: The most likely impact here is the use of web-based interfaces for administrative access to servers, databases, or network devices. As expected, PCI DSS v3.1 dropped the SSL reference from this requirement.

4.1 Use strong cryptography and security protocols (for example, SSL/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.

[Guidance Note that some protocol implementations (such as SSL v2.0, SSH v1.0 and TLS 1.0) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection. For example, TLS v1.1, or later, certificates obtained from a recognized, public certificate authority and supporting only strong encryption, may be considered.]

4.1.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit.

4.1.g For SSL/TLS implementations, examine system configurations to verify that SSL/TLS is enabled whenever cardholder data is transmitted or received.

Impact: All transmissions of cardholder data such as web server traffic or secure file transfers will no longer be able to use SSLv2,SSLv3, or early TLS which for now is effectively TLSv1.0. In addition, any internal solutions such as secure communications from Point of Sale (POS) systems to payment switches should no longer be allowed to use SSLv2, SSLv3, or early TLS (TLSv1.0). However, PCI DSS v3.1 acknowledges that certain POS and POI implementations may be allowed as long as it can be demonstrated that they are not susceptible to exploitation and attack. This special exception will even exceed the June 30, 2018 grace period.

4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

• Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.
• Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.

Impact: All transmissions of cardholder data over wireless networks such as web server traffic or secure file transfers will no longer be able to use SSLv2, SSLv3, or early TLS (TLSv1.0). In addition, any internal solutions such as secure communications from Point of Sale (POS) systems to payment switches over wireless networks will no longer be allowed to use SSLv2, SSLv3 or early TLS (TLSv1.0).

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Impact: Use of SSLv2, SSLv3,  or early TLS (TLSv1.0) for end-user messaging technologies will be prohibited.

6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Impact: Software developers will be expected to prevent the use of SSLv2, SSLv3, or early TLS in their code. This must be called out in software development policies and procedures documentation.

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

8.2.1.a Examine vendor documentation and system configuration settings to verify that passwords are protected with strong cryptography during transmission and storage.

Impact: The use of SSLv2,SSLv3, or early TLS will not be allowed for any remote login or authentication mechanisms for any systems within the cardholder data environment.

How will this affect vulnerability scanning?

The use of strong cryptography is not explicitly mentioned in PCI DSS 11.2 with regards to periodic vulnerability scanning, but the impact is an “automatic failure” for scans that detect the presence or usage of SSLv2, SSLv3 and early TLS (TLSv1.0). Note that the grace period is extended to scan findings, particularly for external vulnerability scans performed by an ASV. While the detection of these protocols must be flagged as failure immediately, scan customers may submit a remediation or migration plan as an exception until the end of the grace period on June 30, 2018.

11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

Impact: The outcome here is that internal vulnerability scans that detect the presence or use of SSLv2, SSLv3, or early TLS (TLSv1.0) will report a finding that needs to be remediated or mitigated in a manner consistent with other “high risk” vulnerabilities (PCI DSS 6.1). The grace period until June 30, 2018 will apply here, so that a remediation plan will be an acceptable exception.

11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

Impact: The use of SSLv2, SSLv3, or early TLS (TLSv1.0) will be declared an “automatic failure” according to the PCI DSS Approved Scanning Vendors Program Guide which previously stated: “A component must be considered non-compliant and marked as an automatic failure by the ASV if it supports SSL version 2.0 or older OR if SSL v3.0/TLS v1.0 with 128-bit encryption is supported in conjunction with SSL v2.0 (due to the risk of ‘forced downgrade’ attacks described to the left).” An exception documentation process shall be in place until June 30, 2018 to demonstrate the presence of a mitigation and remediation plan.

How Tenable can help

Tenable Network Security already provides comprehensive detection capabilities, thanks to recent vulnerabilities such as Heartbleed and POODLE. In anticipation of, and as a result of, the release of PCI DSS v3.1 and PA DSS v3.1, Tenable offers several dashboards and plugins.

SecurityCenter dashboards

There are several relevant dashboards and reports that are available to users of SecurityCenter Continuous Monitoring™ (SecurityCenter CV™); here are just a few that will help identify web applications and deployments of SSL.

SSL Discovery (PCI DSS v3.1) - Tenable has a new custom dashboard which provides a thorough detection of SSLv2 or SSLv3 by incorporating Nessus, PVS™, and LCE™ findings into one view. SecurityCenter CV users can continuously monitor their enterprise networks to identify and track the remediation of all instances of SSLv2 and SSLv3.

Web Services Indicator Dashboard - This dashboard is a collection of components that provide quick visual indications of web service vulnerabilities from several aspects, including TCP port, the SSL certificate, and URLs within a web page.

OWASP Top 10 - Web application security is a key concern for SecurityCenter users. The software security community created the Open Web Application Security Project (OWASP) to help educate developers and security professionals. This dashboard provides SecurityCenter users the ability to monitor web application security by identifying the top 10 most critical web application security flaws as described in OWASP's Top Ten awareness document.

OpenSSL ChangeCipherSpec - As new threats emerge in networks, SecurityCenter customers are able to properly identify risk. This dashboard contains four components, three of which focus on the six CVEs related to the OpenSSL ChangeCipherSpec vulnerability. The remaining component focuses on OpenSSL vulnerabilities.

Where is the POODLE? - Encrypting communications is a key part of network security, and SSL is a key component for securing data in motion. SecurityCenter CV is able to identify vulnerable systems before vendors issue patches, by viewing scan data and event logs. The latest SSL vulnerability is called POODLE, aka Padding Oracle On Downloaded Legacy Encryption. While the vulnerability has a colorful name, do not let the severity fool you. The systems and users that are the most at risk are the ones that use captive portal pages in published hot spots, where Man-in-the-Middle (MitM) attacks are the most prevalent. This attack vector allows an attacker to extract data from secure HTTP connections. This could allow the attacker to do things such as access online banking or e-mail systems.

Nessus plugins

Tenable has updated Nessus® plugin 20007 which may be used to detect the presence of SSLv2 or SSLv3. Use this plugin for internal or external scans, particularly in and around your cardholder data environment.

Tenable also provides Nessus® plugin 56984 which may be used to detect all versions of SSL and TLS that are supported by any remote services. Use this plugin for internal or external scans, particularly in and around your cardholder data environment.

ASV attestation

Tenable will begin immediately to list the usage of SSL V2, SSL V3 and early versions of TLS (TLSv1.0) as a PCI “failure.” Documentation which demonstrates the presence of a risk mitigation and migration plan are in place shall be required to be submitted as evidence for findings which are listed as a failure.

Resources

To learn more about Tenable’s solutions, consult the following Tenable resources.

• PCI Security page
• PCI Discussion forum
• SecurityCenter Dashboards
• Nessus Plugins

This blog will be updated as events occur and when PCI DSS v3.1 and PA DSS v3.1 are released.

Updated January 13, 2016.