Document Comparison
Migrating_from_SSL_Early_TLS_Information_Supplement_v1.pdf
→
Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf
73% similar
7 → 8
Pages
3804 → 4376
Words
15
Content Changes
Content Changes
15 content changes. 13 administrative changes (dates, page numbers) hidden.
Added
p. 2
SSL and early TLS should not be used as a security control to meet these requirements. To support entities working to migrate away from SSL/early TLS, the following provisions are included:
Added
p. 3
If SSL/early TLS is used, the requirements in PCI DSS Appendix A2 “Additional PCI DSS Requirements for Entities using SSL/Early TLS” apply.
Added
p. 5
When reviewing implementations of POI terminals that use SSL/early TLS, assessors should review supporting documentation (for example, documentation provided by the POI vendor, system/network configuration details, etc.) to determine if the implementation is susceptible to known exploits.
Added
p. 7
Do the migration dates apply if there are no cardholder data compromises resulting from use of SSL/early TLS? Yes, the date for migrating away from SSL/early TLS is not affected by the number of payment card data compromises that may or may not occur in the future. The PCI DSS requirements are intended to help prevent compromises of cardholder data through a defense-in- depth approach. Waiting for potential data breaches to be publicized before taking steps to secure your own data is not an effective approach to security, and is not supported in the PCI DSS.
Does this mean entities with a Risk Mitigation and Migration Plan don’t have to patch vulnerabilities in SSL/early TLS? No, the target migration dates are not an excuse to delay patching vulnerabilities. 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, and …
Does this mean entities with a Risk Mitigation and Migration Plan don’t have to patch vulnerabilities in SSL/early TLS? No, the target migration dates are not an excuse to delay patching vulnerabilities. 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, and …
Removed
p. 2
SSL and early TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after 30th June, 2016.
Modified
p. 2
SSL v3.0 was superseded in 1999 by TLS v1.0, which has since been superseded by TLS v1.1 and v1.2. To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
Modified
p. 2
The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers will begin prohibiting SSL connections in the very near future, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol.
The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers have begun prohibiting SSL connections, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol.
Modified
p. 2
What this means for PCI DSS In PCI DSS v3.1, SSL and early TLS are no longer examples of strong cryptography or secure protocols. The PCI DSS v3.1 requirements directly affected are:
What this means for PCI DSS As of PCI DSS v3.1, SSL and early TLS are no longer examples of strong cryptography or secure protocols. The PCI DSS requirements directly affected are:
Modified
p. 3
• e.g. POS POI terminals, payment switches, etc. Risk assessment results and risk reduction controls in place: o 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. Description of processes that are implemented to monitor for new vulnerabilities associated with vulnerable protocols: o Entities need to be proactive and stay informed about new vulnerabilities. As new vulnerabilities …
• e.g. POS POI terminals, payment switches, etc. Risk assessment results and risk reduction controls in place: o 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. Description of processes that are implemented to monitor for new vulnerabilities associated with vulnerable protocols: o Entities need to be proactive and stay informed about new vulnerabilities. As new vulnerabilities …
Modified
p. 4 → 5
For other environments
• e.g. virtual payment terminals, back-office servers, user computers etc., small merchants should validate if SSL/early TLS is used and where it is implemented, and then determine if an upgrade can occur immediately, or if a business justification exists for a delayed upgrade (not to exceed June 30,2016).
• e.g. virtual payment terminals, back-office servers, user computers etc., small merchants should validate if SSL/early TLS is used and where it is implemented, and then determine if an upgrade can occur immediately, or if a business justification exists for a delayed upgrade (not to exceed June 30,
For other environments
• e.g. virtual payment terminals, back-office servers, user computers etc., small merchants should validate if SSL/early TLS is used and where it is implemented, and then determine if an upgrade can occur immediately, or if a business justification exists for a delayed upgrade (not to exceed June 30, 2018).
• e.g. virtual payment terminals, back-office servers, user computers etc., small merchants should validate if SSL/early TLS is used and where it is implemented, and then determine if an upgrade can occur immediately, or if a business justification exists for a delayed upgrade (not to exceed June 30, 2018).
Modified
p. 5
What should merchants do with POI terminals that support SSL/early TLS? As detailed in PCI DSS v3.1, POIs can continue using SSL/early TLS when it can be shown that the POI is not susceptible to the currently known exploits. However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible. New implementations of POIs should strongly consider support for …
What should merchants do with POI terminals that support SSL/early TLS? POIs can continue using SSL/early TLS when it can be shown that the POI is not susceptible to the currently known exploits. However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible. New implementations of POIs should strongly consider support for and use of TLS 1.2 or …
Modified
p. 5
Why are POS POI environments less vulnerable? PCI DSS v3.1 provides an allowance for SSL and early TLS to continue to be used by point of sale (POS) point of interaction (POI) devices and their termination points. This is because the vulnerabilities known at the time of publication are generally more difficult to exploit in these environments.
Why are POS POI environments less vulnerable? PCI DSS provides an allowance for SSL and early TLS to continue to be used by point of sale (POS) point of interaction (POI) devices and their termination points. This is because the vulnerabilities known at the time of publication are generally more difficult to exploit in these environments.
Modified
p. 6
• on the same termination point, the entity will need to ensure that all vulnerable channels are migrated to a secure alternative by June 30th, 2016. If the POI environment is deemed as being not susceptible to vulnerabilities, the entity may wish to consider the following options:
• on the same termination point, the entity will need to ensure that all vulnerable channels are migrated to a secure alternative by June 30th, 2018. If the POI environment is deemed as being not susceptible to vulnerabilities, the entity may wish to consider the following options:
Modified
p. 6
E-commerce environments that have a current need to support customers using SSL/early TLS must begin migrating as soon as possible, with all migrations to be completed by 30th June, 2016. Where migration cannot occur immediately, the justification must be documented as part of the Risk Mitigation and Migration Plan.
E-commerce environments that have a current need to support customers using SSL/early TLS must begin migrating as soon as possible, with all migrations to be completed by 30th June, 2018. Where migration cannot occur immediately, the justification must be documented as part of the Risk Mitigation and Migration Plan.
Modified
p. 7
Prior to June 30, 2016: 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 June 30, 2016: Entities that have not completely migrated away …
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, and the ASV may issue a result of “Pass” for that scan …