#4 Le règlement DORA : les tests de résilience opérationnelle numérique

Le 14 décembre 2022 le Règlement n° 2022/2554 du Parlement européen et du Conseil sur la résilience opérationnelle numérique du secteur financier encore nommé Digital Operational Resilience Act – DORA) a été adopté.

Dans la mesure où il s’agit d’un règlement il entre en application sans transposition et très prochainement, le 17 janvier 2025.

Dans ce cadre, nous avons souhaité, par le biais de plusieurs articles, présenter dans le détail ce nouveau texte, afin de permettre une mise en conformité. L’article ci-dessous concerne les tests de résilience opérationnelle numérique imposés par le règlement DORA. Nous exposerons, après avoir rappelé la définition de la résilience opérationnelle numérique, d’une part les conditions relatives aux tests à réaliser et d’autre part les conditions liées aux acteurs chargés des tests en question.   

I- Les tests pour la résilience opérationnelle numérique

La résilience opérationnelle numérique est la capacité d’une entité financière à développer, garantir et réévaluer son intégrité et sa fiabilité opérationnelles en assurant directement ou indirectement par le recours aux services fournis par des prestataires tiers de services TIC, l’intégralité des capacités liées aux TIC nécessaires pour garantir la sécurité des réseaux et des systèmes d’information qu’elle utilise, et qui sous-tendent la fourniture continue de services financiers et leur qualité, y compris en cas de perturbations.

Les conditions relatives aux tests

Afin d’évaluer l’état de préparation en vue du traitement d’incidents liés aux TIC, de recenser les faiblesses, les défaillances et les lacunes en matière de résilience opérationnelle numérique et de mettre rapidement en œuvre des mesures correctives, les entités financières, autres que les microentreprises, établissent, maintiennent et réexaminent, un programme solide et complet de tests de résilience opérationnelle numérique.

Ces tests doivent être structurés autour de méthodologies et d’outils spécifiques. Dans ce cadre, le règlement Dora liste les tests appropriés qui peuvent être utilisés pour vérifier la résilience opérationnelle, tels que :

  • évaluations et analyses de vulnérabilité que l’on peut définir de la façon suivante : processus visant à identifier, classer et hiérarchiser les faiblesses des systèmes, applications, ou infrastructures, souvent à l'aide d'outils automatisés, pour déterminer les risques potentiels et proposer des mesures correctives ;
  • analyses de sources ouvertes : exploration et collecte d'informations disponibles publiquement sur des systèmes, organisations ou individus afin d’identifier des menaces potentielles ou des informations sensibles accessibles à des tiers malveillants ;
  • évaluations de la sécurité des réseaux : analyse approfondie des configurations, des flux de données, des équipements et des protocoles de communication au sein d’un réseau pour évaluer sa résistance face aux intrusions, attaques ou dysfonctionnements ;
  • analyses d’écarts : étude comparative visant à identifier les divergences entre un état actuel (par exemple, une politique de sécurité ou un niveau de conformité) et un état cible ou des normes reconnues, afin de combler ces écarts ;
  • examens de la sécurité physique : inspection des dispositifs, processus et mesures de protection physique, comme les contrôles d’accès, la surveillance ou les alarmes, pour évaluer leur efficacité à prévenir les intrusions, vols ou sabotages ;questionnaires : outils d'évaluation sous forme de questions standardisées ou personnalisées, utilisés pour recueillir des informations auprès d’experts, de collaborateurs ou de tiers, afin d’évaluer la sécurité ou la conformité ;
  • solutions logicielles de balayage : programmes ou outils automatisés permettant d’examiner les systèmes ou réseaux pour détecter des vulnérabilités, des logiciels obsolètes, des configurations incorrectes ou des fichiers malveillants ;
  • examens du code source lorsque cela est possible : analyse manuelle ou automatisée du code source d’une application pour identifier des erreurs de programmation, des failles de sécurité ou des pratiques de codage non conformes ;
  • tests fondés sur des scénarios : simulations de situations spécifiques basées sur des scénarios réalistes ou probables, afin d’évaluer la réponse d’un système ou d’une organisation à une menace ou un incident ;
  • tests de compatibilité : vérification de l’interopérabilité entre différentes technologies, systèmes ou versions logicielles pour s’assurer qu’ils fonctionnent correctement ensemble sans conflit ;
  • tests de performance : évaluation des capacités d’un système ou d’une application à supporter des charges importantes, des volumes de transactions élevés ou des conditions de fonctionnement extrêmes tout en maintenant des niveaux de performance acceptables ;
  • tests de bout en bout : validation de l’ensemble du flux opérationnel d’un système ou d’un processus, de l’entrée initiale jusqu’au résultat final, pour s’assurer que tous les composants fonctionnent correctement ensemble ;
  • tests de pénétration : simulation d’attaques malveillantes sur des systèmes, réseaux ou applications par des experts en sécurité pour identifier et exploiter les failles, et proposer des améliorations pour limiter les risques.

