Based on some of the questions I have received since my post on v3.2, apparently a lot of people missed this little point in my last post about the Council’s Webinar.
“The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities. If an organization can meet the June 30, 2016 deadline, then they should meet that deadline. If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS. But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.”
For all of you in denial out there, make sure you truly read that last sentence.
Yes folks. Your QSA can mark you as non-compliant if your organization does not have a very, very, very good and legitimate documented business reason for not meeting the June 30, 2016 deadline for getting rid of SSL and early TLS.
Want to argue that point? Fine. Then you can expect your QSA to put you in arbitration with your acquiring bank on this subject. If your acquiring bank is willing to sign off on your lame delay, then so be it. But if your bank denies your request, then expect to be put into remediation by your bank and possibly even be fined for your arrogance.
And one more thing we have since clarified. If you can meet the June 30, 2016 deadline, then you only need mitigation and migration plans for your QSA. If you are not going to meet the 2016 deadline, then in addition to the plans your organization will also need to provide a compensating control worksheet (CCW) for 4.1. Even if you are filing your Report On Compliance (ROC) before June 30, 2016, you still need to provide your QSA with the plans and the CCW if you will miss the 2016 deadline.
So for all of you out there that thought you had dodged a bullet, there is another bullet with your name on it. You have been warned.
PCI Guru 
I’m curious as to what types of compensating controls would be acceptable when the component with the problem is a vendor’s, e.g., Web-based administrative interface to something like anti-virus or patching, or for merchants that use a virtual terminal (e.g., to PayPal). We have a client that uses PayPal (SAQ C-VT), and PayPal doesn’t use TLS 1.2 yet (I just checked today with one of the on-line SSL testing tools). So, for Requirement 4.1 they have to answer not in place, have a RMMP with an unknown remediation date and a CCW.
First, the fact that PayPal has an issue is not the merchant’s problem, it is PayPal’s problem and does not impact the merchant’s PCI compliance. That said, the merchant needs to monitor the situation with PayPal and determine if PayPal is addressing the issue. If the merchant is not comfortable with PayPal’s response to the situation, then the merchant should find a different service provider.
As to administrative interfaces, if they are isolated on an administrative VLAN, that VLAN has no Internet access and only system administrators with job requirements have access, that should be sufficient.
On the processor side, things are never so easy.
We could switch off our SSL/early TLS, and our systems would run just fine no problem!, Oh, but most of our EMV business would be shut down solid. Not good.
We try to work up incentive programs, and work with POI terminal distributors to re-compile applications unchanged with updated network libraries (TLS 1.2 or maybe just a SHA-2 update). But ISO shops sell and ship terminals without management capabilities, so they have to sneaker-net the updates. Not good either…
In the end, we will be the ones subject to a non-compliant scan, because we run the service port.
All the while the ISO’s are screaming bloody murder because they don’t understand a word of what we’re saying: Tee-El-Ess, Shaw-One, Ess-Ess-El… Until december 2016, but wait! it could be June or actually, anytime soon really… It’s all mumbo-jumbo to them…
Meanwhile, their merchants are threatening to break contracts and go elsewhere, and Acquirers loooove to make “free” terminal offers. And the ISO’s are running around like headless chickens, wanting to protect their rental revenue on PED 2.0 devices that they lease
It has been a bad 18 months for crypto, and POI’s depend so much on crypto… Sigh
I know. I was on a call today regarding a P2PE solution that has problems because of TLS 1.0 that has to be replaced by a newer solution to get fixed. Client just implemented it last September and now it needs replacement. Think the vendor is apologizing? Nope.
Wait! TLS 1.0 in a P2PE solution? TLS 1.0 is a 17-year old spec? Very sad.
Well said. My hope is that the acquirers are doing their part(s) in enforcing this.
Some are and some are not. Unfortunately, enforcement is hit or miss.
> Yes folks. Your QSA can mark you as non-compliant if your organization does not have a very, very, very good and legitimate documented business reason for not meeting the June 30, 2016 deadline for getting rid of SSL and early TLS.
My client has been working with Cisco to get their ASA updated to support TLS 1.1/1.2. However, two-weeks ago Cisco responded that the due to severe bug this appliance can’t be updated. The network team is researching solutions. The client is a government entity and the procurement process and timeline can be lengthily.
I will hopefully be discussing the issue with our QSA. Our compliance assessment starts next month.
I would say that having a vendor issue and an inability to replace the appliance in time is a good reason to have a delay. I have a client that found out their blade enclosures have an old version of OpenSSL baked in to their firmware that the vendor informed them will not be updated. As a result, they are replacing all of their blade enclosures but that effort will not finish until hopefully in early December. But again, another valid business reason as to miss the June deadline.
The processors were poised to shut down SSL, warning there will be a significant hit on revenue, not to mention how it would devastate the thousands of shoe-string budget Level 4s. Everyone knows this vulnerability requires a high level of effort for one PAN at a time. I’m not aware of a single merchant breach involving a SSL compromise. Memory scraping is the vogue, high pay-off method.
I’m aware of a Level 2 merchant that has no QSA and does not submit a SAQ to its bank. A BIG bank. I then extrapolate that of those thousands of shoe-string budget Level 4s running “vulnerable POS systems,” less than half of them are likely not submitting SAQs, let alone have a QSA.
So who is going to be the judicial arm of the the compliance continuum?
Does anyone really think all merchants will be “compliant” by 2018?
The judicial arm is the US legal system as we have seen in the past.
Based on the messages and comments I got on my first post, there will likely be a LOT of non-compliant organizations come 2018.
Am I missing something with why certain, very large, companies are allowed to pump out 3.0 to their merchants, which are being provided to me, as “compliant” documents? Shouldn’t they at the very least be warning merchants (via 3.1 for now) that SSL and early TLS migration to current TLS is coming? How is this being allowed by the PCI SSC / and others? Who is policing the QSA companies?
The PCI SSC polices the QSA Companies (QSAC) through their quality assurance assessment (AQM) program. That effort works very well but only happens once a year for the large QSACs.
However, the banks are supposed to be reading all of those Attestation Of Compliance (AOC) forms they get as well as the SAQ/ROC. But as you can see, that is not being done.
At the end of the day, nobody is policing certain classes of merchants. If the banks are not be allowed to pass fines down to their breached merchants, they might do more policing under their risk management program.
Not enough police to go around and no one wants to pay for what it will take to change that fact.
Hi, I always enjoy reading your posts, thank you so much for keeping us updated. On SSL/TLS problem, how about using them within CDE where data can be send in clear text? Kind regards Shahab
As it turns out, the SSL/early TLS exploits are actually easier to execute on an internal network than it is out in the wild. So I would highly recommend that you do not use SSL or early TLS even on your internal network.
Can you provide a reference for that ? I have a SP to inform SSLv3 for FIM service is not good
It is coming in v3.2 so no one will have it until the Council issues the the version of the PCI DSS.
That said, SSL for a FIM service should be an internal issue, not external. I would like to think you could produce a compensating control worksheet (CCW) for that like a lot of other management interfaces that have issues and will either require an upgrade or the fix from the vendor will not arrive until after the June 30, 2016 deadline.