By Natasja Bolton, Senior Acquirer Support QSA
Back in January 2016, we highlighted the PCI Council’s extension of the migration completion date for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher). Now, with just 8 months to go until the migration date deadline, we’re here to ask: Are Your Customers Ready for 30th June 2018?
What is the deadline?
By 30th June 2018, organisations must have moved away from using SSL or early TLS as a security control and instead be using only secure versions of the protocol.
PCI DSS Appendix A2 sets out details of the migration deadline, which is further explained in the Migrating from SSL and Early TLS Information Supplement.
Note that the exception allowing for continued use of SSL/early TLS within a Point of Interaction (POI) terminal and its termination point, that has been verified as not being susceptible to all known exploits for SSL and early TLS, beyond end June 2018 is still in place.
What requirements are impacted?
SSL and early TLS cannot be used as a security control to meet these requirements:
|2.2.3||Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.|
|2.3||Encrypt all non-console administrative access using strong cryptography.|
|4.1||Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.|
|8.2.1||Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.|
What do organisations need to do?
Any entity still using SSL or early TLS as a security control must have a ‘Risk Mitigation and Migration Plan’ with a planned completion date no later than 30th June 2018. Now is the time to confirm with your customers whether their migration plans are still on track for completion before the deadline.
As the Migrating from SSL and Early TLS Information Supplement outlines, organisations have a number of options available to them that will fulfil the requirement to make sure that SSL/early TLS is not being relied upon as a security control:
1.Upgrade to a current, secure version of TLS – implemented securely and configured to not accept fallback to SSL or early TLS.
2.Encrypt the data with strong cryptography before it is sent over SSL/early TLS
- Set up a strongly-encrypted session or tunnel prior to sending data over SSL within the secure tunnel (e.g. IPsec encrypted tunnel).
Are post-migration customers still secure?
Your customers may have already confirmed to you their successful migration to secure versions of TLS. For those customers, it is still worth reminding them that communications security is not just dependent on the protocol used but also on its maintenance and configuration. Aspects of TLS security that should be checked include:
- Software updates and patching – has an update to the customer’s TLS software been released since their migration to TLS was completed? If so, your customer needs to make sure those patches have been applied.
For example, bug and security fix updates for the OpenSSL encryption toolkit, which is commonly used in internet ecommerce web servers, are released every few months.
- Secure Configuration – is the TLS implementation securely configured? Even TLS v1.2 has known weaknesses and your customers should follow industry good practice and vendor recommendations to make sure their implementation is securely configured.
- UK National Cyber Security Centre’s Guidance on Using TLS to protect data
- S. National Institute of Standards and Technology (NIST) Special Publication 800-52 release 1 which specifies minimum requirements for TLS servers
- Open Web Application Security Project (OWASP) Transport Layer Protection Cheat Sheet
Do all instances of SSL/early TLS need to be removed from customer environments?
For those of your customers that may be struggling to remove all uses of SSL or early TLS in their environment; it is worth remembering that SSL and early TLS protocols can remain in use if they are not being used as a security control. That is why options II and III, shown above, are available as ways to meet the migration deadline.
However, those customers that do continue to use SSL and early TLS in those circumstances, need to be aware that, after the June deadline, they will need to work with their Approved Scanning Vendor (ASV) to make sure they can achieve passing ASV external vulnerability scan reports. The customer will need to follow the ‘Addressing Vulnerabilities with Compensating Controls’ process with their ASV to verify that ‘the affected system is not susceptible to the particular vulnerabilities’ (see the ASV Program Guide section 7.8), confirming that the SSL or early TLS usage detected by the ASV is not being used as a security control.
If you are a merchant that requires technical or PCI DSS help, please click here