Où en est-on du Pearl Harbor numérique ?

MISC

n°

114

mars 2021

Par

Soria David

Sécurité organisationnelle

Tag(s)

Cybercriminalité

IoT

Emblème du marketing par la peur pour les uns, cygne noir pour les autres, cette appellation désigne l’éventualité d’une attaque informatique éclair contre un pays et qui serait paralysante pour son économie. Le terme fait couler de l’encre depuis au moins 20 ans [1] et nourrit moult fantasmes. Mais sont-ce des fantasmes ? D’aucuns diraient que si en 20 ans il ne s’est rien passé, c’est probablement qu’il y a eu un alarmisme exagéré.

1. Ont-ils crié au loup ?

En réalité, le premier Pearl Harbor numérique est déjà derrière nous.

Certains l’attribuent à [Stuxnet], ce « virus » très perfectionné qui s’est attaqué aux centrales nucléaires iraniennes entre 2008 et 2010. Le modus operandi était suffisamment discret pour pouvoir rester en place plusieurs années sans être détecté. L’administration Obama estimait que cette « cyber-arme » avait retardé d’au moins deux ans les progrès de l’Iran vers un nucléaire militaire.

Pour autant, on ne peut pas exactement parler de « paralysie » et encore moins « d’attaque éclair ».

Plus consensuellement, l’attaque [WannaCry] de 2017 est considérée comme le premier vrai Pearl Harbor. Elle a notamment paralysé l’informatique du service de santé britannique, obligeant de nombreux hôpitaux à décaler des opérations et occasionnant des pertes définitives de données.

Notons que plusieurs choses se sont correctement passées.

Les spécialistes ont commencé à avertir du risque d’un tel scénario 17 ans avant WannaCry, à une époque où l’informatique s’engouffrait dans de plus en plus de secteurs.

Des entreprises, positionnées sur les moyens pour s’en prémunir, ont émergé environ 15 ans avant WannaCry.

L’État a commencé à se préparer sérieusement à peu près au même moment (plan [Piranet]).

Les médias ont relayé les avertissements des experts environ 10 ans avant WannaCry.

En quelque sorte, il y avait de quoi voir venir.

Face à ce risque, seulement quelques entreprises s’étaient correctement préparées. Des entreprises pensaient être prêtes [TV5]. Beaucoup d’entreprises attendaient que ça arrive aux autres pour s’en occuper.

Il ne s’agit pas pour autant de leur jeter la pierre. En effet, dans une gestion rationnelle du risque, si vous me dites qu’un Pearl Harbor se produit tous les 10 ans et que, quand il advient, je perds 10 millions d’euros, je peux lisser le risque en considérant que je subis 1 million de dégâts par an. Toute solution qu'on me propose pour traiter ce risque, et qui coûte moins d’un million par an, est donc intéressante à implémenter.

Mais tant que le premier Pearl Harbor ne s’est pas produit, j’ignore s’il va advenir tous les 10 ans, tous les 20 ans ou tous les 50 ans et combien ça va me coûter. C’est ce que l’on nomme un [cygne noir].

2. À quoi ressemble le monde après Pearl Harbor ?

Le premier changement significatif est que la plupart des entreprises évaluent désormais leur sécurité (au travers d’audits, d’outils, de personnels dédiés, etc.).

La première mauvaise nouvelle est que les recommandations émises par ces évaluations ne sont majoritairement pas appliquées (et parfois pas applicables). Les sociétés amenées à auditer la sécurité d’un client plusieurs années consécutives peuvent témoigner d’un certain « air de famille » entre les rapports produits.

La faute à des technologies historiques difficiles à remplacer (adhérence logicielle), à l’instabilité des correctifs (il faut d’abord les tester sur un échantillon pour mesurer les effets de bord) et quelques autres facteurs.

Face à ces obstacles, nombre d’entreprises emploient la stratégie du best effort : s’occuper uniquement des « blockbusters » qui font l’actualité (Bluekeep, Zerologon...). Bien que peu glorieuse, cette approche donne des résultats significatifs. En effet, dans l’écosystème actuel, corriger 1% des vulnérabilités peut prémunir de 99% des attaques (qui sont automatisées et peu complexes).

