Introduction

Le reglement DORA (reglement (UE) 2022/2554) fait des tests de resilience operationnelle numerique l’un de ses piliers fondamentaux. Les articles 24 a 27 imposent aux entites financieres de tester regulierement la robustesse de leurs systemes TIC face aux menaces cyber et aux incidents operationnels. Ce cadre de tests se decline en deux niveaux : les tests de resilience de base, applicables a toutes les entites, et les tests de penetration fondes sur la menace (TLPT – Threat-Led Penetration Testing), reserves aux entites d’importance systemique.

L’enjeu est considerable. Il ne s’agit plus de realiser des tests de securite ponctuels et isoles, mais d’inscrire les tests dans un programme structure et periodique, supervise par l’organe de direction et conforme a des normes techniques de reglementation (RTS) definies par les autorites europeennes de surveillance. Pour une vue d’ensemble du reglement, consultez notre guide DORA. Pour un complement sur les methodologies d’audit, consultez notre article sur l’audit de securite informatique.

Le cadre general des tests de resilience (article 24)

Obligation de programme de tests

L’article 24 de DORA impose a chaque entite financiere d’etablir, de maintenir et de reexaminer un programme de tests de resilience operationnelle numerique. Ce programme constitue un element integral du cadre de gestion des risques TIC de l’entite.

Le programme de tests doit :

• Etre proportionnel a la taille, a l’activite et au profil de risque de l’entite.
• Couvrir l’ensemble des systemes et applications TIC critiques de l’entite.
• Etre documente et approuve par l’organe de direction.
• Etre reexamine periodiquement et mis a jour en fonction de l’evolution des menaces et des changements dans l’infrastructure TIC.

Entites concernees

Toutes les entites financieres soumises a DORA doivent mettre en place un programme de tests de resilience. Toutefois, le niveau d’exigence varie selon la taille et l’importance systemique de l’entite :

• Les entites relevant du cadre simplifie (article 16) sont soumises a des exigences allegees en matiere de tests.
• Les entites ne relevant pas du cadre simplifie doivent realiser l’ensemble des tests de base prevus a l’article 25.
• Les entites d’importance systemique designees par les autorites competentes doivent en outre realiser des TLPT (article 26).

Les tests de resilience de base (article 25)

Types de tests requis

L’article 25, paragraphe 1, enumere les categories de tests que les entites financieres doivent realiser dans le cadre de leur programme de resilience :

Tests de vulnerabilite (vulnerability assessments). Il s’agit d’analyses systematiques des systemes TIC pour identifier les failles de securite connues. Les scans de vulnerabilite automatises, completes par des analyses manuelles, constituent la base de ce volet.

Tests de performance et de charge (performance testing). Ces tests evaluent la capacite des systemes TIC a fonctionner sous des conditions de charge elevee, simulant des pics d’activite ou des conditions degradees.

Tests de bout en bout (end-to-end testing). Ils verifient le fonctionnement complet d’un processus metier, de l’initiation a la conclusion, en passant par l’ensemble des composants TIC impliques.

Tests de penetration (penetration testing). Les tests de penetration vont au-dela des scans de vulnerabilite. Ils simulent des attaques reelles contre les systemes de l’entite pour evaluer leur resistance. Ces tests doivent etre realises par des testeurs qualifies, internes ou externes.

Analyses de code source (source code reviews). Lorsque cela est possible et pertinent, les entites doivent realiser des revues du code source de leurs applications critiques pour identifier les failles de securite.

Tests de compatibilite et de regression. Ces tests verifient que les mises a jour et les modifications des systemes TIC n’introduisent pas de nouvelles vulnerabilites ou de dysfonctionnements.

Tests de securite des reseaux. Ils evaluent la securite de l’architecture reseau de l’entite, y compris la segmentation, le filtrage et la detection d’intrusion.

Exercices bases sur des scenarios (scenario-based testing). Ces exercices simulent des incidents specifiques (cyberattaque, defaillance d’un prestataire, panne d’infrastructure) pour evaluer la capacite de reponse de l’entite.

Tests de basculement et de continuite (switchover testing). Ils verifient la capacite de l’entite a basculer vers ses systemes de secours en cas de defaillance des systemes principaux. Ces tests sont essentiels pour valider les plans de continuite d’activite (BCP) et les plans de reprise d’activite (DRP).

Frequence des tests

DORA n’impose pas une frequence unique pour tous les tests. La frequence doit etre definie dans le programme de tests en fonction du profil de risque de l’entite et de la criticite des systemes concernes.

Les normes techniques de reglementation (RTS) adoptees par les AES precisent les attentes en matiere de frequence :

Type de test	Frequence recommandee
Scans de vulnerabilite	Au moins trimestriels pour les systemes critiques
Tests de penetration	Au moins annuels
Tests de continuite/basculement	Au moins annuels
Exercices bases sur des scenarios	Au moins annuels
Revues de code source	A chaque mise en production majeure
Tests de performance	Au moins annuels ou a chaque changement significatif

Ces frequences constituent des minimums. Les entites a haut profil de risque doivent adapter la frequence a la hausse en fonction de l’evolution des menaces.

