Jean-Jacques Quisquater et Charles Cuvelliez
Composite, Quisquater, Cuvelliez,
DR
L'éditeur du Los Angeles Times, du Chicago Tribune, du Baltimore Sun et des versions pour la côte Ouest du Wall Street Journal et du New York Times n'était visiblement pas résilient : un rançonlogiciel (ransomware) a mis à plat la plate-forme d'impression de ses titres dans un style qui fait plus penser à un exercice grandeur nature. Car le ransomware ne visait pas à voler des données ni à demander une rançon, juste à mettre à terre des serveurs qui font tourner une infrastructure. Le ransomware a chiffré, au moment du bouclage, les articles prêts à être publiés, les publicités à insérer dans les pages et même les avis nécrologiques.
Si l'équipe informatique a vite compris le problème (un ransomware), dès le 27 décembre au soir, ce dernier a continué à narguer les spécialistes toute la journée du vendredi, en contournant les correctifs (patches) et en attaquant les serveurs destinés à l'impression des journaux. La transmission des pages pour impression en a finalement été affectée. Les journaux n'ont pas été imprimés à temps pour les livreurs qui n'étaient plus disponibles plus tard dans la journée. Attaquer un secteur qui fonctionne à flux tendus est finement pensé car l'objectif de résilience, qui fait son chemin pour se remettre d'une cyberattaque, y prend une tout autre dimension.
La résilience consiste à remettre un système en l'état dans lequel il était avant la brèche de sécurité. C'est conserver une configuration de son système qu'on sait sûre avec le moins de perte possible. C'est aussi garder, et ne pas effacer, de quoi poursuivre ou au moins rechercher les coupables à l'origine du cyberincident car ce qui dissuade un voleur, dans le monde réel, ce ne sont pas les serrures mais se faire pincer.
Détecter et enlever les programmes malicieux une fois découverts amènera le pirate à se savoir détecté. Il changera de tactique. Pourquoi abandonnerait-il (alors qu'on pensera naïvement la partie gagnée) ? Mettre en quarantaine un réseau contaminé, une technique souvent utilisée, est risquée car il pourrait être reconnecté par inadvertance. On pense parfois que les machines virtuelles sont un bon outil de résilience car il suffit de les mettre hors service en cas d'attaques réussies mais éteindre une machine virtuelle n'est pas l'effacer. Il y a le risque qu'on la redémarre. En cas de contamination, il n'est pas rare qu'on envoie au rebut les machines physiques car on ne saura jamais si on aura pu éradiquer complètement la contamination (quel gaspillage aussi).
Restaurer ses systèmes tels qu'ils étaient à une date antérieure n'est pas la panacée : l'attaque ou l'exfiltration des données intervient souvent des mois, sinon des années, après la première infiltration. Quelle date choisir et sur quelles transactions, qui ont eu lieu depuis, faire l'impasse ?
L’actualité qui compte pour vous, chaque jour dans votre boîte mail.
Une voie qui se développe pour contrer ce problème est la marche arrière sélective. Il s'agit de pouvoir remonter le temps, application par application, processus par processus, afin de cibler celui ou celle qui a été contaminé. Une autre tactique, mise en avant par Google, sont les réseaux zero trust, un changement radical de philosophie qui consiste à ne jamais faire confiance, à toujours vérifier et, au final, à déporter la responsabilité de la sécurité au niveau de l'utilisateur final, pas du gestionnaire du réseau. Quand on y réfléchit, c'est logique : ne demande-t-on pas aussi aux visiteurs et employés de porter leur badge visible dans les couloirs du monde physique. Et pourquoi ne serait-ce plus le cas dans le monde virtuel d'autant plus que le périmètre à protéger devient de plus en plus flou (où s'arrête le réseau de son entreprise ?).
Le cloud est alors plutôt une bonne nouvelle en termes de résilience. Il découple l'utilisateur final des systèmes. Si Meltdown et Spectre ont eu peu d'impact sur Amazon ou Google, alors que ces failles présentaient un risque majeur pour les clouds publics qu'ils gèrent et qui forment leur infrastructure, c'est parce qu'ils ont pu migrer leurs utilisateurs vers des machines patchées. Dieu seul sait combien d'utilisateurs auraient patché aussi vite leur propre serveurs.
Les clouds présentent un autre défi : les données sont réparties un peu partout, c'est le principe même du cloud. Pour pouvoir appliquer une restauration, il y a une énorme tâche d'inventorier et d'analyser ce qu'on va vouloir restaurer. Google, par exemple, garde une vue très centralisée et monolithique de son réseau pour cette raison.
Autre avantage des clouds: un PC peut contenir jusqu'à 20 composants différents avec chacun son firmware dont on ne sait pas si on peut lui faire confiance. Amazon le résout en fabriquant lui-même ses composants : ainsi, il sait ce qu'il y a dedans et peut intervenir plus vite en cas de problème. S'il ne peut tout fabriquer lui-même, il a recours à plusieurs constructeurs pour ne pas se surexposer en cas de problème chez l'un d'eux. De la même manière, Amazon garde toujours plusieurs versions d'un même software pour le cas où la dernière aurait un vice de sécurité ou un bug (une précaution qu'on devrait tous mettre en œuvre).
Amazon a connu une sérieuse panne fin 2017 mais elle était due à une erreur humaine, une simple faute typographique dans une commande introduite par un administrateur système dûment autorisé à ce niveau-là. Depuis, de la résilience a été introduite là aussi. Ce n'est qu'en compagnie d'un collègue lui aussi dûment autorisé que l'administrateur système a accès au cœur d'Amazon. Les commandes les plus critiques, depuis lors identifiées, sont automatisées. Enfin, il y a une limitation du nombre d'instructions de ce type qui peuvent être effectuées de façon, en cas de problème à pouvoir remonter sélectivement dans le passé (et annuler l'instruction à l'origine de l'incident).
Le secteur financier a beaucoup à nous apprendre en termes de résilience : la question qu'on s'y pose souvent est de savoir si une cyberattaque dans une banque aura des effets immédiats et irrésistibles sur les autres banques. Il n'existe pas d'industrie plus interconnectée que celle-là : tout mouvement d'argent dans une banque trouve son équivalent en sens inverse dans une autre. Or, il est très facile pour une banque de restituer un compte tel qu'il était le jour avant et de remonter le passé. Les compensations entre banques, ces bilans dressés en fin de journée pour voir si tout est à l'équilibre, sont aussi un bel outil de résilience. Ils permettent de remonter le passé jusqu'à trois jours parfois. Une mauvaise transaction a peu de chance de se propager. De là l'idée de la marche arrière sélective évoquée ci-dessus.
Les réseaux électriques sont un autre type de réseau qui peut servir d'exemple : la résilience, maintenir le réseau en état de marche, stable, sans effondrement, va 1000 fois plus loin que la simple robustesse de l'IT qui le sous-tend. Ce sont toutes les lois de l'électricité qui sont à l'œuvre avec les services ancillaires, le maintien de la fréquence, l'équilibrage de la puissance réactive, la protection physique des assets, le training du personnel. Avec la transition énergétique et avec la multiplication des raccordements de centrales à énergie renouvelable, les réseaux de transport et de distribution fonctionneront à double sens : distribuer l'énergie mais aussi en accueillir. L'autoconsommation achève de compliquer le tableau. On aura des micro-réseaux dans le réseau dans lequel ils vont se délester d'un surplus de production ou puiser de l'énergie quand la production locale est insuffisante. Là aussi les data et l'IT ont un rôle crucial à jouer pour équilibrer finement production et consommation et pour constituer des zones locales avec un même objectif d'équilibre. Sans résilience de ces réseaux, c'est le black out.
Les réseaux électriques et le secteur bancaire souffrent surtout d'un autre écueil ; ils sont régulés par un nombre trop grand d'institutions. Toutes ces organisations ont leur propre vue et conception sur ce que doit être la résilience... C'est très contre-productif.
Pour en savoir plus :
Jean-Jacques Quisquater et Charles Cuvelliez
