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 :

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 TLPT 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.

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 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é.

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 :

1. Lorsque le prestataire tiers de services TIC met en œuvre des changements importants dans les accords de sous-traitance malgré l’objection de l’entité financière, ou sans approbation dans la période de préavis.
2. Lorsque le prestataire tiers de services TIC sous-traite un service TIC soutenant une fonction critique ou importante dont la sous-traitance n’est pas explicitement autorisée par l’accord contractuel.

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 directives 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.

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.