PCI DSS demande des tests d’intrusion en termes précis, et la plupart des rapports de test qu’on nous remet n’y répondent pas. Non que les testeurs soient mauvais, mais parce que personne ne leur a dit à quoi servirait le rapport.
PCI DSS demande des tests d’intrusion en termes précis, et la plupart des rapports de test qu’on nous remet n’y répondent pas.
Ce que l’exigence 11.4 demande
Une méthodologie définie, fondée sur des approches reconnues, couvrant tout le périmètre de l’environnement des données de cartes et les systèmes critiques à l’intérieur, au niveau réseau comme au niveau applicatif, les tests applicatifs couvrant au moins les classes de vulnérabilités que le standard liste.
Des tests d’intrusion externes au moins une fois tous les douze mois et après tout changement significatif. Des tests d’intrusion internes au moins une fois tous les douze mois et après tout changement significatif. Les vulnérabilités exploitables et les faiblesses trouvées sont corrigées, et le test est répété pour vérifier les corrections. Pour les prestataires de services, la méthodologie doit inclure les tests de segmentation tous les six mois.
Le testeur doit être qualifié et indépendant sur le plan organisationnel. Une équipe interne peut le faire si elle n’est pas celle qui gère les systèmes.
En quoi cela diffère du scan
L’analyse externe trimestrielle par un prestataire d’analyse approuvé, au titre de la 11.3.2, est un outil lancé contre vos adresses exposées sur Internet, avec un rapport de réussite. L’analyse interne trimestrielle, au titre de la 11.3.1, est un outil lancé à l’intérieur. Les deux trouvent des vulnérabilités connues par signature.
Un test d’intrusion, c’est une personne qui essaie d’entrer, en enchaînant ce que le scanner a trouvé avec ce que le scanner ne voit pas : une relation d’approbation, un identifiant par défaut dans le manuel d’un fournisseur, un réseau appairé avec une règle d’autorisation par défaut, un service en écoute que l’inventaire dit devoir être éteint. Sur une évaluation récente, les deux constats qui comptaient le plus, des réseaux non fiables appairés atteignant l’environnement des données de cartes sur tous les ports et un service non approuvé sur un nœud, étaient exactement ce qu’un test interne au niveau réseau est conçu pour trouver, et aucun scan n’avait signalé l’un ou l’autre.
Comment nous le cadrons et le réalisons
Nos QSA cadrent le test sur les exigences dont dépendent vos preuves : le périmètre tel que le document de périmètre le définit, les systèmes critiques à l’intérieur, les contrôles de segmentation, les applications qui touchent aux données de cartes. Lorsque nous ne réalisons pas les tests nous-mêmes, ils sont exécutés par des partenaires spécialisés avec lesquels nous travaillons, dans notre périmètre et sous notre revue. L’évaluateur qui s’appuiera sur le rapport est celui qui le lit en premier, ce qui veut dire que le rapport est écrit pour la personne qui devra le défendre.
Comment un évaluateur lit le rapport
Dans cet ordre. Le périmètre est-il énoncé, et correspond-il au document de périmètre ? La méthodologie est-elle nommée ? Les dates sont-elles dans la période d’évaluation ? Le testeur est-il indépendant ? Les réseaux sources sont-ils nommés ? Les constats exploitables sont-ils listés avec leur gravité, et y a-t-il un nouveau test montrant chacun fermé ? La couche applicative est-elle couverte, avec les classes de vulnérabilités que le standard nomme ?
Un rapport qui répond à tout cela est une preuve. Un rapport qui répond à la moitié est une conversation sur la nécessité de refaire le test.
Ce que l’on fait de travers
On prend le scan pour le test. On teste de l’extérieur et on saute l’intérieur, là où vit la segmentation. On teste avant que l’environnement ne soit terminé et plus jamais après les changements. On corrige les constats et on oublie le nouveau test, qui est la partie que l’exigence demande vraiment de prouver.