Crédits : Pixabay 
Crédits : Pixabay 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 avril, 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.
Commentaires (19)
#1
C'est malheureusement souvent comme ça. Tant que tu ne te prends pas le mur, tu penses que ça va passer...
Enfin, c'est souvent les responsables qui ne voient pas l'intérêt de dépenser pour des broutilles de fiabilités :)
#1.1
Sinon comme toujours, Merci Vincent pour l'article. Cette histoire de panne n'est pas forcément toujours simple à suivre donc il est toujours agréable de prendre le temps de bien comprendre comment cela a pu se produire.
Historique des modifications :
Posté le 24/07/2024 à 14h50
Toujours triste de voir qu'il faut une cata pour faire les changements.
#2
Le truc c'est qu'apparemment, ce type de mécanisme existe bien dans le noyau de Windows. Seulement, Crowdstrike a enregistré le "pilote" de Falcon en tant que "boot-start driver", empêchant l'OS de booter sans le charger. Ça fait sens, on ne voudrait pas que quelqu'un réussisse à faire rebooter la machine sans relancer la solution de sécurité automatiquement. Mais clairement avec ceci en place, il n'y avait plus aucune chance pour que le système s'en sorte tout seul.
Historique des modifications :
Posté le 24/07/2024 à 14h51
Une info que j'ai découverte hier, et que je n'ai pas vue abordée dans les articles sur le sujet publiés sur Next : pas mal de gens dans les commentaires de l'article initial étaient à critiquer Microsoft, en mode "ils sont quand même stupide chez M$, si l'OS n'arrive pas à booter à cause d'un pilote buggé, il devrait juste booter sans charger le driver !".
Le truc c'est qu'apparemment, ce type de mécanisme existe bien dans le noyau de Windows. Seulement, Crowdstrike a enregistré le "pilote" de Falcon en tant que "boot-start driver", empêcvhant l'OS de booter sans le charger. Ça fait sens, on ne voudrait pas que quelqu'un réussisse à faire rebooter la machine sans relancer la solution de sécurité automatiquement. Mais clairement avec ceci en place, il n'y avait plus aucune chance pour que le système s'en sorte tout seul.
#2.1
C'est le problème de ce type d'agent en ring 0 aussi, aucun droit à l'erreur, sinon c'est d'office le crash système.
Pour info une ancienne version avait eu les mêmes conséquences sur des kernels linux aussi donc on ne peut même pas dire que c'est la faute de MS.
Ce qui est clair c'est que
1- leur mécanisme de validation me semble particulièrement faible pour un truc qui part en ring 0
2- je ne pige pas bien qu'ils n'aient pas au moins un "real life testing" avant tout déploiement de masse, sachant que ce truc fonctionne en push
3- Appremment et comme ca a été dit, CrowdStike ne permet pas par exemple d'avoir un noeud de maj qui déploierait "en différé", d'abord sur qqes honey pots puis sur les machines de prod quand on a validé que c'était stable.
#2.2
Il faut donc réussir à trouver le bon équilibre bénéfice/risque entre déployer trop vite et risquer de foutre le système par terre au moindre bug qui passe entre les mailles du filet, et déployer trop lentement et louper des détections qui auraient permis de prévenir des attaques. Le truc c'est que cet équilibre va dépendre du contexte de chaque client de Crowdstrike, donc ça serait bien qu'ils donnent plus de contrôle sur le déploiement de ces updates.
#3
C'est pas un des 1ers trucs qu'on est censés tester dans ce genre de cas ça ? Alimenter le process avec du garbage pour voir si il s'en sort ou si il se vautre lamentablement ?
#3.1
En même temps, tu peux faire tous les tests que tu veux, si les changements sont validés quels que soient les résultats des tests, pourquoi s'embêter ? 😅
Historique des modifications :
Posté le 24/07/2024 à 15h23
En même temps, tu peux faire tous les tests que tu veux, si les changements sont validés quels que soient les résultats des tests, pourquoi s'embêter ? 😅
Posté le 24/07/2024 à 15h23
En même temps, tu peux faire tous les tests que tu veux, si les changements sont validés quels que soient les résultats des tests, pourquoi s'embêter ? 😅
#3.2
Reste quand même le reality test (manquant).
Comme on dit, le vrai test, c'est la confrontation avec la réalité.
#4
A un moment, c'est sympa les automatismes (une bonne escuse), mais comme dit plus haut, balancer un Ring 0, sans parler d'approval, de Change Advisory Board ou autre, c'est quand même extrèmement bizarre. C'est même impensable si cette société a des certifications de sécurité de type SOC1-SOC2/ISO.
N'importe quel auditeur aurait flagé cela dans son rapport et ils n'auraient pas eu leur accréditation de compliance.
ça sent l'enfummage.
Après sur Reddit- Cybersecurity, beaucoup de "Pro" poussaient pour rester chez eux même avec ces problèmes. Etaient-ce de vraies intervention de professionnel Cyber ou bien des cabinets payés à contenir le mécontentement sur les différents médias ? Car des produits alternatifs, il y a en a... et Microsoft en fait partie avec MS Defender.
A suivre.
#4.1
CrowdStrike a une fan-base assez forte, en étant très clivant sur le marché. Leurs execs chient ouvertement sur MS en public notamment à travers des publications LinkedIn, leurs équipes boostent l'égo des technos en expliquant qu'il n'y a qu'eux qui font de la vraie sécurité ... Dans un monde autant polarisé que la cyber, et avec autant de croyances dogmatiques, ça fait mouche.
#4.2
A ma connaissance, MS Defender n'a pas de console de gestion centralisée et ne permet pas d'envoyer des rapports sur des maj qui ne passent pas ou des comportements inhabituels. Et de plus, il ne protège que les WIN, pas les Linux ou Mac OS.
#4.3
L'integration avec MS Sentinel (SIEM), MS 365 Defender, MS Security Center et l'intégration avec leur plateforme XDR est là. Tu rajoutes les remontées des autres services Microsoft et tu te retrouves avec une vue d'ensemble que d'autres produits n'ont pas nativement (ou alors sans devoir faire remonter moult sources de logs dans un SIEM).
Defender est par contre bien compliqué à paramétrer mais comportent des modules qui sont puissants (DLP, Attack Surface reduction, Telemetrie etc...).
L'ensemble demanderait à être simplifié car c'est assez complexe et fouilli, mais ça avance.
Donc il y a de quoi faire avec cet outil. L'intelligence qui repose sur l'agent Crowstrike est déportée sur le cloud avec Microsoft.
Une entreprise avec des licenses Office365 E5, cela peut se tenter. Par contre, cela ne doit pas rester la seule couche de sécurité (le concept de l'onion et des securitées par multi-couches...).
Historique des modifications :
Posté le 25/07/2024 à 08h52
Je ne suis pas tout à faite de cet avis car Defender s'est étoffé grandement ces deux dernières années.
L'integration avec MS Sentinel (SIEM), MS Security Center et l'intégration avec leur plateforme XDR est là. Tu rajoutes les remontées des autres services Microsoft et tu te retrouves avec une vue d'ensemble que d'autres produits n'ont pas nativement (ou alors sans devoir faire remonter moult sources de logs dans un SIEM).
Defender est par contre bien compliqué à paramétrer mais comportent des modules qui sont puissants (DLP, Attack Surface reduction, Telemetrie etc...).
L'ensemble demanderait à être simplifié car c'est assez complexe et fouilli, mais ça avance.
Donc il y a de quoi faire avec cet outil. L'intelligence qui repose sur l'agent Crowstrike est déportée sur le cloud avec Microsoft.
Une entreprise avec des licenses Office365 E5, cela peut se tenter. Par contre, cela ne doit pas rester la seule couche de sécurité (le concept de l'onion et des securitées par multi-couches...).
Posté le 25/07/2024 à 08h52
Je ne suis pas tout à fait de cet avis car Defender s'est étoffé grandement ces deux dernières années.
L'integration avec MS Sentinel (SIEM), MS Security Center et l'intégration avec leur plateforme XDR est là. Tu rajoutes les remontées des autres services Microsoft et tu te retrouves avec une vue d'ensemble que d'autres produits n'ont pas nativement (ou alors sans devoir faire remonter moult sources de logs dans un SIEM).
Defender est par contre bien compliqué à paramétrer mais comportent des modules qui sont puissants (DLP, Attack Surface reduction, Telemetrie etc...).
L'ensemble demanderait à être simplifié car c'est assez complexe et fouilli, mais ça avance.
Donc il y a de quoi faire avec cet outil. L'intelligence qui repose sur l'agent Crowstrike est déportée sur le cloud avec Microsoft.
Une entreprise avec des licenses Office365 E5, cela peut se tenter. Par contre, cela ne doit pas rester la seule couche de sécurité (le concept de l'onion et des securitées par multi-couches...).
#4.5
Je ne savais pas tout ça mais on peut avoir aussi une console hébergée en local et une gestion centralisée si on ne passe pas par O365? Car O365 interdit chez moi...
Si oui, cela m'intéresse!
#4.4
Il n'y a littéralement rien de vrai dans ce commentaire. Microsoft Defender est une suite de sécurité de type XDR, qui est agnostique de l'OS, et qui ne se concentre pas que sur l'antivirus/EDR comme fait CWD, mais va bien plus loin (identité, IoT, mail, collab...).
Ce n'est pas le rôle d'un EDR/XDR. Maintenant, dans Microsoft Defender tu as des solutions de Vulnerability Management qui complètent l'UEM porté par Intune.
#4.6
C'est souvent pour ça que je commence par un "AMHA" ;)
Je ne savais pas que Microsoft avait ajouté la possibilité d'avoir une protection sous Mac OS et Linux. Je crois bien qu'au départ ce n’était pas le cas. Merci pour ta réponse!
Voir ma réponse #4.5
Si c'est possible en local sans O365, ça me donne vraiment envie, d'autant plus que la solution de sécurité que l'on nous a imposé est une bouze infâme pour la gestion centralisée :)
#4.7
Par contre, je ne sais pas trop ce que tu mets derrière "local", mais vu que la solution est agentless sur les dernières versions de Windows, le plus facile pour la gestion est d'activer la feature via Intune. Sinon, tu as une vue des autres options de déploiement plus "classiques" ici, et idem pour les autres OS : https://learn.microsoft.com/en-us/defender-endpoint/onboard-windows-client
Pour revenir sur ton point :
En références publiques sur MDE/M365 Defender, il y a Accenture (700k salariés), la SocGen, la SNCB, Siemens, Pepsi ...
#4.8
Local : avoir le serveur de gestion dans ma salle serveur et rien chez Microsoft. Imposé par mon employeur...
#5
#6