Comment créer un inventaire de certificats pour l'exigence 4.2.1.1 de PCI DSS 4.0

Nous échangeons quotidiennement avec des organisations qui se préparent aux exigences de PCI DSS 4.0. Le 31 mars 2025 marque la fin de la période de transition, et à cette date, les entreprises devront être entièrement conformes à PCI DSS v4.0.1.

L'une des différences entre PCI 4.0.1 et PCI 3.2 concerne l'exigence 4 mise à jour, qui porte sur le chiffrement des transmissions de données des titulaires de carte sur les réseaux publics afin de protéger les informations sensibles contre tout accès et interception non autorisés. Le PCI Security Standards Council décrit ce changement comme un moyen de « refléter l'importance accordée à une ‘cryptographie forte’ pour protéger les transmissions de données des titulaires de carte ».

Voyons en détail ce qui a changé, ainsi que la meilleure façon de créer un inventaire de certificats pour être conforme à PCI DSS 4.0 avec le moins d'effort possible.

Dans la version v4.0.1, le PCI Security Standards Council a ajouté des éléments à l'exigence 4. Ce blog sera consacré à l'exigence 4.2.1.1, qui stipule :

« Un inventaire des clés et certificats de confiance de l'entité utilisés pour protéger le PAN pendant la transmission est maintenu. »

Cette exigence est considérée comme une bonne pratique jusqu'au 31 mars 2025, date après laquelle elle deviendra obligatoire et devra être pleinement prise en compte lors d'une évaluation PCI DSS.

En disposant d'un inventaire, une organisation peut surveiller ses actifs cryptographiques essentiels ainsi que les dates d'expiration des clés. Ce suivi proactif permet à l'organisation de traiter les vulnérabilités identifiées dans les logiciels de chiffrement, les certificats et les algorithmes cryptographiques.

Le PCI Security Standards Council précise également qu'il est recommandé que l'inventaire des certificats inclue l'autorité de certification émettrice ainsi que la date d'expiration du certificat.

Nous allons passer en revue plusieurs façons de créer votre inventaire de certificats. Toutes les méthodes abordées ici s'articulent autour de cinq étapes clés :

1. Prioriser les actifs concernés en fonction des exigences PCI. Cela inclut les certificats des actifs appartenant à des tiers, comme les passerelles de paiement présentes sur votre site.
2. Utiliser des identifiants pour suivre les certificats concernés.
3. Une fois le périmètre défini, vous pouvez exporter les rapports des actifs pour obtenir un inventaire complet et exhaustif des certificats.

L'approche la plus adaptée dépendra de l'état actuel de votre parc de certificats, de sa complexité, ainsi que des ressources que vous consacrez à sa gestion et à la conformité avec PCI 4.0.1.

Les tableurs sont couramment utilisés par les organisations pour suivre et gérer leur parc de certificats, et pourraient servir d'inventaire pour l'exigence 4.2.1.1.

Si une organisation utilise déjà des tableurs pour suivre ses certificats, créer une version similaire pour suivre les certificats utilisés afin de protéger le PAN pendant la transmission peut constituer une solution acceptable pour satisfaire l'exigence de PCI 4.0.

Bien que ce ne soit pas l'approche la plus sophistiquée, elle peut fonctionner à condition d'assurer une mise à jour rigoureuse et de disposer de ressources dédiées au suivi manuel. Si une équipe est déjà surchargée et manque d'effectifs pour maintenir le tableur à jour, cette approche n'est pas adaptée.

Cette approche n'est pas non plus adaptée si vous utilisez actuellement un tableur mais qu'il est obsolète ou incomplet. Il vous faudra alors une solution automatisée pour repartir sur un inventaire à jour. Nous y reviendrons plus loin.

1. Définir les champs de données requis. Identifiez tous les points de données nécessaires à suivre pour chaque certificat. Cela inclut par exemple :Nom/ID du certificat : un identifiant unique pour chaque certificat.Émetteur : l'autorité de certification (CA) ayant délivré le certificat.Sujet : l'entité pour laquelle le certificat a été émis (par exemple, le nom de domaine).Type de certificat : SSL/TLS, signature de code, certificat client, etc.Force de la clé : la robustesse cryptographique du certificat (par exemple, RSA 2048 bits).Algorithme utilisé : l'algorithme cryptographique employé (par exemple, RSA, ECC).Période de validité : dates de début et de fin du certificat.Date d'expiration : la date à laquelle le certificat arrivera à expiration.Responsable des clés : la personne ou l'équipe en charge de la gestion du certificat.Utilisation : l'application ou le système spécifique où le certificat est utilisé.Statut de révocation : si le certificat a été révoqué.Statut de renouvellement : indication sur l'éventuel renouvellement du certificat.Notes de vulnérabilité : toute vulnérabilité connue liée au certificat ou aux algorithmes associés.Commentaires/Notes : remarques ou actions supplémentaires relatives au certificat.
2. Renseigner le tableur. Saisissez les informations de chaque certificat dans la ligne et la colonne correspondantes.
3. Mettre en place une mise en forme conditionnelle. Configurez une mise en forme conditionnelle pour signaler les certificats proches de leur expiration (par exemple, surligner en rouge ou en jaune les certificats expirant dans les 30 ou 60 prochains jours).
4. Créer des rappels et des alertes. Utilisez des fonctions du tableur pour calculer le nombre de jours restants avant expiration et générer automatiquement des alertes ou des rappels pour les certificats à renouveler.
5. Effectuer des revues et mises à jour régulières. Planifiez des revues régulières du tableur pour vous assurer que toutes les informations sont à jour. Mettez à jour le tableur à chaque émission, renouvellement ou révocation de certificat.
6. Sécuriser le tableur. Assurez-vous que le tableur est stocké de manière sécurisée, avec un accès limité aux personnes autorisées. S'il contient des informations sensibles, envisagez de le chiffrer ou de le stocker dans un environnement sécurisé et conforme à PCI.

