Le compte à rebours est lancé pour Keyfactor Tech Days | Réservez votre place dès aujourd'hui !

PCI DSS : SSL Exigences en matière de gestion des certificats

Certificats SSL/TLS

Pour les équipes informatiques et de sécurité, la conformité est une priorité absolue. Si vous êtes responsable de la gestion des clés et des certificats dans votre entreprise, vous ne le savez que trop bien.

PCI DSS est l'un des mandats de conformité les plus courants et les plus largement adoptés. En principe, si votre organisation accepte les paiements par carte de crédit ou de débit, la norme PCI DSS s'applique à vous. La bonne nouvelle, c'est que la plupart des 12 exigences de la norme PCI DSS ne sont que des contrôles de sécurité de bon sens que vous devriez déjà avoir mis en place.

Dans ce blog, nous aborderons la norme PCI DSS, ses modifications et la manière de mettre en correspondance les exigences du certificat PCI DSS SSL avec vos pratiques de gestion des clés et des certificats.

PCI DSS : ce que c'est, pourquoi c'est important

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est un ensemble de règles et d'exigences visant à protéger les données sensibles des titulaires de cartes de crédit et des transactions et à faciliter l'adoption à grande échelle de mesures cohérentes de sécurité des données.

La norme fournit une base d'exigences techniques et opérationnelles conçues pour protéger les données financières. L'objectif de la norme PCI DSS est de protéger les données des titulaires de cartes et les données d'authentification sensibles, où qu'elles soient traitées, stockées ou transmises.

La norme PCI DSS s'applique à toutes les organisations impliquées dans le traitement des cartes de crédit, y compris les commerçants, les entreprises de traitement, les acquéreurs, les émetteurs et les fournisseurs de services. La norme est gérée par un organisme indépendant, le PCI Security Standards Council (SSC), créé par Visa, MasterCard, American Express, Discover et JCB.

Voici un aperçu rapide des 12 exigences fondamentales de conformité énoncées dans la norme PCI DSS :

Exigences PCI DSS

La place des certificats et des clés SSL/TLS dans la norme PCI DSS

L'objectif de la norme PCI DSS est de renforcer les contrôles sur les données des titulaires de cartes afin de réduire la fraude par carte de crédit. La norme PCI DSS fournit une couche de protection aux émetteurs de cartes en exigeant des commerçants qu'ils se conforment à des niveaux de sécurité minimaux lors du stockage, du traitement et de la transmission des données des titulaires de cartes.

Les clés et les certificats numériques jouent un rôle essentiel dans la réalisation et le maintien de la conformité à la norme PCI DSS. Ces actifs cryptographiques sont utilisés pour sécuriser les données, préserver la sécurité et la confidentialité des communications et établir la confiance entre les parties qui communiquent, mais ils doivent également être sécurisés et gérés de manière appropriée pour garantir la conformité à la norme PCI.

Décortiquons quelques-unes des exigences essentielles de la norme PCI DSS pour la gestion des certificats SSL/TLS dans votre environnement.

Exigence 2.3 : chiffrer tous les accès administratifs non-console

Si une authentification forte et des communications cryptées ne sont pas mises en œuvre, des informations opérationnelles sensibles ou des comptes privilégiés peuvent être interceptés, par exemple, par une attaque de type "man-in-the-middle". Un acteur malveillant pourrait alors utiliser ces informations pour accéder au réseau de l'entreprise et voler ou compromettre des données financières. Pour établir une "cryptographie forte", la norme PCI DSS exige l'utilisation de protocoles reconnus par l'industrie avec des forces de clés appropriées et une gestion des clés (voir NIST SP 800-52 et SP 800-57).

Capacités de base :

  • Visibilité centralisée des forces, algorithmes et protocoles clés utilisés
  • Flux de travail basés sur des règles pour émettre, fournir, renouveler et révoquer des clés et des certificats
  • Gestion automatisée du cycle de vie des clés et des certificats

Exigence 2.4 : maintenir un inventaire des composants du système

Cette disposition met l'accent sur la visibilité de tous les composants du système, y compris les clés et les certificats. La tenue à jour d'une liste de toutes les clés et de tous les certificats permet à une organisation de définir avec précision et efficacité la portée de son environnement. L'absence d'inventaire se traduira par des certificats erronés, expirés et non suivis. Cela entraîne des pannes importantes ou, pire encore, des failles de sécurité. Cependant, la plupart des organisations ne savent pas combien de clés et de certificats sont activement utilisés dans leur réseau, se fiant souvent à des scripts internes ou à des feuilles de calcul manuelles et sujettes aux erreurs.

