DORA : Comment le secteur financier renforce ses capacités face aux crises ?

Enseignement des dernières publications des régulateurs

Le règlement européen DORA (Digital Operational Resilience Act), publié en janvier 2023 entre en application le 17 janvier 2025. Son objectif est de renforcer la résilience opérationnelle numérique des acteurs du secteur financier : anticiper, prévenir, répondre et récupérer des incidents numériques, tout en assurant la continuité des activités essentielles.

Afin de guider les acteurs et préciser les exigences, les Autorités de Surveillance Européennes (AES) ont élaboré un ensemble de 14 normes techniques RTS/ITS (RTS : Regulatory Technical Standards et ITS : Implementation Technical Standards) publié en deux lots. La version finale du premier lot a été publiée en janvier 2024. Le second lot, portant sur des chapitres clés de la règlementation tels que les tests, a été publié le 8 décembre 2023. Il est ouvert à la consultation publique, fait l’objet d’échanges avec les acteurs du secteur financier puis sera validé par la Commission européenne en juillet 2024.

Nous analysons ici les principaux sujets traités et les leçons à tirer de ce second lot en se focalisant sur trois enjeux majeurs :

A moins d’un an de la date de mise en application de DORA, les entités financières doivent d’ores et déjà tenir compte de ce projet de lot 2 pour affiner leurs chantiers de mise en conformité.

Des clarifications dans la version définitive du lot 1 des RTS/ITS ont permis d’apporter plus de souplesse et de proportionnalité aux exigences (notamment la possibilité de ne pas recourir obligatoirement à des solutions de chiffrement pour contribuer à garantir la DICT des données (voir dans le glossaire) – nous aborderons ces aspects de manière plus détaillée dans un prochain article dédié au lot 1). Nous pouvons également nous attendre à certaines évolutions / clarifications dans la version finale du lot 2 des RTS/ITS.

Tests d'intrusion guidés par la menace (TLPT)

Un cadre ambitieux pour challenger les capacités des SI critiques à résister aux cyber attaques.

Qui est concerné ? La plupart des entités financières
Systématiquement concernées : les contreparties centrales, les dépositaires centraux et les institutions de crédit reconnues comme d’importance systémique globale ; Les entités financières qui dépassent un certain seuil au cours des 2 années financières précédentes :

120 milliards d’euros de transactions de paiement pour les établissements de paiement ;
120 milliards d’euros de transactions de paiement ou 40 milliards d’euros de monnaie électronique en circulation pour les établissements de monnaies électroniques ;
500 millions d’euros de primes brutes pour les établissements d’assurance et de réassurance ;
La part de marché la plus grande au niveau national ou 5% au niveau européen pour les plateformes de négociations

Le régulateur va prendre en compte le profil de risque de l’entité, la complexité de l’architecture TIC et le degré de dépendance des fonctions importantes ou critiques aux systèmes TIC. Les entités citées précédemment peuvent ne pas être tenues de réaliser des TLPT si l’évaluation de certains critères indique que cela est inutile au regard de facteurs tel que la stabilité financière et les risques TIC. A l’inverse, les autorités en charge des TLP peuvent décider d’inclure des entités ne répondant pas aux critères mentionnés.

La fréquence de réalisation des tests et les acteurs concernés sont d’ores et déjà précisés :

L’article 26 impose aux entités financières, la réalisation d’un TLPT, au moins tous les 3 ans en couvrant les systèmes IT qui soutiennent des fonctions critiques ou importantes.
L’article 27 précise que les testeurs devront posséder les capacités techniques et organisationnelles et justifier de l’expertise nécessaire. Le recours à des testeurs internes devra être validé par l’autorité compétente concernée et le fournisseur de renseignements sur les menaces devra, lui, être externe à l’entité financière.

En revanche, on ignore si chaque entité financière devra tester l’ensemble de ses fonctions critiques ou importantes à chaque occurrence de test.

Comment vont se dérouler les TLPT ? Quatre phases « colorées » avec les White, Blue, Purple et Red team

Préparation – phase clé en coordination avec les régulateurs (White team)

Les autorités de régulation (ACPR, Banque de France etc.), réunies au sein de la TLPT Cyber Team (« TCT »), valident le périmètre de TLPT proposé par l’entité financière. Celle-ci va désigner les personnes qui vont piloter et diriger la bonne exécution du test. NB : la TCT devra valider le choix des prestataires choisis pour réaliser les tests d’intrusion et l’analyse de la menace. En cas de refus des prestataires choisis, le TLPT ne peut donner lieu à un satisfecit à la fin de l’exercice.

Analyse de la menace (Red Team – Threat Intelligence)

L’équipe de Threat Intelligence analyse les menaces et élabore les scénarios d’attaque et les transmettra à la Red Team. Cette phase durera de 4 à 6 semaines en fonction du périmètre validé par la White Team et la TCT.

Test d’intrusion (Red Team – Penetration testing)

