SSL Is Not Going To Go Quietly

A lot of organizations are finding out that just turning off SSL is just not an option. This is particularly true of merchants running eCommerce sites predominantly used by mobile customers or customers running older operating systems. To the surprise of a lot of IT people, it turns out that most mobile browsers do not support using TLS. And while most Western PC users have reasonably current browser software, the rest of the world does not and turning off SSL will remove a significant portion of some merchant’s customer base. As a result, for some organizations going “cold turkey” on SSL is just not an option without suffering significant consequences.

But there is a larger problem with SSL lurking inside almost every data center. That is with appliances and data center management software that have SSL baked into them for their Web-based management interfaces. A lot of vendors availed themselves of OpenSSL and other open source SSL solutions to secure communications with their appliances and solutions. To remediate these solutions, an organization might be lucky enough to upgrade the firmware/software. Unfortunately, a lot of organizations are finding that replacement is the only option offered by vendors to address these situations.

The bottom line is that because of these situations, SSL and early TLS will not be addressed by just disabling it and moving on. As the PCI SSC found out when they asked Qualified Security Assessor Companies and Participating Organizations about what it would take to address the SSL/early TLS situation, they were told about these issues and therefore set a deadline of June 30, 2016 to provide time to address these situations.

While organizations have until June 30, 2016 to address SSL and early TLS, that does not mean an organization can just sit by and do nothing until that deadline. Here are some things your organization should be doing to address SSL and early TLS if you are unable to just turn it off.

• Get a copy of NIST Special Publication 800-52 Revision 1 titled ‘Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Implementations’. This publication is the Bible for how to minimize and mitigate the risks of SSL and early TLS.
• Identify all instances of where SSL or TLS are used and versions supported. It is not just those instances that need to be remediated, but all instances. The reason is that TLS v1.3 is in draft specification and its release is likely just around the corner in 2016. That is why a complete inventory is needed so that when TLS v1.3 is available you will know what remaining instances will potentially need to be updated, upgraded or possibly even replaced.
• Implement TLS-FALLBACK-SCSV to minimize the chance of SSL/TLS fallback. This option was developed to address the issue created by POODLE. However, be aware that only certain versions of browsers support this option, so it is not a perfect solution.
• Monitor your external Web sites for SSL and early TLS usage. Track statistics of how many sessions are using SSL or early TLS so that you can determine usage of those protocols and therefore know the actual impact of any decision regarding those protocols. These statistics will also allow you to know when you might be able to pull the plug on SSL and early TLS with minimal impact.
• Modify any external Web sites to present a message to anyone using SSL or early TLS to warn them that you will be no longer supporting SSL/early TLS as of whatever date your organization chooses to drop that support.
• Where possible, configure the Web site to only use SSL or early TLS as the absolute last resort. Unfortunately, a lot of vendors modified their SSL solution to not allow this sort of change so do not be surprised if that does not become an option.
• Develop a migration plan for your remaining instances where SSL or early TLS are used. Contact vendors involved and document what their plans are for dropping SSL and early TLS.
• Be prepared to create compensating controls for SSL and early TLS that you will not be able to remediate by the deadline. Unfortunately, I have a sneaking suspicion that some vendors will miss the June 30, 2016 deadline as will some merchants be unable to turn off SSL by the deadline. As a result, those organizations will have to put compensating controls in place to maintain PCI compliance. These compensating controls will likely be messy and complex as enhanced monitoring will likely be the only controls available.

Advertisement

Another Annual Community Meeting

Another year has come and gone and so has another North American PCI Community Meeting. This one held in the beautiful city of Vancouver, British Columbia, Canada.

I have to say that the new leadership of the Council is showing. I heard many comments from attendees that this year’s conference was better than in years past.

The Good

• The ‘Mobile Forum Roundtable Discussion’ was probably the best session of the conference. That is based on comments from the attendees of this session as well as the comments from other conference attendees that went to the competing sessions. If the Council is looking for how to structure future sessions, this is the format. Participants sat at numbered tables and then each table was given a question on the topic of mobile payments to discuss for half of the session. The last half of the session was a representative from each table presenting the findings from those table discussions. I think the Council’s Mobile Working Group, of whom some members were present, as well as the other attendees of this session learned a lot in an hour and a half.
• There were two notable sessions regarding point-to-point encryption (P2PE) that had nothing to do with P2PE. One was given by First Data regarding TransArmor and the other was given by Caesars International regarding Shift4. Neither of these end-to-end encryption (E2EE) solutions are P2PE validated. In years past, these sessions would never have occurred. Apparently the new leadership at the Council felt it was important to have their stories told to the Community Meeting participants as a more secure way of conducting transactions even though neither is a P2PE solution. I commend the Council for their foresight in holding such sessions.
• Brian Krebs’ Keynote on Thursday was not what I was at all expecting. I expected Brian would mostly rehash stuff out of his latest book as most writers do at these sorts of events. But it was a very informative and enlightening session with a lot of good information. For those who regularly read his blog, a lot of the stories he gave we had already heard but not with the personal touches he gave them. If anything, people walked away with a better understanding of why card data is sought after by the underground.
• As always it was great to get together with everyone involved in PCI and meet a lot of you. The nightly receptions were excellent as were the session breaks. It always amazes me how many people just walk up and introduce themselves to me at these meetings. I really appreciate the fact that so many of you find the blog so useful as well as providing people with a voice in sharing frustrations with PCI and the process. Thank you to all of you that read this blog and find it useful.

The Not So Good

• The Thursday “TED Talks” format was so-so. While it was definitely the talk at lunch and afterwards at dinner, it was not viewed as a highlight. As I coalesced the comments I heard, I do not think it was not the format as much as not all of the topics presented belonged in such a format. For anyone that has seen or been to TED Talks, they are very, very high energy and involve a passion for a topic that was not completely present in those Thursday sessions. If this is a format the Council wants to use going forward, then the topics are going to have to have a much higher energy to them and be much more important to discuss.
• I had to chuckle at the vendor booths that were pushing their “silver bullet” solution for PCI compliance. There were only a very few of these “snake oil salesmen” present, but there they were saying they could put parts of your environment completely out of scope for PCI compliance. I thought we were long past such claims, but apparently not.
• As with any such event, I saw a lot of people that I really wanted to talk to and just did not get the chance to catch up with them.
• I unfortunately ended up with a number of client and emergency meetings I needed to attend during the conference. As a result, I had a few interruptions and could not attend a number of the sessions I really wanted to attend.

The Notably Missing

• Professional Breakout Sessions were missing. This is a PCI conference that brings together qualified security assessors (QSA), internal security assessors (ISA), approved scanning vendors (ASV) and participating organizations (PO). Yet, there were no breakout sessions for those participants to meet with anyone from the Council. You would think that getting feedback from each of these important groups would be important to the Council. Other than these groups going individually to the Council’s office on “Card Brand Row”, there was no program for these important constituents to get together and voice their concerns. One would think this is a key part of why you hold such an event yet this piece was missing.

Overall though this year’s Community Meeting was probably one of the better ones I have attended.

See you all next year in Las Vegas.