Tests de résilience numérique — DORA — conformité et résilience opérationnelle numérique

Table des matières

Pourquoi le TLPT change la nature des tests de sécurité

Un test d'intrusion classique répond à une question limitée : telle application, tel réseau, tel périmètre contient-il des vulnérabilités exploitables ? Le TLPT (Threat-Led Penetration Testing), régime de tests avancés introduit par DORA, répond à une question différente et plus dérangeante : une organisation entière, avec ses défenses, ses procédures et ses équipes, est-elle capable de détecter et de contenir une attaque menée par un adversaire réaliste, motivé, et informé sur son secteur ?

Cette différence n'est pas cosmétique. Elle transforme le test en exercice de bout en bout, non annoncé aux équipes de défense, mené sur l'environnement de production réel, et jugé non pas sur le nombre de vulnérabilités trouvées mais sur la capacité de détection et de réaction de l'organisation testée.

Le cadre TLPT dans DORA

Les articles 26 et 27 du règlement DORA, complétés par les normes techniques de réglementation (RTS) élaborées par les autorités européennes de surveillance, définissent le cadre TLPT applicable aux entités financières dont l'importance justifie un niveau de test renforcé. Ce cadre ne sort pas de nulle part : il reprend et harmonise des dispositifs nationaux préexistants, en particulier TIBER-EU (Threat Intelligence-Based Ethical Red Teaming), développé par la Banque centrale européenne et l'Eurosystème, ainsi que des cadres comparables comme CBEST au Royaume-Uni.

DORA généralise cette approche à l'échelle de l'Union, avec des règles communes de portée, de fréquence et de gouvernance, tout en laissant aux autorités compétentes nationales une marge d'application tenant compte du contexte local. L'objectif affiché est double : donner aux autorités une vision réaliste de la résilience effective des acteurs les plus significatifs du système financier, et pousser ces acteurs à investir dans une détection et une réponse aux incidents qui fonctionnent réellement, pas seulement sur le papier.

