The Global PCI Barbecue

[arctific]

As we know the entire credit card processing world must have TLS 1.0 disabled by June 30, 2018.  With success one might go to a barbeque:  good eats, fine company, burn a copy of RFC 2246 (TLS 1.0) for entertainment value, talk about anything except cryptography.  Or, without success, one might simply be barbecued.  What is your plan for success and the reward for a job well done?

Where are you?

• Are you planning to open up the global change ticket on June 29, 2018 and trust that the entire credit card processing world's changes in parallel will not interfere nor have dependencies?
• Will all your low depedency solutions complete by December 2017?
• Do you have a scarry domino sequence for high depedencies from January to June 2018?
• TLS 1.0 clients but not servers?

How to tell whether you should be invited?

• You know the name of the vendor who said, "June 30, 2018 is a long way off, what is your hurry?"
• You know the name of the Firewall Vendor that is not compliant.
• You know the name of the developer who said, "I have no idea which library is responsible for my code not being compiant."
• You know the application that is not in PCI scope that will crash if the PCI requried changes go in to produciton.
• Your LDAP or AD team said, "We can turn off all support for TLS 1.0 right now, who will be responsible for the damage to production if we do?"
• Your know the names of applications that your technological discovery process did not detect.

[Wilcho]

Legacy browser usage has naturally shrinked since the original SSL/early TLS phase-out date was extended, so I believe impact should be minimal. Other struggles are in sight with all the new requirements coming alive next year.

[Michael_Maguire]

I was under the impression that only TLS 1.1 and 1.2 were allowable as of mid last year -- a full 2 years prior to the context of this article.  What am I missing?

[arctific]

PCI SSC responded to update PCI DSS 3.1 to PCI DSS 3.2:

1. PCI DSS 3.2 updated due to Industry Pressure from June 30, 2016 to June 30, 2018.
2. Appendix A2.2 allows for the creation of a Risk Mitigation and Migration Plan (RMMP) to be filed that permits repair efforts of TLS 1.0 that must complete on or before June 30, 2018.  Risk Mitigation and Migration Plans were allowed to be filed with a Requirement Of Compliance as evidence of compliance by repair projects in progress.
3. Thus, compliance in June 2016 could have RMMP in place and be fully compliant.  Then, June 2017 could have RMMP in place and still be fully compliant if the promised forward progress was being delivered.

Beyond June 30, 2018: all uses of TLS 1.0, SSL 3.0, SSL 2.0 and weak encryption; DES, MD5, RC4 are not compliant even if a RMMP is in place.

Linux equivalent names: arcfour (RC4), ripemed (MD5)

SHA1 while deprecated is allowed first because the PCI Glossary defines it as Strong Cryptography (even if that statement is not true).  SHA1 is also technologically needed for TLS 1.1 to continue to function properly.

Ideal goals:

- TLS 1.2 with SHA2 only

- Symetric crypto has 128 bits or better

- Asymetric crypto has 2048 bits or better

- No verion of single DES, MD5, RC4 (or below).

- Some InfoSec units moving against 3DES also.

[arctific]

Non-PCI compliant systems can be strongly affected.

- Only recently was Microsoft Skype intending to issue a patch for its TLS 1.0 server to server communicitons.

- Any Server on Windows 2008 R1 cannot be upgraded to use greater than TLS 1.0.

- There are optional patchs for Remote Desktop needed to use greater than TLS 1.0, but those came out more than a year ago, but not having it can be a deep puzzle as communciations with the server shuts down due to an unknown cause.

- Lots of Redhat systems have legacy support for older cryptography unless that has been looked at especially in SSH configuration files.

- Devices have management interfaces using TLS 1.0:  Time Servers, DNS boxes, and more.

- Got to Love Cisco for their TLS 1.0 problems also: ASA firewalls, Cisco IP Phones, Advanced VOIP services.

Then, my all time favorite.  Vendor products using TLS 1.0 services to reach client browsers on workstations.  

Pros:

• Maybe we do not care about the sensitivity of the data
• Maybe hardening will allow TLS 1.0 client browsers because they are hard to detect or control.
• Maybe outside vendors like Exchange will be receiving mail from TLS 1.0 encrypted sources.

Cons:

• False sense of security as usual
• Lack of nerve when dealing with business alliances and vendors.

[obenkuyucu]

Compliance is always a motive. Whether you need to set minimums to the password requirements, or the SSL, early TLS matter. So eventually, all "supported" software, hardware would get TLSv1.1. The problem may arise when you are using unsupported, old versions. Or some crazy vendors can say that they do not believe that even you are using SSL or early TLS, their systems cannot be interfered.

But imho, companies are constantly reminded of the deadline. Even in quarterly ASV reports, we are requesting the plan from companies having SSL or early TLS.

So, of course there would be some that are fully ready to the deadline, and there would be others still figuring out their SSL inventory.

[sdurbin]

@Michael_Maguire

The PCI SSC extended the completion date to deprecate the earlier SSL/TLS protocols. In reality, what this means is that if organisations can prove that they have begun the process of completing this work; they can remain compliant until 30th June 2018.

This date is the new cutoff for "completion" of the process.

Regards,

Stephen