Capacités de base :

  • Découverte des certificats sur l'ensemble des terminaux du réseau, des applications, des autorités de certification (AC), des magasins de clés et de certificats.
  • Rapports et alertes sur les certificats erronés, expirés ou non conformes

Exigence 5 : protéger tous les systèmes contre les logiciels malveillants

Bien que cette exigence soit axée sur la protection basée sur le réseau (c.-à-d. anti-virus, anti-malware) pour protéger les machines contre les logiciels malveillants, les campagnes modernes de logiciels malveillants ciblent de plus en plus les identités sensibles des machines, telles que les clés SSH, SSL/TLS et les certificats de signature de code. Les cybercriminels et les groupes de menaces persistantes avancées (APT) exploitent ces clés et ces certificats pour se faire passer pour des personnes de confiance et contourner les défenses.

Capacités de base :

  • Contrôle continu de l'inventaire des clés et des certificats pour détecter les anomalies
  • Politiques adéquates de génération et de stockage des clés privées
  • Contrôles d'accès stricts et protection des clés de signature de code basée sur hardware
  • Flux de travail basés sur des règles pour la création, le déploiement et la rotation des clés SSH

Exigence 7.1 : Limiter l'accès aux composants du système

La norme PCI DSS exige que les entreprises restreignent l'accès aux systèmes et aux données des titulaires de cartes, ce qui implique de limiter l'accès aux identifiants et aux références des utilisateurs privilégiés, y compris les clés et les certificats. L'application des restrictions de moindre privilège à l'utilisation et à l'accès à vos ressources cryptographiques limitera l'étendue des dommages causés par un accès non autorisé. Sans une protection adéquate, les attaquants peuvent utiliser des clés et des certificats de confiance pour élever leurs privilèges et se déplacer latéralement d'une machine à l'autre.

Capacités de base :

  • Permissions basées sur les rôles pour l'émission et l'utilisation des clés et des certificats
  • Surveillance et correction automatisées des clés et des certificats non autorisés

Exigence 8.6 : Identifier et authentifier l'accès aux composants du système

Enfin, l'exigence 8.6 est liée à la fonction d'authentification fournie par les certificats. Les certificats permettent une authentification simple et puissante, mais ils doivent être attribués à un compte ou à un utilisateur individuel, et non partagés. La mise en place de contrôles permettant d'identifier de manière unique le propriétaire d'une clé ou d'un certificat (et d'y mettre fin ou d'en changer la propriété en cas de départ) empêchera les utilisateurs non autorisés d'obtenir un accès à l'aide d'un mécanisme d'authentification partagé.

Capacités de base :

  • Possibilité d'attribuer et de suivre la propriété des clés et des certificats
  • Possibilité de rechercher et de révoquer facilement des certificats dans votre inventaire

Modification des exigences du protocole SSL/TLS

Que vous soyez directement impliqué dans la gestion des certificats SSL/TLS ou non, il est important de comprendre la nécessité du cryptage web et son impact sur votre activité.

Il est également important de comprendre pourquoi les protocoles de cryptage sur lesquels nous nous appuyons aujourd'hui seront inévitablement peu sûrs à l'avenir. Comment le savons-nous ? Parce que les vulnérabilités de SSL et des premiers protocoles TLS ont donné lieu à de nombreux exploits, tels que Heartbleed et POODLE. Les pirates cherchent à exploiter ces protocoles obsolètes pour infiltrer les réseaux et compromettre les données sensibles des titulaires de cartes.

En conséquence, les exigences PCI DSS pour SSL/TLS ont changé pour suivre le rythme. Nous examinerons ici comment les exigences relatives à la migration vers SSL/TLS sont passées de PCI DSS v3.0 à PCI DSS v3.2 aujourd'hui.

PCI DSS v3.0

Lorsque la norme PCI DSS v3.0 est entrée en vigueur le 1er janvier 2014, le document soulignait que "certaines implémentations de protocoles (telles que SSL v2.0, SSH v1.0 et TLS 1.) présentent des vulnérabilités connues qu'un attaquant peut utiliser pour prendre le contrôle du système affecté". Cependant, il n'y a pas d'obligation d'utiliser des protocoles plus récents.

