Septembre 2020, le projet de Règlement sur la résilience opérationnelle numérique (ci-après « DORA ») est publié par la Commission européenne. Au fur et à mesure des lectures et des échanges avec la place, les contours d’un texte ambitieux et structurant se dessinent peu à peu. On y découvre un savant mélange entre l’héritage des réglementations passées et l’anticipation des défis futurs.
Avec DORA, l’Union européenne (UE) amorce un virage stratégique fondamental :
– elle légifère sous la forme puissante d’un Règlement d’application directe dans chacun des États membres ;
– elle construit le socle sur lequel faire reposer toute stratégie de défense informatique en entreprise, dans toutes ses dimensions, de l’identification et la maîtrise du parc jusqu’à la capacité de reconstruire dans des délais courts les briques du système d’information les plus stratégiques.
Dans un paysage réglementaire en perpétuel mouvement, on y perçoit la promesse de recentrer les priorités autour de principes forts : ancrage des enjeux de résilience informatique dans les Comités de direction, prise de conscience de la dépendance des modèles aux fournisseurs informatiques, renforcement de l’articulation entre sécurité et continuité de l’activité. Ce faisant, DORA consacre le besoin urgent de tracer une ligne continue entre :
– les métiers de la finance et la fonction informatique au sens large, en fixant un objectif commun à cette longue chaîne composée d’hommes et de femmes, de process, d’applications, de réseaux, de composants, etc. ;
– les fonctions informatiques elles-mêmes, de la gestion de projet à la continuité d’activité IT, en passant par la cybersécurité, objet central de cet article, en se concentrant tout autant sur le volet préventif que sur les actions à mener pour rétablir un service perturbé, voire totalement mis à l’arrêt ;
– les systèmes d’information purement internes et leurs extensions, hébergées, gérées et opérées par des prestataires informatiques qui détiennent une partie de la solution ;
– les institutions financières et leurs clients enfin, en imposant de communiquer de manière plus systématique sur ce qui menace la continuité des services auxquels ils souscrivent.
L’ambition de cet article est de revenir sur les questions fondamentales, les défis majeurs, les zones d’incertitude que la découverte, puis l’analyse et les premières étapes de la mise en œuvre de DORA ont fait naître ou resurgir. Cet article n’est pas un guide de mise en conformité. Les chemins pour y parvenir dépendent du profil spécifique de chaque entité financière et dans certains cas, de l’interprétation du texte.
Intuitivement, lorsque l’on évoque le principe de résilience, il est naturellement fait référence, en psychologie, à la capacité à surmonter les chocs traumatiques1. La résilience commence donc après le choc, après la perturbation ou l’incident. DORA donne une vision beaucoup plus large de la résilience opérationnelle numérique :
« 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 perturbations2. »
Définir la cybersécurité au sens de DORA invite au voyage dans les méandres des règlements et directives UE. Le paragraphe 4 de l’article 3 de DORA renvoie à la Directive NIS23 pour définir la sécurité des réseaux et des systèmes d’information :
« Capacité des réseaux et des systèmes d’information de résister, à un niveau de confiance donné, à tout événement susceptible de compromettre la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données stockées, transmises ou faisant l’objet d’un traitement, ou des services que ces réseaux et systèmes d’information offrent ou rendent accessibles4. »
Autrement dit, sécuriser, c’est résister.
La résilience informatique, au sens de DORA, est donc la capacité à maintenir sécurisés et opérationnels les systèmes utiles à la fourniture des services financiers. Pour atteindre les objectifs fixés par la réglementation, les défis sont donc multiples : construire et opérer une informatique fiable et intègre, la sécuriser pour la préserver des perturbations et s’assurer, même en cas de perturbations, que les fonctions opérationnelles puissent se poursuivre dans les meilleures conditions. Partant de là, le raccourci consistant à résumer la résilience opérationnelle autour du triptyque « opérations informatiques-cybersécurité-continuité d’activité » est séduisant.
En poursuivant nos pérégrinations au cœur des textes, il est utile de prendre quelques instants pour définir les cibles visées par les objectifs de sécurité évoqués plus haut. En d’autres termes, que cherche-t-on à sécuriser ? Une nouvelle fois, DORA renvoie vers sa lex generalis, NIS2, pour qui les termes « réseau » et « système d’information » recouvrent les trois notions suivantes :
– le réseau de communications électroniques au sens de l’article 2, point 1), de la directive (UE) 2018/19725 ;
– tout dispositif ou tout ensemble de dispositifs interconnectés ou apparentés, dont un ou plusieurs éléments assurent, en exécution d’un programme, un traitement automatisé de données numériques ; ou
– les données numériques stockées, traitées, récupérées ou transmises par les éléments visés aux deux points précédents en vue de leur fonctionnement, utilisation, protection et maintenance.
Sont donc visés la couche réseau (switch, routeurs, firewalls...), la couche applicative (logiciels) et le matériel physique (serveurs, points de terminaison, postes de travail...), tout comme les données stockées, traitées ou transmises via ces dispositifs.
Le champ des actifs informationnels et des actifs TIC6 définis plus loin confirme cette interprétation et complète le panorama en y incluant « l’ensemble des informations matérielles et immatérielles » et les « logiciels ou matériel dans les réseaux et les systèmes d’information utilisés par l’entité financière ».
L’un des enjeux de la mise en œuvre de DORA porte sur la gouvernance. La résilience version DORA consacre le principe d’une vision intégrée de l’ensemble des chaînes métiers et des actifs informatiques qui les soutiennent. Les impacts dévastateurs d’une perturbation ou l’interruption d’une chaîne critique doivent être connus, analysés, anticipés. Les mesures visant à s’en prémunir ou à en limiter les effets doivent être déployées, notamment lorsque les chaînes concernées sont considérées critiques ou importantes. Pour s’imposer à tous, ces actions doivent être impulsées par l’Organe de direction, qui porte « la responsabilité ultime de la gestion du risque lié aux TIC de l’entité financière »7.
En matière de cybersécurité, l’Organe de direction « met en place des stratégies visant à garantir le maintien de normes élevées en matière de disponibilité, d’authenticité, d’intégrité et de confidentialité des données ». Il assure notamment, par ce biais, que les moyens nécessaires et suffisants seront consacrés aux activités de sécurité informatique pour garantir la résilience des fonctions métiers.
L’Organe de direction est régulièrement alimenté d’indicateurs de performance et de risque, véritable boussole d’un pilotage éclairé. Les incidents majeurs de sécurité sont notifiés à la Direction générale alors que les actions lancées pour améliorer le cadre de sécurité à la suite de ces incidents sont communiquées à l’Organe de direction8. De même, le cadre de gestion des risques fait l’objet d’un rapport annuel, transmis sur demande à l’Autorité nationale compétente (ANC) et approuvé par l’Organe de direction. Il contient notamment les mesures de remédiation mises en œuvre et à envisager à la suite de l’analyse des enseignements tirés des tests de pénétration fondés sur la menace (TLPT), de l’analyse des cybermenaces en continu9.
La stratégie cyber contribue, au même titre que la gestion du risque de tiers, la sécurité physique ou la continuité d’activité, à la stratégie de résilience opérationnelle. Les trois composantes interagissent au sein d’un dispositif qui nécessite également une excellente connaissance de ses actifs informatiques, des ressources du réseau et des équipements matériels, de ses interconnexions, internes et externes et de la sensibilité des données hébergées. Construire, maintenir et faire évoluer les référentiels informatiques soutient l’ensemble du dispositif dans une discussion permanente entre le métier et la DSI.
Dans ce contexte multidisciplinaire, déterminer qui portera la responsabilité de la conduite de la résilience opérationnelle numérique au quotidien est un enjeu important. DORA n’impose aucun modèle. La capacité de rendre indépendantes les fonctions opérationnelles des fonctions de supervision et d’audit interne fait l’objet d’un rappel vertueux au sacro-saint principe de la séparation des lignes de défense mais au-delà, chaque entreprise conserve la flexibilité d’opter pour des modèles de gouvernance centralisés autour d’une fonction coordinatrice ou de décentraliser le dispositif en s’assurant de sa cohérence.
Après avoir identifié les sources de risque liées aux TIC, les entités financières évaluent les cybermenaces et les vulnérabilités qui pèsent sur les TIC et élaborent des scénarios d’attaque cyber. Avec EBIOS Risk Manager10, l’Agence nationale de sécurité des systèmes d’information (ANSSI) propose un dispositif compatible. Ici, les sources de risque cyber susceptibles d’atteindre les fonctions métier sont confrontées aux scénarios stratégiques identifiés par l’analyse de la menace cyber et aux modes opératoires des attaquants. La combinatoire des risques métiers et des scénarios d’attaque conduit à définir des mesures de remédiation du risque cyber.
DORA n’introduit pas de nouveauté sur le volet de l’analyse de risque. En revanche, leur conduite est au fondement même de l’application des mesures de sécurité au périmètre adéquat.
DORA propose aux entreprises d’appliquer les règles en fonction du principe de proportionnalité, c’est-à-dire en prenant en compte leur taille et leur complexité. L’existence d’un régime simplifié du cadre de gestion de risque (Chapitre II) proposé aux micro-entreprises, en est l’illustration.
Malgré tout, le doute quant au bon niveau de mise en œuvre des mesures du texte subsiste, comme pour chaque exercice de mise en conformité. Entre crainte de sous-estimer l’attente du régulateur et nécessité de la faire converger au mieux avec les dispositifs existants et les trajectoires définies en amont, demeure tout le travail de cadrage et d’interprétation. L’approche par les risques est le fil rouge de cette réflexion et renvoie systématiquement à la question de la bonne compréhension du risque à couvrir et des moyens suffisants et proportionnés à déployer pour y parvenir.
Si le principe est global, le règlement délégué sur le cadre de gestion du risque11, texte fondamental dans l’étude des exigences de cybersécurité, apporte des précisions utiles sur la prise en compte, pour une série d’exigences liées au contrôle d’accès, à la confidentialité des données, aux tests de sécurité, à la gestion des vulnérabilités ou encore à la sécurité des réseaux d’une approche par les risques.
Cette gestion par les risques peut consister à s’appuyer sur les résultats de son évaluation du risque des actifs visés, comprenant notamment des éléments liés à la classification de la donnée, à l’exposition sur internet ou encore à la criticité de la vulnérabilité. À titre d’exemple, l’article 6.2 du règlement délégué sur la gestion du risque informatique précise que les mesures liées au chiffrement des données doivent être déployées en fonction du résultat de la classification approuvée des données12.
Enfin, l’appartenance de l’actif à une chaîne métier considérée critique ou importante13 est une clé de lecture importante. Cette caractéristique peut déclencher la mise en œuvre de la version la plus exigeante d’une mesure de sécurité. Ainsi, les fréquences de revue des règles firewalls, des droits d’accès ou encore de scans de vulnérabilités sont accélérées pour les actifs soutenant des fonctions critiques.
En décembre 201814, le Comité de Bâle publie une série de recommandations sur la cyber-résilience15. La Commission européenne n’a pas tardé à emboîter le pas de ce dernier, du Financial Stability Board (FSB) ou encore de la Financial Conduct Authority (voir l’article de François Coupez et Emmanuel Jouffin, « DORA et ses amis »), en proposant dès septembre 2020 un projet de règlement sur la résilience opérationnelle informatique du secteur financier16. Par ce biais, DORA parachève la redéfinition du centre de gravité des objectifs de la cybersécurité autour de l’enjeu de la préservation et de la sauvegarde des métiers critiques, dans la logique des travaux de l’Autorité bancaire européenne (ABE) sur la gestion du risque et de la sécurité17.
Nul besoin d’explorer le texte dans tous ses méandres pour identifier des liens de parentés forts entre les derniers textes réglementaires de référence en matière de cybersécurité et DORA. Les European Supervisory Authorities (ESA18), par l’intermédiaire du mandat que leur confère l’article 15 de DORA, citent pêle-mêle :
« Les orientations relatives aux TIC et à la gestion des risques de sécurité de l’EBA, la Directive 2022/2255 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’ensemble de l’Union (NIS2), le cadre de gestion de la cybersécurité édité par le National Institute of Standards and Technology (NIST)19 » ou encore la famille des normes ISO 27 000.
L’influence du NIST20 est particulièrement visible dans la structure du Chapitre II de DORA qui suit les six fonctions du NIST cybersecurity framework : gouverner (article 5), identifier (article 8), protéger (article 9) détecter (article 10), répondre et rétablir (articles 11 et 12). Cet héritage confirme le caractère international de DORA dont les influences se nourrissent aussi aux sources du droit souple américain.
Les exigences de cybersécurité sont réparties dans l’ensemble du règlement et des textes de second niveau. Leur identification nécessite donc de se plonger dans la lecture exhaustive du texte et de ses actes délégués.
Les articles portant sur la protection, la détection mais aussi les besoins de formation/sensibilisation et la prise en compte des évolutions technologiques sont concentrés dans le chapitre II de DORA (articles 9, 10 et 13). La gestion, la classification et les notifications des incidents de sécurité et des cybermenaces sont abordés au chapitre III, (article 17 à 19) alors que les tests de résilience et les tests de pénétration fondés sur la menace composent le chapitre IV. Enfin, la gestion de la sécurité dans les contrats est abordée, à la marge, dans le chapitre V (articles 28 et 30).
La lecture des normes techniques (« RTS », pour Regulatory Technical Standards) des ESA offre un niveau de détail beaucoup plus fin et permet de sonder la maturité d’un établissement aux exigences de cybersécurité. À cette fin, il faudra toutefois se frotter à l’exercice d’analyse de cohérence entre les politiques, protocoles, procédures et outils imposés par DORA et le cadre de sécurité propre à chaque établissement.
Le RTS sur la gestion du risque informatique (RTS RMF) détaille les attentes du régulateur en matière de sécurité des données et de cryptographie, d’encadrement des développements, de gestion des identités et des accès, d’authentification, de sécurité des réseaux et des équipements, de tests, d’identification et de remédiation des vulnérabilités. Il précise également les règles de détection des activités anormales. Ces règles sont mises en œuvre au travers de process (SIEM21) et d’outils (par exemple EDR22, XDR23, scanners...).
Les critères de classification24 des incidents majeurs, d’une part, le contenu et les modalités de notification des incidents25 à l’Autorité nationale compétente, d’autre part, font l’objet d’un RTS spécifique, accompagné de modèles de notification harmonisés. À ce titre, le dispositif DORA factorise les règles de notification des incidents de production, de sécurité et de paiement. Le mécanisme de notification des incidents majeurs, imposé par la Banque Centrale Européenne (BCE) aux banques systémiques est également englobé dans le dispositif de DORA. Si les bénéfices de faire converger trois dispositifs jusqu’ici séparés semblent indéniables à moyen terme, les enjeux de coordination opérationnelle entre équipes de gestion des incidents sont réels pour éviter les notifications en doublons.
Les tests de sécurité sont repris dans le RTS sur la gestion du risque. Le parallèle avec les orientations de l’EBA de novembre 2019 est flagrant. La réglementation énumère des natures de tests attendus : analyse du code source, tests statiques de la sécurité d’une application, test dynamique de sécurité des applications, recherche des secrets dans le code, scans de vulnérabilité, tests de pénétration, tests fondés sur la menace (red team26 par exemple). Une fois par an minimum, l’ensemble des applications soutenant des activités critiques ou importantes doivent avoir été testées, dans le respect de l’application du principe d’approche par les risques.
Enfin, la sécurité dans les contrats avec les tiers fournisseurs repose essentiellement sur des dispositions isolées des RTS sur les services tiers27 et sur la gestion de la sous-traitance28. Corollaire du volet contractuel, la gestion des risques liés à la sécurité des fournisseurs de services TIC est également abordée, non sans constituer un véritable défi pour les entreprises assujetties.
Bien que la rédaction finale de l’article 6.2 de l’Acte délégué sur la gestion du risque ait été remaniée au cours du temps, notamment pour prendre en compte le contexte technologique, l’UE est probablement à l’origine de l’introduction, dans un texte réglementaire, d’une exigence sur la protection de la donnée en cours d’utilisation.
Déjà évoqué au détour de l’article 9.2 de DORA, le chiffrement de la donnée en cours d’utilisation est repris dans une formulation à peine plus pudique. Désormais, lorsque ce type de chiffrement sera considéré comme irréalisable, les entités financières devront s’efforcer de traiter la donnée dans un environnement séparé ou de prendre des mesures alternatives équivalentes.
Le chiffrement de la donnée en cours d’utilisation demeure, pour l’immense majorité des entreprises assujetties, un sujet d’avenir et non une réalité opérationnelle. Les technologies pour y parvenir (chiffrement homomorphique29, confidential computing...), selon des modalités bien différentes, présentent des niveaux de maturité encore assez faibles.
Dans ce contexte, les précisions des ESAs quant au fait de ne recourir à ce type de chiffrement que lorsque cela est nécessaire et en ouvrant la possibilité à un déploiement de mesures alternatives équivalentes appellent deux observations. Premièrement, les cas d’usage ne devraient demeurer limités, sauf à ce que les tendances au renforcement des exigences en matière de protection des données les plus sensibles ne se confirment. Deuxièmement, le contenu de ce que pourraient être des mesures alternatives équivalentes n’est pas détaillé. L’existence même de mesures équivalentes pourrait alimenter des débats d’experts infinis.
Dans la lignée des Orientations de l’ABE sur la gestion du risque et de la sécurité30, DORA impose un régime très strict aux institutions financières vis-à-vis de leurs tiers, fournisseurs de services TIC. Les exigences s’adressent en particulier aux services soutenant des fonctions critiques ou importantes. Tout d’abord, les éléments qui doivent composer, a minima, la clause de sécurité sont précisés, dans le Règlement et les deux actes délégués liés à la gestion des fournisseurs et des sous-traitants délivrant des services à des fonctions critiques ou importantes. En synthèse, l’institution financière, doit garantir, de la part de ses fournisseurs TIC les plus sensibles :
– l’existence d’une politique de sécurité des systèmes d’information et sa mise en œuvre ;
– la gestion solide des réseaux et infrastructures qui peut inclure la capacité du prestataire d’isoler les actifs affectés de son client en cas de cyberattaque par le recours à des mécanismes automatiques ;
– la mise en œuvre des politiques de gestion et de contrôle d’accès (authentification forte...) ;
– le chiffrement des données ;
– la définition d’une stratégie de tests de sécurité ;
– une politique de gestion des vulnérabilités incluant bien entendu leur remédiation ;
– la notification au client, dès leur détection, des incidents susceptibles d’affecter le service délivré par le fournisseur.
La mise en œuvre de ces mesures doit être suivie et vérifiée durant la prestation. Cela implique notamment la mise en place d’une gouvernance forte autour des sujets de cybersécurité afin de relever les indicateurs utiles au pilotage du risque et le déploiement d’un plan d’audit associé à des événements déclencheurs, liés notamment aux changements majeurs ou à la survenance d’un incident chez le tiers et/ou ses éventuels sous-traitants.
La profondeur de la supervision des tiers par les entités financières n’est pas définie clairement dans le texte. Le régulateur a cependant été clair sur la dimension exhaustive du suivi sur l’ensemble de la chaîne de sous-traitance, ce qui peut générer un impact considérable. En effet, la charge de l’application de DORA repose sur les épaules de l’entité financière pour toute la chaîne, les éditeurs n’étant pas soumis à DORA. L’éligibilité des secteurs des infrastructures numériques et de la gestion des services TIC à la Directive NIS2 pourrait avoir un rôle déterminant dans le renforcement du niveau de cybersécurité de ces prestataires ainsi que sur la fluidité des négociations contractuelles.
Avant même de parler de notification, le premier enjeu réside dans l’identification des cybermenaces. Dans le cycle de vie d’un incident de sécurité, la cybermenace se situe avant l’incident, avant l’alerte et avant l’activité anormale. Il s’agit bien ici de développer la capacité d’identifier tout ce qui serait susceptible de se transformer en événement tangible. Le renseignement autour de la menace (threat intelligence) fait notamment partie des dispositifs qui contribuent à cet objectif.
DORA impose aussi que les cybermenaces soient classifiées puisque certaines d’entre elles sont considérées comme importantes. Cette classification se base sur la même liste de critères que pour les incidents, mais avec des modalités d’application spécifiques31. La difficulté réside ici dans la capacité à estimer les impacts d’une menace alors que par définition, celle-ci ne s’est pas matérialisée par un incident.
Enfin, les cybermenaces peuvent être notifiées par les entités financières à leur Autorité Compétente Nationale (ANC), sur la base du volontariat32, cette mesure pouvant toutefois être interprétée de manière assez inégale. Si le caractère volontaire de cette déclaration peut faire débat, la qualité des analyses de ces notifications par les autorités européennes et leur capacité à rediffuser ces informations aux entités financières contribuera naturellement à améliorer l’adhésion des assujetties à cette mesure.
La révision du texte, d’ores et déjà prévue en janvier 2028 au plus tard33, portera entre autres, sur le passage à une exigence de notification systématique des cybermenaces. Cela laisse aux entités qui n’auraient pas encore déployé les process suffisants pour paralléliser de manière fiable les notifications d’incidents majeurs et de cybermenaces importantes, le temps de s’organiser.
Pour les entités qui y sont assujetties, les TLPT présentent nécessairement des interrogations, voire des inquiétudes. Pour les uns, le sujet est de comprendre, de s’approprier les notions de base de ces tests qui ne sont pas encore très répandus en Europe. Pourtant, la méthodologie des TLPT repose sur TIBER.EU, proposé par la BCE sous la forme d’un framework, non contraignant.
Pour les autres, notamment les entités financières européennes opérant dans plusieurs pays, l’enjeu est de maîtriser ou plutôt d’anticiper au mieux les impacts des TLPT alors que leur déclenchement peut intervenir à n’importe quel moment au cours d’un cycle de trois ans, par le biais d’une notification du régulateur. Par ailleurs, le texte laisse la possibilité au régulateur d’augmenter, à sa discrétion, la fréquence d’un TLPT tous les trois ans.
La probabilité, à l’échelle d’un Groupe dont certaines de ses filiales pourraient être éligibles à la réalisation d’un TLPT, que la fréquence minimale soit augmentée est forte. Dans ces conditions, anticiper le réel impact des articles 26 et 27 de DORA consacrés aux TLPT est un véritable défi. Sur le plan opérationnel, des difficultés liées à la sollicitation des équipes ou à la disponibilité des prestataires externes suffisamment qualifiés pour délivrer ces tests pourraient rapidement émerger. Enfin, les entités financières assujetties aux TLPT devront faire preuve d’agilité pour déclencher, à tout moment sur une période de trois ans, des dépenses non planifiées.
Appréhender DORA comme une loi de plus constituerait certainement une erreur fondamentale. En matière de cybersécurité, la couverture du texte est extrêmement large et invite à se positionner sur un éventail d’exigences complet et sur leur niveau de mise en œuvre en recourant de manière cohérente aux principes de proportionnalité et d’approche par les risques. DORA va désormais coexister avec les lois nationales cyber spécifiques qui échappent au mandat des institutions européennes par leur caractère régalien.
À l’échelle européenne, sa nature est d’agréger autour de lui d’autres initiatives réglementaires. C’est pourquoi l’articulation entre DORA et sa lex generalis NIS2 d’une part, tout comme le recours au socle imposé par ces textes comme référence dans le déploiement du Cyber Resilience Act, en cours de finalisation, d’autre part, sont des enjeux importants dans la construction d’un corpus réglementaire harmonisé.
Les défis proposés par le texte pourraient également déboucher sur des avancées réglementaires attendues de longue date, comme la mise à disposition de clauses contractuelles types, qui permettraient de limiter les difficultés liées aux négociations. n
