DORA : Remettons de l'ordre dans nos idées ?
Avant de « descendre aux Enfers pour y enchaîner Cerbère », (détecter les vulnérabilités et notifier les incidents de sécurité…), revoyons la liste des épisodes précédents consacrés à DORA.
Alors, nous avons déjà vu (épisode 01) pourquoi DORA, puis (épisode 02) qui est concerné.
Après l’identification de la menace et ses définitions légales (épisode 03) ,nous avons évoqué (épisode 04) les analyses de risque et les politiques de sécurité à mettre en œuvre par les entités financières.
Dora va imposer au secteur des mesures techniques obligatoires de sécurité (épisode 05).
Le cœur du dispositif technique et légal de DORA ? Ce sont les tests de résilience (épisode 06) et seuls les « testeurs » DORA compliant pourront procéder à ces tests opérationnels (épisode 07).
L’épisode 8/12 de notre saga DORA aborde l’autre point central du dispositif législatif pensé par l’UE : l’obligation de détection (continue) des vulnérabilités et l’obligation de notification aux autorités de contrôle des « incidents majeurs » de sécurité.
Ce chapitre tout à fait essentiel de DORA est le fruit d’une collaboration avec Vladimir KOLLA, co-fondateur et DG de Patrowl (et contributeur régulier du podcast NoLimitSecu).
Et il fallait bien les remarques d’un spécialiste de la détection des « vuln » pour donner un peu de sens aux nombreuses obligations prévues par ce projet de Règlement (dont la rédaction n’est pas toujours très claire, ni heureuse…).
Bienvenue dans le monde merveilleux du projet de Règlement UE « DORA » .
La V2 du projet ayant fait l’objet d’un accord « technique » publié le 23 juin 2022, le projet final est attendu dans les 6 à 18 mois qui viennent. Ce ne sera pas de trop pour anticiper l’ampleur des 12 travaux d’Hercule qui vont s’imposer aux (je cite) « 22.000 entités financières » de l’UE.
Et DORA précise « et à tous leurs prestataires » IT.
DORA : Une obligation d'identification des "constatations d'importance critique"
Il faut le reconnaitre, DORA est un projet de Règlement difficile à lire, car les principes techniques y sont parfois mélangés et les détails nombreux.
C’est le cas du principe de détection des « vulnérabilités », qu’elles soient potentielles ou avérées (auquel cas il faut agir de manière préventive) ou qu’elles aient fait l’objet d’une exploitation effective par un attaquant (on parle alors d’incident de sécurité).
Le moins que l’on puisse dire est que le principe de l’action préventive de détection des vulnérabilités n’est pas d’une clarté limpide dans la version actuelle de DORA qui prévoit l’adoption de « règles pour … la correction rapide des constatations d’importance critique » , en « prenant dûment en considération la nature, l’ampleur et la complexité des services et des activités des entités financières » .
Qui dit « correction rapide » dit « détection en temps réel » des vulnérabilités. Une fois les « vuln » identifiées, de manière automatisée et priorisée bien évidemment, il s’agit alors de mettre en place un premier niveau de correction, selon la criticité retenue….
Ça aurait été plus simple écrit comme cela (car c’est l’état de l’art pour les pro de la cyber sécurité) mais bon…
Nous sommes bien ici dans la phase amont du problème, dans la détection de toute forme de vulnérabilité « d’importance critique » , par exemple un SPOF – Single Point of Failure – (comme nous l’avons vu dans les tests de résilience opérationnelle de l’épisode DORA 6/12).
DORA : des "indicateurs d’alerte précoce"
On trouve un autre volet de l’obligation de détection préventive des vulnérabilités dans un article consacré aux incidents de sécurité : mettre en place des « des indicateurs d’alerte précoce sous forme d’alertes [sic] » .
Des indicateurs d’alerte précoces ? Ce sont des alertes d’information sur des vulnérabilités identifiées (et priorisées – nous avons l’impression de nous répéter…).
Car – DORA est mal écrit sur ce point – il s’agit soit d’identifier de manière anticipée des vuln susceptibles de provoquer un incident (une vuln potentielle non exploitée) soit d’identifier des vulnérabilités effectivement exploitées par un attaquant. Il s’agit dans ce second cas de détecter des attaques effectives, avérés, ce qui peut alors également passer par la mise en place « d’indicateurs d’alerte précoce » .
Voici la manière dont cette obligation est prévue dans DORA :
En termes de méthodologie, il s’agit simplement de la reprise de concepts figurant dans toute certification de type ISO 27001 et du principe du « PDCA » (Plan Do, Check Act), c’est-à-dire de l’amélioration continue appliquée à la sécurité d’un système d’information.
Cette détection des vulnérabilités, avant ou après exploitation par un malfaisant, cela s’appelle le Maintien en Conditions de Sécurité (ou MCS). Et il existe des tas de service online ou on prem’ pour cela…
… pour identifier les "causes profondes" du problème : les vulnérabilités
Les « causes profondes » ? Ce sont les « vulnérabilités » , nous en revenons à cette notion à laquelle les juristes sont encore peu habitué(e)s.
Voici comment sont légalement définies les « vulnérabilités » dans DORA :
Pour une définition techniquement plus pertinente (qui tient compte notamment des contournements des logiques applicatives et des erreurs humaines…), on se référera plus volontiers au glossaire en ligne de l’ANSSI qui définit une « vulnérabilité » comme suit :
Pour pouvoir affirmer être contractuellement « à l’état de l’art », notamment dans le cadre des prestations de maintenance de leur services SaaS comme de leur logiciels on premises, les prestataires IT du secteur financier devront au moins s’engager à suivre de manière constante la publication des vulnérabilités connues :
- par les grands éditeurs (Microsoft, Oracle, Cisco, etc.)
- le NIST (« US Department of Commerce National Institute of Standards and Technology« ) et
- en France au moins le CERT-FR (« Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques » ).
DORA : et les malwares ??? on parle un peu des malwares ?
S’il est tout à fait compréhensible que l’UE encadre de manière détaillée la détection des « vulnérabilités » , il est extrêmement curieux de constater que le projet DORA n’évoque à aucun moment la menace des logiciels malveillants, quels qu’en soient la nature et les effets recherchés.
Oubli ? Méconnaissance de la menace ?
Pourtant, depuis plus de 10 ans, les contrats BtoB proposés notamment par les banques à leurs prestataires ne sont pas avares de définitions relatives aux « logiciels malveillants (virus, chevaux de Troie, etc.) » , ni d’engagements de détection et de remédiation, toujours à la charge des prestataires IT.
DORA et la notification obligatoire des "incidents majeurs" de sécurité
Ici encore, faisons simple et reprenons la définition de ce que seront les « incidents majeurs » dans le futur Règlement DORA :
Louons la sagesse[1] des fonctionnaires de Bruxelles qui, à la différence du RGPD, n’imposeront pas la notification de tous les incidents, sans tenir compte de leur importance : seulement les « incidents majeurs » .
Le problème sera, pour chaque entité financière, de définir ce qu’est une « incidence négative potentiellement élevée » .
Ici encore, DORA se trompe de cible en voyant l’impact potentiel sur les « réseaux et systèmes d’information » alors que l’incidence négative devrait manifestement porter sur le « business » géré grâce à l’informatique.
Dans la réalité, les entreprises du secteur financier vont devoir définir des grilles quantitatives et contextualisées de classification des impacts des incidents qu’elles pourraient rencontrer.
Ces grilles prendront prioritairement en compte la perte financière effective, les risques liés à la réputation (perte de confidentialité des données, par exemple), etc.
Par exemple, une perte financière suite à l’exploitation d’une vulnérabilité (ou d’un malware) sera classée « low » (dommage inférieur à 50 K €), « medium » (dommage inférieur à 500 K €), « serious » (dommage inférieur à 1 M €) ou « extreme » (dommage supérieur à 1 M €).
Évidemment, les procédures internes de remédiation seront proportionnées à la gravité de l’incident, ainsi que la mise en oeuvre des moyens humains et financiers destinés à assurer « un traitement et un suivi cohérents et intégrés » dudit incident.
[1] Sagesse ou fruit d’un lobbying intense du secteur, bien connu pour son efficacité ? Mystère…
Une harmonisation de la classification des incidents de sécurité
Évidemment, la perception par une entité financière de la gravité de l’impact d’un incident de sécurité ne sera pas forcément du même niveau que celui de la gravité de l’incident à notifier aux autorités de contrôle…
Retenons en substance que DORA imposera une harmonisation de l’obligation de « suivre et d’enregistrer les incidents » [1] qui seront classés sur la base de critères détaillés par les autorités de contrôle qui assureront (sans que nous n’ayons encore de détails à ce stade) la définition de seuils, notamment « d’importance significative » .
[1] « identifier, suivre, consigner, catégoriser et classer les incidents en fonction de leur priorité ainsi que de la gravité et de la criticité des services touchés »
Mais les critères de classification sont, eux, d’ores et déjà extrêmement précis :
Sur ce point, souhaitons bon courage aux autorités de contrôle et à l’Europe pour harmoniser ces indicateurs de gravité avec des entreprises du secteur financier dont la « sensibilité » au problème des vulnérabilités et des incidents de sécurité est extrêmement variable : une banque grand public sera plus sensible à l’atteinte à sa réputation si son site web se fait défacer qu’une banque d’investissement inconnue du grand public…
DORA va imposer un régime très détaillé de notification des incidents de sécurité
Pour donner une idée du régime de déclaration qui se prépare, les entités financières devront, pour chaque « incident majeur » de sécurité :
Pour faire un parallèle, les articles 33 et 34 du RGPD imposent par principe une notification obligatoire des « violations de données » aux autorités de contrôle, et, par exception, une information, aux « personnes concernées » .
Que l’on ne s’y trompe pas, la notification des incidents de sécurité ne gommera pas l’obligation de déclaration des violations de données personnelles au sens du RGPD. Les deux obligations se cumuleront.
Bonne nouvelle cependant, les entités financières ne devront notifier leurs incidents de sécurité majeurs qu’à leur seule autorité nationale, laquelle pourra à son tour les partager de manière anonymisée avec leurs homologues au sein de l’UE et/ou avec les autorités de contrôle du secteur.
Espoir d’un monde meilleur (à échéance indéterminée…), DORA prévoit « qu’il conviendrait d’étudier la possibilité de centraliser les rapports sur les incidents en créant un pôle central de l’UE unique » . A se demander pourquoi l’ENISA n’est pas d’ores et déjà désignée pour assurer cette charge.
… et un partage d’informations sur la cyber-menace
Si vous êtes sensible à la notion d’usine à gaz, vous n’allez pas être déçu(e) par le chapitre de DORA qui vise à « favoriser un processus d’apprentissage intersectoriel et de tirer efficacement parti des expériences d’autres secteurs en matière de lutte contre les cyber-menaces » .
C’est donc de manière pertinente – en principe – que le projet DORA prévoit que « les entités financières [visées par la Directive NIS#1] devraient continuer à faire partie de l’écosystème de cette directive (par exemple, le groupe de coopération SRI et les CSIRT » .
Nous botterons en touche sur la description du futur régime de partage d’information, dont la description dans DORA est… comment dire… perfectible…
DORA : synthèse du processus de "Maintien en Conditions de Sécurité"
A SUIVRE DORA 9/12 : des obligations de gestion et de communication de crise ?
Une analyse technique et juridique de DORA ?
Le sujet est suffisamment technique pour que les commentaires d’un juriste ne soient pas suffisants.
Ce chapitre tout à fait essentiel de DORA est le fruit d’une collaboration avec Vladimir KOLLA, co-fondateur et DG de Patrowl.
Et il fallait bien les remarques d’un spécialiste de la détection des « vuln » pour vous livrer une analyse et des explications qui devraient éclairer à la fois les opérationnel(le)s et les juristes qui gèrent les problématiques de sécurité des systèmes d’information.
DORA illustré en BD avec un Hercule très futuriste
Qui d’autre que le mythique Hercule pouvait vous accompagner dans des explications sur ces 12 travaux de sécurisation des systèmes d’information imposés aux entreprises du secteur financier ?
Les illustrations sont toutes issues de la (magnifique) série « Hercule » en 3 tomes par Jean-David Morvan au scénario, Vivien « Looky » Chauvet et Olivier Thill au dessin et à la couleur.
Encore 4 épreuves herculéennes… (vous avez déjà lu les 2/3 !!!)
le générique des BD ayant servi d'illustration (merci aux éditions Delcourt / Soleil)
Vous voulez en savoir plus sur les bandes dessinées utilisées pour illustrer cette présentation ? Cliquez sur le lien qui vous intéresse !!!
« Les 5 Terres » première série complète en 6 tomes par « Lewelyn » (David Chauvel, Andoryss et Patrick Wong) et Jérome Lereculey © éditions Delcourt 2019-2022
« Arctica » 12 tomes par Daniel Pecqueur et Boyan Kovačević © éditions Delcourt 2007-2022
« Au-delà des merveilles » série complète en 3 tomes par Yohann « Wyllow » Puaud © éditions Clair de Lune 2004-2022
« Badlands » série complète en 3 tomes par Eric Corbeyran et Piotr Kowalski © éditions Soleil 2014-2018
« Carmen mc Callum » 18 tomes (tome 1 par Fred Duval + Olivier Vatine + Fred Blanchard + Stéphane « Gess » et tomes 2 et 3 par Fred Duval et Stéphane « Gess ») © éditions Delcourt 1995-2020
« Le Crépuscule des Dieux » série complète en 9 tomes par Nicolas Jarry et Jean-François « Djief » © éditions Soleil 2007-2016
« lE dERNIER tROYEN » série complète en 6 tomes + 1 intégrale par Valérie Mangin et Thierry Démarez © éditions Soleil 2004-2012
« Excalibur-Chroniques » (époustouflante) série complète en 5 tomes + 1 intégrale par Jean-Luc Istin et Alain Brion © éditions Soleil 2012-2019
« Hercule » série complète en 3 tomes par Jean-David Morvan + Vivien « Looky » Chauvet + Olivier Thill © éditions Soleil 2012-2017
« Horologiom » série complète en 7 tomes + intégrale en 2 tomes par Stéphane Lebeault © éditions Delcourt 1994-2021
« Neandertal » série complète en 3 tomes par Emmanuel Roudier © éditions Delcourt 2007-2011
« La nef des Fous » 11 tomes + intégrale en 2 tomes + hors série par Bernard « Turf » © éditions Delcourt 1993-2021
« Odin » série complète en 2 tomes par Nicolas Jarry et Erwan Seure-Le Bihan © éditions Soleil 2010-2012
« L’Oeil de la Nuit » série complète en 3 tomes par Serge Lehman et Stéphane « Gess » © éditions Delcourt 2015-2016
« Olympus Mons » première série complète en 7 tomes par Christophe Bec et Stefano Raffaele © éditions Soleil 2017-2022
« Les portes de Shamballah » série complète en 4 tomes par Mazuer + Romano + Taranzano © éditions Clair de Lune 2007-2016
« Souvenirs de la Grande Armée » série complète en 4 tomes + 1 intégrale par Michel Dufranne et Vladimir « Alexander » © éditions Delcourt 2007-2018
« Sur les terres d’Horus » série complète en 8 tomes par Isabelle Dethan © éditions Delcourt 2001-2015
« Universal War One » série complète en 6 tomes (absolument remarquables) par Denis Bajram © éditions Soleil 1998-2006
« Yiu Premières missions » série complète en 7 tomes + intégrale en 2 tomes par Thierry « Téhy » + Jeanne « JM Vee » + Vincent « Vax » © éditions Soleil 2003-2010
![Ordre des Avocats de Paris PSSI et analyse des risques ISO 27001 [11 avril 2024]](https://technique-et-droit-du-numerique.fr/wp-content/uploads/2025/04/547-Ordre-des-Avocats-de-Paris-PSSI-et-analyse-des-risques-ISO-27001-11-avril-2024-©-Ledieu-Avocats-2024.001.jpeg)