Panne majeure CrowdStrike : analyse à tiède

D’abord, humilité. Ce type de bourdes est arrivé à toutes les entreprises de la tech ou presque : à titre personnel, je l’ai vécu récemment avec la mise à jour d’un composant middleware que le fournisseur avait faite avec les pieds (quoi qu’il en dise) et qui nous a mis au tas plusieurs centaines de PC. C’est arrivé à d’autres CH/CHU avec d’autres fournisseurs, cela arrivera de nouveau. Si vous ne voulez pas vous tuer en bagnole, vous ne prenez pas la bagnole, si vous ne voulez pas vous coltiner des bugs, vous retournez au papier-crayon, fermez le ban. Je prévois d’ailleurs un recueil de bonnes histoires de gaffes, va falloir réserver plusieurs volumes de la Pléiade avec quelques chapitres me concernant personnellement.

Puis, un mélange d’incrédulité et de consternation sur la root cause. Il semblerait (c’est en tout cas le niveau d’informations disponibles à l’heure où je maltraite mon clavier) que l’origine de la panne proviendrait de la mise à jour simultanée (en gros) à la fois d’un composant du moteur de l’EDR en plus d’une mise à jour de signature ou équivalent. Dans les produits de protection du poste de travail, ce genre d’actions fait souvent partir le logiciel en boucle, et c’est ce qui semble s’être produit ici[1]. De plus, tous les ingénieurs de production savent que l’on ne fait pas deux mises à jour en même temps. Bon, notez que les analyses divergent sur ce sujet.

S’ensuit donc un questionnement. Soit CrowdStrike n’avait pas identifié ce risque spécifique, soit l’entreprise l’avait identifié, mais n’avait pas prévu de procédure (peu probable), soit la procédure existait, mais un ingé devant son clavier ne la connaissait pas – ou l’a bypassée, soit on est sur un cas de fat fingers. Si l’une des causes précédentes est avérée, on est dans de l’amateurisme clair et net, pour une boîte cotée au Nasdaq qui aligne 3 milliards USD de CA annuel. Sinon, on est très friand de l’explication.

Après, voilà définitivement tué le mythe selon lequel il faut tout placer chez de gros hébergeurs Cloud car leurs processus de validation sont forcément meilleurs que ceux d’une petite ou moyenne entreprise. Manifestement, chez Microsoft (qui a été fortement impacté) il semblerait (à confirmer) qu’aucun système de décalage de mise en production J+1 n’ait été établi, procédé qui permet de détecter ce genre d’anomalies sur un bac à sable avant généralisation à l’ensemble du parc. D’ailleurs, s’il faut identifier non seulement les risques de défaillance de nos fournisseurs Cloud, mais aussi des fournisseurs de nos fournisseurs et ainsi de suite, je propose d’abandonner les méthodes d’analyse formelle de risque type Ebios et de revenir à la divination par les cartes ou par la lecture des tripes de bestioles.

Poursuivons : nous devrions collectivement nous interroger sur l’extrême concentration du secteur IT. Qu’une défaillance d’origine quasi mineure au sein de seulement deux entreprises (Microsoft et/ou CrowdStrike) impacte autant d’utilisateurs et de clients finaux sur la planète entière n’augure rien de bon. On est dans le contraire du b.a.-ba de la gestion à la grand-mère qui consiste à ne pas mettre tous ses œufs dans le même panier. Or c’est exactement le principe du Cloud : un gigantesque panier géré/maintenu par très peu d’individus.

À découvrir → Google et CrowdStrike, ou les prémisses de la fin d’un monde

D’ailleurs, le phénomène de fat fingers, bien connu dans les salles de marché (entre un ordre de bourse à 50 millions et un autre à 50 milliards, il n’y a jamais que trois zéros d’écart), fait l’objet d’un nombre considérable de contrôles qui, au final, présentent des failles. On n’évite jamais la fatigue du petit matin, le gars pressé de rentrer à la maison ou l’inattention : le fat fingers ou équivalent est consubstantiel à l’action humaine.

Les entreprises de la tech meurent principalement soit d’un manque d’innovation qui leur fait rater le coche (Kodak pour le numérique, Novell, Palm), soit à cause d’incidents cyber dont elles ne se relèvent pas (BlackBerry). À l’heure où je tape ces mots, le cours de Bourse de CrowdStrike a perdu pas loin de 20 % en une seule séance, avec un risque de prédation/rachat par un acteur IT qui dispose de cash (ce qui ne manque pas, dans la plupart des cas, c’est la base client qui est rachetée et pas les produits), ou carrément de dépôt de bilan (hypothèse plus faible). Ce qui est certain, c’est qu’il va lui falloir provisionner des frais d’avocats car la moitié de la terre va lui envoyer les siens pour réclamer des comptes et des dommages-intérêts. Ce n’est globalement pas une bonne nouvelle, car la survie d’un acteur est potentiellement menacée dans un secteur déjà archiconcentré.

Les Mayas ont disparu – semble-t-il – à la suite d’une conjonction de problèmes écologiques, d’approvisionnement des villes, politiques, etc. Si je devais faire un pari, je pense que l’humanité telle qu’elle existe ne disparaîtra pas du CO₂, du H1N18 ou de Poutine qui pète un câble, mais plus probablement d’un gugusse qui travaillera dans la seule boîte de son secteur ultraconcentré, seul fournisseur dans son domaine du seul opérateur de Cloud mondial restant, et qui mettra au tas tous les PC de la planète sur le seul OS restant, pour avoir voulu aller trop vite dans la mise à jour d’une DLL.

Et le pire, c’est qu’il risque de s’agir d’un stagiaire de troisième au mois d’août.

[1]   https://en.wikipedia.org/wiki/2024_CrowdStrike_incident 

L'auteur

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.