SSL and TLS Update

[steven36]

​

At the beginning of March, a new vulnerability to SSL and TLS was announced called FREAK. This compounded the announcement last fall of POODLE that caused the PCI SSC to abruptly call SSL and “early” TLS (i.e., TLS versions 1.0 and 1.1) as no longer acceptable as secure communication encryption.

​

In April, the PCI SSC issued v3.1 of the PCI DSS and gave us their take on how to address POODLE. Their plan is to have organizations remediate SSL and “early” TLS as soon as possible but definitely by June 30, 2016. While remediating SSL and “early” TLS, organizations are required to have developed mitigation programs for these protocols until they are remediated.

​

There are some exceptions to the June 30, 2016 deadline for devices such as points of interaction (POI) but those exceptions are few and far between and still require some form of mitigation.

​

Reading the explanations for the POODLE and FREAK vulnerabilities, while they are technically possible over the Internet, they are much more realistic to be performed successfully internally. As such, these vulnerabilities are more likely to be used as part of an attacker’s toolkit when compromising a network from the inside. This is not good news as an organization’s internal network is much more vulnerable since a lot of appliances and software have SSL and TLS baked into their operation and will not be quickly remediated by vendors, if they are remediated at all (i.e., you will need to buy a new, upgraded appliance). As a result, organizations need to focus on their internal usage of SSL and “early” TLS as well as external usage.

​

The remediation of these vulnerabilities on the Internet facing side of your network should be quick. Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications.

​

While I do know of a few rare situations where taking such action cannot be taken, most organizations can simply turn off SSL and TLS v1.0/1.1 and be done with the remediation.

​

As I pointed out earlier, it is the internal remediation that is the problem. That is because of all of the appliances and software solutions that use SSL/TLS and vendors are not necessarily addressing those issues as quickly. As a result the only approach is to mitigate the issues with appliances that are at risk. Mitigation can be as simple as monitoring the appliances for any SSL or TLS v1.0/1.1 connections through log data or using proxies to proxy those connections.

​

The answer to SSL and TLS vulnerabilities are to remediate as soon as possible. If you are unable to remediate, then you need to mitigate the risk until you can remediate.

​

​Source

​

[DLord]

"Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications."

Well you realize that won't be easy at all, considering the current extensive use of many applications/appliances of those services. Relying on software vendors to issue updates to their software/code to address the issue also is not realistic as most likely will take a long time, if happens at all.

I wonder how extensively these vulnerabilities will be exploited until the mentioned deadline, if that deadline is taken seriously by organizations at all. The most important and worrisome of all is the POIs as mentioned, which at the same time will be the most challenging task to update and make secure.

Thank you for the post and the information mate.