Conformité PCI-DSS: Etes-vous paré aux derniers changements?

Si votre organisation accepte les cartes

Si votre organisation accepte les cartes de crédit en ligne, c’est que vous êtes probablement très familier avec la norme PCI-DSS (Payment Card Industry Data Security Standard). Depuis fin 2004, ce standard de sécurité des données des cartes de paiement – incluant la prévention, la détection et la réponse aux incidents – évolue. Les domaines couverts par le PCI-DSS sont étendus et vont de l’installation et la maintenance d’une configuration de pare-feu à la surveillance des accès aux ressources du réseau, et inclut même des tests des applications Web, le tout pour protéger les données du titulaire. Un élément clé des exigences de la norme est l’analyse trimestrielle des vulnérabilités; à la fois pour détecter et signaler les menaces potentielles. Depuis le 1er Janvier 2012, la version 2.0 de la norme PCI-DSS, met fortement la mise en place de scans pour éradiquer les différentes failles et vulnérabilités. Depuis le 30 Juin 2012, les conditions 6.2 et 6.5.6, considérées jusque-là comme de bonnes pratiques, sont désormais obligatoires.

Des directives de codage sécurisé

La condition 6.2 demande qu’une organisation “établisse un processus pour identifier et assigner un classement des risques aux nouvelles vulnérabilités de sécurité découvertes” affectant l’environnement des titulaires de cartes (Cardholder Data Environment ou CDE). Les procédures d’évaluation précisent que les classements des risques doivent se baser sur les bonnes pratiques de l’industrie. Pour les organisations qui élaborent le classement des risques et le système de classification, ces bonnes pratiques se traduisent par une approche qui établit des priorités de correction des vulnérabilités; comme un modèle à trois niveaux (Elevé-Moyen-Faible) ou une échelle décimale (de 5.0 à 1.0). Par exemple, les critères de classement des vulnérabilités à ‘haut’ risque peuvent comprendre un score CVSS (Common Vulnerability Scoring System, système de notation de vulnérabilité commun) de 4.0 ou plus, et/ou un correctif proposé par le fournisseur classé comme ‘critique,’ et/ou une vulnérabilité affectant un composant essentiel du système. Implémenter ce système de classement des risques au sein du processus de gestion des vulnérabilités de votre organisation est important; le scan n’est pas un programme de gestion des vulnérabilités en soi. Pour les applications développées en interne et déployées dans l’environnement CDE d’une organisation, la condition 6.5.6 rend obligatoire le test des vulnérabilités classées à ‘haut’ risque dans le cadre du processus de développement d’applications sécurisées. Les applications doivent toujours être développées sur la base des directives de codage sécurisé telles qu’elles sont définies par la condition 6.5. Cela inclut les vulnérabilités de codage les plus courantes définies dans les sous-conditions 6.5 ainsi que les bonnes pratiques de l’industrie telles que le Top 10 OWASP. Depuis le 30 Juin, les organisations doivent également s’assurer que les directives de codage sécurisées se chargent de “toutes les vulnérabilités ‘Elevées’ identifiées dans le processus d’identification des vulnérabilités (tel que cela est défini au point 6.2 du PCI DSS).”

Pour les fournisseurs d’outils de scan, le PCI exige d’être plus proactif et préventif face aux vulnérabilités. Historiquement, les fournisseurs certifiés PCI n’étaient pas tenus d’avertir automatiquement le client de leur vulnérabilité (après découverte d’une telle vulnérabilité); avec la condition 6.2 qui devient obligatoire, ces mêmes fournisseurs doivent désormais également mettre à jour leur logiciel pour veiller à ce que les problèmes soient détectés dans les futurs scans. La composante de classement est en partie dépendante de chaque fournisseur ainsi que de la manière dont ils mesurent les différents résultats, mais cela signifie que plutôt d’attendre qu’une autre organisation assigne le niveau de gravité d’une vulnérabilité spécifique, les fournisseurs doivent désormais lui attribuer au moins un classement provisoire lors de son identification. Comme on pouvait s’y attendre étant donné la complexité et la confusion associées autour de la conformité PCI, il y a des conditions supplémentaires à la fois directement et indirectement posées par les exigences 6.2 et 6.5.6 qui deviennent obligatoires. Elles incluent la vérification que les bases de sécurité minimum exigée par la condition 2.2 soient mise à jour et qu’un scan soit effectué de manière répétée jusqu’à ce que toutes les vulnérabilités classées comme ‘Elevées’ et obtenant un score supérieur à 4.0 par le CVSS tel qu’il est défini au point 6.2 du PCI DSS soient résolues. En outre, lorsqu’un évaluateur de sécurité qualifié (QSA) est engagé, des documents supplémentaires liés aux conditions 6.2 et 6.5.6, incluant la politique de gestion des vulnérabilités, le classement des risques ou la méthodologie de classification des risques seront attendus.

Qu’est-ce que ce changement signifie pour ceux qui sont impliqués? Si vous suivez déjà les bonnes pratiques, peut-être très peu du point de vue du respect de la conformité, mais pour les commerçants en ligne, l’application de ce changement devrait permettre de détecter des failles qui avaient tendance à rester inaperçues, évitant avec un peu de chance un plus grand nombre d’injections XSS, SQL ainsi que d’autres attaques. Pour les fournisseurs d’outils de scan, l’effet de ce changement résulte dans une plus grande efficacité dans la détection et la notification au client. Dans l’ensemble, veiller à ce que ces conditions soient respectées ne réduiront pas seulement le risque de perdre la conformité à la norme PCI-DSS v2.0 mais sécuriseront davantage les données des titulaires des cartes de crédit.