Red team vs pentest : test d'intrusion et TLPT dans DORA - différences, entités concernées et préparation

Le règlement DORA impose aux entités financières de tester leur résilience opérationnelle numérique à deux niveaux. Le premier concerne presque toutes les entités : c'est le programme de tests des art. 24 et 25, qui comprend notamment les scans de vulnérabilités, les examens du code source et les tests d'intrusion. Le second n'en concerne que quelques-unes : ce sont les tests avancés des art. 26 et 27, les tests d'intrusion fondés sur la menace (TLPT), menés sur des systèmes de production en fonctionnement sous la supervision de l'autorité.

Confondre ces deux niveaux coûte cher, dans un sens comme dans l'autre. Une entreprise qui pense qu'« un pentest par an » équivaut à un TLPT ne sera pas prête lorsque l'autorité - en Pologne, la KNF - la désignera pour un TLPT. Une entreprise qui pense que le TLPT ne la concerne pas, et qu'elle n'a donc besoin d'aucun test, oublie le programme obligatoire de l'art. 24. Voici la comparaison red team vs pentest dans DORA, les critères de désignation pour un TLPT, le schéma du test et les actions utiles quelle que soit la décision de l'autorité.

Test d'intrusion et TLPT : la comparaison

En résumé : un test d'intrusion vérifie quelles vulnérabilités présente un système. Un TLPT vérifie si l'organisation dans son ensemble - ses personnes, ses processus et sa technologie - résiste à une attaque réaliste contre ses fonctions les plus importantes.

DORA, articles 24 et 25 : un programme de tests exigé de presque toutes les entités

Avant même la question du TLPT, il faut disposer du socle que DORA exige de toutes les entités financières autres que les microentreprises :

• les entités financières autres que les microentreprises établissent un programme de tests de résilience opérationnelle numérique fondé sur les risques (art. 24, par. 1 à 3).
• les tests sont effectués par des parties indépendantes, internes ou externes (art. 24, par. 4).
• tous les systèmes et applications de TIC qui soutiennent des fonctions critiques ou importantes sont testés au moins une fois par an (art. 24, par. 6).
• les problèmes mis en évidence par les tests sont classés et résolus selon des procédures établies (art. 24, par. 5).

Les plus petites entités testent elles aussi leurs systèmes, mais de façon simplifiée. Les microentreprises effectuent les tests visés à l'art. 25, par. 1, en combinant une approche fondée sur les risques avec une planification stratégique des tests des TIC, et en mettant en balance les ressources et le temps qui y sont consacrés avec l'urgence, le type de risque et la criticité des actifs informationnels et des services (art. 25, par. 3).

L'art. 25 dresse une liste ouverte des tests qui composent le programme : évaluations et analyses de vulnérabilité, analyses de sources ouvertes, évaluations de la sécurité des réseaux, analyses des écarts, 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 d'intrusion (art. 25, par. 1). Les tests d'intrusion n'y sont qu'un élément parmi d'autres - aux côtés des scans, des examens du code source et des tests fondés sur des scénarios. Ce qui distingue un test d'intrusion d'un scan de vulnérabilités et d'un audit de conformité est expliqué sur notre page tests d'intrusion.

Le règlement délégué qui complète DORA ajoute des exigences minimales précises : scans et évaluations automatisés des vulnérabilités des actifs de TIC qui soutiennent des fonctions critiques ou importantes, au moins une fois par semaine (art. 10, par. 2, du règlement délégué (UE) 2024/1774). La procédure de développement des systèmes comprend des examens du code source avec des tests statiques et dynamiques, y compris des tests de sécurité des applications exposées à l'internet (art. 16, par. 3, du règlement délégué (UE) 2024/1774).

TLPT : quelles entités sont concernées

Les entités financières désignées effectuent un TLPT au moins tous les trois ans ; l'autorité compétente peut modifier cette fréquence (art. 26, par. 1). C'est l'autorité qui décide quelles entités doivent effectuer un TLPT, et les modalités nationales peuvent différer d'un État membre à l'autre. L'autorité polonaise de surveillance financière (KNF) désigne, par voie de décision, les entités tenues d'effectuer un TLPT, approuve les testeurs internes et délivre l'attestation du test (art. 18zk de la loi sur la surveillance du marché financier).

