Le début du troisième confinement a été marqué par la panne des systèmes informatiques de téléenseignement . Aussitôt, le ministre de l’Éducation a déclaré que cette interruption de service était due à une cyberattaque (probablement russe, est-il précisé, on ne prête qu’aux riches) mais aussi à un prestataire français d’infonuagique (cloud) dont un entrepôt de données à brûlé il y a quinze jours. Sachant que ledit prestataire n’a pas de contrat avec l’Éducation nationale et qu’on s’interroge sur les motifs éventuels d’une attaque par déni de service (DDOS) du téléenseignement français par les Russes. Et qu’une simple surcharge de demandes de connexion n’est pas forcément organisée par un agent étranger, mais tout simplement explicable par des serveurs pas assez puissants pour supporter la charge.

Cette petite actualité pour rappeler que l’explication de la cyberattaque est toujours à relativiser. Ce que nous explique brillamment François Narolle, ancien officier de marine et observateur avisé du domaine, à la suite du blocage de Suez par un cargo en travers (cf. LV 164). Merci à lui. LV

« Ce n’est jamais un lupus » (Hugh Laurie dans House). Crédit photo

Dans la série du médecin éponyme, le Dr House répète à qui veut bien l’entendre que « ce n’est jamais un lupus ». Malgré cette répétition, les membres de son équipe tentent systématiquement de le convaincre qu’ils tiennent enfin leur cas rare, lequel ne rentre immédiatement dans aucune autre case. De la même manière depuis quelques années, à chaque fois qu’un avion tombe, qu’un incendie se déclare ou, dans le cas qui est le nôtre aujourd’hui, qu’un navire coupe une artère vitale du commerce mondial aussi facilement qu’une vanne quart-de-tour interrompt l’écoulement de l’eau dans un tuyau, on trouve immanquablement de nombreux commentateurs pour se demander si un tel accident n’est pas plutôt la conséquence d’une cyberattaque.

Une petite séance de diagnostic différentiel s’impose, donc. Spoiler alert: ce n’est jamais une cyberattaque.

Dans son désormais célèbre discours du 18 janvier 2019, la ministre des armées Florence Parly l’annonçait sur un ton martial : « La guerre cyber a commencé et la France doit être prête à y combattre ». Et de préciser « Si des attaques ont pu porter atteinte à des infrastructures physiques, en Ukraine ou en Iran, elles n’ont pas encore réussi à provoquer des dommages massifs et durables à des économies et à des sociétés. Mais ce n’est sans doute qu’une question de temps ». La France dévoilait alors sa nouvelle organisation pour créer des dégâts, y compris matériels, à partir d’attaques informatiques.

Même si les exemples d’attaques de ce type ayant réussi sont extrêmement rares dans le monde, l’arme cyber est en passe de devenir auprès du grand public la nouvelle arme magique. Et ce même public de lui attribuer tous les faits inexpliqués (même si ces faits se sont produits seulement quelques heures auparavant), comme on aurait pu soupçonner naguère les espions soviétiques ou les ovnis. Seulement voilà, ce n’est jamais une attaque cyber.

Petit manuel de cyberattaque à l’usage des hackers débutants :

On l’a vu, jusque dans les discours officiels, faire des dégâts matériels par le truchement de la « lutte informatique offensive » (LIO), comme les armées françaises appellent les cyberattaques, c’est possible. Vous aussi dans votre garage, devenez donc cyber-combattant. Pour vous aider, voici la recette :

D’abord, il vous faut un méchant. Un ennemi. Un adversaire, au moins. Et comme tout ennemi, il vous faut le connaître le plus parfaitement possible. Comme vous lui voulez du mal, vous allez essayer de neutraliser ses capacités principales, de frapper un grand coup. Bref, vous allez vouloir cibler son centre de gravité. Mais c’est quoi, son centre de gravité ?