Pendant au moins 12 semaines, la Red Team réalise les tests d’intrusion sur les SI en production, sans appui interne et sans avoir prévenu l’équipe de sécurité interne (Blue Team) avec pour objectif de réussir les missions fixées par l’équipe de Threat Intelligence sans se faire détecter. La détection de la Red Team n’entraine pas la fin de l’exercice. Elle doit être signalée à l’équipe de Red Team qui devra changer de scénario d’attaque. En cas d’échec, la Red Team pourra utiliser les avantages prédéfinis par l’équipe de Threat Intelligence pour s’assurer du réalisme de l’exercice et de l’entrainement de l’intégralité du spectre des équipes de l’entité financière.

Restitution : rejeu, Purple Team et satisfecit

Suite à la réalisation des tests, la Red Team livrera son rapport global à la White Team et à la TCT. Des rejeux seront obligatoires, afin de vérifier certains scénarios empêchés ou non, détectés ou non pendant la phase de test. Ils pourront prendre des formes variées : exercice de crise, Purple Team, rejeu en aveugle… La TCT délivrera l’attestation de complétion du TLPT à la fin de cette phase.

Des précisions sont attendues sur la date butoir pour réaliser le 1er TLPT, sur la composition des Purple Team, et sur la sélection de l’entité décisionnaire pour les TLPT réalisés à l’échelle d’un groupe.

Qui porte la responsabilité des tests ? Dans tous les cas, l’entité financière est pleinement responsable de l’exécution du TLPT

Le RTS pose des contraintes dans l’appel à des testeurs internes :

Définition d’une politique de management des testeurs internes ;
Etablissement de mesures permettant de s’assurer que l’utilisation de testeurs internes n’a pas d’impacts négatifs ;
Etablissement de mesures pour s’assurer que les testeurs internes ont les ressources et les compétences nécessaires pour réaliser les TLPT.

DORA s’appuie largement sur le Framework de référence TIBER

Le Framework européen TIBER (Threat intelligence-based ethical red-teaming) EU publié en 2018 par la Banque Centrale Européenne s’inscrit dans une démarche de renforcement de la résilience des entités financières face aux cyber-attaques. TIBER-EU, transposé en TIBER-FR (janvier 2024) pour prendre en compte les spécificités nationales, propose un cadre de pratiques permettant de conduire des simulations de cyber-attaques sur les fonctions critiques des entités concernées.

La durée d’un engagement TIBER-FR est de l’ordre de 6 à 9 mois (cycle triennal). Les durées mentionnées sur le schéma ci-dessous sont des moyennes et sont fournies à titre indicatif.
Les mêmes équipes sont retrouvées, seules leurs dénominations changent pour trois d’entre elles : la Control Team revêt le nom de White Team, la TPLPT Cyber Team correspond à la TIBER Cyber Team et finalement les testeurs sont appelés Red Team.
Malgré de fortes similitudes entre le RTS TLPT et TIBER-FR, on observe tout de même deux différences : dans DORA, une Purple Team doit être incluse en complément de la Red Team, et il est autorisé d’avoir recours à des auditeurs internes pour composer la Red Team.

TPRM (Third Parties Risk Management)

Une attention particulière aux risques liés aux tiers.

Dans un contexte où les entités financières interagissent de plus en plus avec des tiers, la gestion des risques liés aux tiers (ou TPRM) émerge comme un élément essentiel de la gouvernance d’entreprise. L’utilisation des TIC est devenue centrale dans la fourniture de services financiers. Or, la fourniture de services TIC dépend bien souvent d’une chaîne de sous-traitance complexe dans laquelle les fournisseurs tiers peuvent conclure un ou plusieurs accords de sous-traitance avec d’autres fournisseurs. Cette réalité engendre une situation de dépendance des entités financières à l’égard des sous-traitants TIC.

Dans ce contexte, DORA exige des entités financières de tout mettre en œuvre pour et assurer le suivi de tous les sous-traitants qui fournissent un service TIC et en particulier les tiers soutenant des fonctions critiques ou importantes. Afin de renforcer les capacités de résilience en cas de défaillance d’un tiers critique, DORA exige des entités financières de formaliser des stratégies de sortie puis de les tester. Ces dernières ont pour objectif de permettre aux entités financières d’assurer la continuité de leurs fonctions critiques en cas de rupture de la relation avec un tiers opérant sur ces fonctions.

Un alignement contractuel à anticiper le plus tôt possible #RemédiationContractuelle
Les guidelines de l’EBA sur l’externalisation avaient déjà imposé de revoir les contrats des PSEE, avec DORA ces obligations sont reprises et complétées pour tous les tiers fournissant un service TIC. L’article 30 impose d’inclure dans les contrats une description claire et complète de toutes les fonctions et de tous les services TIC à fournir par le prestataire. Par ailleurs, d’autres exigences de la réglementation pourraient être incluses dans les clausiers afin de facilité la mise en conformité (exigences sécurité, tests, contrôles et auditabilité…)

Les procédures de due diligence garantissent la capacité à sélectionner et à évaluer les compétences, tant opérationnelles que financières des tiers.

