DORA d’un point de vue cyber
mercredi 9 novembre 2022, par Jean-Philippe Gaulier
Nous avons entrepris avec Marc-Antoine Ledieu, avocat à la cour et contributeur régulier NoLimitSecu une série d’articles pour décortiquer le projet de règlement européen DORA. Vous pourrez retrouver les différents sujets ici.
Nous vous proposons dans cet article une vision globale de l’aspect cyber qui sera impacté par le règlement.
L’union Européenne a décidé de frapper un grand coup sur la table des marchés financiers (banque, assurance...) en imprimant un nouveau règlement (pas encore promulgué), par définition avec application immédiate, du doux nom acronymique de DORA. Alors promis, cher lecteur, nous ne parlerons ni d’adolescente aventurière qui te chante en boucle des chansons dans toutes les langues de l’eurovision, ni de poisson à la mémoire flétrie. Non, nous ne parlerons que de "DIGITAL OPERATIONAL RESILIENCE FOR THE FINANCIAL SECTOR" ou plus modestement dans la langue de Robert Larousse de la résilience opérationnelle numérique du secteur financier. Oui, RONF, c’est moins sexy.
DORA (Article 1) établit les règles de cybersécurité obligatoires pour les entités financières. Ces règles se définissent comme suit :
- gestion des risques
- gestion et notification des incidents
- plan (et application) de tests de résilience
- cybersécurité des sous-traitants (coucou article 28 du RGPD)
Il va y avoir du bruit dans les chaumières, car si DORA n’invente pas le fil à couper la roue, elle sanctuarise des obligations depuis bien longtemps énoncées comme état de l’art en matière de cybersécurité.
Le lecteur amusé notera que si le parlement a décidé d’expliciter le périmètre en tant que "sécurité des systèmes d’information et des réseaux", il en oublie naïvement les systèmes industriels, certes peu présents dans le monde financier, mais qui pourraient prendre leur essor dans les années à venir (fermes de blockchain, automates d’IA...). Gageons que cela évoluera avec le temps.
Dans cet article, nous nous intéresserons à la première exigence, celle de la gestion des risques. En effet, hors table des matières, le mot risque est cité 140 fois dans le corps du texte principal, composé de 56 articles, et 153 fois dans les 73 considérants. Ce n’est pas anodin et cela en fait une pierre angulaire.
En comparaison, le mot incident apparaît 85 fois dans le corps et 48 fois dans les considérants, résilience 24 fois (corps) et 74 fois (considérants) et prestataire 181 fois (corps) et 103 fois (considérants). Mais les prestataires, vous le savez, chez Cyberzen, ce sont nos chouchous, nous aurons donc le loisir de revenir sur la question !
Avec cette place de choix, il est donc clair que la gestion du risque, sa déclinaison par une analyse, son application et son suivi sont au cœur du sujet.
Dans son constat et ses analyses, le législateur reconnaît les points suivants :
- les risques informatiques n’ont fait l’objet que d’une attention limitée ou incomplète dans le cadre de la couverture des risques opérationnels ;
- l’UE n’a pas pleinement répondu aux besoins qu’ont les entités financières européennes de gérer les risques opérationnels d’une manière qui leur permette de résister aux conséquences des incidents informatiques ;
- il faut absolument prévenir l’instabilité financière découlant de la matérialisation de ces risques informatiques.
Gageons que l’augmentation des attaques, particulièrement à travers l’initiative inflationniste des rançongiciels, a contribué à créer une prise de conscience globale du besoin de sécurisation du système d’information, véritable ossature de toute entreprise, particulièrement dans le monde financier. Promis, les règles à calculer sont bien rangées dans un carton au grenier.
Alors, comme dans chaque étude, il est nécessaire d’établir un périmètre. Et par chance, lorsque l’on travaille avec des juristes, ce besoin vital de ne pas pouvoir comparer des choux avec des carottes fait partie de leurs marottes. C’est ainsi qu’on nous livre une définition précise de ce qui sera compris comme un risque informatique : « toute circonstance raisonnablement identifiable liée à l’utilisation des réseaux et des systèmes d’information, – y compris un dysfonctionnement, un dépassement de capacité, une défaillance, une perturbation, une altération, une mauvaise utilisation, une perte ou tout autre type d’événement, malveillant ou non – qui, si elle se concrétise, peut compromettre la sécurité des réseaux et des systèmes d’information, de tout outil ou processus dépendant de la technologie, du fonctionnement et de l’exécution des processus ou de la fourniture de services, compromettant ainsi l’intégrité ou la disponibilité des données, des logiciels ou de tout autre composante des services et infrastructures informatiques, ou entraînant une violation de la confidentialité, un dommage à l’infrastructure informatique physique ou d’autres effets préjudiciables. »
définition à laquelle s’adjoint celle essentielle pour pouvoir travailler d’un actif d’information : « un ensemble d’informations, matérielles ou immatérielles, qui justifie une protection. »
puis celle d’une vulnérabilité : « une faiblesse, une susceptibilité ou un défaut d’un actif, d’un système, d’un processus ou d’un contrôle qui peuvent être exploités par une menace. »
Après cette belle homélie, nous allons pouvoir plonger plus avant !
C’est carrément tout un chapitre qui est dédié à notre gestion des risques qui s’étend au chapitre 2 de DORA. Et là, tout le monde en prend pour son grade, à commencer par l’organe de direction d’entreprise (coucou le "COMEX") qui pêle-mêle :
- assume la responsabilité finale de la gestion des risques
- définit clairement les rôles et responsabilités des fonctions liées à l’informatique
- détermine le niveau de risque approprié
- approuve, supervise et examine régulièrement les PCA (continuité) et PRA (reprise)
- approuve et examine périodiquement les plans d’audit ET les audits informatiques
- alloue et réexamine périodiquement le budget (y compris pour la FORMATION face au risque cyber)
- approuve et examine périodiquement les contrats avec les sous-traitants en s’appuyant particulièrement sur un résumé de l’analyse de risque pour chacun
- s’informe des incidents et de leurs suites
Bref, le RSSI s’offre un siège permanent sur des sujets qui jusqu’alors ne passionnaient pas les membres de la direction, qui reléguaient ces tâches ingrates à un obscur comité de sécurité, en général sous l’égide d’un DSI. Chic, chic, chic, on va parler chiffons !
Alors non, vous n’y couperez pas, il va falloir de la méthode. Lorsque l’on parle d’appréciation des risques, on ne demande pas à Michel de la compta la copie des commissaires aux comptes sur la gestion du contrôle d’accès. Parce que, non, il faut être sérieux deux minutes. On parle de structures réfléchies et posées.
Du coup, vous pouvez ressortir vos EBIOS RM et 27005, on est partis pour établir des matrices ! Une bonne nouvelle arrivant rarement seule, la mise en place d’un système de gestion de la sécurité de l’information fondé sur des normes internationales reconnues et conformes aux orientations des autorités des autorités de surveillance est requise pour toute structure qui ne serait pas une microentreprise (entreprise monopersonnelle ne dépassant pas 72 600 € de CA). Quelle joie ! Quel bonheur ! Votre SMSI (système de management de la sécurité de l’information) exulte, votre certification 27001/27701 rie à tue-tête ! Certes, un petit PCI-DSS sera probablement accepté, mais pour le reste, il faudra s’amender et faire preuve de transparence. Comment cela, vous n’êtes pas encore certifié ? Il va falloir que l’on discute...
Tant qu’à être dans les bonnes nouvelles, profitons-en pour aborder un autre sujet. Le règlement exige une séparation des fonctions suivantes :
- gestion informatique
- fonctions de contrôle
- audit interne
En l’occurrence, 2022 est une belle année pour recruter !
Revenons quelques instants à notre ami Michel, de la compta. Depuis des années, il est le roi de la moulinette, le pourfendeur de tableaux croisés dynamiques, le héros ultime de agrégation d’indicateurs. Malheureusement, il y a une mauvaise nouvelle pour Michel. Les systèmes, outils et protocoles doivent être fiables, en capacité d’absorber la croissance et résilients. Autant dire que la résilience et la fiabilité d’un tableau Excel, ça va être compliqué à prouver. Bon, cela dit, ça interdit par là-même tout usage de système obsolète (coucou Windows XP et Windows 2012) et ça prévoit de beaux plans de migration !
Sur la construction des exigences globales, on retrouve pêle-mêle les exigences classiques d’une ISO 27002 éparpillées au gré des articles.
Évidemment, vous ne couperez pas à la création et à la maintenance d’une Politique de sécurité du système d’information (PSSI) basée sur une approche par les risques (ISO 27002, chapitre 5). Celle-ci devra servir de base fondamentale à la gestion organisationnelle, fonctionnelle et technique de la cybersécurité de votre établissement. Et comme dans toute bonne politique, nous trouverons une classification des données et les mesures de sécurité associées à chaque niveau.
Mais comment gérer les risques sans une cartographie (ISO 27002, chapitre 8) complète du système d’information fonctionnelle et technique, me direz-vous ? Et bien, comme c’est impossible, il faudra obligatoirement l’établir afin de mieux pouvoir déterminer les risques encourus et connaître et maîtriser son périmètre d’actifs matériels (serveurs, switches, routeurs...) et immatériels (données), et ce de manière continue.
Comme l’humain reste au cœur du système, vous n’échapperez pas à une sensibilisation régulière pour tout le monde, ni à la formation approfondie périodique et obligatoire des personnels concernés (ISO 27002, chapitre 7), ce qui ciblera avant tout ici le personnel de la DSI et de la cybersécurité.
DORA vous invite également à une gestion maîtrisée du contrôle d’accès physique et logique (ISO 27002, chapitre 9), ce qui sous-entend entre autres la tenue de comptes nominatifs, la maîtrise des droits d’accès et des revues régulières. Bien sûr, de fait, cela embarque la gestion de l’authentification forte et du chiffrement.
Sur la partie de la sécurité de l’exploitation, on retrouve les points habituels, avec la gestion des changements (ITIL & ISO 27002, chapitre 12), partie qui est évidemment extrêmement douloureuse et coûteuse pour les structures de petite taille, le maintien en condition de sécurité, autrement appelé gestion des correctifs et mises à jour (ISO 27002, chapitre 12) ou dans son nom anglais le patch management. Bien que la mise à jour soit en générale réglée de manière automatique, au grand damne des régressions fonctionnelles probables, il ne faut surtout pas minimiser l’impact des fins de maintenance produit et de la conduite du changement ad hoc.
Le rançongiciel l’a mise sur le devant de la scène et lui a donné ses lettres de noblesses, vous ne couperez évidemment pas à la présence d’une politique de sauvegarde et restauration effective et efficace. Pour cette dernière, ce sera sur des systèmes informatiques qui fonctionnent dans un environnement d’exploitation différent du système principal, qui n’est pas directement connecté à ce dernier et qui est protégé de manière sécurisée contre tout accès non autorisé ou toute corruption informatique. Tout un programme ! De fait, vous pouvez oublier les copies ou synchronisations sur des répertoires partagés...
Un autre point d’importance pour toutes les petites et moyennes structures, la compartimentation et segmentation réseau, garantissant la possibilité d’une déconnexion instantanée sans perturbation d’autres systèmes (ISO 27 002, chapitre 13) devient obligatoire. Vous pouvez donc oublier votre connexion directe à votre livebox et la présence de votre Active Directory sur le même réseau que vos postes et votre imprimante. Vous entrez dans le grand monde, tenue de bal exigée.
Toujours dans la catégorie "merci cher rançongiciel", la part belle est donnée à la détection (ISO 27002, chapitre 16) et à la réponse à incident. Ainsi, si vous ne recourrez pas encore aux services d’un CERT et d’un SOC, de manière interne ou externe, vous n’y couperez plus ! Il vous faudra également travailler à la mise en place des mécanismes permettant de détecter rapidement les activités anormales, y compris les problèmes de performance, la classification des alertes, l’enrichissement d’un registre des incidents et de leur gestion. Bien sûr, comme certains incidents sont plus importants que d’autres, vous aurez préparé une gestion de crise adaptée à différents scénarios et vous maintiendrez un plan de communication pour chacun.
La continuité et la reprise d’activité PRA (ISO 27002, chapitre 17) deviennent également obligatoires avec des plans de tests prouvant leur réalité et leur efficacité.
Pour embellir cette belle recette, nous saupoudrerons un programme d’audit (ISO 27002, chapitre 18) aux petits oignons, par des auditeurs qualifiés, laissant à votre charge l’obligation de ne pas caler une table avec le rapport, mais bien de vous en servir pour appliquer un plan de correction et d’amélioration dans les délais les plus brefs.
Voilà, vous tenez le bon bout, ne lâchez surtout pas. En résumé, le législateur a donc décidé que l’ISO 27002 était une cible cohérente de sécurité et qu’à défaut d’avoir un devoir de moyen, les établissements financiers ont une obligation de résultat vis-à-vis de celle-ci.
En complément, L’ENISA donnera des précisions sur les implémentations techniques, mais gageons que cela ne surpassera pas de beaucoup ce qui existe déjà à l’état de l’art.
Pour conclure, le législateur a bien pris conscience que la cybersécurité du système d’information est un maillon critique de l’industrie financière et qu’en dehors des grands groupes qui ont des contraintes référentielles imposées (BAL II et III, Sarbanne-Oxley...), toute la chaîne de valeur, incluant les TPE et les PME, doit se mettre au diapason le plus rapidement possible pour éviter des catastrophes à tout l’écosystème. C’est une marche ambitieuse, élevée mais nécessaire pour éviter des conséquences catastrophiques à venir.