Et vous voici lancé dans un processus de renseignement qui peut être long. Vous allez observer votre ennemi. Que fait-il, dit-il, quels sont les acteurs qui le composent, les relations entre eux, leurs habitudes. Quels sont ses infrastructures, ses moyens, etc. Quels sont les systèmes qu’il utilise pour faire marcher tout ça … Au fur et à mesure de votre collecte, vous allez remettre en cause vos propres observations. « Ce que je vois est-il vraiment ce qui se passe, ou n’est-ce qu’un rideau de fumée créé pour brouiller ma compréhension ? ». Vous allez aussi devoir vous poser des questions douloureuses : « l’information que j’ai eue tant de mal à avoir au début de mes recherches et sur laquelle je base toute mon analyse est-elle encore vraie le jour où j’ai fini celle-ci ? ». Si, sans mauvaise foi, la réponse à cette question n’est pas « oui », alors vous pouvez soigneusement tout brûler dans votre cheminée et recommencer.

Mais vous êtes brillant et méthodique et voici que vous avez compris votre ennemi, ses systèmes, ses sous-systèmes. Vous pouvez même avoir procédé pareillement pour les éléments qui l’entourent : son environnement physique, la géographie et le climat des zones où il opère, ses autres ennemis, ses partenaires, la population au sein de laquelle il vit … Vous avez maintenant votre dossier de compréhension de l’environnement opérationnel qui sera le vôtre, ainsi que votre analyse de « systèmes de systèmes ». De cette étude poussée, vous avez identifié un point, vital pour votre ennemi : son centre de gravité. Par exemple « si cette centrale électrique ne fonctionne plus, l’ennemi sera durablement entravé dans sa capacité d’action, dans ses sources de revenus et sera rapidement privé du soutien de sa population ». Voici votre cible.

Ça ne fait que commencer !

Il est maintenant temps de préparer un dossier de ciblage.

Avant de se demander comment frapper, peut-être faut-il vous demander si vous voulez vraiment le faire. Cette cible est-elle protégée par le droit des conflits armés ? Votre morale réprouve-t-elle de la frapper ? Puisque vous n’agissez pas tout seul, vos supérieurs accepteront-ils de cibler cet élément ? Oui ? Passons à la préparation de votre attaque proprement dite.

Prenez une carte ou un plan de votre infrastructure. Vous l’avez étudiée et vous en connaissez donc les failles. Il ne reste plus qu’à savoir comment les exploiter, en cohérence avec vos moyens. On bombarde ? On coupe l’arrivée des pièces détachées par un blocus ? On corrompt le personnel ? On envoie un commando pour saboter l’élément clef ? On lance une opération terrestre avec chars et canons pour occuper le terrain ? On manipule l’opinion de la population pour qu’elle se révolte contre votre ennemi et prenne d’assaut votre cible pour vous ? Mais vous insistez : votre truc, c’est le cyber. Soit.

Hackons donc !

Vos informations mentionnent les différents systèmes informatisés utilisés dans votre infrastructure cible. Vous avez compris que l’ensemble du mécanisme fonctionne grâce à des baies informatiques qui ont besoin de refroidissement dans ce pays chaud. Que la température monte, et les ordinateurs ne fonctionneront plus. Or vous savez aussi que la climatisation est gérée par un calculateur industriel qui contrôle la température et ajuste la climatisation en fonction dans la pièce des serveurs. Vous avez votre méthode : vous allez vous introduire dans ce système et envoyer au calculateur une fausse indication à la place de la sonde de température : il fera trop froid et la climatisation enverra du chauffage dans la pièce. Les ordinateurs chaufferont, jusqu’à être inutilisables. Avec un peu de chance, il y aura même un incendie. Il faudra remplacer tous ces serveurs, mais ça tombe bien : le seul fournisseur compatible est une entreprise de votre région et le patron vous devait un petit service. Les équipements mettront un certain temps à arriver. Victoire.

Enfin presque. Il reste encore du boulot.

D’abord, préparer l’arme.

