Panne de CrowdStrike : ces dilemmes causés par les tests logiciels
Selon les experts, les efforts visant à éviter des incidents tels que la panne de CrowdStrike nécessitent de faire des compromis incontournables entre la rapidité de livraison des mises à jour, la stabilité des systèmes, leur accès et leur sécurité.
La société spécialisée dans la sécurité des terminaux a également précisé que la mise à jour concernait les données de configuration de ce qu’elle appelle un modèle de contenu de réponse rapide, plutôt que sa base de code principale ou les pilotes du kernel du système d’exploitation.
Selon le rapport de l’éditeur, le contenu de réponse rapide (Rapid Response Content) est destiné à surveiller les systèmes pour détecter les nouvelles menaces de cybersécurité « à une vitesse opérationnelle ». Ce type de fichier est mis à jour plus fréquemment que l’application principale de CrowdStrike et a fait l’objet d’un processus de test moins étendu. À la suite de l’incident d’envergure mondiale, l’entreprise s’est toutefois engagée à appliquer au Rapid Response Content les mêmes procédures de test qu’aux autres composants de sa plateforme, dont les déploiements canari.
De l’avis de Kyler Middleton, ingénieur logiciel principal chez Veradigm, un éditeur d’une solution de gestion de dossiers médicaux, CrowdStrike a « fait beaucoup de choses qu’il n’aurait pas dû faire ». Sa plus grosse erreur étant de ne pas avoir appliqué des tests approfondis sur les mises à jour de Rapid Release Content qui avaient encore un accès direct au système d’exploitation Windows.
« Même un test d’une minute aurait permis de découvrir ces problèmes », considère-t-il. « À mon avis, cette minute de test aurait été acceptable ».
En général, les tests logiciels et la couverture du périmètre associé sont insuffisants ou défaillants dans de nombreux secteurs. Par exemple, un rapport de la Commission fédérale des communications (FTC) a révélé qu’une panne du réseau mobile d’AT&T en février avait été causée par une mise à jour de la configuration du réseau. Celle-ci avait été « poussée » sans suivre les procédures de test internes de l’opérateur télécom.
Selon les données d’IDC, il ne s’agit pas d’un incident isolé. L’enquête « DevOps Practices, Perceptions, and Tooling » réalisée en juin 2024 par le cabinet d’analystes a révélé que seuls 44 % des tests de qualité des logiciels des 300 répondants étaient automatisés. En outre, 27,3 % ont considéré les tests et l’assurance qualité comme l’un des deux principaux goulets d’étranglement dans leurs pipelines DevOps.
« Les tests demeurent un point de friction important [dans le développement d’applications] ».
Katie NortonAnalyste, IDC
« Les tests demeurent un point de friction important [dans le développement d’applications] », constate Katie Norton, analyste chez IDC. « La gouvernance de la qualité des logiciels nécessite une automatisation, la mise en place d'initiatives Agile et continue face à un manque de personnel d’assurance qualité et à une complexité logicielle croissante ».
Les tests de logiciels, tant pour la sécurité que pour la qualité, semblent faire partie des usages les plus prometteurs de l’IA générative d’après les résultats d’autres enquêtes IDC, ajoute Katie Norton.
« J’ai bon espoir que ces statistiques s’améliorent au cours des prochaines années », anticipe-t-elle. « Toutefois, l’IA ne peut pas remédier à l’absence ou au non-respect des politiques et des procédures ».
Un précaire équilibre entre vitesse, stabilité et sécurité
Toutefois, Kyler Middleton et d’autres observateurs du secteur ont reconnu que la panne de CrowdStrike n’était pas simplement due à des processus de test de logiciels laxistes. Il s’agit plutôt d’un exemple confirmant la nécessité pour les développeurs de prendre en compte un empilement de facteurs lorsqu’ils testent les versions de leurs applications.
De fait, la faille de CrowdStrike a été causée par plusieurs couches de bugs. En l’occurrence, un outil de test aurait dû détecter la faille dans le modèle de configuration Rapid Release Content. Cette méthode indirecte présente, en théorie, moins de risques de provoquer une panne du système que les mises à jour des fichiers système eux-mêmes, selon Gabe Knuth, analyste chez Enterprise Strategy Group [propriété de Techtarget, également propriétaire du MagIT].
« C’est un défi pour les systèmes entièrement automatisés, car ils s’appuient eux aussi sur un logiciel pour faire progresser les versions depuis le développement jusqu’à la livraison », indique Gabe Knuth. « S’il y a un bug dans le logiciel quelque part dans le pipeline CI/CD, cela peut conduire à une situation comme celle-ci. Pour découvrir ce type de bug de manière automatisée, il faut donc tester… les tests. Mais cela réclame d'utiliser un logiciel, il faut donc tester le test qui teste les tests, etc. ».
« Pour découvrir ce type de bug de manière automatisée, il faut donc tester… les tests. Mais cela réclame également d'utiliser un logiciel, il faut donc tester le test qui teste les tests, etc. ».
Gabe KnuthAnalyste, Enterprise Strategy Group
L’ampleur des tests de logiciels dépend d’une évaluation des risques qui englobe non seulement la stabilité des systèmes, mais aussi la rapidité avec laquelle ils peuvent être mis à jour pour atténuer les menaces de sécurité qui émergent rapidement.
« Qu’est-ce qui est pire ? soupèse Gabe Knuth. “Un bug qui fait planter des millions de terminaux et provoque des perturbations mondiales pendant qu’il est corrigé ou une vulnérabilité qui entraîne la perte de propriété intellectuelle, d’informations privées, de secrets d’État, etc. ?”
Aussi pénible qu’ait été la panne de Windows qui a cloué au sol les avions des compagnies aériennes et affecté les systèmes hospitaliers, pour de nombreuses entreprises, ce type de compromission de la sécurité serait pire, répond Kyler Middleton.
« En fin de compte, les entreprises préfèrent risquer une panne de disponibilité due à une mauvaise mise à jour de leurs outils de sécurité plutôt qu’une panne de confidentialité due à un logiciel malveillant qui compromet leurs hôtes », affirme-t-il. « De l’extérieur, en tant que consommateurs, nous voyons les choses de la même manière : les services que nous utilisons ne sont pas disponibles. Mais de l’intérieur, c’est totalement différent ».
Selon Kyker Middleton, si l’indisponibilité des services n’a qu’une faible incidence sur les résultats, les logiciels malveillants peuvent entraîner des fuites de données qui obligent une entreprise à fermer ses portes en raison des frais de justice ou qui nuisent à sa réputation au point de lui faire perdre des clients.
« Les entreprises préfèrent de loin être fermées par une mauvaise mise à jour plutôt que par un logiciel malveillant », avance-t-il.
Dans un même temps, des tests logiciels plus poussés « comportent des risques », croit l’ingénieur logiciel chez Veradigm. « Ces fichiers de mise à jour sont composés pour répondre rapidement aux menaces émergentes de logiciels malveillants, et tout retard, même d’une minute, pourrait laisser la porte ouverte à l’infection d’un serveur d’entreprise sensible ». Bref, l’on s’approcherait d’un jeu à somme nulle.
Les professionnels de l’IT appellent à des déploiements canari (et plus encore)
En réponse à la panne, CrowdStrike effectuera des déploiements progressifs de changements, ou mises à jour canari, avec des fichiers Rapid Release Content de la même manière qu’elle le fait avec des mises à jour d’applications moins fréquentes, selon le rapport préliminaire de l’entreprise après l’incident.
Pour certaines organisations, cela permettra de s’assurer qu’une mise à jour défectueuse ne touchera pas toutes les machines des clients en même temps.
« Je suis incroyablement surpris, même s’ils l’appellent “Rapid Response”, que [CrowdStrike] n’a pas une approche progressive qui lui permet de vérifier la santé des terminaux sur lesquels sa solution est déployée », s’étonne Andy Domeier, directeur principal de la technologie chez SPS Commerce, un éditeur de logiciels pour les entreprises de la chaîne d’approvisionnement et de la logistique. « Même avec un ordre logique de criticité des clients, ils pourraient avoir des disjoncteurs pour arrêter un déploiement précoce qui, selon eux, cause des problèmes de santé. Par exemple, ne pas [mettre à jour] les compagnies aériennes tant que le niveau de confiance n’est pas plus élevé après avoir vu l’état des points de terminaison d’autres clients ».
D’autres ingénieurs logiciels ont déclaré que les déploiements canari constitueraient une bonne étape. Cependant, certains considèrent que CrowdStrike devrait repenser plus largement l’architecture de son application afin que les fichiers rapidement mis à jour soient séparés du noyau du système d’exploitation par une couche d’abstraction, telle qu’un contrôleur de gestion, un hyperviseur ou un programme eBPF.
« Il est absolument irresponsable de déployer automatiquement une mise à jour de module du kernel à l’échelle mondiale sans un processus de médiation de la santé ou, au moins, un chemin de récupération à un niveau inférieur du plan de contrôle »
David StraussCofondateur et CTO, Pantheon
« Il est absolument irresponsable de déployer automatiquement une mise à jour de module du kernel à l’échelle mondiale sans un processus de médiation de la santé ou, au moins, un chemin de récupération à un niveau inférieur du plan de contrôle », lance David Strauss, cofondateur et directeur technique du fournisseur de services WebOps Pantheon. « Quelque chose qui reste fonctionnel même si le système d’exploitation déployé au-dessus tombe en panne ».
Les clients qui utilisent ce type de logiciel de détection de logiciels malveillants à haut rendement sur des machines relativement non critiques portent également une part de responsabilité dans l’impact de la panne de CrowdStrike, ajoute David Strauss.
« L’utilisation de CrowdStrike sur des machines telles que les terminaux de porte d’embarquement des compagnies aériennes me paraît absurde », poursuit-il. « Les machines de ce type sont à usage unique et devraient être sécurisées à l’aide de privilèges restreints… et d’une validation de l’intégrité. […] Le seul endroit où il est utile de surveiller les logiciels malveillants, c’est lorsqu’il n’est pas possible de faire ces deux choses. Même dans ce cas, les magasins d’applications, les versions signées et le sandboxing renforcé par le système d’exploitation sont les approches modernes pour gérer cela – bien plus que les agents de balayage qui s’exécutent sur les ordinateurs des usagers ».