Mais 1% des vulnérabilités c’est déjà beaucoup de travail et le 1% des attaques restantes c’est encore un beau volume.

Un autre changement majeur est l’évolution du marketing en cybersécurité de même, d’ailleurs, que le terme cybersécurité. Il y a 15 ans les éditeurs essayaient de vous convaincre qu’avec leur antivirus vous ne risquiez rien. Aujourd’hui, ils essayent de vous convaincre qu’avec leur SIEM vous ne risquez rien (ou avec leur VPN si vous êtes un particulier).

De ce fait, de plus en plus d’entreprises possèdent désormais des capacités de détection, ce qui est positif, mais y investissent exagérément leur budget et leur temps. Or ce sujet n’est qu’une strate de protection (palliative qui plus est) parmi d’autres aussi importantes.

Prenons le cas d’un e-mail contenant une pièce jointe malveillante :

Il va d’abord rencontrer l’antispam. Parfois, il passera à travers.
Il arrive sur le poste de l’utilisateur et rencontre l’antivirus. Parfois, il passera à travers.
Il est maintenant en face de la vigilance de l’utilisateur (le fameux facteur humain). Parfois, il passera à travers.
Il s’exécute maintenant sur le poste. « Parfois », il profitera d’un manque de mises à jour ou d’un utilisateur ayant des droits d’administrateur, ou bien il utilisera une 0day, et il prendra le contrôle de la machine.
Il cherche désormais à se répandre dans le réseau. Parfois, la segmentation et l’étanchéité ne seront pas correctement configurées (ou bien il profitera d’une 0day sur un pare-feu ou un commutateur) et il pourra affecter des actifs plus sensibles que celui duquel il part.
Pendant qu’il fait son œuvre, les sondes et le SIEM mettront un certain temps à le détecter et les analystes mettront aussi un certain temps à confirmer l’attaque. Dans le meilleur des cas, ça prendra quelques minutes, si l’on n’a vraiment rien, ça prendra des mois. Plus il a de temps devant lui, plus le maliciel peut faire de dégâts.
Une fois qu’il a été détecté et éradiqué, il faut réparer ses dégâts. Si le système de sauvegarde est complet et agile, la restauration ne prendra que quelques heures. Si la sauvegarde n’a pas été bien pensée, ce sera plus douloureux (serveur de sauvegarde lui-même chiffré par un rançongiciel, dossiers locaux non sauvegardés, etc.).

Le principe de la défense en profondeur c’est qu’il est très peu probable que tout se passe mal en même temps. Donc, si l’on a investi raisonnablement dans chaque strate de sécurité, on a de bonnes chances de contrer le maliciel.

En revanche, si l’on a succombé aux sirènes du SIEM et mis tous ses moyens en priorité dessus, on risque de se retrouver avec un tas de cendres à la place du SI et de dire « oui, mais je sais exactement d’où c’est arrivé, comment c’est arrivé et jusqu’où c’est arrivé »...

Notons que cette vision globale, des strates de défense en profondeur, est aussi l’occasion de dépasser l’éternel poncif « la plus grosse faille c’est le facteur humain ». Premièrement, toutes les failles sont humaines (les programmes sont codés par des humains). Deuxièmement, la vigilance des utilisateurs est une strate comme les autres, il n’y a pas de raison de l’accuser de tous les maux quand il y a eu un problème, car ce n’est pas la seule à avoir failli.

Un troisième changement est l’explosion de l’Infrastructure as a Service (IaaS) : AWS, Azure et autres qui promettent de vous soulager des tâches de MCO/MCS réseau et système pour ne vous concentrer que sur les applications.

Dans les faits, personne ne migre complètement en cloud et donc tout le monde se retrouve à gérer une infrastructure hybride avec plus de couches d’abstraction qu’avant : au lieu d’installer une appli dans une VM, je vais déployer une image Docker avec Kubernetes, installé via Ansible, déployé via Terraform qui est lui-même installé sur une VM.