Les outils de gestion du cycle de vie des certificats (comme AppviewX et Venafi) ont été conçus pour automatiser l'émission, le renouvellement et le déploiement des certificats. Étant donné le nombre d'étapes du processus – et les erreurs qui peuvent en découler – les CLM se sont imposés comme un moyen pour les professionnels de la sécurité et de l'IT de maîtriser leur parc de certificats.

Par conception, les CLM doivent avoir un périmètre complet afin de pouvoir signer, valider, émettre, déployer, révoquer et générer des rapports sur un certificat. Pour les utilisateurs existants d'un CLM, ces outils disposent de fonctionnalités permettant de satisfaire l'exigence 4.2.1.1 de PCI.

Certains CLM permettent également d'inventorier les clés de confiance, ce qui constitue un autre volet de l'exigence 4.2.1.1.

Pour ceux qui ne disposent pas encore d'un CLM, en déployer un peut s'avérer lourd et consommateur de ressources (avec des manuels d'utilisation pouvant atteindre 2 761 pages).

L'autre scénario dans lequel les CLM peuvent s'avérer peu adaptés concerne les parcs de certificats complexes nécessitant des scénarios de découverte élaborés. Bien que les CLM proposent une découverte automatisée, l'amorçage, les intégrations et les méthodes de découverte peuvent demander du temps à configurer et risquent de passer à côté de certificats critiques.

Le processus exact varie selon l'outil CLM que vous utilisez. Nous allons décrire ici, de manière générale, les étapes à suivre quel que soit l'outil utilisé.

1. Commencer par la découverte des certificats. Selon l'outil CLM utilisé et l'état d'avancement de votre gestion des certificats, ce processus peut être plus ou moins consommateur de ressources. Consultez la documentation de votre fournisseur CLM pour intégrer les autorités de certification et analyser votre infrastructure afin de vous assurer que tous les certificats relevant du périmètre de PCI 4.0 sont bien découverts.
2. Commencer par l'inventaire du CLM. Ces outils offrent un référentiel centralisé permettant de découvrir, d'inventorier et de gérer les certificats à l'échelle de votre organisation. Certains CLM peuvent s'intégrer à diverses autorités de certification (CA) pour importer les détails des certificats.
3. Exploiter les journaux d'audit et les rapports de conformité. La plupart des plateformes CLM conservent des journaux d'audit détaillés de toutes les actions effectuées sur les certificats. Certaines peuvent également générer des rapports de conformité alignés sur les exigences de PCI DSS, facilitant ainsi la démonstration de la conformité lors des audits.

Nous sommes évidemment partiaux, mais nous pensons qu'un outil de surveillance des certificats – comme Red Sift Certificates – est l'une des meilleures façons de créer votre inventaire de certificats pour répondre à l'exigence 4.2.1.1.

Red Sift Certificates est adapté aux entreprises qui ne sont pas certaines d'avoir une visibilité complète sur leur inventaire actuel de certificats. En effet, Red Sift Certificates est le seul outil sur le marché à surveiller les journaux de transparence des certificats (CT Logs) en temps réel afin de détecter chaque certificat dès son émission. À ce jour, Red Sift Certificates a traité plus de 7 milliards de certificats. Sa surveillance de configuration et de déploiement est assurée depuis 10 emplacements répartis dans le monde entier.

Pour ceux qui s'inquiètent de l'expiration des certificats, cette surveillance des journaux CT permet également de conserver des informations constamment à jour sur les certificats déployés. Red Sift Certificates convient à ceux qui disposent déjà d'une solution d'automatisation de la rotation des certificats, ou qui en recherchent une.

Il est toutefois important de noter que, contrairement aux CLM, Red Sift Certificates n'automatise pas le processus de renouvellement.

Créer un inventaire de certificats pour l'exigence 4.2.1.1 de PCI est simple avec Red Sift Certificates.

1. Découvrez tous vos certificats. Saisissez un seul domaine de départ et Red Sift Certificates identifiera l'ensemble des certificats de votre organisation. Nous savons que cela peut sembler trop beau pour être vrai, mais avec un seul domaine, Red Sift Certificates peut créer un inventaire complet de tous les certificats détenus, tiers, auto-signés et privés visibles sur Internet. L'application y parvient en découvrant puis en surveillant tous les noms d'hôte et plages réseau appartenant à votre organisation. Nous pouvons même nous connecter à votre instance de cloud computing. Et surtout, tout cela peut se faire en moins d'une heure.
2. Étiquetez tous les certificats concernés par PCI. À l'aide de groupes ou de tags simples, vous pouvez annoter les certificats relevant du périmètre de l'exigence 4.2.1.1, afin de faciliter vos rapports.
3. Exportez selon vos besoins. Exportez votre inventaire au format .csv, .xls ou JSON pour documenter l'inventaire. Cela peut se faire en fonction du temps écoulé depuis le dernier export, ou dès qu'un changement survient, selon les préférences et besoins de l'utilisateur.

Si vous souhaitez créer un inventaire de certificats et pensez que Red Sift Certificates pourrait être la bonne solution pour votre organisation, contactez-nous ou réservez une démo. Notre équipe se fera un plaisir de vous aider à constituer votre inventaire avant l'échéance de PCI 4.0.1.

Si vous avez des questions sur les futures exigences cryptographiques de PCI 4.0.1, regardez notre webinaire à la demande pour en savoir plus.