En avril, une seule vulnérabilité sur un service VPN a déclenché des fuites de données dans plus de soixante-dix institutions financières qui utilisaient l’infrastructure de Marquis Software. Un correctif était pourtant disponible. Ces établissements avaient probablement réalisé des tests d’intrusion récents. Mais cela n’a pas empêché l’incident de se propager à travers leur système d’information.
Le calcul est simple. Un test d’intrusion externe annuel standard occupe deux à trois semaines d’analyse active. Cela laisse environ 345 jours d’activité réelle sans validation aucune.
Le rapport M-Trends 2026 de Mandiant indique que le temps de séjour médian en 2025 était de quatorze jours, ce qui inverse une baisse observée depuis plusieurs années. Les acteurs spécialisés dans l’espionnage affichent une moyenne de 122 jours.
Le Global Threat Report 2026 de CrowdStrike classe les services financiers au quatrième rang des cibles pour les intrusions interactives. Les adversaires n’attendent pas la période située entre deux évaluations annuelles. Le modèle traditionnel, lui, suppose qu’ils le font.
Les régulateurs fixent un socle minimal face à un modèle de menace plus rapide
Les référentiels PCI DSS, FFIEC et NYDFS mentionnent tous les tests d’intrusion dans leurs exigences et leurs recommandations. Aucun ne décrit la cadence annuelle comme suffisante.
L’exigence 11.3.1 de PCI DSS 4.0 impose un test d’intrusion externe après toute mise à niveau ou modification importante de l’infrastructure ou des applications. Le manuel d’examen informatique du FFIEC présente le test d’intrusion comme un élément de la gestion continue des vulnérabilités, et non comme un événement annuel isolé. La section 500.05 du NYDFS exige des tests annuels, parallèlement à des obligations de surveillance continue renforcées par les amendements de 2023 à la réglementation 23 NYCRR 500.
Tous ces cadres réglementaires partent déjà du principe que les tests interviennent en réponse à un changement. Ce socle minimal a été rédigé pour des institutions dont les modifications importantes suivaient des cycles de publication trimestriels.
Cette cadence ne correspond plus à l’infrastructure bancaire moderne. Les mises à jour de la banque numérique, les migrations de charges de travail vers le cloud, les intégrations d’API avec des fintechs, les lancements de portails tiers et les travaux d’intégration post-fusion-acquisition génèrent tous une surface d’attaque non testée entre les tests annuels.
La question de la conformité ne porte plus sur le fait de savoir si l’institution a effectué un test l’année dernière. Elle porte sur le fait de savoir si l’institution a testé les éléments qui ont réellement changé.
Ce que l’écart produit, un cas concret
Lors d’une mission récente dans une banque régionale, les testeurs de Sprocket Security ont identifié une faille sur un portail client dédié aux demandes de prêt immobilier. La banque héberge ce portail sur un sous-domaine qu’elle possède, mais il est opéré par un fournisseur de plateforme tiers. Cet actif était bien dans le périmètre des tests externes.
La plateforme exposait un point de terminaison API qui renvoyait les enregistrements d’une organisation lorsqu’on lui fournissait un identifiant locataire. Ce point d’accès ne nécessitait aucune authentification ni session particulière. La politique de partage des ressources entre origines différentes de la plateforme autorisait n’importe quel site tiers à invoquer la même requête depuis le navigateur d’un visiteur, sans interaction de l’utilisateur.
L’identifiant locataire lui-même était visible dans les fichiers publics du portail. Un appelant non authentifié n’avait donc pas besoin de le deviner. En incrémentant cet identifiant de un, on obtenait les enregistrements de l’institution suivante sur la plateforme partagée. L’itération sur toute la plage permettait de récupérer les données de chaque institution financière utilisant la plateforme, ainsi que celles du locataire interne du fournisseur.
Les enregistrements renvoyés n’étaient pas génériques. Chacun contenait les noms du personnel avec leurs adresses email professionnelles, leurs numéros de téléphone directs, leurs postes, ainsi qu’un code interne que la plateforme utilisait pour attribuer les demandes des emprunteurs à des agents spécifiques.
Ce code avait une importance capitale : toute personne en possession d’un code valide pouvait soumettre une demande d’emprunteur potentiel au nom d’un agent désigné et pour son institution. La plateforme traitait alors cette soumission comme une entrée légitime dans le processus d’octroi de prêts.
La banque n’est pas à l’origine de cette exposition. C’est le fournisseur de la plateforme qui l’a créée. L’évaluation externe annuelle précédente de la banque avait peut-être inclus ce nom d’hôte dans son périmètre au moment du test, mais aucun scanner automatisé n’aurait détecté cette faille.
Pour la repérer, il a fallu parcourir séquentiellement les identifiants locataires sur un point de terminaison non documenté, vérifier que les données renvoyées appartenaient à d’autres institutions, et ce test devait être exécuté sur le déploiement en production.
Le risque indirect confère à cette découverte une dimension réglementaire, et non plus seulement technique. Les données de toutes les autres institutions sur la plateforme partagée pouvaient être extraites via le nom d’hôte de la banque.
Tout incident de fraude, de hameçonnage ou de non-conformité découlant de cette exposition serait imputé à l’institution nommée dans l’URL, quelle que soit l’institution dont les données auraient été utilisées par l’attaquant.
Le test continu est la réponse opérationnelle au scénario décrit
Cette faille passe largement inaperçue dans un modèle annuel. Pour trois raisons, directement liées à la mission.
Premièrement, l’actif est entré dans le périmètre externe de la banque lorsque le fournisseur l’a intégrée à sa plateforme, et non au moment où le test d’intrusion a été défini. Si le périmètre de la mission se basait sur un instantané de l’infrastructure datant de six mois plus tôt, le nom d’hôte n’y figurait peut-être pas. Une gestion continue de la surface d’attaque comble cet écart en traitant les nouveaux hôtes et les nouveaux services exposés comme des déclencheurs de test, sans attendre la prochaine discussion annuelle sur le périmètre.
Deuxièmement, cet actif est typiquement exclu du périmètre annuel. Les portails opérés par des fournisseurs mais présentés sur un sous-domaine propre à l’institution occupent une zone grise dans les discussions sur le périmètre. Ce n’est pas l’application de la banque, la banque n’a pas le code source, elle ne contrôle pas les mises à jour, et le fournisseur maintient son propre programme de sécurité. Les institutions décident à juste titre que le fournisseur de la plateforme est responsable du test de son propre code et excluent l’hôte de la mission. La reconnaissance externe continue, elle, ne respecte pas cette frontière. Si l’hôte est accessible sur l’Internet ouvert sous un domaine que la banque possède, il fait partie de la surface d’attaque externe de la banque. Un attaquant qui énumère le périmètre de la banque le rencontrera, que le dernier document de périmètre de la banque l’ait listé ou non.
Troisièmement, la détection de cette faille a nécessité un test humain actif, et non la sortie d’un scanner. Un scanner de vulnérabilités balayant l’hôte aurait signalé le point de terminaison comme répondant, la politique CORS comme permissive, et aurait peut-être signalé l’absence d’en-tête d’authentification, puis se serait arrêté là. Il n’aurait pas parcouru les identifiants locataires, vérifié la récupération de données inter-locataires, ni enchaîné le code d’attribution du personnel avec un scénario de falsification de soumission. L’automatisation révèle des possibilités. Les testeurs établissent ce qui est réellement exploitable, et l’impact indirect lorsque cela l’est.
Sprocket Security opère selon ce principe de modèle continu. L’attestation qui suit reflète ce qui a été testé contre l’infrastructure qui existait au moment de l’exécution du test, et non un instantané vieux de douze mois.
L’écart est structurel, ce n’est pas un problème de cadence
L’écart de 345 jours n’est pas un argument marketing. C’est une caractéristique structurelle du modèle de test annuel. Les régulateurs ont rédigé les exigences de test en supposant que les institutions testeraient les éléments qui changeaient, au moment où ils changeaient.
La plupart des institutions testent ce qui existait au moment de la mission, selon le calendrier défini pour cette mission, et considèrent l’attestation qui en résulte comme une description de l’exposition actuelle. Cette description devient moins précise chaque jour après la fin du test.
Les institutions qui comblent cet écart ne sont pas celles qui testent plus souvent. Ce sont celles dont le programme de test répond à ce que leur infrastructure fait réellement.
Sponsorisé et rédigé par Sprocket Security.