L'autorité tient compte de trois critères (art. 26, par. 8, troisième alinéa) :

• l'incidence des services et des activités de l'entité financière sur le secteur financier
• les éventuels problèmes de stabilité financière, y compris le caractère systémique de l'entité
• le profil spécifique de risque lié aux TIC et le niveau de maturité des TIC

Le règlement délégué désigne les catégories d'entités dont l'autorité exige un TLPT, sauf si une évaluation montre que ce n'est pas justifié (art. 2, par. 2, du règlement délégué (UE) 2025/1190) :

• établissements de crédit d'importance systémique (EISm, autres EIS) et établissements faisant partie de leurs groupes
• établissements de paiement et établissements de monnaie électronique au-delà des seuils de valeur des opérations ou de monnaie électronique en circulation
• dépositaires centraux de titres et contreparties centrales
• plates-formes de négociation qui remplissent des critères de part de marché
• les plus grandes entreprises d'assurance et de réassurance (seuils de primes et de provisions techniques)

L'obligation de TLPT ne s'applique ni aux microentreprises ni aux entités qui appliquent le cadre simplifié de l'art. 16 (art. 26, par. 1).

Si votre organisation est proche des seuils de cette liste ou joue un rôle important sur le marché, mieux vaut partir du principe qu'une décision peut arriver et planifier la préparation longtemps à l'avance - le test et les étapes qui l'entourent s'étendent sur de nombreux mois.

Déroulement d'un TLPT : les phases

Le règlement délégué (UE) 2025/1190 divise le test en cinq étapes. L'autorité supervise le déroulement et délivre, à la fin, une attestation qui permet la reconnaissance mutuelle du test.

1. 01

   Préparation

   Notification par l'autorité, constitution de l'équipe chargée du contrôle (control team), document de spécification du périmètre approuvé par l'organe de direction, sélection des prestataires.

2. 02

   Renseignement sur les menaces

   Un fournisseur externe de renseignements sur les menaces prépare au moins 3 scénarios d'attaque adaptés à l'entité financière.

3. 03

   Test de l'équipe rouge

   La phase active d'attaque sur les systèmes de production dure au moins 12 semaines, avec des rapports d'avancement hebdomadaires à l'équipe chargée du contrôle.

4. 04

   Clôture

   Rapport de test de l'équipe rouge sous 4 semaines, rapport de l'équipe bleue, rejeu de l'attaque (replay) et atelier de purple teaming.

5. 05

   Mesures correctives et attestation

   Rapport de synthèse et plan de mesures correctives pour l'autorité, puis attestation de réalisation du test.

Les délais détaillés de chaque étape, les rôles dans le test et les exigences applicables aux testeurs sont présentés sur notre page TLPT DORA : tests d'intrusion fondés sur la menace.

Red team vs pentest : une autre méthode, une autre question

Le TLPT repose sur le red teaming, qui diffère d'un test d'intrusion classique bien plus que ne le laisse penser la proximité des termes :

• Objectif. Un pentest cherche à trouver le plus de vulnérabilités possible dans un périmètre convenu. Une red team doit atteindre un objectif précis - par exemple l'accès au système de paiement - par le chemin qu'emprunterait un véritable adversaire.
• Information des équipes. Un pentest se déroule généralement au su des administrateurs. En red teaming, seule l'équipe chargée du contrôle est informée du test, et les défenseurs réagissent comme face à un véritable incident.
• Périmètre. Un pentest couvre les systèmes désignés. Une red team peut emprunter n'importe quel chemin dans le cadre des scénarios approuvés - y compris les personnes, les processus et les fournisseurs.
• Résultat. Un pentest produit une liste de vulnérabilités avec preuves. Le red teaming montre aussi si l'attaque a été détectée, en combien de temps, et si la réaction a fonctionné - et après le test, les deux camps l'analysent ensemble (purple teaming).

