Exigences DORA en matière de test d'intrusion au-delà du TLPT : le programme de tests des articles 24 et 25

Le chapitre IV du règlement (UE) 2022/2554 organise les tests en deux niveaux.

• Le programme de tests (art. 24 et 25) s'applique aux entités financières autres que les microentreprises. Les microentreprises testent aussi, mais, en vertu de l'art. 25, paragraphe 3, elles combinent une approche fondée sur les risques avec une planification stratégique, en mettant en balance les ressources consacrées et l'urgence ainsi que le type de risque.
• Les tests de pénétration fondés sur la menace (art. 26 et 27) ne s'appliquent qu'aux entités financières identifiées par les autorités compétentes, sur la base de leur impact, de leur caractère systémique et de leur profil de risque lié aux TIC. Les microentreprises et les entités relevant du cadre simplifié de gestion du risque lié aux TIC de l'art. 16, paragraphe 1, en sont exclues. Les entités désignées réalisent un TLPT au moins tous les trois ans.

La plupart des banques, entreprises d'assurance, entreprises d'investissement, établissements de paiement et établissements de monnaie électronique ne recevront jamais de notification de TLPT. Aucun d'entre eux n'est dispensé du premier niveau, et c'est à ce premier niveau que les autorités de surveillance vérifient si les tests sont réguliers, s'ils couvrent les fonctions critiques ou importantes et s'ils débouchent réellement sur une remédiation. Pour le second niveau, voir le TLPT selon l'art. 26 de DORA et le playbook de mission TLPT DORA.

L'article 24 pose le cadre. Le programme doit être :

1. Solide et complet, partie intégrante du cadre de gestion du risque lié aux TIC de l'art. 6, afin d'évaluer l'état de préparation face aux incidents liés aux TIC, d'identifier les faiblesses, les défaillances et les lacunes, et de mettre rapidement en œuvre des mesures correctives (art. 24, paragraphe 1).
2. Un éventail d'évaluations, de tests, de méthodologies, de pratiques et d'outils, appliqués conformément aux art. 25 et 26 (art. 24, paragraphe 2).
3. Fondé sur les risques, en tenant compte de l'évolution du paysage des risques liés aux TIC, des risques propres à l'entité et de la criticité des actifs informationnels et des services (art. 24, paragraphe 3).
4. Mené par des parties indépendantes, internes ou externes. Les testeurs internes doivent disposer de ressources suffisantes et les conflits d'intérêts doivent être évités tout au long de la conception et de l'exécution (art. 24, paragraphe 4).
5. Lié à la remédiation : des procédures et politiques pour hiérarchiser, classer et corriger tous les problèmes constatés, et des méthodes de validation interne pour vérifier que chaque faiblesse est entièrement traitée (art. 24, paragraphe 5).
6. Annuel sur ce qui compte : au moins une fois par an, des tests appropriés sur tous les systèmes et applications TIC soutenant des fonctions critiques ou importantes (art. 24, paragraphe 6).

L'article 25, paragraphe 1, énumère les tests que prévoit le programme, conformément aux critères de proportionnalité de l'art. 4, paragraphe 2 : évaluations et analyses de vulnérabilité, analyses de sources ouvertes, évaluations de la sécurité des réseaux, analyses des lacunes, examens de la sécurité physique, questionnaires et solutions logicielles de balayage, examens du code source lorsque cela est possible, tests fondés sur des scénarios, tests de compatibilité, tests de performance, tests de bout en bout et tests de pénétration. L'article 25, paragraphe 2, ajoute un déclencheur explicite : les dépositaires centraux de titres et les contreparties centrales effectuent des évaluations de vulnérabilité avant tout déploiement ou redéploiement d'applications, de composants d'infrastructure et de services TIC, nouveaux ou existants, soutenant des fonctions critiques ou importantes.

Le règlement délégué (UE) 2024/1774 de la Commission, le RTS sur le cadre de gestion du risque lié aux TIC, apporte des précisions opérationnelles qui alimentent le programme de tests.

• Scans hebdomadaires (art. 10, paragraphe 2) : les procédures de gestion des vulnérabilités doivent garantir des analyses et évaluations automatisées des vulnérabilités des actifs TIC, avec une fréquence et un périmètre proportionnés à leur classification et à leur profil de risque, et au moins une fois par semaine pour les actifs TIC soutenant des fonctions critiques ou importantes. Le même article exige le suivi des bibliothèques tierces et open source, la hiérarchisation des correctifs selon la criticité et le risque de l'actif, la surveillance et la vérification de la remédiation, ainsi que l'enregistrement de chaque vulnérabilité détectée jusqu'à sa résolution.
• Tests du code et des progiciels (art. 16) : la procédure d'acquisition, de développement et de maintenance comprend des examens du code source couvrant à la fois des tests statiques et dynamiques, des tests de sécurité des systèmes et applications exposés à Internet, des tests de sécurité des progiciels au plus tard lors de la phase d'intégration et, lorsque cela est possible, l'analyse et le test du code tiers et open source avant sa mise en production.
• Cadre simplifié (art. 36) : les entités relevant de l'art. 16, paragraphe 1, de DORA établissent un plan de tests de sécurité des TIC qui valide l'efficacité de leurs mesures de sécurité, et mettent à jour ces mesures sans retard injustifié après les tests des systèmes soutenant des fonctions critiques ou importantes.