Qui dit système informatique dit code. Admettons que vous vous trouviez dans le système de contrôle de la climatisation, que voudriez-vous y écrire ? Il vous faut donc un codeur. Votre code est écrit ? Vous préférez passer par une attaque saturante (DoS) ? Vous préférez ouvrir une porte pour pouvoir prendre le contrôle à distance ? Parfait. Comment savoir si ça fonctionnera ?

C’est là qu’on rentre dans le « dur ». Alors que vous avez déjà consacré pas mal de moyens à toute cette planification, vous êtes prêt à tester votre arme. Comme au pas de tir, il vous faut un mannequin, ou au moins quelque chose qui fonctionne avec le même système, exactement, que votre cible. Et là, peu d’autres options que d’aller voir le vendeur de l’équipement et de sortir son chéquier. Selon l’équipement visé, ça peut coûter cher. Surtout si vous voulez aussi tester l’ensemble des conséquences matérielles que vous souhaitez engendrer. Que se passe-t-il si, en fait, la clim ne chauffe pas assez pour gêner le fonctionnement des ordinateurs ? Et s’il suffit d’ouvrir une fenêtre ? La saison chaude est sur le point de terminer d’ailleurs (ça aussi vous l’avez étudié) : dépêchons-nous.

Il nous faut un lance-cyberpatate !

Comme la pierre ne va pas loin sans catapulte, le boulet sans canon et l’ogive nucléaire sans missile, votre code ne risque pas de se retrouver dans le calculateur visé de votre infrastructure cible sans un petit coup de main. Pas de chance, ce système industriel n’est pas encore dans le grand monde de l’internet des objets, car le gérant de l’infrastructure n’a pas souhaité déléguer la planification de sa maintenance préventive au fournisseur. Qu’à cela ne tienne, on va procéder autrement. Bien sûr, à ce stade, si on peut convaincre ou contraindre un employé de la centrale, un agent de nettoyage, un stagiaire ou un visiteur de brancher une petite clef USB sur le bon ordinateur, on gagne un temps fou. On peut aussi y aller nous-même. On se fait embaucher, ou on se présente avec le polo siglé de la marque du fabricant, l’air calme et assuré. « Je viens pour la mise à jour. Comment ça ? Ils ne vous ont pas prévenu ? C’est surprenant. Je repasserai plus tard, tant pis. M’enfin c’est dommage pour vous, parce que c’est une mise à jour de sécurité ultra importante et ça m’embête de laisser votre système si vulnérable pendant un mois ou deux, surtout par les temps qui courent. Comment ? Vous êtes d’accord ? Vous préférez aujourd’hui ? Bon, mais c’est parce que c’est vous alors ». Bon, je vous laisse broder un peu, en fonction de vos talents d’acteur et des us locaux.

Mais aller aussi près de votre ennemi, c’est un peu dangereux. Et si, à la place, vous envoyiez un email indiquant une réduction, un cadeau, une surprise, avec un lien à cliquer ? Là, le personnel de la centrale clique, tombe sur un site factice et télécharge votre virus sans s’en rendre compte. Avec un peu de chance, il passera d’ordinateur en ordinateur, jusqu’à arriver un jour grâce à une clef USB dans le serveur qui gère l’automate de climatisation. Plus large encore ? Et si vous laissiez un virus sur internet, contaminant discrètement la planète entière sans faire le moindre mal, pour passer sous les écrans radars des anti-virus, puis ne s’active qu’une fois qu’il aura repéré être dans le bon système hôte ? Ça peut être plus long, mais pourquoi pas.

Vous avez votre arme, vous l’avez testée, elle marche. Vous avez votre vecteur, que vous avez pu lui aussi tester pour en mesurer le succès et votre préparation a payé là-encore : ça marche. Vous avez même simulé l’introduction de votre arme par votre vecteur puis sa dissémination dans des sous-systèmes et l’ensemble intégré réussi encore à atteindre sa cible et produire les effets escomptés.

Alors, on lance l’attaque ?

Non. Pas encore. Un peu de patience. Avant de proposer à vos supérieurs hiérarchiques de valider l’ensemble de l’attaque, il y a de nouvelles questions à se poser.

