Exigés par le standard PCI DSS, les tests d’intrusion sont incontournables lors d’une certification PCI DSS.
Comment doivent-ils être réalisés, quelle méthodologie le testeur doit-il suivre, quelles sont ses particularités ?
Tout au long de cet article, nous essaierons d’éclaircir ce sujet et de répondre aux questions souvent soulevées par nos clients.
I. Que doit-on tester et comment ?
1. Périmètre des tests
Commençons par le début. Que doit-on tester et quels types de tests doit-on réaliser dans le cadre d’un environnement PCI DSS ?
Tout d’abord, le standard PCI DSS impose de réaliser des tests d’intrusion externes (exigence #11.3.1 du standard) et internes (exigence #11.3.2 du standard).
Cela signifie qu’il faudra tester toutes les ressources de l’environnement exposées sur Internet et l’ensemble des équipements constituant le périmètre PCI DSS.
Cependant, chaque QSA peut avoir une interprétation du « périmètre PCI DSS ».
Selon le guide fourni par le PCI SSC (disponible ici Penetration-Testing-Guidance-v1_1.pdf) :
- The scope of testing may include locations of cardholder data, applications that store, process, or transmit cardholder data, critical network connections, access points, and other targets appropriate for the complexity and size of the organization.
- This should include resources and assets utilized by personnel to maintain systems in the CDE or to access cardholder data, as the compromise of such assets could allow an attacker to obtain credentials with access to or a route into the CDE.
En d’autres mots, le PCI SSC insiste surtout sur les systèmes, les équipements et les applications qui reçoivent, manipulent ou transmettent des données de cartes ainsi sur les ressources utilisées par le personnel en charge de l’administration des systèmes.
Pour XMCO, ces tests ne suffisent pas. En effet, nous incluons systématiquement l’ensemble du périmètre PCI DSS constitué du CDE (Cardholder Data Environnement), mais également des équipements connectés au CDE (serveurs d’infrastructure dont l’Active Directory, serveurs de logs/monitoring, sauvegarde, console antivirus, etc.). En effet, une faille au sein de ces équipements pourrait avoir une incidence potentielle sur la sécurité des données de cartes.
Un point d’attention particulier est également porté aux équipements de sauvegarde ainsi qu’aux réseaux « Out-of-Band », souvent mis de côté ou tout simplement « oubliés » par le client et donc non inclus initialement au sein du périmètre PCI DSS.
Au final, XMCO effectue des tests sur l’ensemble du périmètre PCI DSS (CDE et Connected-to-CDE).
Les stations de travail des administrateurs rentrent-elles dans le périmètre des tests si nous utilisons un bastion d’administration ou un serveur de rebond pour accéder au CDE ?
La réponse est oui. Même si un bastion est utilisé, la compromission d’un tel équipement possédant une connexion établie au CDE pourrait avoir un impact important.
Les interfaces de monitoring ou de gestion des logs rentrent-elles dans le périmètre des tests?
La réponse est oui. Dans le cas de la compromission d’une de ces interfaces, il est très souvent possible de rebondir vers les serveurs stockant les cartes.
En effet, les mécanismes de surveillance et/ou de gestions des logs reposent souvent sur des ressources (scripts, services, flux réseau permissifs, mots de passe, etc.) qui sont sensibles. Notre expérience a démontré que ces interfaces sont souvent négligées et que la compromission du serveur d’indexation de log, d’une sonde de monitoring type Nagios ou Cacti sont souvent déterminant dans la compromission totale d’un environnement.
Des applications sont hébergées sur le même serveur qu’une autre application manipulant des données de cartes. Ces dernières doivent-elles être testées ?
La réponse est évidemment oui. En effet, du moment où une application manipule des données de cartes, tout le serveur et ses applications sont dans le périmètre PCI DSS. Les autres applications éventuelles doivent alors être développées en répondant à l’ensemble des exigences PCI DSS et donc être soumises aux scans et aux tests d’intrusion.
En effet, si une faille d’une application tierce « non sensible » ou « hors-scope » permet de rebondir sur le système sous-jacent, il est alors possible de compromettre l’ensemble du serveur, et donc l’application qui manipule ou stocke des données de cartes.
Mon interface de gestion des comptes est dissociée de mon application qui effectue le traitement des cartes, celle-ci est-elle également dans le périmètre ?
La réponse est oui. Si un pirate arrive à compromettre cette application, il pourra alors s’octroyer des droits élevés sur l’application et donc potentiellement voler des cartes.
L’entreprise certifiée utilise un prestataire, ce dernier doit-il faire partie du périmètre des tests ?
La réponse est oui. Dès l’instant où le prestataire joue un rôle dans la sécurité, l’hébergement, l’infogérance, l’administration ou encore la supervision des systèmes du périmètre PCI DSS, alors ces derniers sont inclus dans le périmètre de l’audit et donc doivent faire l’objet de tests d’intrusion.
Dans le cas où le prestaire est lui-même certifié PCI DSS, est-ce que celui-ci fait toujours partie du périmètre ?
La réponse est oui. En fonction du niveau de certification de celui-ci, les exigences le concernant seront portées par sa propre certification ou vérifiées lors de l’audit le cas écheant.
2. Boite noire, grise ou blanche ?
Les tests d’intrusion PCI DSS doivent être menés en boite noire puis en boite grise/blanche.
Chez XMCO, nous suivons une méthodologie classique qui débute par des tests en boite noire, puis grise. Dans certains cas, les tests en boite blanche seront également menés.
L’objectif de cette méthodologie est de simuler le comportement de chaque population d’utilisateurs :
- Un attaquant positionné sur Internet ;
- Un utilisateur possédant différents profils avec des privilèges plus ou moins élevés sur l’application ;
- Un employé présent sur le réseau interne de l’entreprise non connecté à l’environnement PCI DSS ;
- Un employé possédant des accès privilégiés sur le périmètre PCI DSS (simple utilisateur d’un back-office, support niveau 1 sur des applications de supervision, l’administrateur du périmètre PCI DSS, etc.) ;
- Enfin, le dernier test souvent mené consiste à obtenir un accès non restreint vers l’ensemble des ressources du périmètre PCI DSS, permettant de découvrir des vulnérabilités dont la criticité sera ensuite pondérée par les restrictions mises en place.
Si l’application au sein du CDE requiert une authentification, les tests doivent être réalisés avec tous les types de comptes proposés par l’application, incluant notamment le profil de compte non autorisé à manipuler ou visualiser des données de cartes.
Si l’application comporte un grand nombre de profils, un échantillonnage sera alors réalisé.
II. Les spécificités d’un environnement PCI
1. Le cas des applications PA-DSS (Payment Application Data Security Standard)
Les applications PA-DSS, incluses au sein d’un périmètre PCI DSS, ne doivent pas être testées d’un point de vue applicatif. En effet, elles ont été développées en suivant les exigences imposées par le standard PA-DSS qui inclut notamment le respect des Meilleures Pratiques de développement sécurisé.
La certification PA-DSS couvre l’ensemble des bonnes pratiques du développement sécurisé (exigences #5.2.1 à #5.2.10 du standard PA-DSS).
Cependant, l’implémentation et l’intégration de ces applications doivent être testées. En effet, la certification PA-DSS ne couvre pas l’installation et la configuration des briques sous-jacentes sur lesquelles l’application repose (durcissement de la couche système, configuration des composants middleware tels que le serveur web, la base de données ou le serveur d’authentification distant). Les éditeurs fournissent un guide d’implémentation, mais la mise en oeuvre reste sous la responsabilité du client.
2. Les applications web non développées en interne
Il est fréquent, voir quasiment systématique, d’utiliser des applications web tierces, non développées par son équipe, mais utilisées dans un environnement PCI DSS (applications de supervision, IDS, gestionnaire de mot de passe, etc.). Un test d’intrusion applicatif n’est pas nécessaire pour ces applications web, seules des vérifications sur le système hébergeant cette application sont requises.
Le consultant en charge des tests devra tout de même s’assurer que la version de l’application en question est bien supportée par l’éditeur et que les derniers correctifs de sécurité ont bien été appliqués. De plus, des tests complémentaires permettront de démontrer que la sécurité de cette application n’a pas été altérée (présence d’une authentification par exemple).
Mais que se passe-t-il si l’auditeur trouve tout de même une faille dans ces applications ?
Dans ce cas, on parle alors de vulnérabilité 0-day. XMCO impose au client de contacter l’éditeur et d’obtenir une version corrigée, ce qui, en fonction de la réactivité de la société en charge du développement, peut ralentir l’obtention de la certification.
3. Les environnements de test
Tout comme les scans de vulnérabilités, les tests d’intrusion peuvent malheureusement avoir des effets de bords sur des systèmes de production. En plus des précautions habituelles, il faut redoubler de vigilance, car l’indisponibilité d’un serveur peut souvent coûter cher dans ce type d’environnement.
Peut-on alors réaliser ces tests sur un environnement de recette ou de qualification ?
La réponse est oui. Cependant, en situation réelle, il est souvent difficile d’avoir un environnement de recette « iso-production ». Que ce soit au niveau des versions logicielles, du filtrage réseau ou encore l’utilisation des versions supérieures de l’application, il est rare d’avoir à disposition une copie exacte de la production.
Il est alors possible d’effectuer les tests système et middleware sur l’environnement de production, puis de réaliser les tests applicatifs sur l’environnement de recette. Si une vulnérabilité est identifiée, elle pourra alors être vérifiée sur l’environnement de production.
4. Les tests de segmentation
L’exigence #11.3.4 du standard exige de réaliser des tests d’intrusion sur les équipements en charge de la segmentation, tests devenus obligatoires chaque semestre pour les prestataires de service.
Comment peut-on réaliser ces tests ?
L’objectif de ces tests est de valider le périmètre de l’environnement PCI DSS. Pour ce faire, les tests menés doivent confirmer que les équipements en charge de la segmentation sont toujours actifs et efficaces, et que les règles de filtrage implémentées permettent d’isoler correctement les environnements considérés comme « hors-scope » du périmètre PCI DSS.
L’idéal serait de pouvoir réaliser les tests suivants :
- Scans réseau depuis les différents environnements « Out Of Scope » dont les réseaux WiFi utilisés par les collaborateurs de l’entreprise (invités et internes) à destination du CDE et des serveurs connectés au CDE.
- Scans réseau depuis tous les VLAN « connectés au CDE » à destination du CDE. On trouve typiquement dans cette catégorie les utilisateurs possédant un accès au CDE et les serveurs d’infrastructures.
- Scans réseau depuis les accès distants (par exemple : VPN SSL, VPN IpSec). Ce dernier cas a pour objectif de tester les accès du personnel en astreinte, des nomades, des filiales, des prestataires de services, etc.
Dans la vraie vie, cela n’est pas si simple. En effet, il n’est pas toujours facile de positionner un consultant en charge de ces tests dans différentes localisations du périmètre lorsque les environnements sont complexes et constitués de plusieurs dizaines de VLAN. Ainsi, dans ce cas, le testeur doit avoir une réflexion et une approche orientées « Risques » qui sera validée par le QSA.
Une attention particulière devra être portée aux mécanismes de filtrage dynamique, c’est à dire, aux mécanismes dont les accès/flux autorisés sont différents en fonction des droits, du profil ou encore du groupe auquel l’utilisateur appartient. Dans ce cas de figure, la démarche sera la même. Idéalement, les scans réseau doivent être effectués depuis tous les types de profils disponibles, allant des profils qui n’ont aucun accès à l’environnement PCI DSS jusqu’aux profils qui disposent d’accès administratifs.
L’objectif étant de déterminer si les services exposés par l’environnement PCI DSS sont bien ceux justifiés par le client dans sa matrice de flux et s’il existe des méthodes pour contourner ces restrictions ou en abuser.
Ces tests n’ont pas pour but de tester uniquement les pare-feux. En effet, tous les équipements qui interviennent dans la segmentation de l’environnement PCI DSS doivent être soumis à ces tests. Cela peut donc inclure les switchs et leur mécanisme de VLAN, les technologies de virtualisation (hyperviseurs, VSwitchs, etc.), les bastions d’administration, les serveurs qui possèdent un pare-feu local, etc.
De plus, ces tests ne se limitent pas à la réalisation de scans, mais également aux tests des équipements eux-mêmes (tests des services exposés, interface d’administration, etc.).
5. L’activation du WAF (Web Application Firewall) et de l’IDS…
Faut-il désactiver le WAF et l’IDS durant les tests ?
Cela dépend de la méthodologie utilisée par les pentesteurs.
XMCO recommande grandement de réaliser les tests sans le WAF. En effet, le standard impose de développer les applications en suivant un guide de développement sécurisé. L’application en elle-même doit être exempte de vulnérabilités applicatives. Le WAF ne rajoute qu’une surcouche de protection. Il faut d’ailleurs comprendre que le WAF peut toujours être contourné (même si certains sont beaucoup plus robustes que d’autres), la sécurité de l’application ne doit pas se baser sur cet équipement. Nous l’avons donc sous-entendu, mais il n’est donc pas acceptable de corriger les vulnérabilités applicatives via l’ajout de règles…
Dans un second temps, le WAF pourra être activé afin de mettre le testeur dans des conditions réelles et vérifier s’il aurait pu contourner le WAF pour atteindre son but. Cette phase permettra de configurer plus finement le WAF ou de minimiser l’impact des vulnérabilités identifiées. D’autre part, cela permettra de vérifier si les équipes en charge du monitoring auront été alertées par des remontées du WAF.
Côté IDS, tant que ce dernier a simplement un rôle de détection, mais pas de blocage (contrairement aux IPS), l’IDS a tout son sens lors des tests internes. En effet, les alertes levées par cet équipement permettront aux équipes en charge de la surveillance (type SOC) ou aux administrateurs de déterminer si leur installation fonctionne bien et si les remontées d’informations sont pertinentes.
III. Les étapes de la prestation
1. La méthodologie de test
La société réalisant les tests doit également fournir une méthodologie en accord avec l’exigence 11.3 du PCI DSS, c’est-à-dire un document ou une annexe précisant le périmètre, les types de tests réalisés, la rétention des données obtenues durant les tests, etc. Ce document, qui peut être fourni en avance de phase, permettra d’avoir un aperçu de l’expérience du prestataire dans ce type de test.
Note : la société auditée peut également fournir sa propre méthodologie.
2. La réunion d’initialisation
Cette première réunion de lancement doit permettre aux testeurs de s’approprier l’environnement, comprendre techniquement les briques et l’infrastructure et les risques principaux.
Cette réunion est souvent réalisée avec le responsable de l’environnement PCI DSS, des architectes pouvant présenter les applications et l’infrastructure et avec le QSA maitrisant parfaitement l’environnement.
Elle est importante et essentielle dans le cas d’un environnement complexe et sensible comme les environnements PCI DSS.
3. Les prérequis
Enfin, comme déjà évoqués au début de cet article, les prérequis sont essentiels et nécessaires pour le bon déroulement des tests. Ces derniers sont souvent échangés durant la réunion d’initialisation.
Les prérequis seront alors définis. Bien entendu, certains pourront être distillés au cours des tests (notamment les comptes pour une véritable première étape en boite noire).
Ces derniers peuvent inclure :
- les IP externes ;
- les IP internes ;
- le mandat d’autorisation (en particulier si un hébergeur est utilisé) ;
- un schéma réseau ;
- un schéma des flux de cartes ;
- le fichier définissant le périmètre (équipements et serveurs faisant partie du CDE et connectés au CDE, noms des utilisateurs habilités à accéder au CDE, etc.) ;
- des contacts techniques à joindre en cas d’urgence ;
- le contact du QSA pour toute question relative au périmètre et à la démarche ;
- une prise brassée ;
- un peu de café et une salle de réunion dédiée (oui, tous les pentesteurs ont pratiqué leur art sur un coin de table ou serrés sur un demi-bureau dans un open space).
4. La réalisation du test et les débriefings réguliers
Les tests d’intrusion sont souvent réalisés quelques temps avant l’audit de certification (généralement 2 mois avant) afin d’avoir le temps de corriger avant l’audit tant redouté.
Les testeurs doivent alors signaler au plus vite leurs trouvailles. L’idée n’étant pas de les corriger immédiatement et de bloquer les testeurs, mais de donner au client, les éléments principaux pour comprendre et anticiper les futures corrections (surtout si elles sont structurelles).
Un point d’avancement est conseillé durant les tests, ce qui rassurera (ou non) l’audité.
5. Le contre-audit
Enfin, chaque test PCI doit être complété par un contre-audit permettant de vérifier que les vulnérabilités jugées bloquantes pour la certification ont bien été corrigées. Un rapport mis à jour devra être fourni par les auditeurs.
6. Le rapport
Dernier point important, le rapport des tests.
Comme vous avez pu le comprendre, un test d’intrusion PCI DSS doit mettre particulièrement des éléments en évidence qui seront lus et compris par le QSA et la direction de l’entité audités.
Ainsi les points clés qui devront être inclus sont les suivants :
- définition précise du périmètre ;
- synthèse de l’audit avec un focus sur les véritables risques et scénarios d’attaque mis en oeuvre ;
- le plan d’actions ;
- la liste des vulnérabilités identifiées et la référence PCI DSS de l’exigence associée ;
- la description de chaque vulnérabilité et les recommandations associées (avec tous les éléments permettant de qualifier l’exploitation de la faille : difficulté, type de tests, ressources vulnérables, références, captures d’écran, etc.) ;
- la description des tests réalisés (qui ont réussi et échoué) ;
- la méthodologie employée ;
- la méthodologie pour les tests de segmentation réalisés et les résultats.
IV. Autres sujets
1. Les changements significatifs
L’un des termes utilisés au sein du standard peut laisser libre à l’interprétation. En effet, le terme « significant change » y apparait plusieurs fois (exigences #6.4.6 et #11.2). Cependant, en ce qui concerne les tests d’intrusion (exigences #11.3.1 et #11.3.2), le wording est plus précis, on parle alors de « significant infrastructure or application upgrade or modification ».
Dès qu’un tel changement se produit (nouveau serveur, une modification du réseau ou une nouvelle version de l’application sensible), alors l’audité doit réaliser un nouveau test d’intrusion.
Il est clair que si l’architecture change souvent (ajout de serveurs ou montée de version hebdomadaire), l’exercice devient alors complexe à mettre en oeuvre et surtout couteux si on fait appel à un prestataire. Néanmoins, certains ont recours à une pratique que nous appelons « Pentest Agile » qui permet de déclencher un jour voire deux jours de test additionnels lors d’une montée de version ou de l’ajout de serveurs afin de vérifier qu’une vulnérabilité n’a pas été introduite. Ceci permet alors de répondre à l’exigence.
2. Scans de vulnérabilités vs Tests d’intrusion
Attention à ne pas confondre scans de vulnérabilités et tests d’intrusion !
Malheureusement, certaines sociétés dîtes spécialisées lancent uniquement un scanner tel que Nessus/Qualys et complètent par quelques tests manuels très basiques. Le test d’intrusion attendu est un test manuel, réalisé par des experts de l’intrusion qui contrôlent, corrèlent, et vérifient les résultats, exploitent de manière successive des vulnérabilités jusqu’à la mise en perspective des véritables scénarios d’attaque.
Identifier une faille de type « XSS » (Cross Site Scripting) en étant authentifié sur l’application de monitoring sans mettre en évidence les conséquences concrètes que cela peut avoir sur la sécurité de l’environnement et des cartes n’a que peu d’intérêt !
3. Le social engineering
Le PCI DSS n’impose pas de réaliser de tels tests. Cependant, ils peuvent être particulièrement révélateurs du niveau de sensibilisation de vos collaborateurs.
Pour XMCO, ces tests rarement menés, sont complémentaires des tests d’intrusion « classiques ». En effet, de nos jours, un attaquant qui cible un environnement manipulant des données de cartes bancaires aura tout intérêt à passer par le maillon faible à savoir l’humain.
Cela sera bien plus efficace et plus simple que de tenter d’attaquer frontalement une infrastructure à jour, hébergeant une application développée dans les règles de l’art et renforcée par l’utilisation d’un WAF et d’un IDS/IPS…
Gardez en tête que les administrateurs constituent le point d’entrée préférentiel. Utilisateurs privilégiés, ils peuvent être amenés à posséder un grand nombre d’informations techniques sur leur poste de travail.
Un cheval de Troie envoyé par email à un administrateur peu attentif ou encore une attaque de phishing ciblée afin de voler des identifiants utilisés sur le CDE permettront d’obtenir un pied à l’intérieur du périmètre PCI DSS.
4. Quelles qualifications et expériences atttendre de la société en charge de réaliser ces tests ?
Le PCI SSC n’impose pas de qualifications particulières aux entreprises ou salariés qui réalisent les tests d’intrusion d’un environnement PCI DSS.
Cependant, certaines sont recommandées par le PCI SSC (OSCP, CXEH, GIAC, CREST, etc), mais ne sont absolument pas garantes de la qualité d’un test.
En effet, selon notre expérience, la réalisation d’un test d’intrusion d’un environnement PCI DSS doit être réalisée par des consultants expérimentés, connaissant les vrais risques métiers et mettant en perspective les trophées obtenus.
Le but de ces tests est multiple :
- Mettre en évidence les manquements aux exigences PCI DSS #6.5.x (vulnérabilités applicatives), #2.x (erreurs liées au durcissement), #4.x (chiffrement des flux publics), #6.1.x (niveau des correctifs de sécurité) ;
- Mettre en évidence les scénarios concrets de fraude, de vols de données bancaires ou de potentiels impacts sur la sécurité de l’environnement ;
- Mettre en évidence les problèmes de cloisonnement de l’environnement (#11.3.4) au travers de tests de segmentation ;
- Souligner l’efficacité des moyens de protection mis en place (réaction des équipes, alertes IDS/IPS, alertes WAF, etc.).
Vous l’aurez donc compris, il faut donc des consultants sachant appréhender ces différents sujets. Cela passe souvent par une gestion de projet menée conjointement par le QSA ou un consultant ayant déjà abordé le standard PCI DSS.
La société qui certifie peut-elle réaliser les tests d’intrusion ?
Oui. La société QSA, qui certifie, engage sa responsabilité lorsqu’elle signe l’AOC (Attestation Of Compliance). Dans ce contexte, elle est particulièrement vigilante sur la qualité des tests d’intrusion, seuls ces tests concrêts permettent de mettre en évidence les véritables risques de l’environnement audité. En l’occurence, XMCO préfère faire confiance aux qualités techniques de ses consultants ou de sociétés reconnues plutôt que de reposer sur d’autres acteurs ne maîtrisant pas ce domaine.
En effet, dans le cadre de toutes les certifications que nous avons réalisées depuis 7 ans, nous avons été confrontés à des sociétés tierces n’ayant pas réalisé les tests dans les règles de l’art.
V. Conclusion
Le test d’intrusion d’un environnement PCI DSS ne diffère pas tant que cela d’un test d’intrusion standard. Réalisé par des experts, expérimentés et connaissant les risques liés à des environnements monétiques, il doit être mené dans les règles de l’art, en appliquant une méthodologie stricte.
Ce test sera le véritable indicateur pour le responsable de l’environnement et le QSA sur les faiblesses et manquements de l’environnement manipulant des données de cartes.
Nous vous invitons donc à challenger particulièrement vos fournisseurs lors de vos appels d’offres pour choisir une société reconnue avec une expérience significative sur ce type d’environnements.
