blog.pcisecuritystandards.org Open in urlscan Pro
2606:2c40::c73c:671e  Public Scan

Form analysis
1 forms found in the DOM

GET /search

<form action="/search" method="get">
  <svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd"
      d="M19.07 14.8299L17 12.7099C16.5547 12.2867 15.9931 12.0063 15.3872 11.9047C14.7813 11.8031 14.1589 11.885 13.6 12.1399L12.7 11.2399C13.7605 9.82291 14.2449 8.05661 14.0555 6.29681C13.8662 4.53691 13.0172 2.91421 11.6794 1.75511C10.3417 0.596107 8.61448 -0.0130929 6.84568 0.0501071C5.07678 0.113407 3.39748 0.844307 2.14598 2.09591C0.894384 3.34751 0.163384 5.02671 0.100184 6.79561C0.036884 8.56451 0.646184 10.2916 1.80518 11.6294C2.96418 12.9671 4.58698 13.8161 6.34678 14.0055C8.10668 14.1948 9.87288 13.7105 11.29 12.6499L12.18 13.5399C11.8951 14.0996 11.793 14.7345 11.8881 15.3553C11.9831 15.976 12.2706 16.5513 12.71 16.9999L14.83 19.1199C15.3925 19.6817 16.155 19.9973 16.95 19.9973C17.745 19.9973 18.5075 19.6817 19.07 19.1199C19.3557 18.8405 19.5828 18.5069 19.7378 18.1385C19.8928 17.7702 19.9726 17.3746 19.9726 16.9749C19.9726 16.5753 19.8928 16.1797 19.7378 15.8114C19.5828 15.443 19.3557 15.1093 19.07 14.8299ZM10.59 10.5899C9.89018 11.2879 8.99928 11.7629 8.02968 11.9548C7.06018 12.1467 6.05548 12.0469 5.14258 11.6681C4.22968 11.2893 3.44958 10.6485 2.90068 9.82651C2.35188 9.00451 2.05888 8.03831 2.05888 7.04991C2.05888 6.06161 2.35188 5.09541 2.90068 4.27341C3.44958 3.45141 4.22968 2.81061 5.14258 2.43181C6.05548 2.05291 7.06018 1.95321 8.02968 2.14511C8.99928 2.33701 9.89018 2.81191 10.59 3.50991C11.0556 3.97441 11.4251 4.52621 11.6771 5.13361C11.9292 5.74111 12.0589 6.39231 12.0589 7.04991C12.0589 7.70761 11.9292 8.35881 11.6771 8.96631C11.4251 9.57371 11.0556 10.1255 10.59 10.5899ZM17.3346 17.8788C17.4564 17.8281 17.567 17.7537 17.66 17.6599C17.7537 17.567 17.8281 17.4564 17.8789 17.3345C17.9296 17.2127 17.9558 17.082 17.9558 16.9499C17.9558 16.8179 17.9296 16.6872 17.8789 16.5654C17.8281 16.4435 17.7537 16.3329 17.66 16.2399L15.54 14.1199C15.447 14.0262 15.3364 13.9518 15.2146 13.9011C15.0927 13.8503 14.962 13.8241 14.83 13.8241C14.698 13.8241 14.5673 13.8503 14.4454 13.9011C14.3236 13.9518 14.213 14.0262 14.12 14.1199C14.0263 14.2129 13.9519 14.3235 13.9011 14.4454C13.8503 14.5672 13.8242 14.6979 13.8242 14.8299C13.8242 14.962 13.8503 15.0927 13.9011 15.2145C13.9519 15.3364 14.0263 15.447 14.12 15.5399L16.24 17.6599C16.333 17.7537 16.4436 17.8281 16.5654 17.8788C16.6873 17.9296 16.818 17.9557 16.95 17.9557C17.082 17.9557 17.2127 17.9296 17.3346 17.8788Z"
      fill="#00A7A7"></path>
  </svg>
  <label for="search" class="screen-reader-text">Search</label>
  <input type="text" name="cludoquery" id="search" placeholder="Search">
