April 15, 2015 brought us more than tax day; it 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.
Our team has already fielded many questions regarding this recent release, which we aim to clarify here.
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.