PCI DSS v3.1

Peu après l'entrée en vigueur de la norme PCI DSS v3.0, la nouvelle norme PCI DSS v3.1 a été introduite en avril 2015. L'un des éléments clés de cette nouvelle version est la mise en place d'exigences plus strictes concernant l'utilisation de TLS.

La nouvelle version obligeait les organisations à désactiver SSL 3.0 et les versions antérieures de TLS (1.0) avant le 30 juin 2016. Toutefois, la date limite a été repoussée au 30 juin 2018.

PCI DSS v3.2

La version la plus récente est PCI DSS v3.2 (à la date de publication de ce blog). La version 3.2 a été introduite en avril 2016 et a officiellement remplacé la version 3.1 le 1er février 2018 en tant que norme à suivre.

La nouvelle date limite du 30 juin 2018 a été incluse dans la norme PCI DSS v3.2, qui exige la migration vers TLS 1.1 ou une version ultérieure, à l'exception de certains terminaux de paiement (POI).

Ce qu'il faut attendre de la norme PCI DSS v4.0

PCI SSC a commencé à développer PCI DSS v4.0, dont la version finale est actuellement attendue pour la mi-2021. La nouvelle version devrait être un document axé sur les résultats, en remplaçant l'expression "doit mettre en œuvre" par "le résultat est". Elle mettra également davantage l'accent sur la sécurité en tant que processus continu qui s'intègre à la posture globale de sécurité et de conformité d'une organisation.

D'autres changements interviendront :

  • Authentification, en particulier prise en compte des directives NIST MFA/mot de passe
  • Application élargie du cryptage des données des titulaires de cartes sur les réseaux de confiance
  • Exigences en matière de suivi pour tenir compte des progrès technologiques
  • Augmentation de la fréquence des tests des contrôles critiques

L'importance de l'automatisation du cycle de vie des certificats

Si une seule clé ou un seul certificat est compromis, la confiance numérique dans votre organisation est ébranlée. Malgré ce problème croissant, la plupart des organisations utilisent encore des scripts internes ou des feuilles de calcul manuelles pour assurer le suivi de leurs clés et de leurs certificats. Les équipes de sécurité ne disposent pas de la visibilité et de l'automatisation nécessaires pour anticiper les pannes potentielles, les incidents de sécurité et, surtout, les exigences en matière de sécurité et d'audit.

Le problème est multiplié par le nombre de clés et de certificats dans l'entreprise aujourd'hui, car les environnements multi-cloud modernes en introduisent des milliers d'autres dans le mélange. Cette infrastructure hybride crée également une plus grande surface d'attaque, augmentant le risque de vol ou de compromission des données de cartes de crédit.

Les approches traditionnelles de la gestion des clés et des certificats ne peuvent tout simplement pas suivre le rythme de la croissance et des changements rapides de ces nouveaux déploiements DevOps et multi-cloud. Une nouvelle approche est nécessaire, une approche qui permet à votre organisation d'automatiser et d'évoluer tout en conservant un contrôle total sur le cycle de vie des clés et des certificats, où qu'ils se trouvent.

Une approche automatisée des identités cryptographiques et des autorisations sur les données des cartes de crédit est une étape cruciale pour respecter et maintenir la conformité à la norme PCI DSS. La norme PCI DSS insiste sur le fait que la conformité doit être la stratégie de sécurité habituelle de l'organisation.

Pour assurer des politiques de sécurité normales, la gestion entièrement automatisée des clés et des certificats est indispensable à l'approvisionnement en cryptage de bout en bout dans le secteur financier moderne. L'automatisation élimine les vulnérabilités créées par les processus manuels longs et sujets aux erreurs, et permet une mise à l'échelle. Elle permet également une remédiation rapide, de sorte que les erreurs et les oublis ne se transforment pas en brèches ou en pannes importantes.

Contrôlez vos clés et vos certificats

Découvrez pourquoi les leaders des services bancaires et financiers de Fortune 500 font confiance à Keyfactor pour soutenir leurs initiatives de conformité PCI et fournir une automatisation de bout en bout de PKI et du cycle de vie des certificats.