Une fois votre attaque lancée, votre code va se répandre un peu partout au sein de votre cible. Selon le vecteur que vous avez choisi, d’autres systèmes seront contaminés (au préalable, si le code cherche lui-même sa cible, ou en utilisant les mêmes fuites qui lui ont permis d’entrer). Êtes-vous prêt, ainsi que vos alliés et partenaires et la population que vous souhaitez protéger, à résister à votre propre attaque ? Vous êtes-vous assuré que si elle fonctionnait sur votre système cible, elle ne fonctionnerait pas également sur d’autres systèmes, notamment les vôtres ? Êtes-vous prêt à dévoiler vos compétences ? En analysant l’attaque, ne risquez-vous pas de fournir à votre ennemi le mode d’emploi pour fabriquer ce type d’armes ? Est-ce que votre façon d’agir, votre code, signera votre identité ? Êtes-vous prêt à assumer l’attribution de cette attaque par votre ennemi, et les conséquences qui en découleraient ? Avez-vous au moins préparé votre sécurité, votre communication pour publier un communiqué au bon moment ? Une revendication ? Et puisqu’on parle de synchronisation des effets, avez-vous organisé vos autres mouvements politiques, diplomatiques, militaires, pour qu’ils soient parfaitement prêt à transformer votre pupitre en une véritable symphonie ? À n’en pas douter, écrire la partition et diriger ce grand orchestre vous aura pris un peu de temps aussi. Sans compter qu’en cours de route, l’attaque peut prendre un peu plus ou un peu moins de temps. Il faudra donner des top-départ, et parfois retenir vos actions, voire les replanifier rapidement.

L’heure de la réunion a sonné.

Votre attaque est prête. Vous avez préparé le scénario, les comportements à avoir en cas de problème, vous avez pesé les risques, mesuré votre intérêt à agir, remis à jour votre renseignement. Vous avez préparé les opérations à déclencher pour exploiter votre cyberattaque une fois réussie. D’ailleurs, vous avez déployé différents capteurs qui vous permettront de savoir si cette attaque est réussie, si la perturbation du système est complète et si finalement votre ennemi est bien neutralisé. Aux opérateurs qui dirigent cette veille, vous avez donné les consignes et les seuils qui permettent de mesurer les effets. Ils ont d’ailleurs eu le temps de se « faire l’œil » sur la situation normale et devraient être capables maintenant de repérer immédiatement les réactions prévues ou imprévues suite à votre attaque. Quelques citernes de café, trois batailles de Nerf et deux nuits sur Powerpoint plus tard, vous êtes prêt. À lancer l’attaque ? Non. Patience, ai-je dit. D’abord, la salle de réunion, votre siège, en bout de table. Les dirigeants de votre organisation arrivent en retard, l’air livide … ils viennent visiblement d’apprendre des mauvaises nouvelles. Le boss, lui, n’arrive pas. Son aide de camp vient vous voir, alors que votre créneau prévu d’une heure de réunion est déjà bien entamé. Il vous apprend que finalement, il aura « un peu » de retard, et qu’il faudra faire en 10 minutes, max.

Il arrive. Le voilà. Vous vous levez. Un de vos collègues présente la réunion. Vous vous rendez compte que, le nez dans le guidon depuis des mois déjà, vous n’êtes pas le seul à préparer des attaques dans cette guerre. On parle de météo, du grand commandement suprême qui a demandé en urgence de lui envoyer un rapport sur l’utilisation des cartes de fidélité de la station essence et sur les frais de déplacement. Vous, vous êtes liquide. C’est la première fois que vous allez parler au grand chef, vous êtes en retard, il est de mauvaise humeur, il a une mauvaise réputation, votre carrière en dépend et il y a 60 personnes dans la salle. C’est à vous. Feu.

F2T2EA.

Le grand chef est plutôt du genre à envoyer deux patrouilles de bombardiers et nitrater la zone. Au moins, quand la poussière retombe, que leur logiciel fonctionne ou pas importe moins, qu’il dit. Certes. Mais comme vous êtes un brillant acteur et que votre maladresse de jeunesse l’a attendri, le boss a dit oui. OK pour votre truc du mode d’action doux et mignon, là. Il a même dit qu’il allait l’appeler « opération chatons ». Autant dire que ça s’est vite su parmi vos collègues et que ça miaule pendant un bon moment quand vous lancez la visio pour préparer les derniers détails. De toutes façons, le boss a aussi dit que si ça ne marche pas, dans deux semaines, on rase le truc. Il serait toujours temps. C’est pratique, ce genre d’opinion tranchée.

Bref, l’ordre que vous avez préparé est signé, vous allez pouvoir donner le feu vert pour que votre vecteur rentre en jeu. Vous en êtes au « E » de l’acronyme F2T2EA (mais vous venez de découvrir l’existence dudit acronyme. Si vous l’aviez lu plus tôt …). Find, Fix, Track, Target, Engage and Assess. Vous avez fait le travail pour identifier votre cible, en repérer précisément les caractéristiques. Vous vous êtes assuré que le matériel visé était bien celui prévu. Vous suivez son évolution (il ne manquerait plus qu’un vrai technicien de maintenance pointe son nez deux jours avant votre opération pour installer une nouvelle version du logiciel de climatisation …). Vous l’avez ciblé, avez préparé votre arme, vos vecteurs, vos ordres et votre chef vous a donné le feu vert. Vous prenez votre air le plus martial possible, la voix grave, que tout le monde perçoive votre tête de guerrier, et vous lancez un grand « engagez la cible ». Enfin ça c’est votre rêve. En fait, depuis que votre ordre est passé par le secrétariat, a été signé et numéroté, vous n’en êtes déjà plus responsable et n’en avez pas entendu parler. Jusqu’à ce matin, plusieurs jours plus tard. Réunion de suivi, où l’on présente « l’assessment ». On vous dit que la mission est un succès. Bravo. Il n’y aura pas besoin de réattaquer et donc pas besoin de relancer tout le cycle depuis le début. Votre nom est presque dans l’histoire. Si seulement l’histoire avait le droit de connaître votre nom. Non, vous n’organiserez pas de pot. C’est la guerre et il n’y a pas de pot pendant la guerre.

Et notre bateau qui s’échoue dans tout ça, c’est une cyberattaque ?

À votre avis ? Après avoir lu tout ça ?

Bon allez, je vous aide. Comme ça, au prochain accident dans une centrale électrique, au prochain avion qui atterrit plus tôt et plus brutalement que prévu, au prochain train qui déraille ou feu qui clignote, vous aurez une petite checklist toute prête.

1 – À qui profite le crime ? Si l’événement que vous étudiez semble dramatique, sert-il pour autant des intérêts d’une organisation qui n’aurait pas hésité à le provoquer, y compris en passant outre le droit des conflits armés, sans avoir déclaré de guerre ni ouvert de théâtre d’opérations ? D’ailleurs cet ennemi potentiel a-t-il exploité cet événement ? Y-a-t-il eu des revendications, un communiqué, un mouvement de troupe, autre chose qui puisse être lié ?

2 – Le système qui aurait eu un comportement anormal, conduisant à l’accident, est-il facilement accessible ? S’agit-il d’un système informatique hébergé sur un ordinateur ou juste d’un simple boitier électronique ? Dans le premier cas, cet ordinateur fait-il partie d’un réseau qui sort du système visé ? Est-il relié à internet ?

3 – Est-il facile de modifier le firmware des systèmes atteints ? Le niveau de compétence nécessaire est-il accessible à un acteur individuel, ou est-ce que l’opération demanderait des compétences spécifiques, proches du fabricant industriel concerné ? Est-ce que le système a besoin de mise à jour régulières pour fonctionner ?

