Tests de résilience DORA : TLPT et obligations

Introduction

Le règlement DORA (règlement (UE) 2022/2554) fait des tests de résilience opérationnelle numérique l’un de ses piliers fondamentaux. Les articles 24 à 27 imposent aux entités financières de tester régulièrement la robustesse de leurs systèmes TIC face aux menaces cyber et aux incidents opérationnels. Ce cadre de tests se décline en deux niveaux : les tests de résilience de base, applicables à toutes les entités, et les tests de penetration fondés sur la menace (TLPT – Threat-Led Penetration Testing), réserves aux entités d’importance systémique.

L’enjeu est considérable. Il ne s’agit plus de réaliser des tests de sécurité ponctuels et isolés, mais d’inscrire les tests dans un programme structuré et périodique, supervise par l’organe de direction et conforme à des normes techniques de réglementation (RTS) définies par les autorités européennes de surveillance. Pour une vue d’ensemble du règlement, consultez notre guide DORA. Pour un complement sur les méthodologies d’audit, consultez notre article sur l’audit de sécurité informatique.

Le cadre général des tests de résilience (article 24)

Obligation de programme de tests

L’article 24 de DORA impose à chaque entité financière d’établir, de maintenir et de reexaminer un programme de tests de résilience opérationnelle numérique. Ce programme constitue un élément intégral du cadre de gestion des risques TIC de l’entité.

Le programme de tests doit :

• Être proportionnel à la taille, à l’activité et au profil de risque de l’entité.
• Couvrir l’ensemble des systèmes et applications TIC critiques de l’entité.
• Être documenté et approuvé par l’organe de direction.
• Être reexamine périodiquement et mis à jour en fonction de l’évolution des menaces et des changements dans l’infrastructure TIC.

Entites concernées

Toutes les entités financières soumises à DORA doivent mettre en place un programme de tests de résilience. Toutefois, le niveau d’exigence varie selon la taille et l’importance systémique de l’entité :

• Les entités relevant du cadre simplifié (article 16) sont soumises à des exigences allegees en matière de tests.
• Les entités ne relevant pas du cadre simplifié doivent réaliser l’ensemble des tests de base prévus à l’article 25.
• Les entités d’importance systémique désignées par les autorités compétentes doivent en outre réaliser des TLPT (article 26).

Les tests de résilience de base (article 25)

Types de tests requis

L’article 25, paragraphe 1, énumère les catégories de tests que les entités financières doivent réaliser dans le cadre de leur programme de résilience :

Tests de vulnérabilité (vulnerability assessments). Il s’agit d’analysés systématiques des systèmes TIC pour identifier les failles de sécurité connues. Les scans de vulnérabilité automatisés, complètes par des analyses manuelles, constituent la base de ce volet.

Tests de performance et de charge (performance testing). Ces tests évaluent la capacité des systèmes TIC a fonctionner sous des conditions de charge elevee, simulant des pics d’activité ou des conditions degradees.

Tests de bout en bout (end-to-end testing). Ils verifient le fonctionnement complet d’un processus métier, de l’initiation à la conclusion, en passant par l’ensemble des composants TIC impliqués.

Tests de penetration (penetration testing). Les tests de penetration vont au-delà des scans de vulnérabilité. Ils simulent des attaques réelles contre les systèmes de l’entité pour évaluer leur resistance. Ces tests doivent être réalisés par des testeurs qualifiés, internes ou externes.

Analyses de code source (source code reviews). Lorsque cela est possible et pertinent, les entités doivent réaliser des revues du code source de leurs applications critiques pour identifier les failles de sécurité.

Tests de compatibilité et de regression. Ces tests verifient que les mises à jour et les modifications des systèmes TIC n’introduisent pas de nouvelles vulnérabilités ou de dysfonctionnements.

Tests de sécurité des réseaux. Ils évaluent la sécurité de l’architecture réseau de l’entité, y compris la segmentation, le filtrage et la détection d’intrusion.

