Les scans de vulnérabilités dans le cadre du maintien de la conformité PCI DSS

Dans le maintien de la conformité PCI DSS, nous avons l’obligation de faire des scans de vulnérabilité interne et externe chaque trimestre et si découverte d’une vulnérabilité nous devons faire les corrections pour produire un scan vierge dit « passed ou « passing ».

Le standard PCI DSS exige que que nous devions effectuer des analyses trimestrielles sur les vulnérabilités externes, identifier et traiter ces vulnérabilités en temps opportun, et de vérifier par un plan de réponse aux incidents (Qualification, analyse et remédiation dans les 30 jours) répondent à l’exigence.

Afin d’atteindre ces objectifs, nous devrons démontrer que les scans de vulnérabilités trimestrielles sont « clean » ou « Passed » pour les quatre trimestres précédents à l’audit sur les environnements externes du CDE.

Un scan «Clean» ou «Passed» a dans la plupart des cas les caractéristiques suivantes:

• Aucune erreur de configuration ou le logiciel est détecté que les résultats d’échec automatique (tels que la présence de comptes et mots de passe par défaut, etc.)
• Pour les analyses externes, aucun problème avec un score de 4,0 ou plus sur le système de notation de Common Vulnerability (CVSS)
• Pour les analyses internes, aucun problème « élevé » telles que défini dans l’exigence PCI DSS 6.1

Avec de nouvelles vulnérabilités continuellement identifiées, les scans de vulnérabilités deviennent une partie intégrante du processus de gestion de la vulnérabilité de l’entreprise, résultant un cycle de scan régulier jusqu’à la remédiation des vulnérabilités découverte et produire un scan dit « passed ».

Toutefois, en raison de la fréquence de nouvelles vulnérabilités étant identifié sur les sondes, il peut ne pas être toujours possible de produire un seul scan propre pour chaque trimestre.

Par exemple, notre RSSO favori effectue une analyse trimestrielle qui identifie un certain nombre de vulnérabilités. Celui-ci fait corriger alors toutes les vulnérabilités identifiées et effectue une nouvelle analyse afin de vérifier les remédiations.

La nouvelle analyse montre que les vulnérabilités identifiées dans le premier balayage ont été abordés, mais de nouvelles vulnérabilités qui ne figuraient pas dans la numérisation de l’original sont apparus depuis (on se sent seul sur ce coup).

Dans ce cas, au lieu d’avoir un seul rapport d’analyse, on peut vérifier qu’ils ont satisfait aux exigences des scans de vuln. à travers de la lecture des résultats de celui-ci et du précédent rapport de scan (-1) qui montrent qu’ensemble toutes les analyses nécessaires sont effectuées, et que toutes les vulnérabilités applicables ont été identifiés et traités sur une base trimestrielle.

Pour vérifier que l’exigence de l’analyse trimestrielle a été atteinte, ce qui suit devrait être mis en place:

• Les Scans de tous les systèmes situé dans le CDE sont effectués pour chaque période trimestrielle, et il faut vérifier que  tous les systèmes sont couverts par les processus de scan et de prendre toutes les mesures correctives et d’effectuer un nouveau scan du CDE (facile au départ, plus compliqué sur du multi site avec plusieurs milliers de pétoires…).
• Les scans sont répétés, si nécessaire, et montrent que les vulnérabilités identifiées dans les analyses trimestrielles initiales ont été corrigées, pour tous les systèmes affectés, dans le cadre du processus trimestriel. Vous devez disposer d’un processus en place pour corriger les vulnérabilités identifiées. Ce processus est indispensable.
• Des scans de vulnérabilités répétées avec des résultats de remédiations/Correction faibles ne sont pas obligatoirement le résultat d’un travail de correction médiocre. Il faudra comparer les vulnérabilités nouvelles entre les deux versions. Attention aux faux positifs.

Si, toutefois, on ne dispose pas des quatre scans trimestrielle PCI attendus parce l’on n’a pas programmé les scans correctement, ou les scans sont incomplets, ou les vulnérabilités identifiées ont pas été abordées d’un trimestre à l’autre, alors l’entité n’a pas satisfait à l’exigence. Pour faire simple. C’est l’échec du maintien de la conformité. La loose totale…la honte sur votre équipe 🙂

Y a des jours c’est cool de ne pas être le RSSO, be cool and enjoy PCI 🙂