II- Les tests de pénétration fondés sur la menace

A) Définition

Un cadre simulant des tactiques, techniques, procédures d’acteurs de la menace réelle et perçus comme représentant une véritable cybermenace permettant de tester de manière contrôlée sur mesure doivent être réalisés. Ces tes sont réalisés en fonction des renseignements communiqués sur les systèmes critiques en environnement de production de l’entité financière[2].

Ces tests sont appelés des tests de pénétration fondés sur la menace.

Ces tests ne sont pas de simples pentests, il s’agit de tests plus avancés, l’accent étant mis sur des scénarios plausibles et la prise en compte de réelles menaces.

B) La fréquence des tests de pénétration fondés sur la menace

Ces tests de pénétration fondés sur la menace doivent être réalisés au moins une fois tous les trois ans[1], mais peuvent être plus ou moins fréquents en fonction du profil de risque de l’entité financière et compte tenu des circonstances opérationnelles.

La détermination de cette fréquence en deçà ou au-delà du principe d’une fois tous les trois ans, est décidée par l’autorité compétente[3].

En outre, certaines entités financières peuvent être contraintes de réaliser un test de pénétration par les autorités compétentes tenant compte du principe de proportionnalité. Plusieurs facteurs sont pris en compte dans ce cadre[4] : l’incidence sur le secteur financier ; les problèmes de stabilité financière ; le profil de risque lié aux TIC spécifique ; les niveaux de maturité des TIC de l’entité financière ou les caractéristiques technologiques concernées.

C) Le périmètre des tests de pénétration fondés sur la menace

Ces tests doivent couvrir, en principe, la totalité des fonctions critiques ou importantes d’une entité financière, mais peuvent par exception couvrir seulement certaines fonctions.

Dans ce cadre, ce sont les entités financières, validés par les autorités compétentes, qui déterminent les fonctions qui doivent être couvertes par les tests de pénétration.

D) Les suites du test de pénétration fondé sur la menace : rapport, synthèse et attestation

À la suite du test un rapport et un plan de mesures correctives doivent être réalisés et approuvés.

Une synthèse des conclusions pertinentes doit être fournie par les entités financières, et s’il y a lieu les testeurs externes.

Une attestation est remise par les autorités compétentes aux entités financières qui confirme que les tests ont été effectués conformément aux exigences afin de permettre la reconnaissance mutuelle des tests de pénétration fondés sur la menace entre autorité compétente.

Il est important de noter que cette attestation ne dégage pas de sa responsabilité de sécurité l’entité financière[5]. L’autorité compétente ne valide donc pas la réalité des mesures, mais permet simplement de confirmer qu’un test a été réalisé sur la forme. Sur le fond, l’entité financière doit maintenir sa conformité.

II- Les conditions applicables aux testeurs

A) Les exigences générales applicables aux testeurs

Le Règlement DORA pose plusieurs exigences applicables aux testeurs. Ceux-ci doivent :

  • posséder l’aptitude et la réputation la plus élevée ;
  • posséder les capacités techniques et organisationnelles ;
  • être certifiés par un organisme d’accréditation dans un Etat membre ou adhérent à des codes de conduites ou des cadres éthiques formels ;
  • fournir une assurance indépendante ou un rapport d’audit ayant trait à la bonne gestion des risques associés à la réalisation de tests de pénétration fondés sur la menace ;
  • être entièrement couverts par les assurances de responsabilité civile professionnelle pertinente y compris contre les risques de mauvaise conduite et de négligence.

Ils doivent également justifier d’une expertise spécifique en matière de renseignement sur les menaces, de tests de pénétration et de tests red team[6].  L’ensemble de ces éléments devront donc être vérifiés en amont, par la DSI ou la direction juridique de l’entité concernée.

B) Les exigences spécifiques aux testeurs internes