Exercices bases sur des scénarios (scénario-based testing). Ces exercices simulent des incidents spécifiques (cyberattaque, défaillance d’un prestataire, panne d’infrastructure) pour évaluer la capacité de réponse de l’entité.

Tests de basculement et de continuité (switchover testing). Ils verifient la capacité de l’entité a basculer vers ses systèmes de secours en cas de défaillance des systèmes principaux. Ces tests sont essentiels pour valider les plans de continuité d’activité (BCP) et les plans de reprise d’activité (DRP).

Frequence des tests

DORA n’impose pas une fréquence unique pour tous les tests. La fréquence doit être définie dans le programme de tests en fonction du profil de risque de l’entité et de la criticite des systèmes concernés.

Les normes techniques de réglementation (RTS) adoptées par les AES precisent les attentes en matière de fréquence :

Type de test	Frequence recommandée
Scans de vulnérabilité	Au moins trimestriels pour les systèmes critiques
Tests de penetration	Au moins annuels
Tests de continuité/basculement	Au moins annuels
Exercices bases sur des scénarios	Au moins annuels
Revues de code source	À chaque mise en production majeure
Tests de performance	Au moins annuels ou à chaque changement significatif

Ces frequences constituent des minimums. Les entités à haut profil de risque doivent adapter la fréquence à la hausse en fonction de l’évolution des menaces.

Documentation et reporting

Chaque test doit faire l’objet d’un rapport documenté comprenant :

• La méthodologie utilisée.
• Les résultats détaillés (vulnérabilités identifiées, scénarios testes, performances mesurees).
• Les recommandations d’amélioration.
• Le plan de remédiation avec des échéances.

L’organe de direction doit être informe des résultats des tests et des plans de remédiation. Les autorités de surveillance peuvent demander communication de ces rapports dans le cadre de leurs activités de supervision.

Les tests de penetration fondés sur la menace – TLPT (article 26)

Définition et principes

Les TLPT constituent le niveau le plus avance de tests de résilience prévu par DORA. Ils consistent à simuler des attaques réelles contre les systèmes TIC de l’entité, en s’appuyant sur des renseignements sur la menace (threat intelligence) spécifiques au secteur financier et à l’entité concernée.

Les TLPT se distinguent des tests de penetration classiques sur plusieurs points :

• Ils sont fondés sur une analyse préalable de la menace : un prestataire de renseignement sur la menace identifie les scénarios d’attaque les plus réalistes et les plus pertinents pour l’entité.
• Ils ciblent les systèmes de production (live production systems) de l’entité, et non des environnements de test isolés.
• Ils couvrent l’ensemble de la surface d’attaque de l’entité, y compris les personnes (ingénierie sociale), les processus et les technologies.
• Ils sont réalisés par des testeurs externes qualifiés répondant à des critères stricts.
• Ils font l’objet d’un cadre de gouvernance spécifique, avec l’implication de l’autorité de surveillance.

Le cadre des TLPT de DORA s’inspiré directement du cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) développé par la Banque centrale européenne. Les entités qui ont déjà realise des tests TIBER-EU disposent donc d’un avantage dans la mise en conformité.

Qui doit réaliser des TLPT ?

Les TLPT ne sont obligatoires que pour les entités financières désignées par les autorités compétentes comme devant les réaliser. Les critères de désignation prennent en compte :

• L’importance systémique de l’entité.
• Le profil de risque TIC global de l’entité.
• La criticite des services fournis par l’entité pour le secteur financier.
• La maturité du cadre de gestion des risques TIC de l’entité.

En pratique, sont principalement concernées :

• Les établissements de crédit d’importance systémique (G-SIB, O-SII), qui doivent par ailleurs se conformer aux exigences de sécurité des données du RGPD.
• Les grandes infrastructures de marché (CCP, CSD).
• Les grandes entreprises d’assurance.
• Les grandes sociétés de gestion.
• Les plates-formes de négociation d’importance significative.

Les entités qui relèvent du cadre simplifié (article 16) ne sont jamais tenues de réaliser des TLPT.

Frequence des TLPT

