Promis, ça n'arrivera plus
Dans un billet publié il y a quelques heures, CrowdStrike revient sur la chronologie des évènements ayant engendré la panne mondiale que l’on connait. L’éditeur y explique ses processus de test et ce qui s’est passé. Il annonce également des changements pour que ce type de problème ne se reproduise plus.
Alors que la panne engendrée par un bug dans le produit Falcon de CrowdStrike affecte toujours une partie des machines, l’éditeur est revenu en détail sur ce qui s’est passé. Une publication attendue, car elle revient sur l’enchainement des faits ayant abouti à la diffusion d’une mise à jour qui, en théorie, n’aurait jamais dû engendrer une telle pagaille.
Deux types de mises à jour
CrowdStrike commence par expliquer qu’il existe autour de Falcon deux types de mises à jour. Celles de type « Sensor Content » d’abord, qui ont trait au fonctionnement du capteur lui-même, à ses capacités inhérentes. Elles contiennent de nouveaux modèles (IA et machine learning) et « du code écrit expressément pour fournir des capacités réutilisables à plus long terme aux ingénieurs de CrowdStrike chargés de la détection des menaces ».
Ensuite, les mises à jour de type « Rapid Response Content », qui sont à Falcon ce que les fichiers de définition sont aux antivirus. Ce contenu de réponse rapide est conçu pour mettre à jour les capacités du capteur et est fourni sous forme d’instances de modèles. Ces dernières « sont des instanciations d’un type de modèle donné », chacun correspondant à « des comportements spécifiques que le capteur doit observer, détecter ou prévenir ».
Chacun ses tests
Les deux types reçoivent chacun une série de tests. Les Sensor Content subissent « des tests unitaires, des tests d’intégration, des tests de performance et des tests de stress ». Ces mises à jour sont logicielles et modifient des fichiers. Elles sont soumises aux paramètres de déploiement définis par les clients. Il peut s’agir de la dernière version (N), de la version précédente (N-1) ou de celle d’encore avant (N-2).
Pour les secondes, c’est un peu plus complexe. Trois composants sont impliqués : le système de configuration du contenu, l’interprète du contenu et le moteur de détection du capteur. Le premier est dans le cloud, les deux autres sont sur site. Le système de configuration du contenu est chargé de créer les instances de modèles. Ces dernières sont envoyées au capteur via des fichiers de canaux (nous y sommes), qui sont lus par l’interprète du contenu, pour que le moteur de détection du capteur puisse faire son travail.
« Les nouveaux types de modèles sont soumis à des tests de résistance sur de nombreux aspects, tels que l’utilisation des ressources, l’impact sur les performances du système et le volume d’événements. Pour chaque type de modèle, une instance de modèle spécifique est utilisée pour tester le type de modèle en le comparant à toutes les valeurs possibles des champs de données associés afin d’identifier les interactions négatives du système », explique CrowdStrike.
La chronologie des évènements
La version actuellement utilisée du capteur (Sensor Content) est la 7.11, déployée le 28 février dernier. Elle a introduit un nouveau type de modèle IPC (Inter Process Communication), afin de détecter de nouveaux types d’attaques. Elle est passée par toutes les procédures de tests mentionnées.
Le 5 mars, une nouvelle instance du modèle entre en environnement de test et passe tous les essais (dont des tests sur tous les systèmes d’exploitation et sur des charges de travail). Elle est déployée plus tard le même jour en tant que fichier de canal 291. Trois instances supplémentaires sont déployées entre les 8 et 24 mars, via des mises à jour Rapid Response Content. CrowdStrike ajoute que toutes ces versions ont fonctionné comme prévu.
Que s’est-il passé le 19 juillet ? Deux nouvelles instances du modèle sont déployées via une mise à jour Rapid Response Content à 6h09, heure française. Cependant, l’une de ces nouvelles instances a été validée en dépit de « données problématiques ». Pourquoi ? À cause d’un bug dans le validateur de contenu.
L’envoi en production s’est fait sur la base des tests réalisés et validés par erreur, ainsi que sur ceux du déploiement initial (5 mars) et de toutes les instances publiées ces derniers mois. L’instance validée par erreur, lorsqu’elle a été lue par l’interpréteur de contenu, a entrainé une lecture hors limites de la mémoire, créant une exception. Celle-ci « n’a pas pu être gérée de manière élégante, ce qui a entraîné un plantage du système d’exploitation Windows (BSOD) ». Les hôtes Mac et Linux n’ont pas été concernés, ce que l’on savait déjà.
La diffusion de la mise à jour fautive a été annulée à 7h27, la fameuse fenêtre de 78 minutes qui a suffi à mettre à genoux des millions d’ordinateurs.
CrowdStrike s’excuse et modifie ses processus
« Je tiens à m’excuser sincèrement auprès de vous tous pour cette panne. L’ensemble de CrowdStrike comprend la gravité et l’impact de la situation. Nous avons rapidement identifié le problème et déployé un correctif, ce qui nous a permis de nous concentrer avec diligence sur la restauration des systèmes des clients, qui est notre priorité absolue », a déclaré George Kurtz, fondateur et PDG de CrowdStrike, à la fin du billet.
Ce dernier présente également une série de changements pour s’assurer que ce genre de problème ne se reproduira pas. Il s’agit, on s’en doute, d’un plus grand nombre de tests (stress, fuzzing, injection de fautes, stabilité, interfaces de contenu…) et d’étapes de validation supplémentaires. L’interpréteur va être renforcé pour détecter plus efficacement les données invalides.
En outre, un canal Canary va être mis en place pour tester les mises à jour Rapid Response Content et ainsi échelonner les déploiements. L’éditeur ajoute qu’il va aussi améliorer « le suivi des performances des capteurs et des systèmes », permettre un meilleur contrôle sur leur déploiement (quand, comment et où) et fournir des notes de version. On se demande pourquoi il a fallu attendre une panne aussi critique pour que de telles avancées soient proposées.
Enfin, CrowdStrike s’engage à publier plus tard une « analyse complète des causes profondes » de l’incident, une fois que l’enquête sera terminée.