Les testeurs internes doivent être approuvés par l’autorité compétente et dans ce cadre elle doit vérifier que les testeurs internes disposent des ressources suffisantes et veille à éviter les conflits d’intérêts pendant la phase de conception et d’exécution. Par ailleurs, le fournisseur de renseignement sur les menaces doit, pour sa part, être nécessairement externe à l’entité financière. L’objectif de cette obligation étant à la fois d’éviter la partialité et la subjectivité d’un fournisseur d’information qui serait sous l’influence de la culture de l’entité financière. L’évaluation de ce fournisseur doit rester réaliste et non biaisée pour que les tests soient performants. Ceci est également un avantage étant donné la quantité plus large de donnée dont doit disposer un fournisseur externe.

C) Le cas spécifique des testeurs externes

L’entité financière peut également bénéficier des services des testeurs externes.

Dans ce cadre, s’il est raisonnablement possible de s’attendre à ce que la participation d’un prestataire tiers de service TIC ait une incidence négative :

  • sur la qualité du service ou sur la sécurité du service que le prestataire tiers de services TIC fournit à des clients qui ne sont pas des entités financières ; ou
  • sur la confidentialité des données liée à ces services,

L’entité financière et le prestataire tiers peuvent convenir par écrit que le prestataire tiers de services TIC signe directement des accords contractuels avec un testeur externe, afin de réaliser les tests de pénétration.

De plus, si les entités financières engagent des testeurs internes en principe, elles doivent par exception, une fois tous les trois tests engager des testeurs externes[7]. De multiples précautions sont ainsi prises…

De plus, les établissements de crédit importants, doivent avoir uniquement recours à des testeurs externes.

Dans ce cadre le contrat conclu avec le testeur externe doit contenir, outre les conditions prévues au chapitre V du règlement DORA, les conditions relatives :

  • à la gestion des résultats des tests de pénétration fondés sur la menace ;
  • à la gestion des données (génération, stockage, agrégation, élaboration, projet, rapport, communication, destruction).

III- Nos recommandations

Ainsi en synthèse la mise en place du règlement DORA implique concernant les tests de :

  • déterminer les tests de résilience opérationnelle numérique qu’il faut réaliser notamment leur type, leur périmètre, leur fréquence ; ces éléments doivent prendre en compte le principe de proportionnalité ; 
  • choisir le testeur interne ou externe qui réalise ces tests tenant compte des exigences générales et :  
  • si les testeurs sont internes : faire approuver les testeurs par l’autorité compétente et s’assurer notamment qu’il n’existe pas de conflit d’intérêt pour que les tests soient les plus performants possible ;
  • si les testeurs sont externes : s’assurer de leur indépendance et garantir que le contrat sécurise les résultats et les données.

Dans le cadre du cycle Guide pour la mise en application du règlement DORA expliquant le cadre légal de cette nouvelle réglementation qui entre en application le 17 janvier 2025, nous abordons les six thèmes suivants :

  • #1 Dispositions générales : qu’est-ce que le règlement DORA ? De quoi est-ce qu’il est question ? À qui s’applique-t-il ? Quel est le risque en cas de non-conformité ?
  • #2 Les exigences que DORA impose en matière de gestion du risque lié aux TIC
  • #3 Les règles de gestion, de classification et de notification des incidents liés aux TIC
  • #4 Les tests de résilience opérationnelle numérique
  • #5 La gestion des risques liés aux prestataires tiers de services TIC
  • #6 Le partage d’information et les autorités compétentes

Le département Contrats informatiques, données & conformité peut vous accompagner dans la gestion et la mise en place contractuelle ainsi que dans la constitution du cadre de sécurité indispensable au respect de la conformité DORA.

Pour toute question, n’hésitez pas à nous contacter.


[1] DORA, art. 3 17).

[2] DORA, art. 26 1).

[3] DORA, art. 26 1).

[4] DORA, art. 26 8 al. 3).

[5] DORA, art. 26 7) al. 2.

[6] Le red team sont des tests spécifiques permettant de simuler des attaques réalistes contre une organisation. Le concept de red team prouvent des exercices militaires, ou une équipe jouait le rôle de l’ennemi pour tester la stratégie de défense. En cybersécurité cette approche est transposée pour simuler le rôle d’un attaquant malveillant. À ce sujet le site de la Banque centrale européenne est très instructif.

[7] DORA, art. 26 8).