Le prestataire tiers de services TIC dispose des capacités, de l’expertise, des ressources financières, humaines et techniques adéquates, applique des normes de sécurité de l’information appropriées et dispose d’une structure organisationnelle appropriée, y compris en matière de gestion des risques et de contrôle interne, de rapports sur les incidents et de réponses, pour contrôler ses sous-traitants
L’impact de la défaillance d’un sous-traitant sur la fourniture de services TIC soutenant des fonctions critiques ou importantes doit être maîtrisé

Les sous-traitants intragroupes sont considérés comme des prestataires de services au titre de DORA et sont donc à intégrer dans le chantier de remédiation contractuelle.

Des contrôles renforcés en amont des décisions de sous-traitance d’activités critiques

Les entités financières doivent procéder à une évaluation des risques pour objectiver toutes décisions d’outsourcing. Parmi les éléments de risque spécifiés par les AES, on retrouve :

La localisation du sous-traitant TIC ou de sa société mère
Le nombre de sous-traitants TIC
La nature des données partagées avec les sous-traitants TIC
Le lieu de traitement et de stockage des données
L’impact potentiel des perturbations sur la continuité et la disponibilité des services TIC soutenant des fonctions critiques ou importantes fournis par le prestataire de services TIC tiers
L’évaluation de la difficulté de réintégrer le service externalisé au sein de l’entreprise
Le risque de concentration

L’entité financière évalue chez le sous-traitant :

Sa réputation commerciale
Ses ressources (y compris son expertise et ses ressources financières, humaines et techniques)
La sécurité de l’information
Sa structure organisationnelle (y compris la gestion des risques et les contrôles internes que le sous-traitant doit avoir mis en place)

Un cadre précis d’exigences avant d’autoriser les tiers à avoir eux-mêmes recourt à la sous-traitance

Afin d’atténuer les risques liés à la sous-traitance tout au long du cycle de vie des contrats, ces derniers doivent préciser les conditions dans lesquelles le prestataire pourrait faire appel à des sous-traitants. L’entité financière doit avoir le droit de résilier l’accord avec le prestataire tiers de services TIC dans les deux cas suivants :

Reporting & notification pour les incidents majeurs

Les entités financières doivent enregistrer tous les incidents liés aux TIC et les cybermenaces significatives. Elles assurent une surveillance, un traitement et un suivi des incidents liés aux TIC, afin de veiller à ce que les causes profondes soient identifiées, documentées et traitées de manière à éviter que de tels incidents ne se reproduisent.

Lorsqu’un incident majeur lié aux TIC se produit et a une incidence sur les intérêts financiers des clients, les entités financières informent leurs clients, sans délai injustifié dès qu’elles en ont connaissance. Les mesures prises pour atténuer les effets négatifs de cet incident sont également partagées.
Dans le cas d’une cybermenace importante, les entités financières informent leurs clients potentiellement affectés de toute mesure de protection appropriée que ces derniers pourraient envisager de prendre.
Le chapitre 3, concernant les incidents, vient d’être complété par un RTS et un ITS visant à préciser les templates (ITS), délais et modalités (RTS) de reporting des incidents TIC majeurs et de la déclaration volontaire des cybermenaces importantes.

Des délais de notification des incidents alignés sur les directive Cyber NIS 2

Ces RTS/ITS viennent en complément de l’article 19 (4) de DORA qui impose aux entités financières de soumettre trois rapports de notifications d’incidents : une notification initiale, un rapport intermédiaire et un rapport final. Les délais de déclaration des incidents majeurs sont alignés sur la directive NIS2 (Directive sur la Sécurité des Réseaux et des Systèmes d’Information) :

Des informations précises sur la nature et l’importance de l’incident à remonter au régulateur
Les entités financières sont tenues d’affiner leur reporting au gré de leur maitrise de l’incident.

Notification initiale

La date et l’heure de la détection de l’incident, sa description et sa source, les critères de classification, les États membres impactés, l’impact sur d’autres entités, la récurrence et l’activation du plan de continuité des activités.

Rapport intermédiaire

Le code de référence et le type de l’incident, la date et l’heure de l’occurrence, les détails de la récupération, les critères de classification, les zones et processus affectés, les détails de l’infrastructure, les actions de communication, la déclaration à d’autres autorités et les actions entreprises.

Rapport final

La cause principale, la conformité légale, la violation des accords contractuels, la date et l’heure de la résolution, les mesures de résolution, le reclassement, les informations pour les autorités de résolution, ainsi que les détails des coûts et des pertes.

En parallèle à cette remontée d’incident, le texte prévoit la notification des cybermenaces significatives : date et heure de détection de la menace, description de la menace, impact potentiel, critères de classification, statut de la menace, actions entreprises.

Le régulateur fournit des modèles de déclaration pour homogénéiser les notifications
Les modèles comprennent 101 points de données, avec des champs essentiels obligatoires (46) et des champs conditionnels, en fonction de la nature de l’incident.

Merci à Céline TERRIEN, Cassandre HENAULT, Constance RAGEOT, Estelle BONNET, Pierre LE PIRONNEC, Lucas FAUCHER, Antoine STOEV, Esther REISS, et Tatiana QUINTERO DEDIOGO pour leurs contributions.