Périmètre des tests d’intrusion bancaires : obtenir des devis réellement comparables

La décision que ce guide vous aide à prendre

Un devis de test d’intrusion bancaire n’est pertinent que si l’objectif et le périmètre sont définis. Précisez les canaux clients, les opérations de paiement ou les chemins de confiance internes à évaluer, les accès fournis et les preuves que vous accepterez. Distinguez les tests d’intrusion courants de toute exigence formelle de TLPT au titre de DORA.

Décrivez l’objectif de la mission

Définissez la décision que la banque doit prendre : mettre une application en production, évaluer une frontière de confiance définie, examiner une exposition connue ou valider une correction. Identifiez le responsable du service et le public destinataire du rapport. N’utilisez pas « pentest complet » comme substitut à la définition du périmètre. Les prestataires peuvent interpréter cette expression de façons très différentes, d’un scan limité sans authentification à une évaluation étendue avec accès privilégié et tests de la logique métier.

Distinguez les tests d’intrusion courants de tout exercice avancé fondé sur les menaces. Si un TLPT est requis, appliquez le processus de gouvernance et de passation des marchés correspondant. Le guide des exigences de l’article 27 de DORA applicables aux prestataires présente des aspects qui ne doivent pas être réduits à un questionnaire générique destiné aux fournisseurs.

Décrivez les systèmes à travers les opérations et les rôles

Fournissez un inventaire des applications, API, frontières d’identité, environnements et intégrations concernés. Ajoutez les opérations et rôles pertinents : client, support, approbateur, administrateur et identité de charge de travail, le cas échéant. Précisez quels comptes et objets synthétiques la banque peut fournir. Un nombre de points de terminaison sans ce contexte constitue une base médiocre pour estimer la couverture de la logique métier.

Signalez les composants tiers, les environnements partagés et les autorisations qui restent à définir. Demandez aux soumissionnaires d’indiquer l’incidence de chaque hypothèse sur la couverture et la réalisation. Réservez les détails sensibles de l’architecture au canal confidentiel de consultation convenu plutôt qu’à un formulaire de demande public.

Rendre visibles les contraintes opérationnelles

Indiquez les environnements approuvés, les fenêtres d’intervention, les limites de requêtes et les méthodes interdites. Identifiez les services pour lesquels même un effet secondaire limité nécessite une décision distincte. Décrivez l’autorité habilitée à arrêter les tests, le modèle de communication et les procédures d’escalade des incidents. Si des tests en production sont proposés, exigez une justification fondée sur les risques des preuves nécessaires dans cet environnement et des mesures de protection prévues.

Pour les produits reposant largement sur des API, notre guide de définition du périmètre des tests d’intrusion d’API fintech aide à transformer un inventaire des fonctionnalités en comparaisons vérifiables entre acteur, objet et opération. Les banques peuvent adopter cette approche tout en appliquant leurs propres contrôles de gestion des changements et des fournisseurs.

Précisez ce que doit contenir une constatation utile

Demandez que soient précisés la situation de départ testée, la limite concernée, l’observation reproductible, les éléments de preuve techniques, l’analyse de l’impact et les limites. Exigez une distinction claire entre les actions démontrées et les conséquences plausibles mais non testées. Le rapport doit consigner les éléments de couverture bloqués ou exclus ainsi que les constats. Convenez de la manière dont les observations urgentes seront communiquées avant la remise du document final.

Examinez un constat type avec les parties prenantes techniques et responsables des risques. Il doit être possible de comprendre ce qui a échoué, quelle équipe peut y remédier et comment la banque vérifiera le résultat. La présentation visuelle doit soutenir ce raisonnement, et non le remplacer.

Définir les tests de reprise avant de comparer les prix

Identifier la période de contre-test incluse, les limites des scénarios et les éléments probants attendus pour clôturer les constats. Convenez de la marche à suivre si une correction modifie l’architecture, si de nouveaux chemins apparaissent ou si le rôle de test nécessaire devient indisponible. Précisez si le prestataire validera uniquement les constats nommés ou également les cas connexes convenus. Cela évite qu’un exercice de vérification au périmètre tarifé restreint soit considéré comme une reprise implicite de l’ensemble de la mission.

Définissez un critère d’acceptation pour la prestation elle-même : la banque reçoit des preuves exploitables, un relevé de couverture, un transfert technique et une explication claire du retest. La réception d’un fichier PDF dans les délais ne représente qu’une partie du résultat.

Harmonisez les offres avant de faire votre choix

Établissez un tableau comparatif couvrant le périmètre, les hypothèses, les rôles de réalisation, les mesures de protection opérationnelles, les éléments probants, les exclusions et la clôture. Demandez aux prestataires de lever par écrit toute ambiguïté substantielle. Un prix inférieur peut refléter une prestation efficace, mais aussi l’absence de rôles, d’intégrations ou de travaux de validation inclus dans une autre offre. Comparez explicitement ces différences au lieu de vous fier aux tarifs journaliers ou au nombre de constats.

Utilisez la liste de préparation aux tests d’intrusion bancaires pour préparer les éléments nécessaires. L’énoncé final des travaux doit être compréhensible par le responsable du service, l’équipe de test et la personne chargée de l’examen des achats, sans que chacun ait à inventer les hypothèses manquantes.