Qui dit nouvelles couches, dit nouveaux outils et sujets à maîtriser : scanners d’images Docker (qui souvent loupent les paquets en standalone), permissions des containers (souvent lancés en root et sans segmentation inter-container), etc.

Le mille-feuille numérique a gagné quelques étages et le nombre d’angles morts a augmenté.

Peut-être n’est-ce que le prix à payer d’un temps de transition vers une informatique unifiée et scalable, peuplée de DevOps. Mais quelques éléments font douter que cette transition soit pour demain.

Premièrement, le Cloud mutualisé s’accouple mal avec la souveraineté des données. Tant qu’aucun vrai modèle Zero Knowledge n’existe [ZK], vous êtes condamnés à devoir accorder une confiance quasi aveugle au fournisseur, quant au fait qu’il n’ira pas fouiller dans vos données.

Deuxièmement, les solutions IaaS ressemblent de plus en plus à des SPOF (Single Point Of Failure). Si demain AWS tombe ou se fait hacker, pas mal d’entreprises se retrouveront à l’âge de pierre. Il est vrai qu’Amazon est certainement plus compétent en sécurité que n’importe quelle autre entreprise, dans la mesure où c’est leur cœur de métier de ne pas se faire hacker. Mais ils sont devenus une cible tellement attrayante que ça arrivera forcément un jour.

Les acteurs, qui s’engouffrent actuellement dans le concept à la mode du Zero Trust, où « aucune brique n’accorde une confiance aveugle à une autre », proposent souvent des architectures en cloud mutualisé… pour lesquelles, justement, il faut accorder une confiance aveugle au fournisseur.

Dernier changement que nous mentionnerons : l’aspect légal, normatif et réglementaire a également suivi le pas. Le RGPD a été mis en place. Les grands industriels sont plus regardants avec leurs sous-traitants. L’État produit des référentiels pour le privé et du service pour les acteurs essentiels.

Ceci a aussi produit un nouveau type d’humour avec les prestations du type « Mettez-vous en conformité avec le RGPD ».

Sans avoir à les auditer, je peux vous donner le nombre d’entreprises conformes au RGPD : 0.

Pour l’être il faudrait, a minima, pouvoir répondre à ces trois problématiques :

Pour une donnée, lister tous les endroits où elle se trouve.
Pour une donnée, lister toutes les personnes qui y accèdent.
Pour une personne, lister toutes les données auxquelles elle accède.

Cela semble être le b.a.-ba et pourtant, aujourd’hui, on est à des lieux de pouvoir y répondre avec l’outillage existant (ceux qui ont déjà fait de l’audit de permissions en milieu Windows le savent) dans des frais raisonnables. Les objectifs sont pertinents, mais les ruptures technologiques qui permettraient de les atteindre se font attendre.

Est-ce à dire que rien ne s’est amélioré ? Les anciens problèmes existent toujours… mais en moins grand nombre… mais de nouveaux sont apparus. Toujours est-il que suffisamment d’éléments existent pour que le nicolasruffisme (« la sécurité est un échec ») ait de nombreux adeptes.

3. Le prochain Pearl Harbor

Ce qui a permis à WannaCry d’advenir n’a donc pas disparu. Quand le prochain événement de ce type se produira-t-il ? En toute vraisemblance, la fréquence va augmenter (donc un prochain avant 2030).

D’une part, l’informatique continue de gérer de plus en plus d’aspects de notre vie (villes connectées, santé, prises de décisions…).

D’autre part, on découvre de nouvelles vulnérabilités plus vite qu’on ne les corrige.

Ce qui nous amène au point principal de cet article : contrairement à ce que le grand public semble croire, l’absence actuelle de catastrophe numérique tient moins au bon niveau de sécurité de nos infrastructures qu’à une question d’alignement des planètes.

Il y a des acteurs qui ont les compétences, les moyens et l’occasion pour en provoquer une, mais pas l’intention (les États-Unis par exemple).

Il y a des acteurs qui ont les moyens, l’occasion et la volonté d’en provoquer une, mais pas les compétences (certaines organisations terroristes par exemple).

Il y a des acteurs qui ont les compétences, les moyens et la volonté d’en provoquer une, mais pas l’occasion (des hacktivistes par exemple).

