The Clock Is Ticking – Part 2 Migrate From SSL/TLS Now

It has now been over a month since the Payment Card Industry Data Security Standard (PCI DSS) 3.0 as officially retired on June 30. In part 1 of this series on PCI DSS 3.1 migration, we noted that version 3.1 was swiftly introduced in April 2015 as a response to major security flaws discovered in open source SSL, and the exploits –  including Heartbleed, Shellshock and POODLE – that targeted the vulnerabilities. The flaws enable man-in-the-middle attacks and enabled attackers to read supposedly secure,  authenticated encrypted communications. Consequently, the PCI Council branded SSL and TLS 1.0 as “vulnerable protocols” in the new version of its security standard. Those who are required to comply with PCI DSS have a grace period of June 30 2016, but any new deployments that utilize SSL or early versions of TLS are now prohibited. Please see post #1 in this series (LINK) to view best practice risk-mitigation controls for environments currently using vulnerable protocols. Online merchants need to develop a migration plan to move from SSL to the latest version of the Transport Layer Security protocol  now, and also ensure any payment apps using SSL are updated.  Here’s how to manage your migration. Migrating from SSL and Early TLS Your best resource for managing this upgrade can be found in the PCI SSC guide “Migrating from SSL and Early TLS” from which the information below is based. Here is a basic outline of steps to follow while planning your migration from SSL/Early TLS to a secure protocol:

•         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

SSL/early TLS can remain in an environment if it is not being used as a security control to provide communication confidentiality. Follow defined vulnerability management processes to document how SSL/TLS vulnerabilities are addressed – for example, where it is used only for POI communications that are not susceptible to the exploits, or where it is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication). Don’t Delay The PCI SSC guide notes that now is the time to migrate to a safer protocol. “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.” If you cannot immediately migrate to a secure alternative and are reasonably sure that you will not be able to do so by June 30 2016, you must be prepared to provide your Approved Scanning Vendor (ASV) with documented confirmation that you 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). Entities with POS POI terminals and/or termination points that are verified as not being susceptible to the specific vulnerabilities may be eligible for a reduction in the NVD score for those systems. In this scenario, the ASV must provide (in addition to all the other required reporting elements), the following information in accordance with the ASV Program Guide:

•         The NVD rating of the vulnerability
•         The ASV’s rating of the vulnerability
•         Why the ASV disagrees with the NVD rating

When making any adjustments of this type, the ASV must consider the client’s unique environment, systems and controls, and not make such adjustments based on general trends or assumptions. The scan customer should work with their ASV to provide an understanding of their environment; otherwise the ASV will be unable to determine whether changing a CVSS score is appropriate.