</form>

Text Content

This site uses cookies



Some of these cookies are essential, while others help us to improve your
experience by providing insights into how the site is being used.

If you decline, your information won’t be tracked when you visit this website. A
single cookie will be used in your browser to remember your preference not to be
tracked.

Cookies settingsAcceptDecline
Contact Us
Log In
FAQs
Twitter Linkedin-in Youtube PCI Blogger Profile Envelope
Search
EN
 * English
 * Français
 * Español
 * 日本語
 * Deutsch
 * Português
 * 中文

 * PCI Qualified Professionals
   
   * * * Verify or search for a PCI Qualified Professional. Select the
         qualification that best suits your needs.
         
         
         PCI Qualified Professionals Overview
         Program Listings Overview
          * 3DS Assessor
          * Approved Scanning Vendors
          * Card Production Security Assessors
          * Internal Security Assessors
         
          * Point-to-Point Encryption Assessors
          * Qualified PIN Assessors
          * Qualified Security Assessors
          * Secure Software Assessors
          * Secure Software Lifecycle Assessors
          * PCI Forensic Investigators
          * PCI Professionals
         
          * Qualified Integrator and Resellers
          * PCI Recognized Laboratories
          * Assessor & Vendor Feedback Forms
          * Verify a Professional
 * Products & Solutions Listings
   
   * * * Locate approved devices and payment solutions for use at the point of
         sale, and point-to-point encryption solutions to protect cardholder
         data.
         
         
         Product & Solutions Listings Overview
         Product & Solutions Listings Overview
          * 3DS Software Development Kits
          * Approved PTS Devices
          * Validated Payment Software
          * Secure SLC Qualified Software Vendors
          * Payment Applications (PA-DSS)
         
          * Point-to-Point Encryption Solutions
          * MPoC Solutions
          * SPoC Solutions
          * CPoC Solutions
         
         
 * Training & Qualification
   
   * * * Learn more about PCI SSC’s Training & Qualification programs, class
         schedules, registration information, corporate group training and
         knowledge training.
         
         
         Training & Qualification Overview
         Training & Qualification Overview
          * 3DS Assessor Training
          * Approved Scanning Vendor Training
          * Associate QSA Training
          * Card Production Security Assessor Training
          * Internal Security Assessor Training
          * PCI Acquirer Training
          * PCI Awareness Training
          * PCI Forensic Investigator Training
         
          * PCI Professional Training
          * P2PE Assessor Training
          * Qualified Integrator and Reseller Training
          * Qualified PIN Assessor Training
          * Qualified Security Assessor Training
          * Secure SLC Assessor Training
          * Secure Software Assessor Training
          * Working From Home: Security Awareness Training
         
          * Training Class Schedule
          * Corporate Group Training
          * Knowledge Training
          * Programs Fee Schedule
          * Meet our Trainers
          * Credly Digital Badging
 * Events
   
   * * * Attend PCI SSC upcoming Community Meetings, programs, webcasts, and
         industry events where we are speaking.
         
         
         Events Calendar & Overview
         Events Calendar & Overview
          * Community Meetings
          * Forums
          * Past Events/Photo Galleries
         
         
         
 * Get Involved
   
   * * * Get involved with PCI SSC and help influence the direction of PCI
         Standards.
         
         
         Overview
         
         Join Us
         Overview
          * Ways to Participate
          * Associate Participating Organization
          * Principal Participating Organization
          * Request For Comments
          * Special Interest Groups (SIGs)
         
         
         
 * Newsroom
   
   * * * View the latest news, announcements, and resources from PCI SSC.
         
         
         Newsroom
         Newsroom
          * Press Releases
          * PCI Perspectives Blog
          * Coffee with the Council Podcast
          * Industry Bulletins
          * Media Coverage
          * Join Our Mailing List
         
         
         
 * Resources
   
   * * * Access PCI SSC standard and program documents and payment security
         resources.
         
         
         Resources Overview
         Resources Overview
          * Document Library
          * FAQs
          * Community Job Board
          * Global Content Library
          * Standards
          * Merchant Resources
          * PCI SSC Glossary
          * PCI Perspectives Blog
          * PCI SSC Portal
         
          * PCI Security Essentials
          * PCI SSC Threat Center
         
         
 * About Us
   * * * Get to know the PCI Security Standards Council.
         
         Who we are
         Who we are
          * PCI SSC Leadership
          * Board of Advisors
          * Affiliate Members
          * Strategic Members
          * Principal Participating Organizations
          * Participating Organization Directory
         
          * Regional Engagement Board (REB)
          * Global Executive Assessor Roundtable (GEAR)
          * Careers at PCI SSC
          * Policies
          * Contact Us
         
         

