D’anciens employés de CrowdStrike : « Le contrôle qualité ne faisait pas partie du processus »
(semafor.com)- Avant la panne majeure de juillet 2024, d’anciens employés disent avoir alerté la direction sur des délais serrés, une charge de travail excessive et des problèmes techniques croissants
- Parmi les 24 anciens employés interrogés, beaucoup estiment que la direction privilégiait la vitesse à la qualité, et que certains salariés se sont vu confier des tâches de développement et d’exploitation sans formation suffisante
- CrowdStrike conteste largement les déclarations des anciens employés et rétorque que les informations proviennent de « quelques anciens employés mécontents licenciés pour violation manifeste de la politique de l’entreprise »
- Le défaut de la mise à jour de Falcon Sensor en juillet a immobilisé 8,5 millions d’ordinateurs, causé jusqu’à 5,4 milliards de dollars de pertes aux entreprises du Fortune 500, et CrowdStrike a manqué environ 60 millions de dollars de contrats attendus pour le trimestre concerné
- Même si le lien direct entre des problèmes durables de qualité et d’exploitation et la panne de juillet n’a pas été établi, CrowdStrike fait depuis face à une baisse de ses prévisions de revenus et de bénéfices, à une audition au Congrès et à une pression judiciaire accrue
Des inquiétudes sur la qualité accumulées bien avant la panne
- D’anciens ingénieurs logiciels de CrowdStrike affirment avoir signalé à leur hiérarchie, plus d’un an avant la panne majeure de juillet, des échéances très serrées, une surcharge de travail et des problèmes techniques grandissants
- Selon eux, ces alertes ont été répétées lors de réunions, par e-mail et dans des entretiens de départ
- Jeff Gardner, ancien senior user experience designer, a déclaré que « la vitesse était ce qui comptait le plus » et que le contrôle qualité ne faisait pas partie du processus ni des discussions
- Un ancien senior manager dit que, lors de plusieurs réunions, des employés avaient averti que lancer un « produit impossible à supporter » risquait de faire « échouer » les clients
Témoignages divergents d’anciens employés et réponse de l’entreprise
- Semafor a interrogé au total 24 anciens employés
- 10 disent avoir été licenciés ou visés par des suppressions de postes
- 14 disent être partis volontairement
- L’un d’eux était encore dans l’entreprise jusqu’à l’été 2024
- Trois anciens employés ne partagent pas les propos des autres
- Joey Victorino, parti en 2023, estime que CrowdStrike était « très méticuleux dans tout ce qu’il faisait »
- L’entreprise conteste largement le contenu du reportage
- Elle affirme que les informations viennent de « quelques anciens employés mécontents licenciés pour violation manifeste de la politique de l’entreprise »
- Elle dit appliquer des tests rigoureux et un contrôle qualité strict pour garantir la résilience de ses produits, et rejette totalement les affirmations contraires
Une panne de juillet après une croissance rapide
- CrowdStrike a été fondée en 2011 et s’est imposée comme un acteur majeur de la cybersécurité après le lancement du package antivirus Falcon en 2013
- Depuis son introduction en Bourse en 2019, l’entreprise a recruté plusieurs milliers de salariés supplémentaires, et son chiffre d’affaires a progressé de plus de 1 000 % à la fin de l’exercice 2024
- En juillet 2024, une mise à jour logicielle erronée a conduit à ce qui pourrait être la plus grande panne informatique de l’histoire
- 8,5 millions d’ordinateurs ont été immobilisés
- Les pertes des entreprises du Fortune 500 pourraient atteindre 5,4 milliards de dollars
- Des voyageurs aériens sont restés bloqués dans les aéroports, l’accès aux services bancaires en ligne a été interrompu, et des centres d’appels d’urgence sont tombés hors ligne
- Le CFO Burt Podbere a déclaré, lors de la publication des résultats du 28 août, que l’entreprise avait manqué environ 60 millions de dollars de contrats qu’elle pensait conclure sur le trimestre clos le 31 juillet
- Le CEO George Kurtz a affirmé qu’il n’oublierait pas l’ampleur de l’incident du 19 juillet et qu’il veillerait à ce qu’une telle situation ne se reproduise plus
Tests, données clients et cas LogScale
- Certains anciens employés disent que, dans la course au rythme des lancements produits, les vérifications de qualité logicielle étaient parfois expédiées
- Preston Sego, employé entre 2019 et 2023, explique qu’il était parfois difficile de convaincre les équipes de mener des tests suffisants
- Son travail consistait à vérifier, avant le déploiement de modifications de code chez les clients, si les tests des développeurs de l’expérience utilisateur signalaient correctement les bugs
- Sego dit avoir été licencié en février 2023 comme « insider threat » après avoir critiqué sur Slack la politique de retour au bureau
- CrowdStrike a répondu qu’elle ne commentait pas les dossiers RH individuels
- Au sein du département des services professionnels, il y a eu trois cas où des informations privées d’un client ont failli être téléversées dans le dossier d’un autre client
- CrowdStrike a confirmé ces incidents et en a attribué la cause à une erreur de saisie manuelle des données
- L’entreprise précise qu’il s’agissait d’informations de base, comme des noms d’hôtes, des adresses IP et des noms de domaine
- Elle affirme avoir mis en place des contrôles pour éviter tout envoi erroné de données confidentielles clients
- Plusieurs anciens employés disent aussi avoir constaté des problèmes sur Falcon LogScale
- L’un d’eux se souvient qu’une mauvaise mise à jour a brièvement désactivé au moins deux fois des alertes en temps réel signalant une activité potentiellement malveillante
- Certains ingénieurs ont dit, en réunion interne, y voir la conséquence de délais trop serrés
- CrowdStrike conteste cet exemple et dit ne pas avoir connaissance d’une « bad update » ayant empêché des clients de recevoir des alertes
- L’entreprise précise que LogScale n’est pas un service conçu pour avertir les clients « en temps réel » d’une potentielle compromission de données
Polémique autour du lancement de Falcon OverWatch Cloud Threat Hunting
- Un ancien employé affirme que Falcon OverWatch Cloud Threat Hunting, lancé en 2022, a été mis sur le marché dans la précipitation
- Ce service permet aux experts sécurité de CrowdStrike de rechercher, dans les environnements cloud des clients comme Amazon Web Services, des comportements suspects pouvant indiquer une compromission
- Un ancien senior manager ayant participé au projet dit qu’une tâche qui prend normalement un an a été confiée aux ingénieurs et threat hunters en 2 mois
- Selon lui, au moment du lancement, les threat hunters ne disposaient pas des outils internes nécessaires pour surveiller complètement les systèmes cloud des clients et, jusqu’à l’été dernier environ un an après le lancement, ils répondaient aux alertes de systèmes de sécurité existants
- Ce même ancien senior manager affirme aussi que l’entreprise a mobilisé pour la détection des menaces cloud des salariés formés à surveiller des systèmes clients comme des ordinateurs portables et de bureau, sans imposer de nouvelle formation
- CrowdStrike a confirmé avoir utilisé des ingénieurs existants plutôt que de recruter une nouvelle équipe de « cloud threat hunters »
- L’entreprise affirme qu’il était impossible de trouver des « cloud threat hunters » expérimentés pour un service nouveau, et de recruter des personnes déjà formées dans un domaine qui n’existait pas avant que CrowdStrike ne le développe
- Elle dit ne pas avoir rendu la nouvelle formation obligatoire, mais l’avoir proposée aux employés qui la souhaitaient
- Elle ajoute que les salariés reçoivent régulièrement des formations adaptées à leur poste
- Le SANS Institute propose depuis 2020, soit deux ans avant le lancement du service de CrowdStrike, des formations et des conférences sur la sécurité cloud
- CrowdStrike affirme que le service OverWatch a toujours fonctionné comme prévu et rejette les affirmations selon lesquelles le projet aurait été précipité ou les threat hunters privés des outils nécessaires
Code ancien et charge de travail en hausse
- Sego dit que du code écrit de manière provisoire pour faire avancer un projet n’était souvent pas amélioré par la suite
- Un ancien senior engineer affirme avoir demandé plus de 20 fois du temps pour corriger du vieux code, sans succès
- CrowdStrike rétorque que le développement est un processus itératif, et qu’il est courant dans l’industrie logicielle de déployer du code puis de l’améliorer en continu à partir de l’usage réel des produits
- Les anciens employés citent aussi la hausse de la charge de travail comme l’une des raisons expliquant l’absence d’amélioration de ce vieux code
- Certains disent avoir dû assumer davantage de tâches après des réductions d’effectifs et des réorganisations
- CrowdStrike a refusé de commenter la question des licenciements, mais dit que ses effectifs ont augmenté régulièrement chaque année
- Les dépenses de R&D sont passées de 371,3 millions de dollars sur l’exercice 2022 à 768,5 millions de dollars sur l’exercice 2024, principalement en raison de la hausse des effectifs
- L’entreprise dit recueillir, évaluer et prendre en compte les différents retours de ses équipes, tout en restant concentrée sur le maintien d’une culture de haute performance
- Elle ajoute avoir figuré parmi les Fortune 100 Best Companies to Work For au cours des quatre dernières années
Coûts et suites de la panne
- CrowdStrike attribue la panne de juillet à un défaut de mise à jour de Falcon Sensor
- L’incident a fait perdre plus de 21 milliards de dollars de capitalisation boursière à l’entreprise
- Plusieurs poursuites ont suivi, et Delta Air Lines a évalué ses pertes à 550 millions de dollars après l’annulation de milliers de vols, en évoquant une possible action en justice
- Le senior vice president Adam Meyers doit témoigner devant le Congrès en septembre 2024
- Michael Sentonas, president de CrowdStrike, a accepté en août, lors d’une convention de hackers, le prix du « Most Epic Fail », en disant qu’il était très important de reconnaître quand on s’était gravement trompé
- Le lien entre les problèmes de long terme évoqués par les anciens employés et la panne de juillet n’a pas encore été établi
1 commentaires
Commentaires Hacker News
Un article construit autour d’anciens employés mécontents, avec des phrases du genre « la vitesse était ce qui comptait le plus, et le contrôle qualité ne faisait pas partie de notre processus ni de nos conversations », semble ne pas valoir plus qu’une carte cadeau d’excuses GrubHub.
Je ne porte pas CrowdStrike dans mon cœur, mais quand quelqu’un a une rancœur et une occasion d’attirer l’attention, il peut dire n’importe quoi. En plus, cette personne était designer et n’était probablement pas directement impliquée dans le contrôle qualité.
L’article dit aussi que, sur 24 anciens employés, 10 avaient été licenciés ou touchés par des suppressions de postes, 14 étaient partis volontairement, et 3 n’étaient pas d’accord avec les autres témoignages. Joey Victorino a déclaré que CrowdStrike était « méticuleuse dans tout ce qu’elle faisait » ; au final, il y a très peu de certitudes.
Ils ont poussé le changement directement dans les environnements de production du monde entier, sans déploiement progressif, et n’avaient même pas de labo où le nouveau code était réellement installé et exécuté. On voit de la fumée, et plusieurs témoignages disent qu’il y a eu un incendie : c’est dans ce contexte qu’il faut lire cela.
Au contraire, ces employés sont sans doute plus susceptibles de parler franchement de la situation interne, et même s’ils ne travaillaient pas dans l’assurance qualité ou le contrôle qualité, ils peuvent connaître l’ambiance. Ce type d’information est plus crédible que les gens qui acquiescent à tout ce que dit l’entreprise.
On peut prétendre que Semafor fait mal son travail ou agit avec malveillance, mais ce n’est pas un argument facile à tenir quand le passage cité présente aussi des éléments contradictoires.
Si l’on entend cela d’un seul ancien employé, cela peut relever d’un cas personnel ; mais quand plusieurs personnes expriment la même plainte, il faut le prendre beaucoup plus au sérieux.
Les personnes mécontentes sont plus susceptibles de laisser un avis, et celles qui ont quitté CrowdStrike avaient probablement des griefs. Ce sont des données biaisées, mais elles restent utiles.
Je suis surpris de voir à quel point les commentaires ici balaient cela facilement. D’anciens employés, dont des ingénieurs, disent que la culture de développement dangereuse de leur ancienne entreprise a contribué à une panne mondiale majeure et à des incidents antérieurs.
Ces témoignages devraient être considérés comme crédibles, ou au moins comme des informations utiles, mais beaucoup semblent s’en prendre uniquement au designer UX qui a dit que « le contrôle qualité ne faisait pas partie de notre processus ».
Peut-être que beaucoup se projettent dans la phrase « la vitesse de sortie avant tout », autrement dit « move fast and break things ». Parce que la culture du plaisir de déployer du code, d’éteindre des incendies, d’avoir de l’impact, puis de laisser le nettoyage aux ingénieurs et managers suivants leur est familière.
Du point de vue de l’ère des taux zéro, ces échecs de processus pouvaient sembler non pas être des bugs, mais des fonctionnalités. L’accent mis sur la « qualité » pouvait aussi être vu comme une barrière pénible empêchant de s’amuser aux frais des clients.
Il y a quelque temps, un client avait commandé une solution sur mesure de haute sécurité basée sur un pilote noyau. Il faisait tourner une base de données importante sur un ordinateur hors ligne, et il fallait tracer tous les appels système afin d’alerter et d’enregistrer précisément toute modification de données. Les sauvegardes ne devaient jamais sortir, et des procédures de sûreté étaient aussi exigées avant l’installation sur site, comme vérifier si
ntdllde Windows était hooké. Exceptions, blocages et interblocages étaient inacceptables, et manquer ne serait-ce qu’un seul appel système aurait été catastrophique.Donc, à chaque modification du code du pilote, nous retestions selon une procédure définie sur 7 ordinateurs de bureau dotés de matériels différents, et le dernier test avant publication était encore plus large.
À cette aune, CrowdStrike est quasiment amateur. Ils n’ont rien apporté à la communauté sécurité, et leur niveau de recherche ressemble à celui d’un chercheur junior en sécurité. Leur tendance à exagérer ouvertement ou à tirer des conclusions hâtives n’est pas bien vue dans la communauté non plus.
Il faut regarder de vraies entreprises spécialisées comme Kaspersky et Checkpoint. Non seulement elles ont construit des solutions de sécurité éprouvées et de très haut niveau, mais elles ont aussi contribué gratuitement à la communauté avec des recherches de valeur, en découvrant par exemple des zero-days et en les signalant avant leur exploitation. CrowdStrike mérite les critiques.
Parmi les stratégies de réorganisation que j’ai vues se répéter pendant des années, celle qui m’a le plus marqué était : « nous allons former toute l’ingénierie pour que chacun soit immédiatement remplaçable dans chaque domaine ». C’est du surplace complet.
Les infrastructures logicielles critiques devraient être régulées comme les infrastructures physiques critiques. On ne se contente pas de croire que les gens qui construisent des bâtiments et des ponts « feront ce qu’il faut » ; on impose des réglementations et des inspections.
Si, quand un logiciel s’arrête, des millions de personnes dans le monde se retrouvent bloquées, alors c’est une infrastructure critique. Cette fois, c’était un « accident » ordinaire, mais si demain, dans un contexte de guerre, des acteurs malveillants tentaient de faire tomber des systèmes, cela pourrait être bien plus grave.
Quand un domaine est critique pour la sécurité, il faut l’examiner plus strictement que le reste, et ne pas le laisser aux processus d’assurance qualité autorégulés d’entreprises à but lucratif. Il faut davantage de revue avant d’appuyer sur le gros bouton.
Au passage, les phrases entre guillemets ne sont pas de moi : ce sont des objections que j’ai entendues de la part d’autres personnes quand j’évoquais la réglementation.
Le logiciel est presque toujours produit vite et à bas coût. Même la NASA a déjà vu une fusée exploser en vol à cause d’une erreur logicielle.
Hier matin, j’ai appris qu’une personne que je connaissais venait de décéder et que ses funérailles étaient prévues pour la semaine prochaine
Cette personne avait passé plus d’un mois à l’hôpital, puis a fait un AVC quelques jours seulement après être rentrée chez elle
Et je me suis souvenu qu’elle devait initialement subir une opération importante, mais que celle-ci avait été retardée à cause de la panne CrowdStrike. Il a fallu plusieurs semaines avant qu’un nouveau créneau soit trouvé et que l’opération ait lieu
Elle a été opérée ce jour-là, et je n’arrête pas de me demander si l’issue aurait été différente si elle n’était pas restée plusieurs semaines de plus à l’hôpital, dans le stress lié à son état et à son avenir
Ce n’est qu’un des millions de préjudices que cet incident a probablement causés, mais comme il n’est pas converti en argent, il n’est pas vraiment « comptabilisé »
Par exemple, si vous donniez un coup de pied dans le genou d’un enfant de 3 ans et le rendiez handicapé à vie, on vous traiterait évidemment de monstre. Mais si vous soutenez une réforme éducative qui écarte la langue des signes américaine de l’école, laissant des enfants sourds grandir sans langue pendant leur période de développement, nous n’avons même pas vraiment les mots pour exprimer l’ampleur cumulée et les dégâts d’un tel acte
Nous gérons très mal les préjudices distribués. L’une des grandes raisons est que nous ne voyons pas, et ne pouvons pas voir, l’ensemble des dommages concrets qu’ils provoquent
Je trouve douteux que la personne citée comme experte des processus d’ingénierie soit senior UX designer. Elle n’était probablement pas très proche du processus de déploiement de correctifs du noyau
Je ne cherche pas à justifier la gestion de la qualité chez CrowdStrike, mais dans plusieurs environnements de développement logiciel que j’ai connus, il était assez fréquent que la gestion de la qualité soit absente
En lisant l’article, on pourrait avoir l’impression que tous les projets logiciels sont bien testés, mais d’après mon expérience, la plupart sont publiés dans la précipitation
Pour des logiciels de divertissement ou des logiciels métier peu critiques, cela peut aller, mais pour des logiciels importants, c’est une très mauvaise idée. Malheureusement, l’attitude « aller vite » s’est propagée jusque dans des endroits où elle n’aurait pas dû exister
Le secteur donne l’impression d’un endroit où une poignée de personnes compétentes parvient, tant bien que mal, à faire tourner les systèmes, tandis que le reste révèle une incompétence technique stupéfiante. À chaque occasion, la direction privilégie les réductions de coûts à court terme au détriment de la qualité, ce qui accumule une terrible dette technique et des équipes surmenées et démotivées. Quand parler de problèmes de qualité vous vaut des sanctions, les gens finissent par ne plus s’en soucier
Certains anciens employés mécontents peuvent très bien parler de CrowdStrike d’une manière qui donne une mauvaise image de l’entreprise. Cela arrive dans toutes les sociétés
Mais CrowdStrike a désormais une crédibilité nulle. Je ne crois pas un mot de ce qu’ils disent
Tout ce qu’on sait sur CrowdStrike me rappelle Knight Capital. De petits problèmes de culture qui se transforment en dysfonctionnement complet, puis finissent par produire un bug capable de tuer l’entreprise
Le problème de trading qui a semé la confusion sur les marchés mercredi matin lui coûtait déjà ce montant, et Knight Capital Group a annoncé avoir perdu 440 millions de dollars en revendant toutes les actions achetées par erreur à cause d’une défaillance informatique
Une « défaillance »…
https://en.wikipedia.org/wiki/Therac-25
Dans mon ancienne entreprise, certains clients et assureurs en responsabilité poussaient fortement à l’adoption de CrowdStrike pour des raisons de conformité. BCG, en particulier, exigeait l’utilisation de CrowdStrike
Convaincre de ne pas utiliser CrowdStrike a été un vrai combat. Nous avons fini par y arriver, mais il a fallu beaucoup de réunions et de temps pour convaincre les différentes parties prenantes. Je pense que beaucoup de gens auraient simplement cédé et l’auraient déployé
J’ai travaillé dans une équipe qui déployait l’agent CrowdStrike dans une organisation, et l’un des plus gros problèmes était que le daemon générait une quantité énorme de logs, sans aucun paramètre permettant de les arrêter ou de les réduire