Le TLPT ne remplace pas les tests de sécurité réguliers (scans de vulnérabilités, tests d'intrusion ciblés, exercices de continuité). Il s'ajoute à ce socle comme test avancé périodique, réservé aux entités dont le profil de risque et l'importance systémique le justifient.

Qui est soumis à un TLPT

Toutes les entités financières couvertes par DORA ne sont pas tenues de conduire un TLPT. L'autorité compétente identifie les entités concernées en fonction de critères tels que l'importance systémique, la nature, l'ampleur et la complexité des services fournis, ainsi que le profil de risque global de l'entité vis-à-vis de la stabilité financière. Les grands établissements bancaires, les infrastructures de marché et certains prestataires critiques figurent typiquement parmi les entités désignées.

Une entité peut également mutualiser une partie de l'exercice avec un prestataire TIC critique partagé par plusieurs entités du secteur, sous certaines conditions encadrées par les autorités, afin d'éviter une multiplication de tests redondants sur une même infrastructure sous-jacente. Les entités de taille plus modeste, non désignées pour un TLPT, restent soumises aux autres obligations de test prévues par DORA — tests de vulnérabilité, analyses de code, tests basés sur des scénarios — à une fréquence adaptée à leur profil de risque.

Ne pas être désigné pour un TLPT ne dispense pas d'un programme de test robuste. Le règlement prévoit un socle de tests proportionné pour toutes les entités, le TLPT constituant le niveau le plus exigeant, réservé à un sous-ensemble d'entités.

Les phases d'un exercice TLPT

Un exercice TLPT se déroule en quatre grandes phases, réparties sur plusieurs mois, encadrées de bout en bout par l'autorité compétente qui joue le rôle de Control Team.

Les quatre phases d'un exercice TLPT, du cadrage initial à la clôture, avant reprise du cycle suivant.

Cadrage (scoping)

La phase de cadrage détermine le périmètre du test : quelles fonctions critiques ou importantes de l'entité seront visées, quels systèmes sous-jacents les supportent, et quels objectifs l'attaquant simulé devra atteindre (exfiltration d'un jeu de données donné, interruption d'un service de paiement, compromission d'un accès privilégié). Ce cadrage est validé conjointement par l'entité testée et l'autorité compétente, qui s'assure que le périmètre choisi reflète effectivement les fonctions les plus sensibles, plutôt qu'un sous-ensemble commode mais peu représentatif.

Threat intelligence ciblée

Un prestataire de threat intelligence produit un profil de menace réaliste, construit à partir de renseignements sur les groupes d'attaquants effectivement actifs contre le secteur financier et contre des organisations comparables à l'entité testée. Ce profil documente les techniques, tactiques et procédures (TTP) susceptibles d'être employées, et sert de base au scénario que suivra ensuite l'équipe red team. Cette étape distingue fondamentalement le TLPT d'un test d'intrusion générique : l'attaque simulée n'est pas un catalogue de techniques génériques, elle rejoue un mode opératoire plausible pour l'entité concernée.

Test red team

Le profil de menace établi pour une banque de détail pointe vers un groupe connu pour cibler les identifiants d'administrateurs via des campagnes d'hameçonnage suivies d'un mouvement latéral vers les systèmes de paiement. L'équipe red team reproduit ce mode opératoire précis — hameçonnage ciblé, élévation de privilèges, tentative d'accès aux systèmes de virement — plutôt que de tester des vulnérabilités génériques sans lien avec une menace réelle documentée.

L'équipe red team, accréditée et indépendante, exécute le scénario en conditions réelles, sur l'environnement de production, sans en informer les équipes de défense (le Blue Team) qui continuent d'opérer normalement. Seule une petite cellule interne, la White Team, est informée à l'avance de la tenue du test, afin de pouvoir arbitrer en cas de dérive ou de risque opérationnel réel. Cette absence d'annonce est ce qui donne sa valeur à l'exercice : il mesure la détection et la réaction effectives, pas la performance d'une équipe prévenue et préparée.

Un test red team mal cadré peut produire un impact opérationnel réel sur des systèmes de production. Des règles d'engagement précises, des points d'arrêt d'urgence et une supervision continue par la White Team sont indispensables pour éviter qu'un exercice de résilience ne devienne lui-même un incident majeur à notifier.

Clôture et rapport

À l'issue du test, les équipes red team, threat intelligence et défense (désormais informée) se réunissent pour une séance de restitution partagée (purple teaming). Un rapport de clôture documente le déroulement de l'attaque, les points d'entrée exploités, les délais de détection observés, les failles de procédure identifiées et un plan de remédiation avec échéances. Une attestation de réalisation du test, conforme au format attendu par l'autorité compétente, est transmise à cette dernière comme preuve de conformité.

Fréquence : le cycle triennal

DORA fixe une fréquence de référence d'un TLPT complet au moins tous les trois ans pour chaque entité désignée, sauf ajustement décidé par l'autorité compétente en fonction du profil de risque, d'un changement significatif d'infrastructure, ou de la survenue d'incidents majeurs qui justifieraient un test anticipé. Ce cycle triennal ne signifie pas trois années d'inactivité entre deux tests avancés : les autres obligations de test de DORA (scans de vulnérabilités, tests basés sur des scénarios, tests de continuité) continuent de s'appliquer selon leur propre fréquence, generalement annuelle.

Le plan de remédiation issu d'un TLPT ne doit pas rester un document dormant jusqu'au cycle suivant. Les correctifs les plus critiques gagnent à être vérifiés par un test ciblé indépendant avant l'échéance des trois ans, plutôt que d'attendre la prochaine campagne complète pour découvrir qu'ils n'ont pas tenu.

Les rôles impliqués

Un exercice TLPT mobilise plusieurs parties aux responsabilités distinctes, dont la séparation est elle-même un gage d'intégrité du test.

Rôle	Composition	Responsabilité principale
Control Team	Autorité compétente (parfois appuyée par une équipe TLPT dédiée)	Valide le cadrage, supervise le déroulement, réceptionne les preuves
White Team	Cellule restreinte au sein de l'entité testée	Seule informée à l'avance ; arbitre les risques opérationnels en temps réel
Threat Intelligence Provider	Prestataire accrédité, indépendant du testeur	Produit le profil de menace ciblé à partir de renseignements sectoriels
Red Team	Testeurs accrédités, indépendants de l'entité et du TI Provider	Exécute l'attaque simulée en conditions réelles
Blue Team	Équipes de défense internes	Non informée à l'avance ; détecte et réagit dans les conditions du test

La séparation entre le prestataire de threat intelligence et l'équipe red team n'est pas accessoire : elle garantit que le scénario d'attaque n'est pas construit par la même équipe qui l'exécute, ce qui limiterait le réalisme et l'indépendance du test.

Choisir ses prestataires

Le choix des prestataires — threat intelligence et red team — répond à des exigences précises. Les testeurs doivent démontrer une accréditation ou une qualification reconnue, une expérience documentée sur des exercices comparables, une couverture d'assurance adaptée, et une indépendance vis-à-vis de l'entité testée suffisante pour éviter tout conflit d'intérêts. Certaines autorités compétentes publient ou reconnaissent des listes de prestataires qualifiés, ce qui simplifie la sélection sans dispenser l'entité de sa propre diligence contractuelle.

Les clauses contractuelles avec ces prestataires doivent couvrir la confidentialité stricte du déroulement du test, les règles d'engagement et les limites techniques à respecter, les procédures d'arrêt d'urgence, ainsi que les responsabilités en cas de dommage causé aux systèmes testés. Un prestataire de threat intelligence recruté sans vérification de son indépendance vis-à-vis de l'équipe red team, ou une équipe red team dépourvue d'assurance responsabilité civile professionnelle adaptée à des tests en production, constituent des lacunes fréquentes qui exposent l'entité en cas d'incident pendant le test.

Preuves, documentation et supervision

L'autorité compétente attend un dossier de preuves complet à l'issue de chaque TLPT : le cadrage validé, le profil de menace produit par le TI Provider, le rapport détaillé du red team, le rapport de clôture partagé (purple teaming), le plan de remédiation avec échéances, et l'attestation formelle de réalisation du test selon le format attendu. Ce dossier constitue la preuve principale examinée lors des contrôles ultérieurs, bien au-delà du seul fait d'avoir « fait un test ».

La supervision ne s'arrête pas à la remise du rapport : l'entité doit démontrer un suivi effectif des correctifs, avec des échéances tenues et une vérification de leur efficacité réelle. Un plan de remédiation resté sans suite jusqu'au cycle suivant expose l'entité à des observations sévères lors d'une inspection, indépendamment de la qualité du test initial.

Amélioration continue et remédiation

Un TLPT n'a de valeur que s'il modifie durablement la posture de sécurité de l'entité testée. Les enseignements typiques d'un exercice débordent souvent le strict périmètre technique : délais de détection trop longs, procédures d'escalade mal comprises par les équipes d'astreinte, cloisonnement insuffisant entre systèmes critiques et systèmes périphériques, ou encore dépendance excessive à un contrôle unique facilement contourné.

Les correctifs les plus utiles combinent souvent des mesures techniques (segmentation réseau, durcissement des accès privilégiés, détection renforcée) et des mesures organisationnelles (révision des procédures d'astreinte, formation ciblée des équipes de sécurité, clarification des chaînes de décision en cas d'alerte). Le cycle suivant de cadrage TLPT devrait explicitement intégrer ces correctifs comme points de vérification, afin de constater s'ils ont réellement changé le comportement de l'organisation face à une attaque similaire.

Pièges courants et checklist

Les difficultés les plus fréquemment observées lors des premières campagnes TLPT :

cadrage réduit à un périmètre confortable, écartant les fonctions réellement critiques par souci de simplicité ;
profil de menace générique, peu adapté au secteur ou à la taille réelle de l'entité, produit par un prestataire peu spécialisé ;
règles d'engagement imprécises, sans procédure d'arrêt d'urgence clairement testée avant le lancement ;
plan de remédiation sans échéances vérifiables, jamais suivi jusqu'au cycle suivant ;
confusion entre TLPT et test d'intrusion classique dans la communication interne, ce qui affaiblit le soutien de la direction au moment critique ;
absence de coordination avec les prestataires TIC critiques dont les systèmes font partie du périmètre testé.

Une checklist minimale avant d'engager un exercice TLPT :

cadrage validé conjointement avec l'autorité compétente, couvrant les fonctions réellement critiques ;
threat intelligence provider et red team sélectionnés selon des critères d'indépendance et d'accréditation documentés ;
règles d'engagement et procédure d'arrêt d'urgence formalisées et testées avant le lancement ;
White Team désignée et briefée, avec un canal de décision rapide en cas de dérive ;
plan de remédiation assorti d'échéances et d'un responsable identifié par correctif ;
dossier de preuves structuré dès le cadrage, pas reconstitué a posteriori pour la clôture.

Ce qu'il faut retenir

Le TLPT déplace la question posée par un test de sécurité : non plus « trouve-t-on des vulnérabilités ? » mais « l'organisation détecte-t-elle et contient-elle une attaque réaliste ? ». Cette bascule impose une rigueur particulière sur le cadrage, l'indépendance des prestataires, la gestion du risque opérationnel pendant le test lui-même, et surtout sur le suivi effectif des correctifs jusqu'au cycle suivant. Un TLPT réussi ne se mesure pas au nombre de failles trouvées, mais à la vitesse et à la justesse de la réaction qu'il révèle — et à ce que l'organisation en fait une fois le rapport refermé.

L'essentiel à retenir

Ce chapitre détaille le régime de tests avancés TLPT (Threat-Led Penetration Testing) introduit par DORA, qui va au-delà du test d'intrusion classique en simulant une attaque réaliste pilotée par du renseignement sur la menace. Il décrit les quatre phases d'un exercice — cadrage, threat intelligence ciblée, test red team, clôture — ainsi que les rôles associés (Control Team, White Team, testeurs, prestataire de threat intelligence). Il couvre la fréquence triennale attendue, les critères de sélection des prestataires accrédités et l'exploitation des preuves produites pour alimenter un cycle d'amélioration continue de la posture de sécurité.

Questions fréquentes

Un TLPT peut-il être mutualisé entre plusieurs entités financières ?

Oui, dans certaines conditions encadrées par l'autorité compétente, une entité peut mutualiser une partie de l'exercice avec un prestataire TIC critique partagé par plusieurs entités du secteur, afin d'éviter de multiplier des tests redondants sur une même infrastructure sous-jacente. Cette mutualisation reste néanmoins encadrée pour garantir que chaque entité conserve un niveau de test proportionné à son propre profil de risque.

Que se passe-t-il si un test red team provoque un incident opérationnel réel ?

Des règles d'engagement précises et une procédure d'arrêt d'urgence, supervisées par la White Team, doivent permettre d'interrompre immédiatement le test dès qu'un risque opérationnel réel se matérialise. Si l'impact franchit les seuils de classification prévus par ailleurs dans DORA, l'incident devra être traité selon la chaîne de notification habituelle des incidents majeurs, indépendamment du fait qu'il soit survenu pendant un exercice de test.

Le rapport TLPT est-il rendu public ou communiqué aux clients de l'entité testée ?

Non, le déroulement et le contenu détaillé d'un TLPT restent strictement confidentiels, réservés à l'entité testée et à son autorité compétente. Cette confidentialité protège à la fois les vulnérabilités identifiées, qui ne doivent pas être exposées avant remédiation, et l'intégrité du dispositif de test lui-même pour les cycles suivants.

Quelle différence entre le Threat Intelligence Provider et l'équipe red team ?

Le Threat Intelligence Provider produit le profil de menace réaliste — les techniques, tactiques et procédures d'un attaquant plausible pour le secteur et l'entité concernée — sans participer à l'exécution de l'attaque. L'équipe red team exécute ensuite ce scénario en conditions réelles. Les deux rôles sont tenus par des prestataires distincts et indépendants afin de préserver le réalisme et l'objectivité du test.

Un changement d'infrastructure majeur entre deux cycles TLPT déclenche-t-il un test anticipé ?

L'autorité compétente peut effectivement ajuster la fréquence de référence et demander un test anticipé si un changement significatif d'infrastructure, une acquisition, une migration majeure vers un nouveau prestataire cloud ou la survenue d'un incident majeur modifie sensiblement le profil de risque de l'entité entre deux cycles triennaux.

Comment le TLPT s'articule-t-il avec les autres obligations de test prévues par DORA ?

Le TLPT constitue le niveau le plus avancé d'un ensemble de tests gradués prévus par DORA. En parallèle, l'entité continue de réaliser des tests plus fréquents et moins exhaustifs — scans de vulnérabilités, tests basés sur des scénarios, tests de continuité d'activité — généralement selon une périodicité annuelle, indépendamment du cycle triennal du TLPT.

Qui décide du périmètre exact testé lors d'un TLPT ?

Le cadrage résulte d'une validation conjointe entre l'entité testée et son autorité compétente. L'entité propose un périmètre couvrant ses fonctions critiques ou importantes, mais l'autorité s'assure que ce périmètre est réellement représentatif et ne se limite pas à un sous-ensemble commode qui minorerait la portée réelle du test.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

Besoin d'un accompagnement complet ? De la gap analysis à la certification — nos experts vous guident.

Devis gratuit