Dès demain, on pourrait imaginer que les États-Unis bloquent tous les postes Windows de la Chine pour faire pression dans un conflit diplomatique (évidemment c’est le genre de moyen de pression qu’on n’utilise qu’une seule fois puisqu’après ça Microsoft n’est plus près de vendre des machines en Chine).

Dès demain, on pourrait imaginer qu’une organisation terroriste recrute un type calé en informatique industrielle, qui dérègle une centrale nucléaire, qui ouvre un barrage ou qui, par exemple, pousse quelques satellites à se rentrer dedans, jusqu’à provoquer une réaction en chaîne qui annihile tout ce qui orbite autour de la Terre (cf. Gravity).

Dès demain, on pourrait imaginer un groupe d’hacktivistes qui arrive à se faire embaucher dans une banque « systémique » et qui profite de cet accès privilégié aux réseaux sensibles pour provoquer une crise financière mondiale (cf. Mr ROBOT).

Si rien d’important n’a craqué jusqu’ici, c’est en bonne partie, car ceux qui pourraient mettre à genoux les éléments cruciaux ne sont pas ceux motivés pour le faire.

Symétriquement, certains éléments cruciaux sont peu protégés, en bonne partie, car personne ne les a encore attaqués. Je ne donnerai pas d’exemple ici afin de ne pas inspirer quelque mauvais bougre.

Or, comme les connaissances se propagent de plus en plus vite, il n’est pas raisonnable de parier sur l’immuabilité de cette situation.

Voilà pour la fréquence. Qu’en est-il de la sévérité ?

Vu que tout est de plus en plus interconnecté, ne risque-t-on pas de passer d’événements de type « Pearl Harbor » à une sorte d’« Armageddon numérique » : une attaque paralysant le monde entier ?

La réponse est incertaine (décidément). Les interconnexions de plus en plus nombreuses, et l’immixtion de l’informatique dans toujours plus de domaines, étendent le nombre de portes d’entrée et l’étendue de ce qui sera affecté.

Mais d’un autre côté, l’hétérogénéité des technologies, et la complexification du monde numérique, multiplient les compétences que devrait avoir un adversaire pour avoir un impact généralisé. Le CV qu’il faudrait pour tout faire tomber, de la banque à la ville connectée, provoquerait des afflux sanguins titanesques chez nos recruteurs LinkedIn. Le résultat est donc que les attaques d’envergure mobilisent de plus en plus des équipes plutôt que des loups solitaires.

Même si un retour complet à l’âge de pierre semble donc improbable, il n’en demeure pas moins que l’on peut mettre un pays à genoux en ne ciblant qu’un seul élément de son infrastructure. Imaginez Paris, un seul jour, sans électricité ou sans métro ou avec des feux rouges désynchronisés ou, pire, avec des caisses qui refusent les transactions tant que le client n’a pas dit bonjour… ce serait l’anomie.

Or chacun de ces points névralgiques est à la fois assez gros pour ne pas être exempt de vulnérabilités et assez homogène pour qu’un seul homme ait les compétences nécessaires à le saborder.

4. Face à cela que faire ?

Miser uniquement sur la robustesse (entendez : empêcher les adversaires de pénétrer nos réseaux) est actuellement illusoire pour les raisons que nous avons développées. Il faut privilégier la résilience (être capable de récupérer rapidement).

Toute entreprise mature possède un Plan de Continuité d’Activité (PCA) et un Plan de Reprise d’Activité (PRA) qui sont des protocoles à dérouler pour supporter un sinistre informatique puis retourner à une situation nominale.

L’avantage d’un PCA/PRA est que la démarche pour le mettre en œuvre nécessite de passer par des étapes comme la cartographie des actifs (et de leur criticité), des menaces, des risques, etc. Autant de choses qui sont utiles pour bien d’autres champs de la sécurité (préventifs et palliatifs).

Si vous n’avez pas de PCA/PRA, mettez-en un en place. Si vous en avez un, testez-le de temps en temps et évitez qu’il ne s’appuie sur des ressources potentiellement indisponibles si l’événement est national, voire mondial (produits d’importation, lignes téléphoniques, etc.).

