If you’re looking at compliance as the endgame of your overall security hygiene practices, you’ll be missing out on crucial updates. The looming PCI TLS encryption upgrade offers us a prime case in point.
La conformité et les bonnes pratiques de sécurité vont de pair. Selon l'idée reçue, plus vous respectez les règles, plus votre programme de sécurité informatique sera efficace. Cela vaut que votre organisation utilise la norme PCI-DSS (s'ouvre dans un nouvel onglet), la norme le cadre de cybersécurité du NIST (s'ouvre dans un nouvel onglet), les contrôles de sécurité critiques du CIS (s'ouvre dans un nouvel onglet), ou toute autre réglementation spécifique à votre secteur d'activité, en fonction du type de données sensibles que vous stockez et partagez.
Si le respect des bonnes pratiques de sécurité vous aidera à remplir vos obligations de conformité, l'inverse n'est pas nécessairement vrai. Les exigences de conformité correspondent souvent au niveau de protection le plus bas pour vos données. Si vous considérez la conformité comme l'aboutissement de vos pratiques globales en matière de sécurité, vous passerez à côté de mises à jour essentielles.
Secteur des cartes de paiement
Prenons l'exemple du secteur des cartes de paiement (PCI). Le protocole SSL/TLS est utilisé depuis longtemps comme protocole de chiffrement (s'ouvre dans un nouvel onglet) au sein du PCI. Dans le document « avril 2015 », le PCI Security Standards Council (SSC) a annoncé que le protocole SSL ne serait plus utilisé comme mesure de sécurité et que les organisations seraient tenues de mettre à niveau leur implémentation TLS de la version 1,0 à la version 1,1. Cette mesure visait à combler une lacune en matière de conformité qui permettait l'utilisation de protocoles de chiffrement obsolètes. Certaines de ces versions SSL/TLS dataient de plus de 15 ans et présentaient des failles de sécurité connues.
Il s'agissait essentiellement d'une mise à niveau d'un protocole de sécurité unique, passant de la version 1,0 à la version 1,1 de TLS. Le tout dernier protocole, TLS v. 1,2 (s'ouvre dans un nouvel onglet), défini dans avril 2014, a été recommandé mais n'est pas obligatoire selon le PCI SSC.
Les organisations disposaient initialement d'un délai allant jusqu'au 30 juin 2016 pour se conformer aux exigences de mise à niveau. Mais à l'approche de la date butoir, les organisations commençaient à se rendre compte à quel point il serait difficile de mettre en œuvre cette mesure élémentaire de sécurité. Quelque temps plus tard, avec la publication de la norme PCI DSS v3,2, la date limite pour la mise en œuvre de ces changements a été reportée au 30 juin 2018.
En quoi les exigences de conformité sont insuffisantes
L'exemple du protocole TLS illustre particulièrement bien à quel point les exigences de conformité peuvent s'avérer insuffisantes. Si l'exigence de mise à jour imposée par le PCI SSC visait à combler des failles de sécurité, elle impliquait également que les organisations se retrouveraient cruellement dépassées, même après avoir procédé à la mise à niveau. La version 1,1 du protocole TLS existait déjà depuis neuf ans, en avril 2015 lorsque le PCI SSC a pour la première fois demandé aux organisations de passer à cette version. Le protocole aura presque atteint l'adolescence en 2018, date à laquelle la nouvelle échéance de mise en conformité entrera en vigueur. Bien que la version TLS v.1,2 , légèrement plus récente, ait été définie dans la norme «août 2008 », les organisations seront considérées comme conformes à la norme PCI même sans la mettre en œuvre.
Il s'agit là d'une période extrêmement longue pour assurer la protection de données aussi sensibles que les numéros de carte bancaire et autres informations permettant d'identifier une personne (PII), surtout si l'on considère la fréquence à laquelle nous changeons de téléphone portable, voire de voiture. L'objectif de la norme PCI et d'autres normes de conformité est d'améliorer le niveau de sécurité des organisations en évaluant celui-ci à intervalles réguliers. Mais comme le montre l'exemple de la norme PCI, si vous attendez qu'un organisme professionnel vous impose de mettre en œuvre des mises à niveau, vous vous rendrez compte que votre environnement de sécurité est dangereusement obsolète.
Un programme rigoureux de bonnes pratiques en matière de sécurité aurait conduit les organisations à mettre en œuvre ces mises à jour de chiffrement dès 2008. De cette manière, les organisations adhérant à la norme PCI auraient été conformes à la norme mise à jour bien avant qu'elle ne devienne obligatoire.
Comment Tanium peut vous aider
Pour toute personne utilisant la plateforme Tanium, la gestion de cette mise à jour impliquerait de disposer d'un capteur permettant de détecter les versions TLS, capable d'analyser l'ensemble de votre infrastructure en quelques secondes. À partir de la liste des systèmes détectés, Tanium peut ensuite déployer des paramètres de configuration sur ces terminaux afin de les mettre à jour vers la dernière version, là encore en quelques secondes.
Il est essentiel de considérer l'hygiène de sécurité comme un parcours, et non comme une fin en soi. Vous apprendrez au fur et à mesure et vous adapterez votre stratégie en conséquence. Les normes et réglementations en matière de conformité évoluant chaque année. Tanium permet aux organisations de s'adapter beaucoup plus facilement aux évolutions réglementaires, ce qui n'était pas possible avec les outils de 2008. Tanium étant une plateforme ouverte et extensible, l'ajout de nouveaux contenus – tels que le capteur PCI TLS et les mesures correctives mentionnés ci-dessus – peut vous permettre d'adapter facilement votre dispositif de sécurité en réponse à des changements législatifs ou réglementaires.
À propos de l'auteur : En tant que directeur de la gestion des produits chez Tanium, Alexander Quilter met à profit son expérience dans les domaines de la sécurité d'entreprise et des logiciels d'automatisation des systèmes et des réseaux. Avant de rejoindre Tanium, Alexander a dirigé les activités de gestion des produits pour les gammes de solutions de sécurité et de conformité de Cisco, Lancope, Qualys, nCircle et Opsware. Il est titulaire d'un master en gestion du génie logiciel de l'université Carnegie Mellon et d'une licence en informatique de l'université de l'Utah.
