PCI SSC pushes back deadline for secure TLS
The PCI SSC has pushed back the date by which members must change to a secure version of TLS (currently 1.1 or higher); the migration is being revised today and pushed back from June 2016 to June 2018.
PCI SSC pushes back deadline for secure TLS
Organisations using SSL and early TLS encryption have been shown to be vulnerable to attack, including by Poodle and Heartbleed, causing the Payment Card Industry Security Standards Council (PCI SSC) to instruct members that they must change to a secure version of TLS (currently 1.1 or higher), by June 2016, but the date for the migration is being revised today and pushed back to June 2018.
The organisation is hosting a webinar with National Institute of Standards and Technology (NIST) ( which originally reported the vulnerabilities in SSL and early versions of TLS in 2014) and expert speakers from the Assessor community to provide more information on the vulnerabilities and the shift and final versions of these document will be made available on its website later today.
The June 2016 deadline for migration, was included in the PCI Data Security Standard, version 3.1 (PCI DSS 3.1) published in April 2015. The new deadline date, June 2018, will be included in the next version of the PCI Data Security Standard, which is expected in 2016.
The PCI SSC issued a statement saying that the move followed, “significant feedback from the global PCI community and security experts”. Stephen Orfei, general manager, PCI SSC is quoted in the statement as saying: “Early market feedback told us migration to more secure encryption would be technically simple, and it was, but in the field a lot of business issues surfaced as we continued dialogue with merchants, payment processors and banks.” He continued: “We want merchants protected against data theft but not at the expense of turning away business, so we changed the date. The global payments ecosystem is complex, especially when you think about how much more business is done today on mobile devices around the world. If you put mobile requirements together with encryption, the SHA-1 browser upgrade and EMV in the US, that's a lot to handle. And it means it will take some time to get everyone up to speed. We're working very hard with representatives from every part of the ecosystem to make sure it happens as before the bad guys break in.”
Troy Leach, chief technology officer, PCI SSC explained how, “Some payment security organisations service thousands of international customers all of whom use different SSL and TLS configurations.” However, he adds that PCI DSS still, “encourage all organisations to migrate as soon as possible and remain vigilant. Staying current with software patches remains an important piece of the security puzzle.”
Separately the PCI SSC has anew requirement date for payment service providers to begin offering more secure TLS 1.1 or higher encryption; a requirement for new implementations to be based on TLS 1.1 or higher, and an exception to the deadline date for Payment Terminals, known as “POI” or Points of Interaction.
Merchants are encouraged to contact their payment processors and / or acquiring banks for detailed guidance on upgrading their ecommerce sites to the more secure encryption offered by TLS 1.1 or higher.
The PCI Security Standards Council has also issued the following list of frequently asked questions:
Q: Why change the original date for SSL included in PCI DSS v3.1?
A: For more than 20 years Secure Sockets Layer (SSL) has been one of the most widely-used encryption protocols. It remains in widespread use today despite existence of a number of security vulnerabilities and being deprecated by NIST in 2014.
According to NIST, there are no fixes or patches that can adequately repair SSL or early TLS. Therefore, it is critically important that organisations upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
In April 2015, after extensive marketplace feedback, PCI SSC removed SSL as an example of strong cryptography from the PCI Data Security Standard (PCI DSS) version 3.1, stating that is can no longer be used as a security control after June 30, 2016. During the implementation period of PCI DSS 3.1, PCI SSC continued to seek feedback from the market, and has now revised and updated sunset dates.
The new date of June 2018 offers additional time to migrate to more secure protocols, but waiting is not recommended. The existence of the POODLE and Heartbleed exploits, among others, prove that anyone using SSL and early TLS risks being breached.
In total, the revisions state:
1. All processing and third party entities – including Acquirers, Processors, Gateways and Service Providers must provide a TLS 1.1 or greater service offering by June 2016.
2. Consistent with the existing language in PCI DSS v3.1, all new implementations must be enabled with TLS 1.1 or greater. TLS 1.2 is recommended.
(New implementations are when there is no existing dependency on the use of the vulnerable protocols – see PCI SSC Information Supplement: Migrating from SSL and Early TLS.)
3. All entities must cutover to use only a secure version of TLS (as defined by NIST) effective June 30, 2018 (with the following exception).
4. The use of SSL/early TLS within a POI terminal and its termination point that can be verified as not being susceptible to all known exploits for SSL and early TLS, with no demonstrative risk, can be used beyond June 2018 consistent with the existing language in PCI DSS v3.1 for such an exception.
What is the PCI Standards Security Council doing next?
PCI DSS 3.1 will be updated in 2016. Information supplements and additional guidance will also be updated at this time.
Understanding the Risk
Q: What is SSL/TLS?
A: TLS is a cryptographic protocol used to establish a secure communications channel between two systems. It is used to authenticate one or both systems, and protect the confidentiality and integrity of information that passes between systems.
Q: What is the history of SSL/TLS?
A: TLS was originally developed as SSL- Secure Sockets Layer by Netscape in the early 1990s. Standardised by the Internet Engineering Taskforce (IETF), TLS has undergone several revisions to improve security to block known attacks and add support for new cryptographic algorithms, with major revisions to SSL 3.0 in 1996, TLS 1.0 in 1990, TLS 1.1 in 2006, and TLS 1.2 in 2008.
Q: What are the SSL/TLS Vulnerabilities?
A: Because of its widespread use online, SSL and TLS have been targets by security researchers and attackers. Many vulnerabilities in SSL and TLS have been uncovered over the past 20 years.
Q: What are the different classes of vulnerabilities?
A: Protocol Vulnerabilities: There are many! Cryptographic vulnerabilities in either the SSL/TLS protocol itself, or in how it uses cryptographic algorithms. e.g., POODLE, BEAST, CRIME.
A: Implementation Vulnerabilities: Vulnerabilities in TLS software. E.g., Heartbleed's Buffer over-read vulnerability in OpenSSL.
A: Configuration Vulnerabilities: e.g., weak cipher suites or key sizes. Logjam attacks using export-grade cryptography.
Q: What are the impacts of vulnerabilities?
A: Loss of confidentiality or integrity: Many of the attacks, particularly protocol vulnerabilities, allow for Man-in-the-Middle attacks allowing an attacker to decrypt sensitive information.
A: Loss of cryptographic keys: In some of the most serious cases, vulnerabilities could allow an attack to steal long-lived cryptographic keys.
Q: Who is most susceptible to SSL vulnerabilities?
A: Online and e-commerce environments using SSL (and early versions of TLS) are most susceptible to the SSL exploits and attacks and should be upgraded immediately. With that being said, the PCI DSS migration date of 30 June 2018 applies to all environments (except for Point of Interaction (POI) environments as stated above).
Q: What you can and should do now?
A: Migrate to a minimum of TLS 1.1, preferably TLS 1.2. While it is possible to implement countermeasures against some attacks on TLS, migrating to a later version of TLS - notably TLS 1.1 and TLS 1.2 - is the only reliable method to protect yourself from the current protocol vulnerabilities.
A: Patch TLS software against implementation vulnerabilities. Implementation vulnerabilities, such as Heartbleed in OpenSSL, can pose serious risks. Keep your TLS software up-to-date to ensure you are patched against these vulnerabilities, and have countermeasures for other attacks.
A: Configure TLS securely. In addition to providing support for later versions of TLS, ensure your TLS implementation is configured securely. Ensure you're supporting secure TLS cipher suites and key sizes, and disable support for other cipher suites that are not necessary for interoperability. For example, disable support for weak “Export-Grade” cryptography, which was the source of the recent Logjam vulnerability.
Q: If my payment terminals (POIs) use SSL or TLS 1.0 for encryption, do I need to replace my payment terminals?
A: Not necessarily. POIs are currently not as susceptible to the same known vulnerabilities as browser-based systems. Therefore, after 30 June 2018, POI devices (and the termination points to which they connect) that can be verified as not being susceptible to any of the known exploits for SSL and early versions of TLS may continue to use SSL / early TLS
A: If SSL/early TLS is used, the POIs and their termination points must have up-to-date patches, and ensure only the necessary extensions are enabled.
A: Additionally, use of weak cipher suites or unapproved algorithms – e.g., RC4, MD5, and others – is NOT allowed.
Q: Who can verify my POIs meet the above characteristics?
A: Entities may contact the terminal vendors directly for evidence or attestation that payment devices are not susceptible to known vulnerabilities. Entities may also consult with knowledgeable security professionals to obtain verification. The verification will need to occur any time a new SSL/TLS vulnerability is discovered, and organisations will need to remain up-to-date with vulnerability trends to determine whether or not they are susceptible to any known exploits. New threats and risks must continue to be managed in accordance with applicable PCI DSS Requirements, such as 6.1, 6.2, and 11.2.
Q: Do all POIs use SSL for encryption?
A: No. Newer payment devices should already be using secure protocols such as TLS version 1.2. Check with the terminal manufacturer or terminal documentation to understand what level of encryption your particular POI uses. If a device does not need to support SSL/early TLS, disable both use of and fallback to these versions.
Q: My ASV scan is flagging the presence of SSL and my scan is failing. What should I do?
A: Prior to June 30, 2018: Entities that have not completed their migration should provide the ASV with documented confirmation that they have implemented a Risk Mitigation and Migration Plan and are working to complete their migration by the required date. Receipt of this confirmation should be documented by the ASV as an exception under “Exceptions, False Positives, or Compensating Controls” in the ASV Scan Report Executive Summary.
After 30 June 2018: Entities that have not completely migrated away from SSL/early TLS will need to follow process outlined in the ASV Program Guide section entitled “Managing False Positives and Other Disputes” to confirm the affected system is not susceptible to the particular vulnerabilities. For example, where SSL/early TLS is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication).
Q: Does this mean that I don't have to address this vulnerability until 2018?
A: No, this is not an excuse to delay addressing vulnerabilities. You should be patching those vulnerabilities that have patches.
Q: What if a new attack is discovered on a current version of TLS?
A: It is always important to focus on security and keep track of new vulnerabilities. Technology and threats are constantly evolving. When new vulnerabilities are discovered they need to be addressed and may result in a need to upgrade to a newer, more secure version of the TLS protocol. Future-planning is vital to stay protected. Implement strong options now is the recommended action. PCI DSS already requires organisations to keep systems protected from vulnerabilities.
Q: What about Approved Scanning Vendors and how this impacts ASV scans?
A: We're aware that some current SSL vulnerabilities trigger a CVSS, Common Vulnerability Scoring System, score of 4.3. Any medium to high vulnerabilities, CVSS of 4.0 or higher must be corrected and rescanned to ensure the vulnerability has been addressed.
However, because there are no known ways to address some SSL/early TLS vulnerabilities, it makes it difficult to correct and rescan as with other vulnerabilities.
Prior to June 30, 2018, we recommend every entity work with their ASV and provide their migration plan as discussed previously. The ASV can document receipt of this plan under the “Exceptions, False Positives, or Compensating Controls” section of the ASV scan report.
After June 30, 2018, the entity still has SSL or early TLS in their environment, they will need to document that it has been verified the systems are not susceptible to the vulnerability and complete the Addressing Vulnerabilities with Compensating Controls process for their particular environment.
For POS POI environments, where it has been verified that terminals are not susceptible to current SSL vulnerabilities, the ASV has the discretion to change the CVSS score for a specific vulnerability as long as they follow the defined process in the ASV program guide and provide justification for the change. It's important for the ASV to consider the clients unique environment before making any changes.
Q: What goes into creating a risk mitigation and migration plan?
A: A risk mitigation and migration plan details how an entity will address the migration to a secure protocol, including the controls in place to reduce risk associated with SSL and early TLS, until their migration is complete. The plan will need to be provided to an assessor during an entity's PCI DSS assessment. An assessor can then check the progress of the plan if a Report on Compliance (ROC) is completed prior to June 2018.
Q: Can you give some examples of information that may need to be included in the risk mitigation and migration plan?
A: A description of how vulnerable protocols are being used, including;
• The type of environment where the protocols are used – e.g. the type of payment channel and functions for which the protocols are used
• The type of data being transmitted – for example does it include elements of payment card account data, administrative connections etc.
• Number and types of systems using and/or supporting the protocols – e.g. POS POI terminals, payment switches, etc.
The risk assessment results and risk reduction controls currently in place:
• Entities should have evaluated and documented the risk to their environment and have implemented risk reduction controls to help mitigate the risk until the vulnerable protocols can be completely removed.
A description of processes that are implemented to monitor for new vulnerabilities associated with vulnerable protocols:
• Entities need to be proactive and stay informed about new vulnerabilities. As new vulnerabilities are published, the entity needs to evaluate the risk they pose to their environment and determine if additional risk reduction controls need to be implemented until the migration is complete.
A description of change-control processes that are implemented to ensure SSL/early TLS is not implemented into new environments:
• If an entity does not currently use or need to support vulnerable protocols, there is no reason why they should introduce such protocols to their environment. Change controls processes include evaluating the impact of the change to confirm the change does not introduce a new security weakness into the environment.
An overview of migration project plan including target migration completion date no later than 30th June 2018:
• Migration planning documentation includes identifying which systems/environments are being migrated and when, as well as a target date by which the overall migration will be completed. The target date for the overall migration must be on or before 30th June 2018.
Q: Where do you begin with the migration process?
A: Some key points to consider are:
• Identify all system components and data flows relying on and/or supporting the vulnerable protocols
• For each system component or data flow, identify the business and/or technical need for using the vulnerable protocol
• Immediately remove or disable all instances of vulnerable protocols that do not have a supporting business or technical need
• Identify technologies to replace the vulnerable protocols and document secure configurations to be implemented
• Document a migration project plan outlining steps and timeframes for updates
• Implement risk reduction controls to help reduce susceptibility to known exploits until the vulnerable protocols are removed from the environment
• Perform migrations and follow change control procedures to ensure system updates are tested and authorized
• Update system configuration standards as migrations to new protocols are completed
• It is important to build a communications element into migration planning. Consider how much leg work it will take to get agreement on changing.
The PCI Council has published very specific guidance on interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols, including FAQs and tips for small merchant environments, all available on the website. The information supplement will be updated with the new dates. However, the guidance in it is still relevant and helpful; please review it for valuable content realising that the dates will be updated.
Q: I am a small merchant and/or franchisee and my employees are not security professionals. Where can I get additional support?
A: It is recommended that small merchants and franchisees work with their acquiring bank to determine whether their environment is at risk for SSL or early versions of TLS vulnerabilities.