< Return to Blog Home Print


DATE CHANGE FOR MIGRATING FROM SSL AND EARLY TLS

Posted by Laura K. Gray on 18 Dec, 2015 in eCommerce and TLS/SSL




The Payment Card Industry Security Standards Council (PCI SSC) is extending the
migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0
to a secure version of TLS (currently v1.1 or higher).


These dates provided by PCI SSC as of December 2015 supersede the original dates
issued in both PCI Data Security Standard v3.1 (DSS 3.1) and in the Migrating
from SSL and early TLS  Information Supplement in April 2015.

Below are answers to questions about new timelines, requirements and reasons for
the adjustments.

Thank you to all who have provided feedback on the issue, including members of
 the National Institute of Standards & Technology (NIST), members of the
Financial Services Information Sharing Analysis Center (FS-ISAC), Retail
Solution Providers Association, Hotel Technology Next Generation, National
Restaurant Association and Retail Industry Leaders Association.

Should you wish to share the information from this blog post, a PDF copy of the
questions and answers below is provided at the bottom of this blog post.  A
video explaining the date change and many considerations that go along with it
is also available on the PCI Security Standards Council website.

How Big is the Risk?

The vulnerabilities within SSL and early TLS are serious and left unaddressed
put organizations at risk of being breached.





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 organizations 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 it can no longer be used as a security control after
30 June 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 30 June 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.

Q: What is the PCI Standards Security Council doing next?

A: PCI DSS v3.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: Transport Layer Security (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 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. 

Implementation Vulnerabilities: Vulnerabilities in TLS software. E.g.,
Heartbleed’s Buffer over-read vulnerability in OpenSSL.

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.

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.

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.

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

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.

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 organizations 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 30 June 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 organizations 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 30 June 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 30 June 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 it 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 realizing 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. 

A PDF version of these questions and answers can be downloaded here.



Download the bulletin


LIKE WHAT YOU READ?

Subscribe to the PCI Perspectives blog to receive insights, information and
practical resources to help your organization protect payment data.



Subscribe Here
Laura K. Gray
Twitter Email Website
The PCI Security Standards Council (PCI SSC) is a global forum that brings
together payments industry stakeholders to develop and drive adoption of data
security standards and resources for safe payments worldwide.

< Return to Blog Home Print





ABOUT US


 * Who We Are
 * Leadership
 * Careers
 * FAQs


TRAINING


 * Our Programs
 * Class Schedule


GET INVOLVED


 * Participating Organizations
 * Affiliated Members
 * Request for Comments
 * Special Interest Groups


NEWS & EVENTS


 * Newsroom
 * Events
 * PCI Perspectives Blog


CONTACT


 * Press Contacts
 * Contact Us

Twitter Linkedin-in Youtube PCI Blogger Profile


COPYRIGHT © 2006 – 2022 PCI SECURITY STANDARDS COUNCIL, LLC. ALL RIGHTS
RESERVED. TERMS AND CONDITIONS.


 * Association Management services provided by Virtual, Inc.
 * Antitrust Policy
 * Privacy Policy
 * IPR Policy


 * English
 * Français
 * Español
 * 日本語
 * Deutsch
 * Italiano
 * Português
 * 中文
 * Русский
 * Türkçe