This Just In – SSL Conversion Deadline Has Changed

This is hot off the presses from the PCI SSC.

I’m not sure I necessarily like this decision, but I can appreciate what is driving it.  That said, I think the better approach would have been to have organizations do compensating controls for keeping SSL around.

Read the update for yourself.



6 Responses to “This Just In – SSL Conversion Deadline Has Changed”

  1. February 3, 2016 at 8:16 AM

    Does anyone have an example of what an appropriate compensating control would be for the usage of SSL 3.0?

    • February 7, 2016 at 11:08 AM

      That is the $64,000 question these days. Most of the ones that I have encountered are internally focused and come down to monitoring usage and restricting access. I have yet to see one justifying keeping SSL v3 running for external users.

  2. 3 Kyle
    December 24, 2015 at 11:16 PM

    They should have kept SSL 3.0 on the current timeline and only applied the extension to “early TLS”.

    SSL 3.0 is wrecked whereas TLS 1.0 is still secure when properly configured. I imagine any device made in the last 10-15 years supports at least TLS 1.0.

  3. December 21, 2015 at 2:08 PM

    Argh! I have mixed emotions about this one. Yes, moving to TLS 1.1/1.2/1.3 is the right move from an information security perspective. Yes, the timeline for the move was aggressive for some (just over a year from the April guidance). Yes, my stress levels are much lower now that we have some breathing room. But, I’m concerned about the risks.

    • 5 Erik
      December 23, 2015 at 4:26 AM

      The Poodle vulnerability was disclosed in October 2014. Technically, all PCI DSS compliant organisations should (according to requirement 6.1 and 6.2) have discovered and fixed the problem or implemented compensating controls before december 2014. In theory, no additional guidance from the PCI Council should have been necessary, it’s just basic PCI compliance.

      With the original deadline in PCI DSS 3.1, organisations were effectively given an extension of about 20 times longer than normal to fix a security vulnerability. The new deadline gives organisations more than 3.5 years to fix a critical security vulnerability. Not particularly agressive, IMHO.

      • December 23, 2015 at 3:15 PM

        “Fixed” is in the eye of the beholder. Under the PCI DSS, POODLE needed to either be remediated or mitigated. Remediation involved removing SSL and “early TLS” from allowed protocols, something not every organization could do. If POODLE could not be remediated, then the risk needed to be mitigated with enhanced monitoring or other techniques.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

December 2015

%d bloggers like this: