Depuis le premier juillet 2012 les marchands soumis à PCI-DSS doivent être des experts du risque. C’est du moins la lecture, certes exagérée, que l’on pourrait faire de l’entrée en vigueur de l’exigence 6.2 de PCI-DSS 2.0.

L’exigence 6.2 stipule en effet que les marchands doivent non seulement découvrir les vulnérabilités sur leurs systèmes soumis à PCI-DSS mais désormais également leur attribuer une valeur de risque afin de les prioritiser (pour les anglophone, très exactement : « Requirement 6.2 : Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities« ).

Ce qui conduit le marchand à devoir mettre en oeuvre uns stratégie en trois points :

• Détecter les vulnérabilités. Ici bien entendu un scanner de vulnérabilités automatisé est un outil précieux, mais pas seulement. L’exigence 6.2 vise à rendre les marchands pro-actifs face aux vulnérabilités et non plus seulement réactifs. Elle pousse alors à déployer une procédure de veille active sur les nouvelles vulnérabilités (via des mailing lists par exemple – SANS, NIST ou SecurityFocus par exemple, ou bien des services tiers)
• Assigner un score aux vulnérabilités détectées. Pour cela le Common Vulnerability Scoring System (CVSS) offre un cadre standard d’évaluation de la critcité d’une vulnérabilité. Un score CVSS supérieur à 7.0 est considéré comme « critique » (High). Mais le commerçant doit alors faire face à deux difficultés : tout d’abord adapter la notation CVSS à celle de son propre scanner de vulnérabilités (à partir de quelle note CVSS le scanner utilisé estime-t-il qu’une vulnérabilité est critique ?). Et surtout adapter les résultats à son contexte métier : quel est l’impact de telle ou telle vulnérabilité sur le SI du marchand indépendamment de son score CVSS ? Dans le doute, évidemment, toutes les vulnérabilités CVSS 7 ou supérieur seront considérées critiques, mais le marchand doit pouvoir apporter la preuve qu’il procède effectivement à une analyse maison.
• Corriger les vulnérabilité critiques. Il faut enfin, bien entendu, corriger les vulnérabilités jugées critiques – c’est à dire d’un niveau CVSS supérieur à 7.0. Là aussi, il ne suffit pas de les corriger au fil de l’eau mais bien de pouvoir démontrer qu’un processus existe destiné à rationnaliser la correction des vulnérabilités.

PCI-DSS 2.0 est entré en vigueur en début d’année dernière (janvier 2011) mais la conformité à l’exigence 6.2 n’est obligatoire que depuis le 1er juillet 2012. Quelle a été votre expérience en la matière ? Comment vous êtes-vous organisés afin d’y répondre ?