Speaker #0Bonjour mamie ! Bonjour et bienvenue dans la cybersécurité expliquée à ma grand-mère, le podcast pour expliquer la cybersécurité à des gens qui n'y comprennent rien. Aujourd'hui, je voudrais vous emmener sur une petite île des Philippines, une île qui s'appelle Lubang, et vous raconter l'histoire d'un homme qui a fait la guerre pendant 29 ans. 29 ans, alors que tout le monde autour de lui, le monde entier en fait, avait signé la paix depuis longtemps. Cet homme s'appelle Hiro Onoda. Il est sous-lieutenant de l'armée impériale japonaise. En décembre 1944, Merci. On l'envoie sur Lubang avec une mission de renseignement et de sabotage, et un ordre très clair de son supérieur, le major Tanigoshi. Tenir, ne jamais se rendre, ne jamais se donner la mort, et attendre que l'armée vienne le chercher. Quelques semaines plus tard, les Américains débarquent, la gare d'Inaison est balayée, et Onoda se replie dans la jungle avec trois camarades. Puis, en août 1945, le Japon capitule. La guerre est finie, mais Onoda, lui, ne le sait pas. Ou plus exactement, il refuse de le croire. Des tracts sont largués sur l'île pour annoncer la fin des hostilités. Il les lit et il conclut que ce sont des faux, une ruse de l'ennemi pour le faire sortir du bois. Des lettres de sa famille, des journaux, des messages par haut-parleur, tout est interprété comme de la propagande. Ses trois camarades meurent ou se rendent un par un au fil des ans. Lui reste. Il continue ses patrouilles. Il vit de ceux qu'il vole dans les fermes. Il tire sur ceux qu'il prend pour des soldats ennemis. Il faudra attendre 1974 et un jeune japonais un peu fou nommé Nori Suzuki partit, je cite, chercher Onoda, un panda et le Yeti, dans cet ordre et dans cet ordre uniquement. Et là, le détail qui fait toute l'histoire, Onoda accepte de parler. Mais il refuse de se rendre. Il explique qu'il n'a reçu aucun ordre. Il attend l'ordre de son supérieur. Alors le Japon va retrouver le majeur Tanegoshi, devenu libraire. Le fait monter dans un avion, et c'est lui, en uniforme, qui vient dans la jungle de Logan, relever officiellement de ses fonctions, un soldat que personne n'avait pensé à prévenir que le monde avait changé. Vous vous demandez sûrement ce que cette histoire vient faire dans un podcast sur la cybersécurité. Eh bien, je vais vous le dire. Nos entreprises, nos banques, nos hôpitaux, nos administrations sont pleines de héroes onodas. Des systèmes informatiques qui tournent encore, fidèlement, obstinément. selon les ordres reçus il y a 20 ou 30 ans, et que personne n'a jamais relevé. Dans le jargon, on appelle ces systèmes « legacy » , de l'anglais « héritage » . C'est le patrimoine informatique dont on a hérité, souvent sans l'avoir choisi. Un logiciel écrit en cobol, dans les années 80, qui calcule encore vos taux d'intérêt bancaires. Un automate dans un hôpital dont le fabricant a disparu depuis 10 ans. Un programme dont le dernier développeur qui comprenait vraiment est parti à la retraite en 2011. Et attention, ces systèmes ne sont pas forcément mauvais. Bien au contraire, si Onoda a survécu 29 ans dans la jungle, c'est parce qu'il était extraordinairement compétent. Le cobol qui tourne dans les banques est d'une fiabilité qui ferait rougir bien des applications modernes. Si ces systèmes sont encore là, c'est précisément parce qu'ils marchent. Ils font exactement ce qu'on leur a demandé, sans jamais faillir, jour après jour, depuis des décennies. Le problème, c'est qu'ils vivent dans un monde qui n'existe plus. Car en 1944, l'ennemi d'Onoda, c'est l'armée américaine. En 1974, l'ennemi n'existe plus, mais Onoda, lui, continue de se battre contre lui. Et dans son obstination, il a tué une trentaine de villageois philippins, qui prenaient pour des soldats. Le système Legacy, lui, a été conçu pour un monde où les menaces étaient celles de son époque. Un monde sans internet généralisé, sans rançon judiciaire, sans groupe criminel organisé, capable de scanner la planète entière en quelques heures et à la recherche d'une porte mal fermée. Il se défend contre les ennemis de 1995 et il est aveugle à ceux de 2026. Alors me direz-vous, il suffit de les mettre à jour, de leur envoyer les fameux tracts qui disent que la guerre est finie. Et c'est là que l'histoire de Nozad devient vraiment instructive. Parce que les tracts ont été largués, les messages ont été envoyés, et ils ont tous été rejetés. Dans nos systèmes, c'est exactement pareil, pour trois raisons. La première, c'est que parfois l'éditeur du logiciel a tout simplement cessé de produire des mises à jour. On dit que les systèmes sont en fin de vie. Le majeur Tanikoshi a fermé sa boutique, en quelque sorte. Microsoft a arrêté de corriger Windows XP en 2014. Les failles découvertes après cette date resteront ouvertes à tout jamais. Et tout le monde le sait, y compris les attaquants.
Speaker #0La deuxième raison, c'est que même quand un correctif existe, on a peur de l'appliquer. Parce que le système est tellement ancien, tellement imbriqué dans tout le reste, que personne ne sait vraiment ce qui se passerait si on y touche. C'est comme si le gouvernement japonais s'était dit, si on va chercher Onoda, il risque de tirer. Mieux vaut le laisser dans la jungle. Et c'est souvent la décision qui est prise, année après année, par des gens parfaitement raisonnables. Le risque de casser quelque chose en modifiant paraît toujours plus concret et plus immédiat que le risque plus abstrait d'être attaqué un jour. La troisième raison, c'est la plus humaine. On ne sait même plus qu'il est là. Pendant des années, pour la plupart des japonais, Onoda était une rumeur, puis un oubli. Dans une grande organisation, il y a des serveurs que plus personne ne connaît, installés par quelqu'un qui est parti pour un projet qui n'existe plus et qui continue de tourner dans un coin du réseau parce que personne n'a jamais osé les éteindre. Et je vous rappellerai que nous avons déjà évoqué dans ce podcast, on ne peut pas protéger ceux qu'on ne connaît pas. Avant de parler des dégâts, je voudrais prendre un instant pour regarder ce risque comme le regarde un responsable de la sécurité. Parce que « c'est vieux, c'est donc dangereux » est une intuition, pas une analyse. Et une intuition, ça ne se présente pas devant un comité de direction. Dans mon métier, un risque, c'est toujours la rencontre de deux choses. La probabilité qu'un événement se produise et la gravité de ce qu'il provoque. Et le système Legacy a cette particularité assez rare de faire grimper les deux en même temps. Commençons par la probabilité. Quand une faille est découverte dans un logiciel moderne, l'éditeur publie un correctif et la fenêtre pendant laquelle l'attaquant peut... se ferment en quelques jours ou en quelques semaines. Pour le système Legacy, cette fenêtre ne se referme jamais. La faille est connue, elle est documentée, elle est publiée dans des catalogues que n'importe qui peut consulter et elle restera ouverte jusqu'à la fin des temps. Il existe même des listes tenues par des agences gouvernementales des failles que l'on sait activement exploiter en ce moment même. Pour un attaquant, c'est un menu. Il n'a pas besoin d'être brillant, il a besoin d'être patient et de savoir lire. Onoda, dans sa jungle, avait au moins l'avantage que personne ne savait exactement où il se cachait. Le système Legacy, lui, est repérable en quelques minutes par des outils automatiques qui balayent Internet en permanence à la recherche de versions obsolètes. Il n'est pas caché, il est simplement oublié. Et ce n'est pas du tout la même chose. Ensuite, les gravités. Et là, ils font comprendre une chose qui échappe souvent aux non-spécialistes. Le système Legacy n'est presque jamais la cible finale. Il est toujours la porte d'entrée. Un attaquant qui prend le contrôle d'un vieux serveur dans un coin du réseau ne s'y arrête pas. Il s'en sert comme d'une tête de pont pour aller plus loin, vers les systèmes qui comptent vraiment, vers les données, vers les sauvegardes. C'est ce qu'on appelle le mouvement latéral. Et ironiquement, ces vieux systèmes sont souvent très bien connectés, parce qu'à l'époque où on les a installés, on faisait confiance à tout ce qui se trouvait à l'intérieur de l'entreprise. Ils ont des mots de passe partagés, des comptes techniques tout puissants, des liaisons directes avec les bases de données centrales. Onoda n'était pas dangereux parce qu'il était seul dans la jungle. Il était dangereux parce qu'il savait où se trouvaient les villages et qu'il y descendait la nuit. Il y a une troisième dimension, moins visible, que j'appelle le risque de dépendance. Plus un système est ancien, plus il repose sur des ressources rares. Les quelques personnes qui le comprennent encore, le fournisseur, qui accepte encore de le maintenir à prix d'or, le matériel, que l'on ne fabrique plus et qu'on achète d'occasion. Chacune de ces dépendances est un point de fragilité unique. Le jour où la dernière personne qui comprenait le système part, ou tombe malade, ou refuse une mission de plus, l'organisation découvre qu'elle ne sait plus ni le réparer, ni le migrer, ni même l'éteindre proprement. Et c'est là que le risque opérationnel rejoint le risque de sécurité. Un système qu'on ne sait pas vraiment faire évoluer est un système qu'on ne sait plus défendre. Et puis, il y a le risque réglementaire, qui pour une banque ou un hôpital n'est pas un détail. Les régulateurs ont parfaitement compris le problème. Quand un auditeur ou un superviseur découvre un système en fin de vie qui traite des données sensibles, sans mesure de protection documentaire, documenté, il ne voit pas un vieux serveur. Il voit une défaillance de gouvernance. Il voit une organisation qui n'a pas à regarder ses propres patrimoines en face. Et les amendes qui suivent une fuite de données causée par un système non maintenu sont systématiquement plus lourdes parce Parce que les failles étaient connues, les correctifs existaient, ou le système aurait dû être isolé. Et rien n'a été fait. En droit comme en sécurité, savoir et ne pas agir est toujours plus grave que de ne pas savoir. Alors comment juge-t-on, concrètement, si un ONDA donné est acceptable ou non ? On se pose quatre questions simples. Que fait-il ? Et que se passerait-il s'il s'arrêtait demain ? Qui peut l'atteindre depuis l'extérieur, depuis l'intérieur ? Et par quel chemin ? Que contient-il ? À quoi d'intimider ? y l'accès ? Et enfin, qu'il connaît encore ? Ces quatre questions, posées honnêtement pour chaque système, permettent de classer vos soldats oubliés en trois catégories. Ceux qu'il faut relever d'urgence, ceux qu'on peut garder à condition de les isoler sérieusement, et ceux qu'on peut laisser tranquilles parce qu'ils ne mettent rien en danger. Et vous verrez que la troisième catégorie est beaucoup plus petite qu'on l'imagine. Laissez-moi vous donner quelques exemples réels de ce que ça coûte. Le plus C'est le mois de mai 2017 avec le Rendsongiciel. Un verre informatique qui se propage tout seul en exploitant une feuille Windows. Microsoft avait publié le correctif deux mois plus tôt. Mais le système de santé britannique, le NHS, faisait tourner des dizaines de milliers de postes sous des versions de Windows obsolètes et jamais mises à jour. Résultat, des hôpitaux paralysés, des opérations annulées, des ambulances détournées, des services d'urgence qui reviennent au papier et au crayon. Des onodades dans tous les couloirs qui se battaient avec des défenses d'un autre âge Merci. contre un ennemi qui n'existait pas quand on les avait installés. Deuxième exemple, moins connu mais tout aussi parlant. Décembre 2022, la compagnie aérienne SAS West aux Etats-Unis, une tempête hivernale, rien d'exceptionnel pour une compagnie aérienne. Sauf que le logiciel qui affecte les équipages au vol, un système vieux de plusieurs décennies, s'est retrouvé incapable de suivre les rythmes de changement. Les pilotes ne savaient plus où ils devaient être, les hôtesses attendaient des appels qui ne venaient pas. Plus de 16 000 vols annulés en une dizaine de jours. jours pendant que les concurrents eux avaient repris normalement ce n'était même pas une cyber attaque c'était simplement un soldat du 1944 à qui on demandait de faire la guerre de 2022 et puis il ya le printemps 2020 en pleine pandémie aux états unis les demandes d'allocations chômage explose et plusieurs états dont le new jersey découvre que leur système de traitement tourne en kobol, un langage que presque plus personne n'enseigne. Le gouvernement en est réduit à lancer un appel public à la télévision pour trouver des programmeurs cobalt volontaires, des retraités pour la plupart. On a dû littéralement chercher la majorité à Nogoshi dans sa librairie. Mais lequel plus instructif, je crois, c'est celui que montre l'autre face du problème, la banque britannique TSB, en avril 2018. Cette fois, on a décidé d'aller chercher Onoda. On a lancé une grande migration vers un système moderne. Et ça s'est très mal passé. Pendant des semaines, des clients ne pouvaient plus accéder à leurs comptes. D'autres voyaient les comptes de parfaits inconnus. Des centaines de millions de livres de pertes et d'amendes. Parce que sortir un soldat de la jungle après 30 ans, ça ne s'improvise pas non plus. Ça demande une préparation méticuleuse, une compréhension intime du terrain et un plan de retour en arrière si quelque chose tourne mal. Alors, que fait-on de nos onodas ? La réponse tient en quatre gestes et ils sont dans l'histoire elle-même. Le premier, c'est de savoir qu'il est là. Avant toute chose, il faut l'inventaire. Un recensement honnête et complet de tout ce qui tourne. Et avec chaque système, une simple question. Est-il encore maintenu par quelqu'un et si oui, jusqu'à quand ? Ce n'est pas un hasard si le règlement européen DORA, qui impose aux banques et aux assurances depuis janvier 2025, demande explicitement aux établissements d'identifier leur système legacy et d'en suivre le risque. Le régulateur a compris que la première faille, c'est l'ignorance. Le deuxième geste, c'est de décider. Une fois le soldat repéré, l'organisation doit choisir en conscience. Leur lève-t-on ? Leur remplace-t-on ? Ou l'acceptant-elle tel qu'il est ? Les trois réponses sont légitimes. Ce qu'il n'est pas, c'est de ne pas choisir, et de laisser la jungle décider à notre place. Un risque qu'on a regardé en face et accepté, en le documentant et en le faisant valider par la direction, est un risque géré. Un risque qu'on a oublié est une bombe à retardement. Et j'insiste sur un point. Accepter un risque, ce n'est pas signer un papier une fois pour toutes. C'est le mettre dans un registre, lui donner un propriétaire qui a un visage et vérifier à chaque échéance que les conditions qui rendent ce risque acceptable sont toujours vraies. Parce qu'un Onuda tolérable en 2020, isolé dans son coin, peut devenir intolérable en 2026 si entre-temps quelqu'un lui a ouvert une liaison vers Internet pour un projet de télémaintenance. Le risque n'est jamais figé, il faut aller le refoire dans sa jungle régulièrement. Le troisième geste, si on choisit de garder le système, c'est de protéger de l'extérieur, puisqu'on ne peut pas le protéger de l'intérieur. On appelle ça des mesures compensatoires. On l'isole dans un coin du réseau où très peu de choses peuvent l'atteindre. On place devant lui des filtres qui bloquent les attaques connues avant qu'elles n'arrivent. C'est ce qu'on appelle parfois le patch virtuel. On surveille de très près tout ce qui est entre et tout ce qui sort. En somme, on ne cherche pas à convaincre Onoda que la guerre est finie, on s'arrange pour qu'il ne puisse faire de mal à personne. Et le quatrième geste, C'est le plus important et le plus souvent négligé. Quand on décide enfin de le relever, il faut envoyer le majeur Tanagashi en personne. Autrement dit, préparer la migration avec le même soin qu'on aurait mis à concevoir le système au départ. Comprendre ce qu'il est vraiment, pas ce que dit la documentation d'il y a 20 ans. Tester, retester, prévoir le scénario où tout s'effondre et savoir comment revenir en arrière. TSB nous a montré ce qui arrive quand on envoie un simple tract à la place d'un commandant. Hiro Onoda est rentré au Japon en mars 1974, accueilli en héros par une foule immense. Il n'a jamais vraiment compris ce pays qu'il retrouvait, ce Japon pacifiste, prospère, qui n'avait plus rien de celui qu'il avait quitté. Il est mort en 2014 à 91 ans. Jusqu'au bout, il a affirmé qu'il n'a jamais fait que son devoir. Et c'est vrai, il a fait exactement ce qu'on lui avait demandé. Le drame, ce n'est pas lui. Le drame, c'est que pendant 29 ans... personne n'a pris la peine de venir lui dire que les ordres avaient changé. Dans votre organisation, il y a des onodas. Ils font leurs devoirs, fidèlement, selon les ordres de 1995. Ils ne demandent qu'une chose, que quelqu'un vienne, avec l'autorité et la préparation nécessaires, et leur dire que le monde a changé. La question n'est pas de savoir s'ils existent, la question, c'est de savoir si vous allez les chercher. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout, n'oubliez pas, pour certains, la cybersécurité est un enjeu de vieux de mort, c'est bien plus sérieux que ça.
