Les tests de résilience opérationnelle numérique représentent le troisième pilier du règlement DORA — et probablement celui qui donne le plus de sueurs froides aux RSSI. Non pas parce que le concept est nouveau. Les tests d'intrusion existent depuis des décennies. Mais DORA formalise, durcit et élargit considérablement les exigences. Et surtout, il introduit les TLPT — des tests offensifs d'un niveau de sophistication inédit pour la plupart des entités financières.
Votre établissement est classé comme entité financière significative ? Le premier cycle TLPT devrait être en cours ou planifié. Si ce n'est pas le cas, il y a un problème.
L'architecture des tests DORA : deux niveaux, deux logiques
DORA distingue deux niveaux de tests de résilience. Le premier concerne toutes les entités financières sans exception. Le second — les TLPT — ne s'applique qu'aux entités significatives identifiées par les autorités compétentes.
| Caractéristique | Tests de base | TLPT |
|---|---|---|
| Périmètre | Toutes les entités financières | Entités significatives uniquement |
| Fréquence | Annuel minimum | Tous les 3 ans minimum |
| Exécution | Interne ou externe | Testeurs externes qualifiés uniquement |
| Base légale | Articles 24-25 | Articles 26-27 |
| Périmètre fonctionnel | Systèmes et applications ICT | Fonctions critiques, y compris externalisées |
| Coût estimé | 20 000-100 000 € | 200 000-500 000 € |
Les tests de base — annuels et non négociables
L'article 25 détaille les types de tests que chaque entité financière doit réaliser au minimum une fois par an. La liste est explicite :
Évaluations de vulnérabilité
Scans automatisés et manuels de l'ensemble du périmètre ICT. Pas seulement les systèmes exposés sur Internet — les systèmes internes aussi. Un scan Nessus ou Qualys sur votre périmètre externe ne suffit pas. DORA attend une couverture complète incluant les réseaux internes, les postes de travail, les environnements de développement et les systèmes de gestion des bases de données.
Analyses en source ouverte (OSINT)
Vérifier ce qu'un attaquant peut apprendre sur votre infrastructure à partir de sources publiques. Fuites de credentials sur GitHub ? Configurations exposées sur Shodan ? Employés publiant des photos de leur badge sur LinkedIn ? Ces tests OSINT révèlent souvent des surprises désagréables.
Évaluations de la sécurité réseau
Analyse de l'architecture réseau, segmentation, contrôles d'accès, règles de pare-feu, configurations des équipements. Un audit réseau sérieux prend du temps mais reste essentiel — combien de règles de pare-feu "temporaires" datent de 2019 dans votre infrastructure ?
Tests de pénétration
Pentests classiques — internes et externes — sur les systèmes critiques. L'article 25 précise que les tests doivent couvrir les systèmes, applications et outils ICT qui supportent des fonctions critiques ou importantes. Les résultats doivent être documentés, les vulnérabilités classifiées par criticité, et les plans de remédiation suivis jusqu'à résolution.
Tests de continuité et de reprise
Exercices de bascule sur site de repli, tests de restauration de sauvegardes, simulations de panne de datacenter. Un RSSI d'une société de gestion parisienne m'avouait que leur premier test DRP post-DORA avait révélé un RTO réel de 72 heures pour leur système de gestion de portefeuille — alors que le contrat avec le prestataire garantissait 4 heures. L'écart entre le théorique et le réel est souvent vertigineux.
Pour approfondir les exigences de continuité, consultez notre article sur le plan de continuité d'activité DORA.
Les TLPT — le niveau supérieur
Les Threat-Led Penetration Tests sont directement inspirés du framework TIBER-EU développé par la BCE. DORA les rend obligatoires pour les entités financières significatives — une évolution majeure par rapport à TIBER-EU qui restait volontaire dans la plupart des juridictions.
Qu'est-ce qui rend un TLPT différent d'un pentest classique ?
Un pentest classique teste des vulnérabilités techniques. Un TLPT simule une attaque réaliste menée par un adversaire sophistiqué, basée sur des renseignements actuels sur les menaces qui pèsent spécifiquement sur votre entité.
Le processus se déroule en trois phases distinctes :
Phase 1 — Threat Intelligence (renseignement sur les menaces)
Un fournisseur de Threat Intelligence analyse les menaces spécifiques qui ciblent votre type d'entité, votre secteur et votre géographie. Il identifie les groupes d'attaquants pertinents, leurs tactiques, techniques et procédures (TTP), et élabore des scénarios d'attaque réalistes. Cette phase dure typiquement 4 à 6 semaines.
Attention : le fournisseur de TI et l'équipe de test (Red Team) doivent être deux entités distinctes. Pas de conflit d'intérêt — celui qui conçoit les scénarios ne peut pas être celui qui les exécute.
Phase 2 — Red Team Testing (exécution des tests)
L'équipe Red Team exécute les scénarios d'attaque définis lors de la phase 1. Elle tente de compromettre les fonctions critiques ou importantes de l'entité, en utilisant les mêmes techniques qu'un attaquant réel. La durée typique est de 10 à 12 semaines.
Le périmètre doit inclure les systèmes en production — pas un environnement de test. C'est ce qui rend les TLPT à la fois précieux et risqués. Des gardes-fous sont évidemment nécessaires : cellule de contrôle (White Team), procédures d'escalade, critères d'arrêt d'urgence.
Point crucial : le périmètre inclut les fonctions externalisées chez des prestataires ICT tiers. Si votre core banking est hébergé chez un prestataire cloud, le TLPT peut — et devrait — inclure ce périmètre. L'article 26(4) précise que l'entité financière doit s'assurer que ses prestataires ICT tiers participent au test. En pratique, ça nécessite une préparation contractuelle et opérationnelle significative.
Phase 3 — Closure (clôture et remédiation)
L'équipe Red Team, l'équipe Blue Team (défenseurs) et la White Team se réunissent pour le "purple teaming" — une session collaborative où les attaquants expliquent ce qu'ils ont fait, les défenseurs expliquent ce qu'ils ont détecté (ou pas), et les deux élaborent ensemble un plan de remédiation.
Le rapport final est transmis à l'autorité compétente. Il inclut les scénarios testés, les résultats, les vulnérabilités identifiées et le plan de remédiation. L'autorité peut demander des compléments ou imposer des mesures correctives spécifiques.
Qui conduit les TLPT ? Les exigences sur les testeurs
Les testeurs TLPT doivent répondre à des critères stricts définis dans les RTS du lot 2 :
| Critère | Exigence |
|---|---|
| Indépendance | Externe à l'entité testée (sauf dérogation encadrée) |
| Expertise | Expérience démontrée en Red Teaming dans le secteur financier |
| Assurance | Couverture responsabilité professionnelle adéquate |
| Certifications | CREST, CBEST, ou équivalent reconnu par l'autorité compétente |
| Séparation TI/RT | Le fournisseur de Threat Intelligence doit être distinct de la Red Team |
| Habilitation | Capacité à traiter des informations sensibles/classifiées |
Le marché des prestataires qualifiés reste étroit en Europe. Les principaux acteurs — Context IS, NCC Group, Synack, certaines équipes des Big Four — sont très sollicités. Les délais de démarrage peuvent atteindre 3 à 6 mois. Anticiper est indispensable.
Peut-on utiliser des testeurs internes ?
L'article 27(1)(a) prévoit une dérogation limitée : les testeurs internes peuvent être utilisés pour les TLPT, mais uniquement si l'autorité compétente l'autorise, si l'entité n'a pas de conflit d'intérêt, et si au moins un TLPT sur trois est conduit par un testeur externe. En pratique, la plupart des autorités nationales recommandent fortement le recours à des testeurs externes.
Scénarios de menaces — ce que les TLPT testent réellement
Les scénarios ne sont pas génériques. Ils sont construits à partir du paysage de menaces spécifique à l'entité. Quelques exemples de scénarios typiques :
Compromission via un prestataire ICT tiers. L'attaquant compromet d'abord un prestataire (fournisseur de mise à jour, outil de supervision) puis pivote vers l'entité financière. Scénario inspiré de l'attaque SolarWinds.
Spear-phishing ciblé sur le comité de direction. Campagne de phishing sophistiquée ciblant les dirigeants pour obtenir des accès privilégiés. Scénario classique mais toujours efficace — même avec des formations régulières.
Attaque destructive type wiper. Simulation d'un ransomware destructeur visant à tester la capacité de détection, de confinement et de restauration. Inspiré d'attaques comme NotPetya qui a coûté 10 milliards de dollars à l'économie mondiale en 2017.
Exfiltration de données clients. Tentative d'extraction massive de données personnelles et financières, testant les mécanismes de DLP et la détection d'anomalies.
Manipulation de transactions. Tentative de modifier des ordres de paiement ou des instructions de transfert, testant l'intégrité des systèmes transactionnels.
Budget et ressources — parlons chiffres
Autant être transparent, parce que c'est souvent le premier sujet qui freine.
| Composante | Coût estimé (entité intermédiaire) |
|---|---|
| Tests de base annuels (vulnérabilité + pentest) | 50 000 - 150 000 € |
| TLPT complet (TI + RT + closure) | 200 000 - 500 000 € |
| Outils de gestion des vulnérabilités | 30 000 - 80 000 €/an |
| Ressources internes (coordination, remédiation) | 1-2 ETP dédiés |
| Formation Blue Team | 20 000 - 50 000 €/an |
Pour un établissement de taille intermédiaire, le budget annuel récurrent se situe entre 150 000 et 400 000 euros, avec un pic les années TLPT. Les grandes banques systémiques dépensent évidemment beaucoup plus — certaines dépassent le million d'euros annuel pour l'ensemble du programme de tests.
Calendrier type d'un programme de tests DORA
| Mois | Activité |
|---|---|
| Janvier-Février | Planification annuelle, définition du périmètre, sélection prestataires |
| Mars-Avril | Scans de vulnérabilités, analyses OSINT |
| Mai-Juin | Tests de pénétration internes et externes |
| Juillet-Août | Tests de continuité et de reprise d'activité |
| Septembre-Octobre | Phase TI du TLPT (années TLPT) |
| Novembre-Décembre | Phase RT du TLPT / Remédiation et reporting annuel |
L'articulation avec les autres piliers DORA
Les tests de résilience ne vivent pas en silo. Ils alimentent et sont alimentés par les autres piliers :
Les résultats des tests doivent être intégrés dans le cadre de gestion des risques ICT (pilier 1) et peuvent conduire à une réévaluation du profil de risque. Un TLPT qui révèle une vulnérabilité critique dans votre infrastructure de paiement modifie votre cartographie des risques.
Les scénarios de tests incluent des simulations d'incidents ICT (pilier 2) — le test vérifie la capacité de détection, de classification et de notification dans les délais requis.
Les prestataires ICT tiers (pilier 4) doivent participer aux tests quand ils supportent des fonctions critiques. Cela nécessite des clauses contractuelles appropriées et une coordination opérationnelle.
FAQ — Tests de résilience DORA
Qui décide quelles entités sont soumises aux TLPT ?
L'autorité compétente nationale identifie les entités soumises aux TLPT sur la base de critères de significativité : taille, importance systémique, nature et complexité des activités, profil de risque ICT. La liste n'est pas publique mais les entités concernées en sont informées directement.
Peut-on mutualiser un TLPT entre plusieurs entités d'un même groupe ?
Oui, sous conditions. L'article 26(4) permet la mutualisation au sein d'un groupe, à condition que le périmètre couvre les fonctions critiques de chaque entité concernée. Le résultat est partagé mais chaque entité reste individuellement responsable de la remédiation.
Que se passe-t-il si le TLPT cause un incident en production ?
C'est le risque principal. La White Team est justement là pour ça — elle supervise le test en temps réel et peut déclencher un arrêt d'urgence. Les scénarios sont validés en amont avec des critères d'arrêt clairs. Malgré tout, le risque zéro n'existe pas, d'où l'importance de l'assurance responsabilité professionnelle des testeurs.
Les tests de base peuvent-ils être réalisés en interne ?
Oui, contrairement aux TLPT. L'article 24 précise que les entités peuvent utiliser leurs ressources internes pour les tests de base, à condition de disposer des compétences nécessaires et d'éviter les conflits d'intérêt (l'équipe qui teste ne doit pas être celle qui a conçu le système testé).
Les tests de résilience sont le moment de vérité. C'est là qu'on découvre l'écart entre la conformité sur papier et la résilience réelle. Les entités qui prennent ces tests au sérieux — pas comme un exercice de case à cocher mais comme une vraie simulation de crise — sont celles qui résisteront le mieux le jour où un incident réel surviendra. Pour une vue complète du règlement, consultez notre guide complet DORA.