L’article 26, paragraphe 1, de DORA prévoit que les TLPT doivent être réalisés au moins tous les trois ans. L’autorité compétente peut toutefois exiger une fréquence plus elevee en fonction du profil de risque de l’entité.

Ce cycle triennal est cohérent avec la pratique établie par TIBER-EU et s’inscrit dans la logique d’évaluation continue promue par la directive NIS2. Entre deux TLPT complets, l’entité doit maintenir son programme de tests de base (article 25) et surveiller l’évolution des menaces.

Deroulement d’un TLPT

Un TLPT se déroule en plusieurs phases clairement définies :

Phase 1 : Préparation et cadrage. L’entité, en coordination avec l’autorité de surveillance, définit le périmètre du TLPT, les objectifs et les contraintes. Un comité de pilotage restreint est constitue (le “white team”), compose de personnes habilitées a connaître l’existence du test mais n’y participant pas directement.

Phase 2 : Renseignement sur la menace (threat intelligence). Un prestataire de renseignement sur la menace realise une analyse des menaces spécifiques à l’entité. Il identifie les scénarios d’attaque les plus réalistes, les techniques, tactiques et procédures (TTP) des adversaires potentiels, et les vecteurs d’attaque les plus probables. Ce travail produit un rapport de renseignement sur la menace qui sert de base au scénario de test.

Phase 3 : Execution du test (red teaming). Une équipe de testeurs externes (le “red team”) exécute les scénarios d’attaque identifiés lors de la phase de renseignement. Les testeurs tentent de compromettre les systèmes de production de l’entité en utilisant les mêmes techniques que des attaquants réels. Le test se déroule sur une période de plusieurs semaines à plusieurs mois.

Phase 4 : Cloture et remédiation. À l’issue du test, les résultats sont présentes à l’organe de direction et à l’autorité de surveillance. Un plan de remédiation est élaboré, avec des échéances précises pour corriger les vulnérabilités identifiées. L’autorité de surveillance examiné les résultats et peut formuler des observations.

Exigences relatives aux testeurs externes

L’article 27 de DORA définit les exigences applicables aux testeurs qui réalisent les TLPT :

• Les testeurs doivent être des entités externes à l’entité financière testée. Le recours à des testeurs internes n’est autorisé que de manière exceptionnelle et sous des conditions strictes (notamment pour les établissements de crédit d’importance systémique).
• Les testeurs doivent être techniquement compétents et disposer d’une expérience avérée en matière de tests de penetration et de red teaming.
• Les testeurs doivent être indépendants de l’entité testée et ne pas présenter de conflits d’intérêts.
• Les testeurs doivent disposer d’une assurance responsabilité civile professionnelle adéquate.
• Les testeurs doivent respecter des obligations de confidentialité strictes.
• Les prestataires de renseignement sur la menace et les testeurs red team doivent être distincts (sauf dérogation justifiée).

Les autorités compétentes peuvent établir et tenir à jour des listes de testeurs agréées, sans que cela constitue une obligation d’agrément formel.

Les tests mutualisés (pooled testing)

Principe

L’article 26, paragraphe 4, de DORA prévoit la possibilité de réaliser des TLPT mutualisés (pooled testing). Ce mécanisme permet à plusieurs entités financières de partager un même TLPT lorsqu’elles utilisent un prestataire TIC commun.

Conditions

Le pooled testing est autorisé sous reserve des conditions suivantes :

• Les entités participantes doivent obtenir l’accord de leur autorité compétente.
• Le périmètre du test mutualise doit couvrir les systèmes TIC pertinents pour chaque entité participante.
• La confidentialité des résultats propres à chaque entité doit être garantie.
• Le test mutualise doit être au moins aussi rigoureux qu’un TLPT individuel.

Avantages

Le pooled testing presente plusieurs avantages pratiques :

• Réduction des coûts : les coûts du TLPT sont partagés entre les entités participantes.
• Efficacite : un seul test couvre les systèmes d’un prestataire TIC commun, évitant la multiplication de tests redondants.
• Évaluation du prestataire : le test permet d’évaluer la résilience du prestataire TIC dans des conditions proches de la réalité.

