What’s new in PCI-DSS v3.1 update

PCIPCI SSC has announced that the PCI DSS 3.1 update.

This update makes the following summary clarifications about the use of SSLv3 and TLS 1.0 in PCI relevant environments:

  • New implementations must use alternatives to SSL and early TLS.
  • Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
  • Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration plan as an exception in the ASV Scan Report (in accordance with the ASV Program Guide).
  • Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and early TLS may continue to use these protocols as a security control after June 30, 2016.

April 15, 2015 brought us the much-anticipated release of the PCI DSS standard from the PCI Council.  As SSL and early TLS are no longer considered strong cryptography, this release describes how the industry is to move forward in regard to the use of SSL and early TLS versions and how current PCI DSS status is impacted.

The PCI DSS requirements that are directly affected by this update are:

  • Requirement 2.2.3: Implement additional security features for any required services, protocols, or daemons that are considered to be insecure;
  • Requirement 2.3: Encrypt all non-console administrative access using strong cryptography; and
  • Requirement 4.1: Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

Does this mean that if one has used SSL to address the above requirements, that one now fails these requirements?  No, it does not.  The updated standard allows for a timeframe in which SSL and early TLS can be phased out.  The updated standard specifies a deadline of June 30, 2016, after which SSL and early TLS must no longer be used.  However, a few caveats apply:

  • Prior to June 30, 2016, 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 and/or early TLS.
  • POS POI terminals (and the SSL/TLS termination points to which they connect) verified as not susceptible to any known exploits for SSL and/or early TLS may continue using these weaker protocols after June 30, 2016.

What are SSL and early TLS?

SSL v3.0 has existed for at least 15 years.  It was superseded by TLS v1.0 which was in turn replaced by TLS v1.1 and TLS 1.2.  The problem is that the application that supported SSL v3.0 and TLS v1.0 did not remove support for these protocol versions.  They simply added support for TLS v1.1 and later versions.  This was done to maintain backward compatibility with consumer web browsers, POS terminals, and legacy applications that may not have been upgraded to support TLS v1.1+ versions.  This was fine until exploits that could not be fixed were discovered in SSL and early TLS.  Therefore, for the purpose of the updated PCI DSS 3.1 standard, SSL is defined as any SSL v3.0 or earlier and early TLS is defined as TLS v1.0.

What is “new” versus “existing” implementation?

Understanding the difference is critical because an “existing” implementation may continue to use the insecure protocols up until June 30, 2016, while a “new” implementation may not.  According to supplemental guidance from the PCI SSC, an “existing” implementation is one where there is a pre-existing dependency or use of the vulnerable protocols (SSLv3.0/TLSv1.0), and a “new” implementation is one where there is no existing dependency on the use of the vulnerable protocols.

Practically speaking, if an organization currently uses SSLv3.0/TLSv1.0 and these weaker protocols are required to continue operations, then the organization may continue using these protocols. However, it is essential to consider each case individually.  Consider the following examples:

Example 1:  A payment gateway supports an API that accepts transactions from terminals or POS software communicating over SSLv3.0/TLSv1.0.  This payment gateway can continue to use these weaker protocols until June 30, 2016.  Even if the payment gateway provider builds a new API that supports a stronger version of TLS, weaker protocols can continue to be used until the June deadline as long as continued operations depend on supporting legacy software and terminals that rely on the weaker protocols.

Example 2:  A payment gateway provides access to a virtual terminal interface or to a management portal interface.  Since an end-user’s web browser is not considered a “pre-existing” dependency, this payment gateway cannot continue to support SSLv3.0/TLSv1.0 and must migrate to stronger protocols at once.

In fact, for those who operate an e-Commerce site or portal, it is mandatory to update immediately to more secure protocols unless sufficient evidence shows that the application or server software must continue to support weaker protocols.

If weaker protocols must continue to be used, an organization must develop a Risk Mitigation and Migration Plan.  Only by developing this plan can an organization that continues to use the weaker SSLv3.0/TLSv1.0 meet the current PCI DSS 3.1 requirements.  The plan must:

  • detail each scenario where insecure protocols are used;
  • define the existing risk reduction controls to prevent and detect attacks;
  • describe methods in place to monitor for new vulnerabilities associated with the insecure protocols;
  • describe change control methods to ensure that the insecure protocols are not allowed to be implemented into new environments; and
  • Outline how the environment will be migrated to meet the June 30, 2016 deadline.

Why are POI terminal deployments exempt?

Point of Interaction (POI) devices that support the weaker SSLv3.0/TLSv1.0 are not subject to the June 30, 2016 deadline.  Weaker protocols can continue to be used because POI devices are not as prone to known vulnerability exploits.  Exploits generally require that a device support multiple client side connections, JavaScript, cookies, or that the end-user software be a web browser.  Since POI devices do not operate in this manner, they are not as susceptible to known attack vectors.  In addition, the device communications adhere to specified message types that limit exposure to replay attacks.  However, should new vulnerabilities be discovered, this exemption for POI devices can readily disappear.

What action should I take going forward?

If possible, upgrade or configure systems that only use TLS 1.1 or greater and disable fall back support to lower protocols.  It is important to note that proper configuration of TLS 1.1 or greater is critical and is fully outlined in the NIST 800-52 rev1 publication.  A key requirement is ensuring proper cipher suites are utilized.  These cipher suites are critical for mitigating attack scenarios where weaker cipher suites are exploited.

If one must continue to use weaker protocols, then monitoring the use of these weaker protocols is critical.  IPS/IDS or other alerting technologies (reverse-proxies) can detect multiple requests for protocol downgrades and flag an attack attempt.  In addition, firewalls and other network access control devices can limit access to services that support weak protocols.

Migrating away from SSLv3/TLS1.0 is not an easy task.   Otherwise, new releases of the protocols would have promptly replaced the older protocols. Instead, migration is complex and difficult because of the ubiquitous nature of SSL. It is found in firewalls, routers, POS terminals and applications that communicate across networks. SSL dependency is far-reaching, as this protocol is also found in devices and applications that extend outside the payment industry.  Although updating to stronger protocols may be daunting and time-consuming, this migration is necessary to ensure compliance with updated PCI standards and ultimately, to have a stronger defense against unauthorized network intrusions

What is the risk?

SSL/TLS encrypts a channel between two endpoints (for example, between a web browser and web server) to provide privacy and reliability of data transmitted over the communications channel. Since the release of SSL v3.0, several vulnerabilities have been identified, most recently in late 2014 when researchers published details on a security vulnerability (CVE-2014-3566) that may allow attackers to extract data from secure connections. More commonly referred to as POODLE (Padding Oracle On Downgraded Legacy Encryption), this vulnerability is a man-in-the-middle attack where it’s possible to decrypt an encrypted message secured by SSL v3.0.

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

How does the presence of early TLS impact ASV scan results?

SSL v3.0 and early TLS contain a number of vulnerabilities, some of which currently result in a score of 4.3 on the CVSS (Common Vulnerability Scoring System). The CVSS is defined by NVD (National Vulnerability Database) and is the scoring system ASVs are required to use. Any Medium or High risk vulnerabilities (i.e. vulnerabilities with a CVSS of 4.0 or higher) must be corrected and the affected systems re-scanned after the corrections to show the issue has been addressed.

However, as there is no known way to remediate some of these vulnerabilities, the recommended mitigation is to migrate to a secure alternative as soon as possible. Entities that are unable to immediately migrate to a secure alternative should work with their ASV to document their particular scenario as follows:

  • 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 from SSL/early TLS will need to follow the Addressing Vulnerabilities with Compensating Controls process to verify 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).





Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *