Le PCI SSC nous propose quelques pistes pour envisager une migration en...douceur

Depuis l’annonce du standard 3.1 de PCI DSS, les différents acteurs se posent la question « Comment migrer mes composants SSL/TLS d’ici Juin 2016« . Je me suis appuyé sur le document du PCI SSC qui apporte quelques axes de réflexions. Cela fait maintenant 20 ans que nous utilisons SSL sur Internet.

Ce protocole de chiffrement est aujourd’hui fortement répandu et dépit des actualités sur les diverses vulnérabilités présentes dans le protocole. Depuis une quinzaine d’année SSL v3.0 a été remplacé par TLS v1.0 qui depuis à évoluer vers TLS v1.1 et v1.2 à ce jour. Le protocole SSL à migrer vers TLS suite à de nombreuses vulnérabilités dont il n’était pas possible de corriger. Il est important et critique de remplacer d’ici Juin 2016 les chiffrements SSL & TLS d’ici là. Le standard PCI DSS ne peut supporter un niveau aussi faible de durcissement et exposer à de nombreuses vulnérabilités. Cela nous laisse 14 mois soit demain dans le monde des fournisseurs de paiements PCI DSS.

 

Identifions le risque

SSL/TLS chiffre un canal entre deux composants (par exemple un navigateur Web et un serveur Web) pour assurer la confidentialité et l’intégrité des données transmises sur ce réseau (Communication Channel). Depuis la sortie de SSL v3.0 plusieurs vulnérabilités ont été identifiées, et plus récemment à la fin de l’année 2014 des chercheurs mettent en avant des vulnérabilités de sécurité (CVE-2014-3566) qui pourrait permettre à des attaquants afin d’extraire des données/Informations sur ce réseau chiffré malgré la présence d’un cadenas sur le navigateur (Version Mme Michue). On peut se souvenir de POODLE qui permet d’exploiter une vulnérabilité du type man-in-the-middle ou il est possible de déchiffrer un message sur un réseau sécurité par SSL v3.0.

La conclusion du PCI Council est que le protocole SSL (Toutes versions confondues) ne peut être corrigé. Il n’y a aucune méthode connue pour réellement ce proteger contre la vulnérabilité POODLE (Avril 2015). Le protocole SSL/TLS ne répond plus aux exigences de sécurité pour permettre la protection des données sur les réseaux publiques (Internet pour ne pas le nommer). Ce qui est intérressant c’est que le Council nous autorise à utiliser SSL/TLS sur nos réseaux d’entreprises qui sont aussi exposé au risque (la première source de compromission est l’interne, Target s’en souvient encore…).

Les navigateurs Web sont en phases de réflexions d’interdire les connexions SSL (je demande à voir quand même) et utiliser un protocole plus moderne.

La problématique de migration, Comment y répondre ?

Le PCI Council demande de désactiver SSL entièrement et de migrer vers un protocole de chiffrement moderne qui est au moment de la publication TLS v1.1 (Je recommande fortement la version TLS v1.2, passer deux audits PCI DSS haut la main avec ceux-ci). Il est intéressant que le PCI Council nous encourage fortement à migrer en TLS v1.2 et que le NIST considère que TLS v1.1 est sure (NIST-SP-800-52 rev 1) pour obtenir des configurations sécurisés via ce protocole.

 Pour nous qui utilisons PCI DSS Kesako cette nouvelle(s) exigence(s)?

Suite à la sortie de la version 3.1 du standard PCI DSS ce mois-ci (Avril 2015), SSL et TLS ne sont plus autorisés dans le cadre de solutions de chiffrement fort ou de protocoles sécurisé. Les exigences suivantes sont directement touchées:

Exigence 2.2.3
Mettre en oeuvre des fonctions de sécurités supplémentaires pour les services, protocoles ou démons qui sont considérées comme étant non sécurisées.

Exigence 2.3
Chiffrer toutes les consoles qui permettent un accès avec les privilèges d’administrations avec un chiffrement fort.

Exigence 4.1
Utiliser des protocoles de chiffrement et de sécurité robustes pour protéger les données sensibles des titulaires de cartes pendant la transmission sur les réseaux publiques.

SSL et TLS ne sont plus considérés comme des protocoles de chiffrement fort et ne pourront être utilisé après le 30 Juin 2016 dans le cadre de PCI DSS. Avant cette date butoir, les implémentations existantes qui utilisent SSL et/ou TLS doivent/prévoir d’avoir un plan de migration ainsi qu’une réduction du risque via un Risk Mitigation Plan. A compter de maintant les nouvelles implémentations ne doivent plus utiliser SSL ou TLS. Les terminaux (POS/POI) peuvent utilisés SSL et TLS à la condition qu’ils ne soient pas exposés à des exploits connus.

Enjoy PCI DSS 🙂