SSL is Dead: What to do for PCI DSS Compliance

PCI SSC bulletin on impending revisions to PCI DSS, PA-DSS has created turmoil in payment industry. PCI SSC has announced that they will be bringing newer version of PCI DSS v3.1 and PA DSS v3.1 and Secure Socket Layers (SSL) v3.0 protocol will be treated as no longer acceptable for protection of data due to inherent weaknesses within the protocol.

PCI SSC has announced to release the new version of standards in April 2015.

Why SSL is dead:

What is wrong in SSL version 3.0 that PCI SSC has to announce it dead?
(Please note that only SSL version 3.0 and above was allowed as per PCI DSS)

The National Institute of Standards and Technology (NIST) has declared Secure Socket Layers (SSL) v3.0 protocol not secure for protection of data due to inherent weaknesses within the protocol and because of the same, no version of SSL meets PCI SSC’s definition of “strong cryptography”.

So SSL version 3.0 was all secure throughout these years?

While weaknesses were identified in SSL 3.0 earlier too, it was still considered secure until POODLE vulnerability came to light.  POODLE (“Padding Oracle on Downgraded Legacy Encryption”), SSL 3.0 is quickly becoming unacceptable. Where Heartbleed was a vulnerability in OpenSSL, POODLE is a vulnerability in the SSL 3.0 protocol itself, so it’s not something that can be fixed with a software patch.

Risk to payment card data and other sensitive data i.e. password

The objective of implementing SSL was to ensure data in transmission can be secured from interception and confidentiality and integrity of data can be protected. But due to SSL flaws card data and other sensitive data i.e. password can be compromised.

PCI DSS Requirements 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.

Effect:
– The use of services, ports, or protocols associated with SSL need to be reviewed.
– Entity will required to prove that SSL is not enabled for any of these services or protocols.

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

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.

Effect:
– The reference to SSL will be removed in this requirement. Entity will probably have to prove that SSL v3 is not available for use with any of the services, protocols, or daemons used in PCI DSS scope.

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.

Effect:
– The most likely impact here is the use of web-based interfaces for administrative access to servers, databases, or network devices must be over TLS v1.2.

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.

Effect:
– Usage of SSL will be terminated and only TLS v1.2 and above will be acceptable for transmitting Cardholder data.

4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.)

Effect:
– Secure Mail communication need to be reviewed to ensure no mail communication is over SSL and only TLS v1.2 or above is being used.

6.5.4 Insecure communications.

Effect:
– Application code need to be reviewed to ensure no communication is over SSL and only TLS v1.2 or above is being used.

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
• Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Effect:
– Application WAF and Web PT result will demonstrate SSL v3 as red flag, In case of Web Application Firewall need to reconfigure and Web PT finding need to be fixed to ensure clean Web PT report.

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

Effect:
– The use of SSL v3 will not be accepted for any remote login or authentication mechanisms for any systems within the PCI DSS scope.

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.

Effect:
– The internal vulnerability scans that detect the presence or use of SSL v3 will report a finding that needs to be remediated or mitigated in a manner consistent with other “high risk” vulnerabilities.

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.

Effect:
– The use of SSL v3 will be declared an “automatic failure” according to the PCI DSS Approved Scanning Vendors Program.

11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.

Effect:
– The use of SSl v3 will cause failure in Application and network layer Internal and External Penetration Test.

12.2 Implement a risk-assessment process that:

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
• Identifies critical assets, threats, and vulnerabilities, and Results in a formal risk assessment

Effect:
– The Risk Assessment exercise must identify usage of SSL as high vulnerability.

Solution:

The successor protocol to SSL is TLS (Transport Layer Security) and its most current version as of this publication is TLS v1.2.

TLS v1.2 currently meets the PCI SSC definition of “strong cryptography” which means even TLS v1.0 and v1.1 is not going to be accepted for PCI DSS compliance. So it is time to Reconfigure and/or Upgrade.

Identify the usage of SSL version in the PCI Scope systems

Mostly SSL is used to secure the transmission over open and public network from one point to another

• Browser to Server Communication
• Server to Server communication between entities to entity
• Applications using SSL
• FTP server over SSL
• Email communication
• Remote access to systems/ Non console access to the systems
• Wireless Communication

Reconfigure and/or Upgrade

Entity need to check whether their SSL certificate has provision for TLS v1.2.

If Yes, TLS v1.2 must be configured and backward compatibility need to be disabled explicitly. In case of SSL certificate does not support TLS v1.2, vendor need to be contacted for upgrading the certificate.

Code level/ Configuration level change at the application

Applications where SSL has been embedded in code need to be changed.

Implementation constraint:

It seems to be very easy move from SSL v3 to TLS v1.2, what so big deal!

It is not so easy as Transmission security has dependency on two points – sending and receiving – hence both points must be compatible and capable of supporting TLS v1.2.

Technical:

• Legacy Application and software
• Hardware compatibility
• Browser compatibility

Business:

• Failure to receive the data
• Hardware and software upgrade cost
• Vendor Dependency

Conclusion:

The good news is that PCI SSC is going to give buffer time “When published, the revisions will be effective immediately but impacted requirements will have a sunset date to allow for organizations with affected systems to implement the changes“.

But entities need to plan right now as they may have to communicate the changes to their business partners, service providers and merchants. This is not going to impact only PCI DSS but PA DSS and PCI PTS standard as well.

—

Source:  https://www.pcisecuritystandards.org/pdfs/15_03_25_PCI_SSC_FAQ_SSL_Protocol_Vulnerability_Revisions_to_PCI_DSS_PAD.pdf

https://www.pcisecuritystandards.org/security_standards/documents.php