Comment faire maintenant pour diminuer la survenance des Pearl Harbor numériques ? Demander aux utilisateurs de changer leur mot de passe tous les 6 mois ne vous sauvera pas (passer de Yolo2k18! à Yolo2k19! ou de Welcome03 à Welcome04 n'est pas « game changing »). La problématique ne se résume pas à quelques rustines piochées dans la rubrique informatique de la matinale de votre radio préférée, il s’agit plutôt de voir comment se dépatouiller avec un colosse aux pieds d’argile.

C’est une vaste question qui n’a pas encore de réponse consensuelle parmi les experts. Nous nous contenterons de cinq pistes de réflexion.

4.1 Renoncer à avoir des chaussettes connectées

On entend partout parler de « l’explosion de l’IoT », mais il semble qu’il y ait une part d’astroturfing [2] là-dedans. La plupart des gens conçoivent, heureusement, qu’« innovation » n’est pas exactement le bon terme pour qualifier une bouilloire connectée.

Bien que ce discours puisse paraître trop « boomer », anti innovation et autres, limiter ce qui est connecté limitera ce qui sera affecté en cas d’attaque grave. Donc il serait sage de ne pas absolument tout connecter juste, car « on peut le faire ».

De plus, l’IoT peut ressembler à une régression lorsqu’il s’applique à certains sujets. Prenons une serrure connectée. Qu’est-ce qui arrive le plus souvent : perdre des clés physiques ou se retrouver à cours de batterie sur votre portable (qui sert de clé) ? Quiconque sait crocheter une serrure physique devra quand même y passer un certain temps quand il sera en face de la vôtre. Mais quiconque sait pirater une serrure connectée donnée pourra automatiser l’attaque et revendre un outil permettant de l’ouvrir instantanément.

L’actualité a montré un exemple saisissant de cette limite du raisonnable avec des portes connectées inutilisables lors d’une panne AWS [Panne].

4.2 Mettre un peu de « biodiversité » dans le numérique

Lorsqu’un acteur a le monopole d’un segment technologique, chaque fois qu’une vulnérabilité critique affecte son produit, c’est le monde entier qui est sur la sellette.

Si chaque pays essayait de développer au moins un acteur dans chaque grand domaine (matériel, système, réseau, hébergement), cela diminuerait la possibilité, pour une seule vulnérabilité, d’avoir un impact planétaire.

L’idée n’est pas tellement d’aboutir à ce que chaque entreprise d’un pays utilise l’OS souverain, le constructeur de PC souverain, l’hébergeur souverain, etc. Ni même de pousser les entreprises à complexifier leur SI avec de multiples constructeurs. Mais qu’au moins on évite qu’il n’y ait qu’un seul constructeur sur étagère. Ces positions de quasi-monopole sont délétères pour la sécurité (avec des entreprises qui émettent des standards non sécurisés, non documentés et que, parfois, elles ne suivent pas elles-mêmes).

De cette manière, connaître sur le bout des doigts le fonctionnement d’un routeur Pisco ou d’un OS Doors, et y trouver une vulnérabilité, ne serait plus suffisant pour attaquer 99,99 % des entreprises.

4.3 Réinvestir du budget en cartographie informatique

On ne maîtrise pas ce qu’on ne connaît pas. Une entreprise qui n’a pas de moyen d’inventaire performant s’expose à des attaques depuis cet angle mort [Shadow IT].

La plupart des entreprises ont souvent des moyens minimaux en termes de cartographie. La vraie difficulté pour un outil d’inventaire est triple :

qu’il soit unique et centralisé ;
qu’il soit à jour ;
qu’il soit exhaustif.

Or il semble que ce soit une sorte de triangle d’incompatibilité. Mettez en place un outil assez riche pour que toutes les infos, utiles au service achat comme au service réseau, s’y trouvent et probablement que ce sera un enfer à maintenir à jour. Faites un outil qui se met à jour semi-automatiquement et vous aurez des données incomplètes, etc.

Mais il faut essayer quand même.

L’idée générale serait qu’en quelques minutes (deux ou trois requêtes sur l’outil) vous puissiez sortir une liste lorsque quelqu’un vous demande :

Est-ce que des machines chez nous utilisent le programme X ?
Quels sont les utilisateurs de l’application Y ?
Est-ce qu’on a des routeurs Z dans notre parc et où sont-ils ?

4.4 Sécuriser « by design »

Arrêter l’hémorragie en limitant la commercialisation d’outils informatiques dont la sécurité n’a pas été auditée, tout comme on ne commercialise pas de voiture qui n’a pas passé les contrôles de sécurité.

Au moins pour les produits et logiciels payants, ce devrait être incontournable. Aujourd’hui, on paye parfois des fortunes pour des outils qui, indirectement, nous font perdre d’autres fortunes, car ils sont truffés de vulnérabilités.

Sans parler des cordonniers mal chaussés que sont les produits de sécurité (antivirus et autres) : quand ils sont eux-mêmes des sources de vulnérabilités [F5] alors qu’ils sont censés nous en prémunir…

Cette idée peut paraître rebutante, car elle semble aller à l’encontre de certains aspects positifs, comme les logiciels gratuits ou le fait que n’importe qui puisse créer une application depuis sa chambre, avec trois bouts de ficelle, et toucher des millions d’individus.

Mais gardons à l’esprit qu’il faudra déjà de nombreuses années pour éliminer les vulnérabilités dans nos réseaux, or, si on en rajoute chaque année plus qu’on en corrige…

4.5 Rendre la sécurité « simple »

Favoriser des architectures informatiques où les opérations importantes sont simples.

Combien de vulnérabilités existent dans nos réseaux, car « l’application du patch a été testée sur 60 machines, mais ça a fait bugger 15 d’entre elles, du coup on attend pour l’appliquer aux 2000 postes du parc », ou encore « on ne met pas à jour l’Active Directory, car l’application X ne marche qu’avec la version 2003 et le fournisseur n’a pas produit de version plus récente ».

Alors, oui, c’est mal fait et les fournisseurs pourraient quand même se débrouiller pour que leurs produits puissent être utilisés dans la durée sans créer plus de problèmes qu’ils n’en solutionnent. Mais un peu d’autocritique ne fait pas de mal non plus. « Dieu se rit de ceux qui déplorent les conséquences dont ils chérissent les causes », ou comme le disait Coluche « quand on pense qu’il suffirait que les gens n’achètent pas pour que ça ne se vende pas ».

Cela fait 10 ans que le problème de « l’adhérence logicielle » est clairement identifié et subi par toutes les entreprises. Peut-être faudrait-il penser à arrêter d’acheter des produits qui ne sont pas maintenables, même s’ils sont dans le Gartner. Peut-être faudrait-il que tous les cahiers des charges incluent des exigences sur le maintien en conditions de sécurité (MCS).

Ces dernières années, les paradigmes se multiplient et certains proposent des améliorations sensibles de ce point de vue.

Les applications web (internes ou en SaaS) permettent de n’avoir qu’une seule machine à mettre à jour, plutôt que de passer sur chaque poste. Les infrastructures avec clients légers mutualisent aussi l’effort de patch.

Enfin, garder en tête que la solution à un problème n’est pas toujours de rajouter un outil. À force d’empiler les couches d’outillage, on perd en productivité, en visibilité et en maintenabilité.

Les SI profiteraient d’avoir des campagnes, une fois tous les 3 ans par exemple, où l’on ne fasse aucun nouvel achat et où, à la place, on fasse la chasse à tout ce qui est inutile, superflu ou qui produit plus de problèmes qu’il n’en résout. En quelque sorte : « dégagez les oreilles et la nuque » afin d’éclaircir la visibilité sur le SI, de récupérer du budget pour des choses plus utiles, etc.

« La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. » (Saint-Exupéry)

Conclusion

Toute prospective est par essence périlleuse. Peut-être ai-je raison. Ou peut-être qu’en 2030 la blockchain et l’ordinateur quantique nous auront sauvés de tous ces périls. La vérité est probablement entre ces deux extrêmes… (en fait non, j’ai juste raison, mais c’est pas classe comme conclusion).