Le scan hebdomadaire est la fréquence la plus concrète de tout l'édifice des tests DORA, et il figure dans le RTS sur la gestion des risques plutôt que dans les articles 24 et 25. Il est souvent oublié par les équipes qui ne planifient qu'autour du test annuel.

Au sens strict, l'article 25, paragraphe 1, cite les tests de pénétration parmi les tests que prévoit le programme, « tels que », et l'article 24, paragraphe 6, exige des « tests appropriés » sur les systèmes critiques ou importants au moins une fois par an. Le règlement ne dit pas que chaque système doit faire l'objet d'un test d'intrusion chaque année.

En pratique, la marge pour s'en passer est étroite. L'objectif déclaré du programme est d'identifier les faiblesses et les lacunes (art. 24, paragraphe 1). Un scan de vulnérabilités vous dit ce qui manque ; il ne vous dit pas si un attaquant peut s'en servir pour atteindre une fonction critique. Pour un service exposé sur Internet, une passerelle d'accès distant ou l'infrastructure d'identité qui sous-tend une fonction critique, il est difficile de soutenir que des scans seuls constituent le test approprié. La position défendable consiste à consigner, pour chaque fonction critique ou importante, les types de tests appliqués et leurs raisons, et à inclure un test d'intrusion partout où la question est l'exploitabilité. Si vous choisissez un test plus léger pour un système, consignez votre raisonnement : le programme est fondé sur les risques, et un choix motivé est précisément ce que demande le texte.

Un programme qui résiste à la supervision comporte généralement :

• Une correspondance entre les fonctions critiques ou importantes et les systèmes et applications TIC, y compris ceux externalisés auprès de prestataires tiers de services TIC. L'art. 24, paragraphe 6, se mesure par rapport à cette liste : chaque système qui y figure doit faire l'objet d'au moins un test approprié par an.
• Une matrice de tests par système : scans automatisés hebdomadaires (art. 10 du RTS), évaluation des vulnérabilités et évaluation de la sécurité des réseaux, test d'intrusion depuis l'extérieur et depuis l'intérieur avec les accès d'un utilisateur standard, examen du code source pour le code développé en interne ou personnalisé lorsque cela est possible, tests fondés sur des scénarios et tests de bout en bout pour les fonctions elles-mêmes.
• Une indépendance documentée : qui a testé, en interne ou en externe, comment les conflits d'intérêts ont été évités et quelles ressources ont été consacrées (art. 24, paragraphe 4).
• Un registre des constats : classification, priorité, responsable, date cible, remédiation et une étape de validation qui confirme la correction (art. 24, paragraphe 5). Un constat est clôturé lorsque le re-test réussit, pas lorsque le ticket est fermé.
• Des déclencheurs hors calendrier : changements majeurs, nouveaux services exposés sur Internet et, pour les dépositaires centraux de titres et les contreparties centrales, chaque déploiement ou redéploiement touchant des fonctions critiques (art. 25, paragraphe 2).

Gardez la distinction entre boîte noire et boîte grise explicite dans la matrice ; voir tests en boîte noire et en boîte grise. C'est un test mené depuis l'intérieur qui montre si la segmentation autour d'une fonction critique tient lorsqu'un poste de travail est compromis.

