Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

PCI-DSS 3.0 : ce qui va changer

auteur de l'article Jerome Saiz , dans la rubrique Conformité & Bonnes pratiques

Commentaires Commentaires fermés sur PCI-DSS 3.0 : ce qui va changer

Dans à peine plus d’un mois les cyber-marchands pourront découvrir les nouvelles exigences de PCI-DSS, troisième du nom. La version 2.0 restera valable jusqu’à la fin 2014 afin d’assurer une transition en douceur, mais les marchands qui le souhaitent pourront choisir dès le 7 novembre 2013 d’être audités sur la base de PCI 3.0.

Cette troisième édition semble être placée sous le signe du « serrage de boulons » et du bon sens. Le Conseil lui-même citait d’ailleurs cinq faiblesses principales de la version précédente, qui ont guidé les réflexions pour cette troisième incarnation de PCI DSS :

  • Le manque de sensibilisation et d’information
  • La faiblesse des mots de passes, les mauvaises pratiques d’authentification
  • Les faiblesses introduites par l’interaction avec des outils tiers
  • La difficulté de détecter correctement, et de traiter, les infections virales
  • Des audits inconstants

On retrouve dans cette liste de vieilles rengaines sécuritaires (sensibilisation, mots de passe, virus…) dont on entend souvent qu’elles vont sans dire… mais, qu’elles vont encore mieux en le disant ! Et c’est bien en cela que cette troisième version du standard est celle du bon sens.

Globalement, le texte a pour ambition d’aider les marchands à mieux sensibiliser leurs partenaires et leurs utilisateurs, à leur offrir un peu plus de souplesse dans certains contrôles, une meilleure visibilité sur leur périmètre et les systèmes concernés, et surtout il prend enfin en compte officiellement le fait que PCI DSS n’est pas qu’une affaire d’informatique interne mais souvent une responsabilité partagée entre plusieurs acteurs (sous-traitants, hébergeur, etc…).

Bien entendu, tout ceci restera une liste d’intentions creuses si les obligations qui en découlent ne reflètent pas concrètement ces objectifs. Bien que nous n’ayons pas eu accès à la version de travail, le document préalable publié cet été par le Conseil semble offrir quelques bonnes idées :

  • L’obligation de définir clairement le périmètre PCI. Cela « allait sans dire » jusqu’à présent (car on se demande comment être conforme sans avoir au préalable défini le périmètre), mais il est désormais obligatoire de maintenir un inventaire des systèmes soumis à PCI
  • L’obligation de créer un « data flow » : un support visuel qui montre exactement, pour chaque étape d’une transaction, les systèmes qui fournissent des données et ceux qui les reçoivent. Cette obligation va au delà de la simple définition du périmètre (ci-dessus) car elle exige de se pencher en détail sur le rôle et le fonctionnement de chaque système. Les bons élèves le faisaient déjà, maintenant tout le monde devra s’y coller
  • La prise en compte plus stricte de la sécurité physique des terminaux de paiement. Le risque n’est certes pas nouveau (Visa mettait d’ailleurs les commerçants en garde dès 2010), mais l’on a assisté dernièrement à une recrudescence des attaques physiques contre ces outils, qui sont régulièrement piégés par les pirates directement dans les boutiques (et même dans des restaurants parisiens, nous ont confiés des enquêteurs…)
  • Prise en compte de l’authentification forte (cartes à puce, tokens, etc…)
  • Clarification du partage de responsabilité entre l’entreprise et ses fournisseurs ou ses sous-traitants (écrire noir sur blanc les responsabilités de chacun). Là encore beaucoup le font déjà, mais cela va mieux en l’écrivant
  • Rappel du fait que les informations d’authentification (SAD : le contenu de la piste magnétique, les codes PIN ou CVV) ne doivent *jamais* être stockées, même si le PAN (primary account number) n’est pas présent. Encore une fois c’est une évidence (d’ailleurs les SAD ne doivent jamais être stockées), mais cela va mieux en le disant

Pour d’autres, en revanche, on préfèrera attendre la version complète du standard avant de se prononcer, tant ces obligations semblent difficiles à justifier efficacement :

  • Plus de souplesse dans ce qui constitue un « bon » mot de passe, a robustesse équivalente. Hélas à moins d’être un expert en cryptographie il est difficile d’évaluer la robustesse comparée de deux mots de passe similaires…
  • Se tenir à jour des menaces malwares y compris pour les systèmes qui ne sont pas habituellement visés par des malwares. L’intention d’exhaustivité est louable mais l’on attend de voir comment les veilleurs vont prouver qu’ils veillent efficacement dans un domaine où il ne se passe rien
  • Se tenir à jour des nouvelles vulnérabilités (listes OWASP, NIST, SANS, etc…). Mais il reste à définir à partir de quel moment on est « à jour », et comment le prouver

Enfin, notre point préféré, dont nous n’arrivons pas à décider s’il s’agit d’un coup de génie ou d’un coup d’épée dans l’eau : PCI-DSS 3.0 devrait apporter des conseils afin de mieux intégrer la sécurité dans l’activité quotidienne de l’entreprise (« implementing security into business-as-usual activities« ) et aider à rester conforme dans la durée. Et le Conseil d’affirmer sans rire que ce point a été spécifiquement ajouté en réponse aux affaires où un marchand conforme PCI-DSS a été tout de même piraté, et a donc perdu sa certification.

Croire que PCI-DSS 3.0 parvienne à régler ce problème en quelques recommandations relève certainement de la plus grande naïveté. Mais cela ajoute à notre impatience de découvrir le nouveau standard !


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

Les commentaires sont fermés.

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.