Documentation et reporting

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

• La methodologie utilisee.
• Les resultats detailles (vulnerabilites identifiees, scenarios testes, performances mesurees).
• Les recommandations d’amelioration.
• Le plan de remediation avec des echeances.

L’organe de direction doit etre informe des resultats des tests et des plans de remediation. Les autorites de surveillance peuvent demander communication de ces rapports dans le cadre de leurs activites de supervision.

Les tests de penetration fondes sur la menace – TLPT (article 26)

Definition et principes

Les TLPT constituent le niveau le plus avance de tests de resilience prevu par DORA. Ils consistent a simuler des attaques reelles contre les systemes TIC de l’entite, en s’appuyant sur des renseignements sur la menace (threat intelligence) specifiques au secteur financier et a l’entite concernee.

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

• Ils sont fondes sur une analyse prealable de la menace : un prestataire de renseignement sur la menace identifie les scenarios d’attaque les plus realistes et les plus pertinents pour l’entite.
• Ils ciblent les systemes de production (live production systems) de l’entite, et non des environnements de test isoles.
• Ils couvrent l’ensemble de la surface d’attaque de l’entite, y compris les personnes (ingenierie sociale), les processus et les technologies.
• Ils sont realises par des testeurs externes qualifies repondant a des criteres stricts.
• Ils font l’objet d’un cadre de gouvernance specifique, avec l’implication de l’autorite de surveillance.

Le cadre des TLPT de DORA s’inspire directement du cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) developpe par la Banque centrale europeenne. Les entites qui ont deja realise des tests TIBER-EU disposent donc d’un avantage dans la mise en conformite.

Qui doit realiser des TLPT ?

Les TLPT ne sont obligatoires que pour les entites financieres designees par les autorites competentes comme devant les realiser. Les criteres de designation prennent en compte :

• L’importance systemique de l’entite.
• Le profil de risque TIC global de l’entite.
• La criticite des services fournis par l’entite pour le secteur financier.
• La maturite du cadre de gestion des risques TIC de l’entite.

En pratique, sont principalement concernees :

• Les etablissements de credit d’importance systemique (G-SIB, O-SII), qui doivent par ailleurs se conformer aux exigences de securite des donnees du RGPD.
• Les grandes infrastructures de marche (CCP, CSD).
• Les grandes entreprises d’assurance.
• Les grandes societes de gestion.
• Les plates-formes de negociation d’importance significative.

Les entites qui relevent du cadre simplifie (article 16) ne sont jamais tenues de realiser des TLPT.

Frequence des TLPT

L’article 26, paragraphe 1, de DORA prevoit que les TLPT doivent etre realises au moins tous les trois ans. L’autorite competente peut toutefois exiger une frequence plus elevee en fonction du profil de risque de l’entite.

Ce cycle triennal est coherent avec la pratique etablie par TIBER-EU et s’inscrit dans la logique d’evaluation continue promue par la directive NIS2. Entre deux TLPT complets, l’entite doit maintenir son programme de tests de base (article 25) et surveiller l’evolution des menaces.

Deroulement d’un TLPT

Un TLPT se deroule en plusieurs phases clairement definies :