Le règlement délégué (UE) 2025/1190 de la Commission du 13 février 2025, publié le 18 juin 2025, est le RTS sur le TLPT. Il fixe les critères utilisés par les autorités ainsi qu'une liste par défaut des entités tenues de réaliser un TLPT, sauf si l'évaluation montre que cela n'est pas justifié : établissements de crédit qui sont des EISm ou d'autres EIS (G-SII ou O-SII) ou qui en font partie, établissements de paiement et établissements de monnaie électronique dépassant 150 milliards d'EUR d'opérations de paiement au cours de chacune des deux années précédentes (ou, pour les établissements de monnaie électronique, 40 milliards d'EUR de monnaie électronique en circulation), dépositaires centraux de titres, contreparties centrales, plateformes de négociation détenant la plus grande part de marché nationale ou une part de marché significative dans l'UE, et certaines entreprises d'assurance et de réassurance (art. 2).

Les caractéristiques qui distinguent le TLPT de tout test interne :

• Des systèmes de production en conditions réelles soutenant plusieurs ou l'ensemble des fonctions critiques ou importantes, avec un périmètre validé par l'autorité (art. 26, paragraphe 2, de DORA).
• Des scénarios fondés sur le renseignement sur les menaces, fournis par un fournisseur de renseignements sur les menaces qui doit être externe à l'entité financière, même lorsque des testeurs internes sont utilisés (art. 27, paragraphe 2, point c), de DORA).
• Les testeurs : des testeurs externes répondant aux exigences de l'art. 27, paragraphe 1, ou des testeurs internes uniquement avec l'approbation de l'autorité, des ressources suffisantes et sans conflit d'intérêts ; une entité qui recourt à des testeurs internes doit faire appel à des testeurs externes tous les trois tests, et les établissements de crédit importants relevant du MSU doivent recourir exclusivement à des testeurs externes (art. 26, paragraphe 8, et art. 27, paragraphe 2, de DORA). Selon les considérants du RTS, une équipe mêlant testeurs internes et externes compte comme un test réalisé avec des testeurs internes.
• Une phase active de red team d'au moins 12 semaines, suivie d'un rejeu et d'un exercice de purple teaming avec la blue team dans les 10 semaines qui suivent sa fin (art. 11, paragraphe 5, et art. 12, paragraphe 5, du RTS).
• Une attestation délivrée par l'autorité après la synthèse des constats et les plans de remédiation (art. 26, paragraphes 6 et 7, de DORA).

Aucun outil, aussi autonome soit-il, ne transforme des tests internes en TLPT. Ce que les tests internes peuvent faire, c'est garantir que le TLPT est consacré aux bonnes questions.

Douze semaines de red teaming fondé sur la menace coûtent cher. Si l'équipe externe entre par un équipement de bordure non corrigé ou par un identifiant par défaut qu'un scan hebdomadaire aurait pu détecter, le test prouve quelque chose que vous auriez déjà dû savoir, et les questions de détection et de réponse auxquelles le TLPT doit répondre disposent de moins de temps.

Des tests internes continus au cours des mois qui précèdent un TLPT comblent cet écart :

• Éliminez d'abord les chemins dont l'exploitabilité est connue. Validez quels constats sont réellement exploitables sur les systèmes qui seront dans le périmètre du TLPT, corrigez-les et re-testez.
• Testez l'intérieur, pas seulement le périmètre. Les scénarios de TLPT supposent généralement un premier point d'ancrage ; des campagnes en boîte grise depuis un compte utilisateur standard montrent jusqu'où va aujourd'hui le mouvement latéral.
• Répétez la production des preuves. Les plans de remédiation et les synthèses des constats qu'exige la clôture d'un TLPT sont plus faciles à produire si l'organisation tient déjà un registre des constats avec validation au titre de l'art. 24, paragraphe 5.
• Mettez la blue team à l'épreuve. Savoir que des tests internes s'exécutent selon un calendrier n'est pas la même chose que savoir si le SOC les détecte ; comparez ce qui a été testé avec ce qui a déclenché une alerte.

Ce même travail couvre le test annuel de l'art. 24, paragraphe 6, pour les entités qui ne sont jamais désignées : il n'est donc pas perdu si la notification de TLPT n'arrive jamais.

Une red team IA autonome pour les réseaux et les infrastructures n'est pas un prestataire de TLPT, ne fournit pas de renseignements sur les menaces et ne rend pas votre équipe interne indépendante au sens de l'art. 24, paragraphe 4 : les ressources et les contrôles relatifs aux conflits d'intérêts restent à documenter par vous. Il vous donne un moyen d'exécuter et de documenter une grande partie du programme des art. 24 et 25 entre deux missions externes.

• Des campagnes planifiées et déclenchées par les changements, en mode boîte noire depuis l'extérieur et en mode boîte grise avec les accès d'un utilisateur standard, sur les systèmes qui soutiennent des fonctions critiques ou importantes.
• Des constats dont l'exploitabilité est prouvée, ce dont la hiérarchisation de l'art. 24, paragraphe 5, a besoin, et des re-tests à la demande comme étape de validation qui clôture chaque constat.
• Correspondance avec les référentiels : les résultats sont associés aux contrôles de DORA (art. 24 à 27) et de TIBER-EU, parmi les 34 référentiels de conformité pris en charge par le moteur, avec des rapports de conformité exportables.
• Approbation humaine des étapes à risque : cinq niveaux d'autonomie définissent ce qui attend la validation d'un opérateur, et les preuves de concept d'exploit peuvent être retenues pour revue. Sur les systèmes de production soutenant des fonctions critiques, c'est le contrôle qui évite que le test ne devienne l'incident ; voir human-in-the-loop.
• Intégrité des preuves : chaque tentative d'attaque est une entrée signée Ed25519 dans une chaîne de hachage SHA-256 propre à chaque campagne, vérifiable hors ligne, et les rapports et lots de preuves sont signés.
• Aucune donnée client ne quitte l'appliance : les modèles s'exécutent sur l'appliance, sans aucun service d'IA externe, de sorte que les constats sur vos systèmes critiques ne sont pas envoyés à un fournisseur d'IA tiers. Voir red team IA on-premise.

• Règlement (UE) 2022/2554 (DORA), art. 16 et 24 à 27 (EUR-Lex)
• Règlement délégué (UE) 2024/1774 de la Commission, RTS sur le cadre de gestion du risque lié aux TIC, art. 10, 16 et 36 (EUR-Lex)
• Règlement délégué (UE) 2025/1190 de la Commission, RTS sur les tests de pénétration fondés sur la menace (EUR-Lex)