Le vendredi 9 juillet dernier s’est produit ce qui est déjà qualifié de « pire panne informatique de l’histoire ». Notre chroniqueur et expert, René-Sylvain Bédard, fondateur et PDG d’Indominus Sécurité Gérée, fait le point sur cet événement, et tente d’en dégager les meilleures leçons à tirer pour l’avenir.
Le tribunal populaire et Microsoft Windows
Dès les premières minutes, les journalistes avaient déjà Microsoft dans le collimateur, « Panne globale chez Microsoft ». Bien que Microsoft Windows soit le récipiendaire, tant en version poste qu’en version serveur dudit patch, Microsoft n’a rien à voir avec cette dernière.
Un patch ou correctif, est une section de code que l’on ajoute à un logiciel, pour y apporter des modification
J’ai lu énormément de commentaires, et certains véhéments, sur comment nous devrions remplacer Windows par Linux, et ce, même si le manufacturier n’avait rien à voir avec la panne. C’est comme décider de réduire la réputation de Renaud ou Volkswagen à néant, parce que vous avez eu une crevaison. Très peu pour moi.
Les faits sont qu’un tiers parti, s’exécutant sur Microsoft Windows, a publié un patch, et que ce dernier a causé une panne sur le système d’exploitation. Point.
Également, un événement semblable est arrivé, attribuable à CrowdStrike, sur la plateforme Linux (Debian et Rocky Linux), quelques mois auparavant. En revanche, puisque la plateforme n’est pas aussi répandue, peu de gens en ont souffert.
Je recommande à tout le monde de prendre une belle dose d’humilité avant de critiquer Windows, la majorité d’entre nous n’avons pas de code qui a durée plus de 40 ans dans le marché et, surtout, nous n’avons pas ce genre de succès.
Les risques et périls d’être un système ouvert
Microsoft a fait le choix, il y a plus de 40 ans, d’être un système d’exploitation qui serait ouvert, ce qui veut dire qu’ils accepteraient, avec un minimum de contrainte, qu’un autre manufacturier se serve de la plateforme pour y ajouter son matériel propriétaire ou y exécuter son logiciel.
Ceci impose à Microsoft de ne pas avoir le contrôle sur certaines portions de son système d’exploitation. Ce qui le fragilise, mais en retour, le rend disponible pour un plus grand nombre de scénarios.
Il fut un temps, pas si lointain, où les mises à jour de Microsoft étaient elles-mêmes des événements périlleux. Mais je dois dire que dans la dernière décennie, les choses se sont tellement améliorées, que tout patch qui serait identifié comme problématique est retiré de la distribution avant d’être publié.
L’informatique ne connaît pas de vacances
Quel hasard, quand même. La dernière journée avant les vacances de la construction au Québec… C’est une leçon que nous devons tous intégrer :
- Pas de mises à jour ou de grand changement avant le week-end ou une période de vacances, au risque de les perdre ;
- Si vous devez faire un changement ou une mise en prod à ce moment, prenez du temps pour tester, pour vérifier que l’impact est sous contrôle et, surtout, ayez un plan de retour en arrière. Dans bien des cas, cela peut aussi impliquer de restaurer une image ou une sauvegarde d’il y a quelques heures.
Les cybercriminels font flèche de tout bois
Dans les heures qui ont suivi l’annonce, nous avons pu voir les réseaux cybercriminels se mettre en action :
- L’achat en masse de noms de domaines dans le but de subjuguer les victimes, du genre FixCrowdStrikeBug.com, dans le but de lancer des campagnes de logiciels malveillants ;
- Le déploiement de fausses solutions à télécharger, qui venaient compromettre les serveurs et les postes de travail qui l’utilisaient, et ce, sans régler le problème.
Bref, se servir d’une catastrophe, pour faire du profit.
Les patches, c’est nécessaire, mais le temps de les tester l’est d’autant plus
La majorité des nouvelles vulnérabilités découvertes de nos jours sont profondément ancrées dans le code des applications que nous utilisons. Donc, plus de logiciels différents, plus de vulnérabilités.
Comme il s’agit parfois (comme dans le cas de CrowdStrike) de logiciels qui s’approchent du cœur de Windows (ou du coeur au niveau de Linux) pour le protéger des cyberattaques et permettre de défendre la stabilité du système d’exploitation, les tests sont de plus en plus critiques.
Mais voilà qu’intervient la réalité commerciale : qui sera le premier à régler telle ou telle phase, qui sera le meilleur, qui y arrivera en premier. C’est un jeu dangereux.
Ce jeu, joué par la majorité des grands joueurs, mène à d’énormes dépenses en R-D, et la patience des investisseurs (ou des sociétés) pour le retour sur investissement est pratiquement inexistante. La pression est énorme pour que ces investissements fassent une différence.
Il est grand temps, je crois, pour que tout le monde prenne un pas de recul et, surtout, prenne le temps d’investir dans ses processus d’assurance qualité, afin d’éviter qu’un tel scénario se reproduise.
Les patches peuvent être déployés en différé
La majorité des administrateurs système d’expérience vous le diront. Ne jamais déployer le jour du lancement. Que ce soit une nouvelle version du système d’exploitation, d’une série de patches ou d’un nouveau logiciel. Il faut prendre le temps de voir. Dans ce cas-ci, ceux qui se sont dotés d’une fenêtre différant les mises à jour de 24 h, ont sauvé leurs environnements, et également, leur départ en vacances.
Donc, oui, vous pouvez induire un délai avant le déploiement, soit d’un, deux voire même trois jours. Ceci vous laisse le temps de voir comment les mises à jour se comportent sur le marché, mais laisse également le temps au manufacturier, si un problème est découvert, de retirer leur code ou même de le remplacer avec une version fonctionnelle.
L’erreur reste humaine
Même si le cloud et ces machines font les déploiements et publient ces fichiers de mises à jour à travers la planète, il est important de comprendre qu’à sa base, cet incident n’est qu’une erreur humaine. Malgré que le stock de CrowdStrike ait reçu une énorme correction (on parle de jusqu’à 15% ou 11 milliards de dollars américains), il y a un humain, en arrière-plan, qui n’a peut-être plus de travail aujourd’hui, qui a poussé un bout de code qui n’a pas proprement été testé, et contre-validé par des services d’assurance-qualité.
L’architecture se doit d’être simplifiée
Je persiste et je signe. Plus les systèmes sont complexes, plus ce genre d’erreur peut s’introduire. Je préconise désormais de ne plus se fier uniquement au modèle Best of breed, qui implique de déployer la meilleure techno de sa catégorie, mais bien de se concentrer sur la construction de partenariat plus profond, avec un nombre limité de manufacturiers.
Mon expérience me dit donc que moins il y a de manufacturiers différents, moins il y a de chance qu’il y ait un jeu de ping-pong en cas de problème et, surtout, moins il y aura de coins obscurs dans lesquels des vulnérabilités ou des cybercriminels peuvent se cacher.
Les systèmes critiques exigent une attention critique
J’avais le débat, avec l’un de mes « génies résidents », vendredi matin. Il argumentait que les systèmes critiques ne devraient pas être sur Windows. J’en étais presque offensé. Je lui expliquais que Windows, c’était bien plus qu’un contrôleur de domaine ou un serveur de fichier. C’était à l’arrière-plan d’une tonne d’autres fonctionnalités qui maintenaient des personnes en vie dans les hôpitaux et qui faisaient le suivi, en temps réel, d’avions et de trains.
Le problème avec les systèmes critiques n’est pas le système d’exploitation qu’ils exécutent, mais bien l’attention qu’on leur porte. La criticité d’un système doit se refléter dans le sérieux de son administration, et des opérations qui le gèrent.
Un système qui gère les services critiques d’un aéroport ne peut être géré de la même manière qu’un serveur de fichier, dans un département moins critique. L’échelle des valeurs doit s’ajuster.
Donc, quand je vois la quantité de serveurs critiques, mis à jour de façon totalement automatique, j’y vois une seconde erreur humaine ; celle d’automatiser des processus, qui auraient dû être validés avant d’aller en production.
Ce point peut être justifié vu la pénurie de main-d’œuvre, mais, par contre, si vous ne pouvez les valider vous-même, donnez-vous 48-72 heures de délai pour être en mesure de les arrêter si un tel problème survient.
L’expérience est amère pour les propriétaires de PME
Pour les propriétaires de moins grandes entreprises qui viennent de subir cette panne, je vous en prie, retenez-en la leçon.
Non, cela n’arrive pas qu’aux autres.
Cette panne est tout à fait similaire à une cyberattaque. La différence est que la résolution d’une cyberattaque sera en semaines, et potentiellement en mois.
Mettez en place, je vous en prie, des mesures de prévention et d’atténuation, pour éviter que cela vous arrive et que vous ne soyez, de nouveau, pris au dépourvu.
L’effritement de la crédibilité
L’impact le plus significatif, au-delà des pertes financières et de l’impact pour les personnes affectées, est l’érosion de la crédibilité. Cette crédibilité qui est nécessaire pour créer un sentiment de confiance envers les technologies.
Ceci peut affecté grandement la manière dont les sociétés feront confiance aux technologies pour régler des problèmes d’affaires.
Je crois que, dans ce sens, l’innovation et les investissements dans ce secteur pourront être les grands perdants.
Ce qui aurait pu éviter à certains clients d’être affectés
- La mise en place de mesures de sécurité simples, mais très bien maîtrisées et, surtout, très efficaces ;
- Une architecture simplifiée, tout en étant imposante ;
- Le fait d’avoir différé les mises à jour de 24 h ;
- Chez Indominus, par exemple, nous avons choisi Microsoft Defender for Endpoint, et non CrowdStrike.
Comment résoudre le problème
Pour ceux qui seraient encore aux prises avec le problème, voici la recette qui fut publiée un peu plus tôt hier.
- Redémarrez en mode sans échec (Safe Mode)
- Ouvrez le répertoire suivant : C:\Windows\System32\drivers\CrowdStrike
- Localisez et détruisez les fichiers répondant au nom suivant : C-00000291*.sys
- Redémarrez le poste/serveur
En espérant que l’incident ainsi que cette chronique soutiennent votre réflexion vis-à-vis des leçons à tirer de cette panne.
Je demeure disponible si vous souhaitez discuter du sujet ou si vous avez besoin d’un coup de main pour vérifier comment garantir que ceci ne vous arrive pas.
Crédit Image à la Une : Gauche : archives. Droite : fournie par René-Sylvain Bédard