Phase 1 : Preparation et cadrage. L’entite, en coordination avec l’autorite de surveillance, definit le perimetre du TLPT, les objectifs et les contraintes. Un comite de pilotage restreint est constitue (le “white team”), compose de personnes habilitees a connaitre 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 specifiques a l’entite. Il identifie les scenarios d’attaque les plus realistes, les techniques, tactiques et procedures (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 scenario de test.

Phase 3 : Execution du test (red teaming). Une equipe de testeurs externes (le “red team”) execute les scenarios d’attaque identifies lors de la phase de renseignement. Les testeurs tentent de compromettre les systemes de production de l’entite en utilisant les memes techniques que des attaquants reels. Le test se deroule sur une periode de plusieurs semaines a plusieurs mois.

Phase 4 : Cloture et remediation. A l’issue du test, les resultats sont presentes a l’organe de direction et a l’autorite de surveillance. Un plan de remediation est elabore, avec des echeances precises pour corriger les vulnerabilites identifiees. L’autorite de surveillance examine les resultats et peut formuler des observations.

Exigences relatives aux testeurs externes

L’article 27 de DORA definit les exigences applicables aux testeurs qui realisent les TLPT :

• Les testeurs doivent etre des entites externes a l’entite financiere testee. Le recours a des testeurs internes n’est autorise que de maniere exceptionnelle et sous des conditions strictes (notamment pour les etablissements de credit d’importance systemique).
• Les testeurs doivent etre techniquement competents et disposer d’une experience averee en matiere de tests de penetration et de red teaming.
• Les testeurs doivent etre independants de l’entite testee et ne pas presenter de conflits d’interets.
• Les testeurs doivent disposer d’une assurance responsabilite civile professionnelle adequate.
• Les testeurs doivent respecter des obligations de confidentialite strictes.
• Les prestataires de renseignement sur la menace et les testeurs red team doivent etre distincts (sauf derogation justifiee).

Les autorites competentes peuvent etablir et tenir a jour des listes de testeurs agreees, sans que cela constitue une obligation d’agrément formel.

Les tests mutualises (pooled testing)

Principe

L’article 26, paragraphe 4, de DORA prevoit la possibilite de realiser des TLPT mutualises (pooled testing). Ce mecanisme permet a plusieurs entites financieres de partager un meme TLPT lorsqu’elles utilisent un prestataire TIC commun.

Conditions

Le pooled testing est autorise sous reserve des conditions suivantes :

• Les entites participantes doivent obtenir l’accord de leur autorite competente.
• Le perimetre du test mutualise doit couvrir les systemes TIC pertinents pour chaque entite participante.
• La confidentialite des resultats propres a chaque entite doit etre garantie.
• Le test mutualise doit etre au moins aussi rigoureux qu’un TLPT individuel.

Avantages

Le pooled testing presente plusieurs avantages pratiques :

• Reduction des couts : les couts du TLPT sont partages entre les entites participantes.
• Efficacite : un seul test couvre les systemes d’un prestataire TIC commun, evitant la multiplication de tests redondants.
• Evaluation du prestataire : le test permet d’evaluer la resilience du prestataire TIC dans des conditions proches de la realite.

Reporting aux autorites

Transmission des resultats

Les resultats des TLPT doivent etre transmis a l’autorite de surveillance competente. L’article 26, paragraphe 8, de DORA prevoit que l’autorite competente delivre une attestation confirmant que le TLPT a ete realise conformement aux exigences du reglement. Cette attestation est fondee sur la documentation fournie par l’entite, le rapport de test et le plan de remediation.

Reconnaissance mutuelle

L’une des avancees majeures de DORA en matiere de TLPT est le principe de reconnaissance mutuelle. L’attestation delivree par une autorite competente est reconnue par les autorites competentes des autres Etats membres. Ce mecanisme evite aux entites financieres operant dans plusieurs Etats de devoir realiser des TLPT distincts dans chaque pays.

Confidentialite

Les resultats des TLPT sont strictement confidentiels. Les rapports de test contiennent des informations hautement sensibles sur les vulnerabilites des systemes de l’entite. Leur diffusion est limitee au comite de pilotage, a l’organe de direction et a l’autorite de surveillance.

Articulation avec les tests existants

Tests de securite sectoriels

De nombreuses entites financieres realisent deja des tests de securite dans le cadre de reglementations sectorielles existantes (orientations EBA sur les TIC, exigences de securite DSP2, TIBER-EU…). DORA ne rend pas ces tests obsoletes mais les integre dans un cadre unifie.

Les tests realises au titre de TIBER-EU avant l’entree en application de DORA peuvent etre reconnus comme TLPT au sens de DORA, sous reserve de conformite avec les exigences specifiques du reglement.

Tests des prestataires TIC

Les entites financieres doivent s’assurer que leurs prestataires TIC maintiennent egalement un programme de tests adequat. Le contrat avec le prestataire TIC (article 30) doit inclure des clauses relatives aux tests de securite, et l’entite financiere doit disposer de droits d’audit lui permettant de verifier la realisation effective de ces tests.

Bonnes pratiques de mise en oeuvre

Pour mettre en place un programme de tests de resilience conforme a DORA, les entites financieres doivent :

Cartographier les systemes critiques. Identifier les systemes et applications TIC qui soutiennent les fonctions critiques ou importantes de l’entite. Cette cartographie determine le perimetre des tests.

Definir un programme pluriannuel. Etablir un calendrier de tests sur trois ans minimum, couvrant l’ensemble des types de tests requis avec des frequences adaptees au profil de risque.

Allouer un budget dedie. Les tests de resilience, en particulier les TLPT, representent un investissement significatif. Le budget doit etre prevu et approuve par l’organe de direction.

Selectionner des testeurs qualifies. Pour les TLPT, la selection des testeurs externes est un enjeu critique. Privilegier des prestataires disposant d’une experience sectorielle financiere et de references verifiables.

Integrer les resultats dans la gestion des risques. Les resultats des tests ne doivent pas rester dans un rapport. Ils doivent alimenter le registre des risques TIC, le plan de remediation et la strategie de resilience de l’entite.

Impliquer l’organe de direction. L’organe de direction doit approuver le programme de tests, etre informe des resultats et valider les plans de remediation. Son implication est une exigence explicite de DORA.

Conclusion

Les tests de resilience constituent l’un des apports les plus structurants de DORA. En imposant un programme de tests complet, periodique et supervise, le reglement eleve considerablement le niveau d’exigence par rapport aux pratiques anterieures. Les TLPT, reserves aux entites d’importance systemique, representent le sommet de cette exigence avec des tests grandeur nature sur les systemes de production.

La mise en conformite necessite un investissement en temps, en competences et en budget. Mais elle constitue aussi une opportunite d’ameliorer concretement la resilience operationnelle de l’entite face a des menaces cyber en constante evolution. Consultez notre guide DORA pour une vue d’ensemble et notre article sur l’audit de securite informatique pour des methodologies complementaires.