The PCI Security Standards Council (PCI SSC) has released Payment Application Data Security Standard (PA-DSS) Version 3.1 to address vulnerabilities in the Secure Socket Layer (SSL) protocol. This update removes SSL and early TLS as examples of strong cryptography. PA-DSS 3.1 is effective June 1, 2015.
The PCI DSS requirements that are directly affected by this update are:
Requirement 8.2: The payment application must only use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware, including those provided by third parties, for any functionality of the payment application.
Requirement 11.1: If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including at least 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.
Requirement 12.1: If the payment application facilitates non-console administrative access, encrypt all such access with strong cryptography using technologies such as SSH, VPN, or TLS, for web-based management and other non-console administrative access.
Requirement 12.2: Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access.
It is important to note that the removal of SSL impacts more than just the transmission of cardholder data. Also impacted is the transmission of other sensitive data elements such as passwords, and strong cryptography for the protection of non-console access is critical. The following requirements are also affected by the PA-DSS 3.1 update, although PCI SSC documentation does not specify these as having direct impacts:
Requirement 7.2.1: Patches and updates are delivered to customers in a secure manner with a known chain of trust.
Many software vendors provide methods to download updates from a support site using web-based protocols. Going forward, these sites will need to use TLS 1.1+ for the transmission of the updates or utilize another method to ensure the security of the transmission.
Requirement 10.2.3: Remote access to customers’ payment application by vendors, integrators/resellers, or customers must be implemented securely.
This requirement specifies that such remote access must encrypt data transmissions in accordance with PA-DSS Requirement 12.1. If a vendor is to access a merchant’s environment over the Internet, then SSL or early TLS cannot be used.
Not only do the changes in PA-DSS 3.1 impact new PA-DSS validation efforts, but the update also affects PA-DSS validations currently in progress as well as applications currently listed as validated applications on the PCI SSC website. Our team has already fielded many questions regarding this recent release, which we aim to clarify here.
Applications Currently Under PA-DSS Validation
The PCI SSC has specified a transition period for applications currently undergoing PA-DSS 3.0 validations:
- New application submissions to PA-DSS 3.0 will be accepted by the PCI SSC until 31 August 2015;
- Applications being validated against PA-DSS 3.0 which are “in queue” (that is, submitted to the PCI SSC with PCI SSC invoices paid) by 31 August 2015 will have until 30 November 2015 to complete the validation process.
To meet these deadlines, it is critical that software vendors provide their PA-QSA ample time to complete testing and generate reports for submission to the PCI SSC. In addition, software vendors must have paid all fees to the PCI SSC prior to August 31, 2015. To facilitate payments, the PCI SSC can issue an invoice upon a PA-QSA’s notification that a submission is pending.
It is also important to understand that having an application submitted under the PA-DSS 3.0 guidelines does not mean that support of SSL and early TLS is acceptable. Based on our experience, the PCI SSC takes a firm stand on the removal of weaker protocols. Since December 2014, the PCI SSC has required us to confirm that submitted applications utilize TLS 1.1 or later and use these protocols as a preference over SSL and early TLS. In addition, we have been required to verify that submitted applications are not responsible for any downgrades in protocols. For example, if an application communicates with a processor’s payment gateway, any downgrade in protocols must be initiated by the payment gateway server and not by the application.
Applications Currently Listed as Validated Payment Applications
For applications already validated to PA-DSS versions prior to 3.1, an extra check will be added to the annual revalidation process effective December 1, 2015. Application vendors will be asked to attest that the application only uses or supports the use of cryptographic protocols that meet PCI SSC’s definition of strong cryptography. If the vendor cannot attest to this, then the annual revalidation cannot be accepted and the application moves to the Acceptable only for Pre-Existing Deployments listing.
In short, an application vendor must show/attest that their currently listed payment application does not use SSL or early TLS for the transmission of cardholder data. If this cannot be stated, then the application must undergo a new validation effort.
New validation efforts may be a delta assessment or a complete PA-DSS 3.1 validation. The level of validation depends on whether the application was validated under the 2.0 or 3.0 standard. Certain change submissions are no longer accepted for applications validated under PA-DSS 2.0, forcing these applications to undergo a complete PA-DSS 3.1 validation in order to remain on the Acceptable for New Deployments listing.
What action should I take going forward?
If your application currently supports SSL or early TLS, define the necessary steps to remove this support. If these weaker protocols are required to interface with a payment gateway you are certified against, work with the payment gateway to understand their migration path and to verify whether you will remain certified against their gateway if you remove support for the weaker protocols. If you are using SSL and early TLS to deliver updates to deployed applications or to provide remote support, begin a migration path to update to TLS 1.1+ features only. Unlike PCI DSS, which gives merchants until June 30, 2016 to remove SSL and early TLS, PA-DSS 3.1 requires software vendors to take prompt action with their payment applications. The removal of SSL and early TLS is required now.