Reporting aux autorités

Transmission des résultats

Les résultats des TLPT doivent être transmis à l’autorité de surveillance compétente. L’article 26, paragraphe 8, de DORA prévoit que l’autorité compétente délivré une attestation confirmant que le TLPT a été réalisé conformément aux exigences du règlement. Cette attestation est fondée sur la documentation fournie par l’entité, le rapport de test et le plan de remédiation.

Reconnaissance mutuelle

L’une des avancées majeures de DORA en matière de TLPT est le principe de reconnaissance mutuelle. L’attestation délivrée par une autorité compétente est reconnue par les autorités compétentes des autres États membres. Ce mécanisme évite aux entités financières opérant dans plusieurs États de devoir réaliser des TLPT distincts dans chaque pays.

Confidentialité

Les résultats des TLPT sont strictement confidentiels. Les rapports de test contiennent des informations hautement sensibles sur les vulnérabilités des systèmes de l’entité. Leur diffusion est limitée au comité de pilotage, à l’organe de direction et à l’autorité de surveillance.

Articulation avec les tests existants

Tests de sécurité sectoriels

De nombreuses entités financières réalisent déjà des tests de sécurité dans le cadre de réglementations sectorielles existantes (orientations EBA sur les TIC, exigences de sécurité DSP2, TIBER-EU…). DORA ne rend pas ces tests obsolètes mais les intègre dans un cadre unifie.

Les tests réalisés au titre de TIBER-EU avant l’entrée en application de DORA peuvent être reconnus comme TLPT au sens de DORA, sous reserve de conformité avec les exigences spécifiques du règlement.

Tests des prestataires TIC

Les entités financières doivent s’assurer que leurs prestataires TIC maintiennent également un programme de tests adéquat. Le contrat avec le prestataire TIC (article 30) doit inclure des clauses relatives aux tests de sécurité, et l’entité financière doit disposer de droits d’audit lui permettant de vérifier la réalisation effective de ces tests.

Bonnes pratiques de mise en oeuvre

Pour mettre en place un programme de tests de résilience conforme à DORA, les entités financières doivent :

Cartographier les systèmes critiques. Identifier les systèmes et applications TIC qui soutiennent les fonctions critiques ou importantes de l’entité. Cette cartographie détermine le périmètre des tests.

Définir un programme pluriannuel. Établir un calendrier de tests sur trois ans minimum, couvrant l’ensemble des types de tests requis avec des frequences adaptées au profil de risque.

Allouer un budget dédié. Les tests de résilience, en particulier les TLPT, représentent un investissement significatif. Le budget doit être prévu et approuvé par l’organe de direction.

Selectionner des testeurs qualifiés. Pour les TLPT, la sélection des testeurs externes est un enjeu critique. Privilegier des prestataires disposant d’une expérience sectorielle financière et de références verifiables.

Intégrer les résultats dans la gestion des risques. Les résultats des tests ne doivent pas rester dans un rapport. Ils doivent alimenter le registre des risques TIC, le plan de remédiation et la stratégie de résilience de l’entité.

Impliquer l’organe de direction. L’organe de direction doit approuver le programme de tests, être informe des résultats et valider les plans de remédiation. Son implication est une exigence explicite de DORA.

Conclusion

Les tests de résilience constituent l’un des apports les plus structurants de DORA. En imposant un programme de tests complet, périodique et supervise, le règlement élevé considérablement le niveau d’exigence par rapport aux pratiques antérieures. Les TLPT, réserves aux entités d’importance systémique, représentent le sommet de cette exigence avec des tests grandeur nature sur les systèmes de production.

La mise en conformité nécessite un investissement en temps, en compétences et en budget. Mais elle constitue aussi une opportunité d’améliorer concrètement la résilience opérationnelle de l’entité face à des menaces cyber en constante évolution. Consultez notre guide DORA pour une vue d’ensemble et notre article sur l’audit de sécurité informatique pour des méthodologies complémentaires.