Les deux approches se complètent. Une red team qui s'introduit dès la première semaine par une vulnérabilité connue et non corrigée gaspille le temps du test sur ce qu'un simple pentest, voire un scanner, aurait trouvé.

La méthodologie du TLPT est issue du cadre européen TIBER-EU pour les tests red team dans le secteur financier.

Se préparer au TLPT - avant que la décision n'arrive

Ces actions sont utiles, que l'autorité de surveillance (en Pologne, la KNF) désigne ou non votre organisation pour un TLPT, car elles découlent d'obligations déjà en vigueur :

1. Un programme mature au titre des art. 24 et 25. Des scans réguliers, des tests d'intrusion des systèmes qui soutiennent des fonctions critiques ou importantes et le retest (contre-test) des corrections. Corrigez les vulnérabilités connues avant le test, pas pendant.
2. Un inventaire des fonctions critiques ou importantes et des systèmes qui les soutiennent, avec les dépendances vis-à-vis des prestataires tiers de services TIC.
3. Détection et réponse. Le TLPT met votre défense à l'épreuve : mieux vaut exercer au préalable la surveillance, l'escalade et la gestion des incidents sur des scénarios.
4. Prestataires TIC. Lorsque le périmètre inclut des prestataires tiers de services TIC, l'entité financière assure leur participation et conserve l'entière responsabilité ; un test groupé est possible (art. 26, par. 3 et 4). Dans les contrats portant sur des services qui soutiennent des fonctions critiques ou importantes, DORA exige une clause sur la participation du prestataire au TLPT (art. 30, par. 3).
5. Équipe chargée du contrôle et décisions de la direction. Quelqu'un doit piloter le test du côté de l'organisation, en protéger la confidentialité et décider d'interrompre les actions si elles menacent la production.
6. Choix des testeurs et du fournisseur de renseignements sur les menaces conformément à l'art. 27 - les exigences sont détaillées ci-dessous.

Exigences applicables aux testeurs TLPT : comment lire les offres

Une entité financière ne peut recourir qu'à des testeurs qui (art. 27, par. 1) :

1. possèdent l'aptitude et la réputation les plus élevées
2. possèdent des capacités techniques et organisationnelles et justifient d'une expertise spécifique en matière de renseignement sur les menaces, de tests d'intrusion et de tests en mode red team
3. sont certifiés par un organisme d'accréditation dans un État membre ou adhèrent à des codes de conduite ou à des cadres éthiques formels
4. fournissent une assurance indépendante ou un rapport d'audit sur la bonne gestion des risques liés au TLPT, y compris la protection des informations confidentielles
5. sont entièrement couverts par une assurance de responsabilité civile professionnelle

Lors de l'évaluation des offres, vérifiez que le prestataire a documenté chacun de ces points : certifications ou codes de conduite, assurance indépendante sur la gestion des risques du test et sur la protection des informations confidentielles, assurance responsabilité civile professionnelle, ainsi que l'expérience de l'équipe et les références exigées par le règlement délégué. Une entité financière qui a recours à des testeurs internes fait appel à un testeur externe tous les trois tests. Les établissements de crédit importants supervisés par la BCE ont uniquement recours à des testeurs externes (art. 26, par. 8, premier et deuxième alinéas).

Comment nous pouvons vous aider

Nous n'intervenons pas comme testeur TLPT : pendant le test lui-même, nous ne remplaçons ni l'équipe rouge (red team) ni le fournisseur de renseignements sur les menaces. Nous vous accompagnons avant et après le test : nous réalisons des tests d'intrusion et des examens du code source dans le cadre du programme des art. 24 et 25, évaluons votre programme de tests et votre préparation au TLPT, analysons les offres des testeurs et des fournisseurs de renseignements sur les menaces au regard de l'art. 27 et, après le test, vérifions par des tests de confirmation les corrections prévues dans le plan de mesures correctives. Nous échangeons avec vous en anglais ou en polonais.

Les services que nous proposons aux entités soumises à DORA sont présentés sur notre page DORA : tests de résilience et risque lié aux TIC.