Déroulement d’un test d’intrusion : du cadrage au retest

Un test d’intrusion est souvent acheté comme une ligne budgétaire et livré sous forme de PDF. Ce qui se passe entre les deux compte davantage que le rapport lui-même. Un test bien mené suit une méthode que vous pouvez expliquer à votre auditeur, à votre conseil d’administration et à vos clients. Cet article présente cette méthode, phase par phase, et la met en correspondance avec ce que PCI DSS v4.0.1 attend au titre de l’exigence 11.4.

Pourquoi la méthode est importante

PCI DSS ne vous permet pas de tester comme bon vous semble. L’exigence 11.4.1 demande une méthodologie de test d’intrusion « définie, documentée et mise en œuvre » et fondée sur des « approches de test d’intrusion acceptées par l’industrie » (texte de l’exigence). La même exigence précise ce que la méthode doit couvrir :

• l’ensemble du périmètre de l’environnement de données de titulaires de carte (CDE) et des systèmes critiques ;
• des tests depuis l’intérieur et l’extérieur du réseau ;
• la validation de toute segmentation et des contrôles de réduction du périmètre ;
• des tests au niveau applicatif visant, au minimum, les vulnérabilités listées dans l’exigence 6.2.4 ;
• des tests au niveau réseau de tous les composants prenant en charge les fonctions réseau et les systèmes d’exploitation ;
• un examen des menaces et vulnérabilités rencontrées au cours des 12 derniers mois ;
• la conservation des résultats de test et de remédiation pendant au moins 12 mois.

Parmi les référentiels courants figurent NIST SP 800-115, qui organise les tests en planification, découverte, attaque et reporting, le OWASP Web Security Testing Guide pour les applications et les API, et MITRE ATT&CK pour décrire les techniques d’attaque dans un vocabulaire commun. Le Penetration Testing Guidance du PCI SSC reste le document unique le plus utile pour le cadrage et le reporting.

Phase 1 : cadrage et autorisation

La plupart des tests échoués échouent ici. Avant d’envoyer le moindre trafic, le testeur et le client se mettent d’accord sur :

• Cibles. Plages d’IP et domaines externes, segments de réseau internes, applications, API et limites de segmentation à valider.
• Règles d’engagement. Fenêtres de test, ce qui est hors périmètre, la manière de traiter les systèmes de production et qui appeler si quelque chose casse.
• Autorisation écrite. Une autorisation signée par une personne habilitée à l’accorder, y compris pour des systèmes hébergés par des tiers.
• Points de contact. Une personne de chaque côté, joignable pendant le test.
• Approche. Boîte noire (aucune information préalable), boîte grise (identifiants au niveau utilisateur, comme recommandé pour la plupart des applications) ou boîte blanche (documentation et accès au code source).

Un bon périmètre part de vos flux de données, pas d’une liste d’adresses IP. Si des données de carte ou des informations personnelles sensibles transitent par un système, il doit faire partie de la discussion.

Phase 2 : reconnaissance et énumération

Le testeur cartographie la surface d’attaque : services exposés, technologies et versions, fonctions applicatives et endpoints d’API, rôles utilisateurs et relations de confiance. Les tests externes simulent un attaquant sans accès. Les tests internes simulent un attaquant disposant déjà d’un point d’appui, par exemple un poste de travail compromis. Les deux sont exigés par PCI DSS, au titre des exigences 11.4.2 (interne) et 11.4.3 (externe).

Phase 3 : tests et exploitation

C’est ici qu’un test d’intrusion se distingue d’un scan. Des outils automatisés identifient des faiblesses potentielles. Le testeur les valide ensuite manuellement, élimine les faux positifs et tente d’exploiter ce qui est réel. La question n’est pas « cette version est-elle obsolète ? », mais « à quoi un attaquant peut-il réellement accéder depuis ici ? ».

• Couche réseau : services faibles, mauvaises configurations, identifiants par défaut, correctifs manquants, mouvement latéral entre segments.
• Couche applicative : injection, contrôle d’accès défaillant, failles d’authentification et de session, API non sécurisées, abus de logique métier.
• Segmentation : tentatives d’atteindre le CDE depuis des réseaux hors périmètre, comme l’exige 11.4.5 lorsque la segmentation est utilisée pour réduire le périmètre.

L’exploitation est contrôlée. L’objectif est de démontrer l’impact avec des preuves, pas de provoquer une interruption de service.

Phase 4 : reporting

Un rapport utile s’adresse à deux publics. La direction a besoin d’un résumé court du risque global et des priorités. Les équipes techniques ont besoin de chaque constat avec :

• une description et les systèmes concernés ;
• des preuves (requêtes, captures d’écran, commandes) afin que le résultat puisse être reproduit ;
• une évaluation de la sévérité, généralement basée sur CVSS et ajustée à votre contexte ;
• des recommandations de remédiation claires et pragmatiques.

Le rapport doit également indiquer ce qui a été testé, quand, depuis où et sous quelles contraintes. Un auditeur cherchera cela avant de lire le moindre constat.

Phase 5 : remédiation et retest

L’exigence 11.4.4 est explicite : les vulnérabilités exploitables et les faiblesses de sécurité sont corrigées selon votre classement des risques, et « le test d’intrusion est répété pour vérifier les corrections » (texte de l’exigence). Un test sans retest vous laisse avec une liste de problèmes et aucune preuve qu’ils ont été corrigés. Planifiez la fenêtre de retest en même temps que le test.

À quelle fréquence, et par qui

• Au moins une fois tous les 12 mois, et après toute mise à niveau ou tout changement significatif de l’infrastructure ou des applications.
• Par une ressource interne qualifiée ou un tiers externe qualifié.
• Avec une indépendance organisationnelle vis-à-vis des systèmes testés. Le testeur n’a pas besoin d’être un QSA ou un ASV.

Les prestataires de services qui s’appuient sur la segmentation doivent la valider tous les six mois (exigence 11.4.6).

Questions à poser avant de signer

• Quelle méthodologie suivez-vous, et pouvons-nous la consulter ?
• Les tests sont-ils manuels, ou s’agit-il surtout de scans automatisés ?
• Le prix inclut-il un retest ?
• Comment gérez-vous une constatation critique découverte en cours de test ?
• Que contiendra le rapport, et pouvons-nous voir un exemple anonymisé ?

Pour la différence entre les scans et les tests d’intrusion, consultez notre comparaison. Pour cadrer un test, visitez notre page tests de sécurité ou contactez-nous. Ubitrak réalise des tests internes, externes, applicatifs et de segmentation, et vous pouvez voir des exemples de rapports.

Sources

• PCI SSC Information Supplement: Penetration Testing Guidance v1.1
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide
• MITRE ATT&CK
• FIRST: Common Vulnerability Scoring System
• Microsoft Learn: PCI DSS Requirement 11 (texte de l’exigence)
• PCI SSC: Just Published: PCI DSS v4.0.1