DORA projet 6/12 : les tests de résilience (le coeur du dispositif)
Pour vous y retrouver dans les épisodes précédents de DORA
Dans ce nouvel épisode de notre saga consacrée à l’étude du projet de Règlement UE DORA, nous allons longuement évoquer les aspects techniques des tests de résilience bientôt imposés aux entreprises du « secteur financier » (et à leurs prestataires IT).
Remettons d’abord les choses dans l’ordre.
Nous avons commencé par comprendre pourquoi DORA (épisode 01) puis qui est concerné (épisode 02).
Après l’identification de la menace et ses définitions légales (épisode 03), nous avons évoqué les analyses de risque et les politiques de sécurité à mettre en œuvre par les entités financières (épisode 04).
Dora va imposer au secteur des mesures techniques obligatoires de sécurité (épisode 05).
Il va bien falloir les tester, ces mesures de sécurité ? Pour vérifier qu’elles servent à quelque chose ?
Intéressons-nous aujourd’hui aux tests de résilience opérationnelle. Cette 6ème épreuve d’Hercule du projet de Règlement UE DORA publié le 24 septembre 2020 (et en version rectifiée le 23 juin 2022) représente le cœur du dispositif technique et légal qui devrait arriver dans les tous prochains mois.
Ça tombe bien, les tests techniques de sécurité, c’est la spécialité de Sylvain LECONTE, DG et co-fondateur de COGICEO.
DORA projet 6/12 : les tests de résilience opérationnelle pour "recenser les faiblesses" du système d'information des entreprises du secteur financier
« Rapporter les pommes d’or du jardin des Hespérides » ? Ce seront les « faiblesses, défaillances ou lacunes » des systèmes d’information et des mesures techniques de sécurité déjà mises en place que les auditeurs techniques de sécurité vont devoir identifier en gravissant les pentes du mont Atlas, « là où les chevaux du char du Soleil achèvent leur randonnée en se couchant à l’ouest de l’océan Atlantique » (merci Wikipédia).
Ici encore, contentons-nous de citer le projet DORA :
Pour y parvenir, les entreprises du secteur financier devront « établir » , « maintenir » et « réexaminer » des programmes « solides et complets » de tests numériques à effectuer « par des parties indépendantes internes ou externes » .
Précisions : ces « évaluations, tests, méthodologies, pratiques et outils » devront tenir compte de « l’évolution du paysage [sic] des risques » et permettre de « hiérarchiser, classer et résoudre« tous les problèmes recensés au cours des tests de sorte qu’ils soient « entièrement [sic] corrigés » .
Sur le papier, ça claque !
Seuls les « systèmes et applications informatiques essentiels » (pas seulement « critiques » ?) seront soumis « au moins une fois par an » à ces tests.
Ce sera évidemment à prévoir dans les contrats conclus avec les prestataires IT du secteur financier, en plus des très nombreuses obligations de rédaction qui se préparent et que nous analyserons dans l’épisode DORA 10/12 à venir.
DORA projet 6/12 : la liste (somme toute assez curieuse) des tests de résilience opérationnelle
Nouvel inventaire à la Prévert de la nature des tests à prévoir.
Allons-y pas à pas…
DORA projet 6/12 : les tests de résilience opérationnelle : (i) évaluations et analyses de "la vulnérabilité [sic]"
Si l’on s’en tient au terme technique de « vulnérabilité » , l’état de l’art impose aujourd’hui, coté client comme coté prestataire IT, de procéder à la détection en temps réel des vulnérabilités connues dans les logiciels on premises et dans les services SaaS.
Nous reviendrons en détail sur les modes de détection des vulnérabilités (dans l’épisode DORA 8/12) qui permettent de faire du « Maintien en Conditions de Sécurité » (ou MCS).
S’il faut comprendre « vulnérabilité » par « faiblesse » , ce type de tests n’ajoute pas grand-chose à la compréhension de DORA, ni à la cyber sécurité du secteur financier (mais qui a écrit ça ???).
DORA projet 6/12 : les tests de résilience opérationnelle (ii) analyses des "sources ouvertes" comme les leaks
« Leaks » ? Ce sont les données « volées » auxquelles les pirates donnent libre accès via un site web ou via TOR (sites en .onion) par exemple. Pour prouver la réalité du « vol » commis et faire pression sur la victime pour l’inciter à payer la rançon…
Évidemment, le contenu de ces leaks est très variable : des données personnelles au sens du RGPD, des informations protégées par un secret (secret médical, secret des affaires, etc.), des codes source protégés par le droit d’auteur, etc.
Pourtant, la recherche et l’analyse des leaks est une étape préparatoire essentielle pour toute opération de RedTeam un tant soit peu professionnelle.
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (iii) évaluations de la sécurité des réseaux
Pas de commentaire utile face à ce type de déclaration dont on se demande ce qu’elle fait ici…
Il aurait été pertinent d’évoquer l’évaluation de « l’architecture » des systèmes d’information et des réseaux.
Une architecture technique SI résiliente est une architecture qui possède des environnements séparés (environnement de développement, de test, de qualification, de recette, de production, etc.) permettant le repli (la bascule) en cas d’indisponibilité d’un environnement au profit d’un autre.
Cela permet à une entreprise de continuer à fonctionner avec des fonctions dégradées… Mais de fonctionner quand même.
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (iv) "analyses des lacunes"
La première des lacunes à identifier s’appelle le SPOF, le « single point of failure » , la base du château de carte, celle que l’on retire et qui fait s’effondrer tout l’édifice…
On pense ici à l’exemple (tristement) classique de la compromission par un attaquant de l’Active Directory (ou « AD » , le service LDAP de Microsoft), « l’annuaire informatique » listant l’ensemble des utilisateurs autorisés du SI d’une entreprise et l’étendu de leurs « droits » (admin ? user ? prestataire externe ? invité ?).
Si l’AD est compromis par un attaquant (accès + cryptolockage), c’est tout le système d’information de l’entreprise qui est compromis.
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (v) "examens" de la sécurité physique
On touche ici un sujet généralement oublié des professionnels (et que nous n’avons qu’évoqué dans notre épisode DORA 1/12).
La sécurité physique est rarement l’affaire du RSSI dans l’immense majorité des entreprises, et pas que du secteur financier.
C’est le problème de la clé USB trouvée par terre et insérée dans un ordinateur…
On pense aussi à l’installation « sauvage » de réseau Wi-Fi à partir de bornes personnelles par un salarié…
On pense enfin (et surtout) à la sécurité des prises réseaux largement disponibles « à tout vent » dans les locaux de toutes les entreprises et qui ne font l’objet d’aucune mesure de protection.
Mais qui, dans une agence bancaire, surveille le branchement de « devices » dans les salles de réunion ou dans les salles d’attente ?
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (vi) "questionnaires et solutions logicielles d’analyse"
Des questionnaires dans une liste de tests techniques ?
Mais qui a rédigé ce paragraphe ???
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (vii) "examens du code source lorsque cela est possible [sic]"
On pense ici au problème de la « dette technique » , du « legacy » , des logiciels écrits dans des langages de programmation aujourd’hui disparus (et dont les développeurs sont à la retraite) mais qui fonctionnent toujours en production ! Et ne croyez pas qu’il s’agit là d’une simple anecdote ou d’une hypothèse bidon, demandez ce qu’il en est à n’importe quel auditeur (sérieux) de sécurité numérique…
Si l’idée d’examiner certains codes source est tout à fait louable, la réalité est qu’aucune entreprise ne dispose du temps ni des moyens pour auditer les codes source de ses fournisseurs IT, ni (pire encore) pour re-développer des applications vieilles parfois de 30 ans (et qui « tournent » encore…).
Là, on touche au sujet très sensible du développement sécurisé des logiciels.
Voyez comme il est déjà difficile, après 4 ans de RGPD, de demander à un prestataire IT un engagement de développement logiciel en « privacy by design » .
Alors de là à demander des engagements de développement en « security by design » , il y a un pas (de géant) que l’industrie du logiciel n’est clairement aujourd’hui pas en mesure de franchir (en tout cas pas au prix que le secteur financier serait prêt à payer).
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (viii) tests "fondés sur des scénarios"
Cette notion de « tests sur scénarios » rejoint directement la notion d’analyse de risques, notamment avec la méthode EBIOS RM que nous avons évoquée dans l’épisode DORA 4/12.
Encore faut-il avoir mené cette analyse de risque avec les personnes qui connaissent parfaitement leur système d’information et en ont une vue suffisamment claire pour construire des scénarios de menace concrets.
Hélas…
Trop souvent, l’exercice ne passionne guère et les pro se contentent juste d’appliquer un modèle « classique » sans l’adapter à la réalité de la situation de leur entreprise. C’est vrai que c’est compliqué de réfléchir…
L’idée serait de pousser les entreprises du secteur financier à mener des exercices de crise orientés technique ayant pour base des scénarios plausibles, comme celui d’un attaquant qui compromettrait une grappe de serveurs névralgiques de la production et les rendrait indisponibles. Il n’y a aujourd’hui pas beaucoup d’entreprises qui se risquent à mener des exercices grandeur nature sur leur production… Et c’est bien ça le problème…
D’ailleurs, combien d’entreprises (et pas que dans le « secteur financier » ) testent pour de vrai la restauration de leurs sauvegardes ?
DORA projet 6/12 : les tests de résilience opérationnelle DORA : (ix) "tests de compatibilité"
Dès qu’on comprend ce qui se cache derrière ces termes, nous aurons, à notre tour, le plaisir de vous l’expliquer …
DORA projet 6/12 :les tests de résilience opérationnelle DORA : (x) "tests de performance ou tests de bout en bout"
Les « tests de performance » , ce seraient les tests de montée en charge permettant d’éviter les DDoS, les attaques par saturation qui font « tomber » les serveurs ?
Pour les « tests de bout en bout » , nous poursuivons nos recherches afin de comprendre ce que ça veut dire…
Au final, que retenir de cet inventaire ? De bonnes idées, certes. Mais ce serait mieux si l’UE faisait appel à des professionnels de la cyber-sécurité pour écrire des choses sensées (comprendre ayant un sens technique) plutôt que de lancer des mots en l’air.
Mais que manque-t-il à cette liste ? Les fameux pen-tests, les « tests de pénétration » .
DORA projet 6/12 : des "tests de pénétration fondés sur la menace" ?
Curieusement, seules les entités financières « d’importance significative » (un « petit pourcentage » d’entre elles selon le considérant 35 de DORA) devraient être tenues « au moins tous les 3 ans » de procéder « à des tests de pénétration fondés sur la [réalité de la] menace [cyber] » .
Les auteurs sont en mesure d’attester que dans un grand nombre de secteurs d’activité en 2022, la pratique des contrats BtoB en France considère comme « à l’état de l’art » l’obligation de procéder tous les ans à des « pentests » , coté commanditaire comme coté prestataire IT. Alors, « au moins tous les 3 ans » pour des entreprises « d’importance significative » du secteur financier ??? Attendons la version finale de DORA…
L’article 23 du projet DORA est suffisamment mal écrit pour que nous ne puissions pas encore déterminer quelles entités financières seront soumises à ces « tests avancés » .
Nous passerons donc sous silence le détail de cet impératif légal particulier, sauf à se demander quelle est la différence entre un « test fondé sur des scénarios » (pour tout le monde) et un « test de pénétration fondés sur la menace » (seulement pour les entités « d’importance significative » ) ?
Tout cela manque un peu de cohérence…
A suivre DORA épisode 7/12 : les obligations applicables aux testeurs
Une analyse technique et juridique de DORA ?
Le sujet est suffisamment technique pour que les commentaires d’un juriste ne soient pas suffisants.
Qui mieux que Sylvain LECONTE, DG et co-fondateur de COGICEO, pouvait vous parler concrètement des tests à faire subir à un système d’information ?
Cet article lui doit beaucoup, ainsi que son expérience d’auditeur de sécurité qualifié PASSI par l’ANSSI.
DORA illustré en BD avec un Hercule très futuriste
Qui d’autre que le mythique Hercule pouvait vous accompagner dans l’explication des 12 travaux de sécurisation des systèmes d’information imposés aux entreprises du secteur financier ?
Les illustrations sont toutes issues de l’incroyable série « Hercule » en 3 tomes par Jean-David Morvan au scénario, Vivien « Looky » Chauvet au dessin et Olivier Thill à la couleur.
Vous avez déjà accompli 6 travaux herculéens, n'en restent plus que 6 autres !
Le générique des BD ayant servi d'illustration à cette présentation : 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