4 – Le système accidenté utilise-t-il un logiciel ou un matériel spécifique, qu’il serait le seul à détenir ? Ceci permettrait d’avoir une opération ciblée qui ne perturbe pas les systèmes du monde entier. Dans le cas contraire, a-t-on pu observer les mêmes comportements anormaux sur les systèmes similaires du monde entier ?

5 – En cas de dysfonctionnement des systèmes informatiques, les opérateurs de l’infrastructure endommagée ont-ils la possibilité de prendre le contrôle des sous-systèmes de façon manuelle ? Si oui, est ce que cette prise de contrôle aurait pu éviter l’accident que vous étudiez ?

6 – Des organismes de contrôle, des associations, des collectifs, des administrations chargées de la cybersécurité ou des éditeurs d’antivirus, ou même les fabricants des systèmes concernés, leurs utilisateurs, les exploitants de l’infrastructure atteinte par l’accident ont-ils publié un communiqué mettant en cause une cyberattaque ?

Six questions. Six éléments à vérifier avant de vous faire une idée sur la possibilité qu’une cyberattaque ait mené à l’accident que vous étudiez. Et enfin une dernière question, ultime, qui les gouverne toutes : était-ce vraiment le plus simple ? Le moins cher ? Il existe bien des moyens pour viser une infrastructure. Comme vous l’avez lu, préparer un plan de ciblage est dans tous les cas un processus très long, demandant des moyens humains, financiers et matériels importants. Ajoutez à cela la préparation d’une cyberattaque, ses tests, ses équipements, tous ces gens qui doivent garder le secret sur les activités qu’ils préparent et qui ne pourront même pas s’en attribuer le succès. Tout ça alors que deux bombes auraient suffi. Un acteur qui aurait les moyens de préparer une telle cyberattaque n’aurait-il pas les moyens d’arriver plus facilement aux mêmes objectifs, en s’évitant toutes ces complications ?

Parfois, c’est quand même un lupus.

Lorsqu’un événement se produit et que des systèmes physiques sont atteints, l’attribuer rapidement à une cyberattaque est toujours hasardeux. Une telle action est hautement improbable. Qu’il s’agisse d’un acte hostile en général, d’ailleurs, est souvent improbable. Il est souvent pertinent d’envisager méthodiquement une avarie technique, des conditions environnementales, une erreur humaine ou tout élément d’ambiance ayant conduit à de mauvaises décisions et, en général, une combinaison de ces trois facteurs. S’il peut d’ailleurs être pertinent d’émettre une première hypothèse en fonction des premières informations disponible, il faut en général pouvoir remettre cette hypothèse en question lorsque de nouveaux éléments sont connus, pour arriver in fine à une compréhension plus globale de l’ensemble des causes ayant mené à un événement soudain et imprévu. Plusieurs outils méthodologiques permettent de rechercher les différentes causes (notamment l’arbre des causes, le diagramme d’Ishikawa et le modèle des plaques de Reason). Il faut aussi savoir dissocier la recherche de l’origine d’un accident (et la succession des causes, nécessaire à l’apprentissage pour prévenir une nouvelle occurrence de l’accident) et la recherche des responsabilités.

Il n’empêche que, parfois, très rarement, alors que l’on a méthodiquement analysé l’ensemble des éléments, que l’on s’est posé toutes les questions, il soit permis d’envisager que l’acteur étudié a été victime d’une cyberattaque ayant mené à une neutralisation physique du système. Parmi les très rares cas qui fassent l’unanimité figure l’opération « Jeux Olympiques », mettant en œuvre le vers « Stuxnet » contre l’usine d’enrichissement d’uranium du programme nucléaire iranien.

Dans l’immense majorité des autres cas, ce n’est pas une cyberattaque. ■

¹ François Narolles est consultant en organisation et ancien officier au sein de l’état-major des armées, spécialisé dans la planification et la conduite d’opérations interarmées. Ce billet est développé à partir de la série de tweets publiée sur son compte @FNarolles en réponse aux questions concernant l’échouement du porte-containers Ever Given le 23 mars 2021 (le fil original est disponible ici : https://twitter.com/FNarolles/status/1375878914598309889)