Je comprends qu’on trouve de l’humour dans ce désastre, mais je me demande ce qu’il en est de la responsabilité.
J’ai vu plusieurs fois sur HN qu’il aurait causé des milliards de dollars de pertes, mais pas encore beaucoup de discussions sur des procès.
Est-ce que la licence est à ce point blindée que les clients n’ont aucun recours ? Je peux le comprendre pour un particulier dont le PC est resté bloqué quelques heures/jours, mais il me paraît absurde que l’industrie accepte une exposition à un risque de ce niveau.
C’est aussi l’une des grandes raisons pour lesquelles le génie civil est considéré comme une discipline sérieuse. Si un pont s’effondre, il peut y avoir non seulement une responsabilité financière, mais aussi une responsabilité pénale, et les étudiants en génie civil apprennent à répétition qu’ils peuvent aller en prison s’ils agissent de manière contraire à l’éthique ou s’ils acceptent un risque inadmissible en tant qu’ingénieurs.
Les ingénieurs logiciels pourront-ils un jour atteindre ce niveau de responsabilité et de normes professionnelles ?
Le génie civil est différent en ce qu’il conçoit des produits physiques. Rien n’est conçu au plus près des limites, et tout intègre une marge de sécurité suffisante.
On calcule par exemple un pont rempli de camions pendant un ouragan avec un séisme en plus, puis on ajoute 20 %. Si l’on n’est pas sûr qu’une poutre tienne, on la fait plus grosse ; si le calcul est faux de 0,5 %, ce n’est pas très grave.
Si une faute de frappe dans le dossier de conception conduit à vouloir insérer une poutre de 150 pieds dans un espace de 15,0 pieds, l’entrepreneur demandera une vérification. L’effondrement d’un pont est donc presque certainement le résultat d’une négligence grave.
En programmation, à l’inverse, un simple < à la place de <= peut faire la différence entre un état parfaitement normal et des milliards de dollars de dégâts. Aucun programmeur sur Terre ne peut écrire une application d’une complexité non triviale avec une absence totale de défauts.
Même le micro-noyau seL4, qui met en avant une preuve formelle de correction, contient des bugs. Les compilateurs et les vérificateurs de preuves sont techniquement possibles, mais ils ne se plaignent pas si on leur demande de faire quelque chose de manifestement incorrect.
Accepter une responsabilité de fait illimitée pour la moindre petite erreur n’est pas quelque chose qu’une personne normale peut accepter.
Si l’on veut tenir les ingénieurs logiciels pour responsables, il faut d’abord trouver un moyen de distinguer les erreurs ordinaires commises de bonne foi de la négligence grave, et il sera très difficile de le formaliser.
Quand Delta a annoncé une action en justice pour 500 millions de dollars de pertes, CrowdStrike a répondu publiquement que, contractuellement, le plafond de responsabilité de CrowdStrike était de quelques millions de dollars seulement.
Ils ont ensuite envoyé une liste de ce qu’ils demanderaient lors de la discovery si le procès était lancé : plans de sauvegarde, plans de bascule, calendriers et résultats des tests, date du dernier exercice de restauration de sauvegarde, etc.
En gros, cela revenait à dire : « si vous nous attaquez, nous fouillerons vos pratiques IT suffisamment en profondeur pour vous embarrasser encore plus que nous, et nous montrerons que la faute venait de vous ».
Il existe des recours, mais comme dit, ils ne sont pas destinés aux gens ordinaires. Des entreprises intentent des procès contre CrowdStrike et continueront de le faire ; à la lecture des documents publiés par CrowdStrike, il semble très probable que les entreprises touchées gagnent.
Elles ont de fortes chances de convaincre un juge, un jury ou un arbitre que CrowdStrike a commis une négligence grave et a clairement causé aux entreprises des pertes directes ainsi qu’un préjudice indirect à leur réputation.
Honnêtement, je ne suis même pas sûr que CrowdStrike ira jusqu’au bout du contentieux. La plupart des affaires se régleront probablement à l’amiable, et on pourrait voir CrowdStrike s’effondrer au cours des prochaines années.
Beaucoup d’entreprises ont une assurance contre les événements qui interrompent leurs revenus. Comme l’assurance récolte d’un agriculteur ou l’assurance catastrophe d’un grand distributeur, il doit bien exister quelque chose pour les cas où l’effondrement d’une infrastructure ramène le chiffre d’affaires à zéro pendant un certain temps.
Même si toutes les personnes touchées réclamaient 100 % de leurs pertes à ClownStrike, le chiffre d’affaires de ClownStrike ne suffirait pas à les couvrir. Même si l’on voulait faire fermer l’entreprise, on ne pourrait pas récupérer un montant proche des pertes réelles.
Je me demande donc ce qu’on propose concrètement. Du code sans bug est quasiment impossible, et certains risques sont acceptés par l’utilisateur.
Pensez-vous vraiment qu’un logiciel doive obligatoirement être 100 % exempt de bugs avant d’être utilisé ? Comment le prouver ? Et la question suivante serait alors : à quel point votre propre code est-il propre pour que vous pensiez cela possible ?
C’est possible, mais la réponse, c’est le temps. Le génie civil a des milliers d’années d’histoire, alors que le génie logiciel est beaucoup plus jeune et que les fondations du domaine évoluent encore.
Au moins dans mon pays, depuis la fin des années 1970, il existait des projets de loi instaurant des licences pour les analystes systèmes, les programmeurs d’ordinateurs électroniques, les opérateurs de machines de traitement de données, les dactylographes (!)
Si ces lois avaient été adoptées, le développement logiciel de notre pays aurait pris des décennies de retard. Par exemple, l’un de ces projets voulait réserver « la manipulation et l’exploitation d’appareils ou de machines de traitement électronique, y compris les terminaux (dispositifs numériques ou visuels) » aux détenteurs d’une licence d’« opérateur de machines de traitement de données ».
Ce problème dépasse CrowdStrike : il illustre toute une approche de la sécurité qui consiste à acheter des produits de sécurité sur étagère pour satisfaire les régulateurs et les assureurs, sans vraiment se soucier de ce qu’ils font ni de leur fonctionnement.
Cela ne veut pas dire qu’il ne faut pas réglementer la technologie, mais le modèle actuel du « achetons ça pour nous décharger de la responsabilité » ne fonctionne pas.
Le pire, c’est que les personnes qui avaient probablement anticipé ce genre de problème — les services IT — n’ont sans doute rien pu faire. Il est très probable que la direction l’ait imposé à cause d’exigences liées à une « cyberassurance » ou à d’autres règles. C’est dingue.
J’ai vu beaucoup de bons responsables IT qui ressentaient les choses ainsi, mais d’après mon expérience, la plupart des services IT, une fois les cases nécessaires au contrat cochées, se souciaient assez peu de savoir si cela résolvait réellement le problème.
Dans un ancien emploi, un logiciel similaire à CrowdStrike a été installé sur mon poste de travail pendant le week-end, et à mon retour, les temps de compilation avaient ralenti de 20 %.
Je les mesurais à l’époque, donc j’avais des dizaines de relevés, et j’ai montré via des traces ETL que ce logiciel en était la cause, mais l’IT a refusé de l’admettre. Le contrat du fournisseur indiquait qu’il ne devait pas y avoir d’impact sur les performances pour notre charge de travail.
La plupart des services IT n’auraient probablement pas pu prévoir cela, et il est normal qu’ils n’aient pas construit toute leur stratégie de sécurité autour de cette possibilité. Je ne sais pas d’où vient ce récit.
Falcon apportait, et apporte encore, de vrais avantages de sécurité à ses clients. Cela ne veut pas dire qu’il élimine tous les risques, ni qu’il n’en crée pas lui-même.
Comme tout problème d’ingénierie, c’est littéralement un jeu de compromis. Cela ne devrait pas être étranger aux gens ici.
Soudain, HN est rempli d’experts en sécurité pétris de certitude rétrospective et de biais lié à l’événement le plus récent, qui expliquent comment les entreprises auraient pu éviter cette balle, sans prendre en compte les vraies balles qu’elles évitaient justement en utilisant Falcon au départ.
C’est quelque chose qui pourrait servir de preuve vidéo au tribunal ou dans un procès, et ce n’est pas drôle.
À l’origine, cela aurait sans doute été un moment fermé, entre passionnés de sécurité, mais c’est désormais public, et le grand public qui a subi de lourds préjudices peut s’en moquer à loisir.
Je n’ai absolument pas eu l’impression que le dirigeant de CrowdStrike prenait la situation à la légère. Au contraire, son discours semblait prendre la situation au sérieux, reconnaître qu’il s’agissait d’une énorme erreur, et accepter ce trophée comme un signe de honte ainsi qu’un avertissement pour les futurs employés de CrowdStrike.
Je pense que le fait que ce dirigeant ait accepté ce prix était vraiment une attitude très digne. Bien sûr, dire cela ne signifie absolument pas que CrowdStrike soit exonérée de sa responsabilité dans l’incident ni de son obligation d’indemnisation.
Ça pourrait être drôle sur un t-shirt.
When I use
REGEXP
I use it in my
KERNEL CODE
La tragédie et la comédie sont les deux faces d’une même pièce.
Les problèmes de sécurité informatique existaient déjà à l’époque de la guerre du Vietnam, et les États-Unis ont réellement travaillé à trouver un modèle efficace de sécurité informatique. Pourtant, nous vivons dans une société qui a pour ainsi dire effacé cela de sa mémoire.
Pourquoi un scanner doit-il tourner 24 h/24 et 365 jours par an au-dessus de tout ce qu’un ordinateur tente d’exécuter ?
Pourquoi les systèmes d’exploitation doivent-ils dépendre de droits périphériques ?
Blâmer CrowdStrike ne fait que détourner l’attention de l’échec de conception fondamental que nous ignorons chaque jour dans les systèmes d’exploitation comme Linux, macOS ou Windows.
Je continue de blâmer Microsoft : il n’est pas impossible d’exécuter le code mis à jour en dehors du noyau, et de n’utiliser le code en mode noyau que pour l’observation et l’action, pas pour la logique.
Je travaille dans l’IT, et j’étais le pauvre type d’astreinte au moment où Clown Strike a fait tomber la majeure partie de l’infrastructure.
Personnellement, le fait d’avoir tenu bon en refusant d’utiliser des conneries basées sur le cloud nous a probablement permis de rétablir la situation en quelques heures, plutôt qu’en quelques jours.
Ce qui m’inquiète pas mal, c’est que des gens comme les directeurs IT ne voient pas cela comme un problème et ne prennent aucune mesure pour empêcher ce genre de conneries ; on risque donc de devoir gérer bientôt une autre panne majeure liée au cloud.
Je répète jusqu’à l’écœurement que « seuls les idiots dépendent des ordinateurs des autres », et je suis d’accord à 100 % avec cette phrase.
C’est étrange que certains managers ou dirigeants comprennent pourquoi un point de défaillance unique est mauvais dans une infrastructure interne, tout en considérant qu’il est acceptable que les produits ou services d’un fournisseur externe deviennent ce point de défaillance unique.
On dirait que, dès qu’ils signent un contrat et paient, ils pensent que ce sont des surhumains, incapables de faire des erreurs contrairement aux ingénieurs internes, qui construisent et maintiennent le tout. Je ne comprends pas cette confiance mal placée.
Entièrement d’accord. Et en plus, je suis sidéré de voir les sommes absurdes payées pour des services cloud comme Azure VD.
Avec seulement une partie du budget cloud annuel, une entreprise pourrait construire elle-même une infrastructure très stable et capable de fonctionner hors ligne.
Le ton paraît extrêmement agressif. Même si tu dis des choses justes, je n’aurais probablement pas envie de travailler avec toi.
Peut-être que tu ferais mieux passer ton message en t’exprimant moins agressivement.
Quand des CTO idiots prennent leurs conseils dans des sommets de CTO, auprès de consultants aux incitations biaisées, et dans toutes sortes de conférences au hasard, il n’y a pas grand-chose à faire.
Les précédents lauréats du prix de l’« échec le plus épique » sont naturellement dominés par Microsoft.
On peut continuer à faire circuler la honte, mais si l’on considère que cette panne en production est due à de mauvais processus, Microsoft a clairement joué un rôle important ici aussi.
Je me demande vraiment comment le CEO et le CTO ont pu conserver leur poste après un tel fiasco.
Le 911 ne fonctionnait plus dans plusieurs villes et le fonctionnement des hôpitaux a ralenti au point d’être paralysé, mais ils ont le temps d’aller à la Defcon faire des blagues ?
Y a-t-il encore des hôpitaux dont les ordinateurs ne sont pas réparés ? Bien sûr, CS a tout gâché, mais à part indemniser les dégâts et changer les processus, je ne vois pas très bien ce qu’ils peuvent faire d’autre maintenant.
Avertir les gens pour qu’ils ne répètent pas la même erreur ne me semble pas être une mauvaise utilisation du temps.
Oui, CS mérite d’être critiquée ici, mais je pense que le fait même d’avoir mis CS dans des systèmes critiques comme le 911 était une grosse erreur.
Cela dit, la personne qui l’a fait savait probablement qu’elle pourrait échapper à toute responsabilité, donc elle n’avait sans doute aucune raison de s’en soucier.
1 commentaires
Avis sur Hacker News
Je comprends qu’on trouve de l’humour dans ce désastre, mais je me demande ce qu’il en est de la responsabilité.
J’ai vu plusieurs fois sur HN qu’il aurait causé des milliards de dollars de pertes, mais pas encore beaucoup de discussions sur des procès.
Est-ce que la licence est à ce point blindée que les clients n’ont aucun recours ? Je peux le comprendre pour un particulier dont le PC est resté bloqué quelques heures/jours, mais il me paraît absurde que l’industrie accepte une exposition à un risque de ce niveau.
C’est aussi l’une des grandes raisons pour lesquelles le génie civil est considéré comme une discipline sérieuse. Si un pont s’effondre, il peut y avoir non seulement une responsabilité financière, mais aussi une responsabilité pénale, et les étudiants en génie civil apprennent à répétition qu’ils peuvent aller en prison s’ils agissent de manière contraire à l’éthique ou s’ils acceptent un risque inadmissible en tant qu’ingénieurs.
Les ingénieurs logiciels pourront-ils un jour atteindre ce niveau de responsabilité et de normes professionnelles ?
On calcule par exemple un pont rempli de camions pendant un ouragan avec un séisme en plus, puis on ajoute 20 %. Si l’on n’est pas sûr qu’une poutre tienne, on la fait plus grosse ; si le calcul est faux de 0,5 %, ce n’est pas très grave.
Si une faute de frappe dans le dossier de conception conduit à vouloir insérer une poutre de 150 pieds dans un espace de 15,0 pieds, l’entrepreneur demandera une vérification. L’effondrement d’un pont est donc presque certainement le résultat d’une négligence grave.
En programmation, à l’inverse, un simple
<à la place de<=peut faire la différence entre un état parfaitement normal et des milliards de dollars de dégâts. Aucun programmeur sur Terre ne peut écrire une application d’une complexité non triviale avec une absence totale de défauts.Même le micro-noyau seL4, qui met en avant une preuve formelle de correction, contient des bugs. Les compilateurs et les vérificateurs de preuves sont techniquement possibles, mais ils ne se plaignent pas si on leur demande de faire quelque chose de manifestement incorrect.
Accepter une responsabilité de fait illimitée pour la moindre petite erreur n’est pas quelque chose qu’une personne normale peut accepter.
Si l’on veut tenir les ingénieurs logiciels pour responsables, il faut d’abord trouver un moyen de distinguer les erreurs ordinaires commises de bonne foi de la négligence grave, et il sera très difficile de le formaliser.
Ils ont ensuite envoyé une liste de ce qu’ils demanderaient lors de la discovery si le procès était lancé : plans de sauvegarde, plans de bascule, calendriers et résultats des tests, date du dernier exercice de restauration de sauvegarde, etc.
En gros, cela revenait à dire : « si vous nous attaquez, nous fouillerons vos pratiques IT suffisamment en profondeur pour vous embarrasser encore plus que nous, et nous montrerons que la faute venait de vous ».
Elles ont de fortes chances de convaincre un juge, un jury ou un arbitre que CrowdStrike a commis une négligence grave et a clairement causé aux entreprises des pertes directes ainsi qu’un préjudice indirect à leur réputation.
Honnêtement, je ne suis même pas sûr que CrowdStrike ira jusqu’au bout du contentieux. La plupart des affaires se régleront probablement à l’amiable, et on pourrait voir CrowdStrike s’effondrer au cours des prochaines années.
Même si toutes les personnes touchées réclamaient 100 % de leurs pertes à ClownStrike, le chiffre d’affaires de ClownStrike ne suffirait pas à les couvrir. Même si l’on voulait faire fermer l’entreprise, on ne pourrait pas récupérer un montant proche des pertes réelles.
Je me demande donc ce qu’on propose concrètement. Du code sans bug est quasiment impossible, et certains risques sont acceptés par l’utilisateur.
Pensez-vous vraiment qu’un logiciel doive obligatoirement être 100 % exempt de bugs avant d’être utilisé ? Comment le prouver ? Et la question suivante serait alors : à quel point votre propre code est-il propre pour que vous pensiez cela possible ?
Au moins dans mon pays, depuis la fin des années 1970, il existait des projets de loi instaurant des licences pour les analystes systèmes, les programmeurs d’ordinateurs électroniques, les opérateurs de machines de traitement de données, les dactylographes (!)
Si ces lois avaient été adoptées, le développement logiciel de notre pays aurait pris des décennies de retard. Par exemple, l’un de ces projets voulait réserver « la manipulation et l’exploitation d’appareils ou de machines de traitement électronique, y compris les terminaux (dispositifs numériques ou visuels) » aux détenteurs d’une licence d’« opérateur de machines de traitement de données ».
Ce problème dépasse CrowdStrike : il illustre toute une approche de la sécurité qui consiste à acheter des produits de sécurité sur étagère pour satisfaire les régulateurs et les assureurs, sans vraiment se soucier de ce qu’ils font ni de leur fonctionnement.
Cela ne veut pas dire qu’il ne faut pas réglementer la technologie, mais le modèle actuel du « achetons ça pour nous décharger de la responsabilité » ne fonctionne pas.
Le pire, c’est que les personnes qui avaient probablement anticipé ce genre de problème — les services IT — n’ont sans doute rien pu faire. Il est très probable que la direction l’ait imposé à cause d’exigences liées à une « cyberassurance » ou à d’autres règles. C’est dingue.
Dans un ancien emploi, un logiciel similaire à CrowdStrike a été installé sur mon poste de travail pendant le week-end, et à mon retour, les temps de compilation avaient ralenti de 20 %.
Je les mesurais à l’époque, donc j’avais des dizaines de relevés, et j’ai montré via des traces ETL que ce logiciel en était la cause, mais l’IT a refusé de l’admettre. Le contrat du fournisseur indiquait qu’il ne devait pas y avoir d’impact sur les performances pour notre charge de travail.
Falcon apportait, et apporte encore, de vrais avantages de sécurité à ses clients. Cela ne veut pas dire qu’il élimine tous les risques, ni qu’il n’en crée pas lui-même.
Comme tout problème d’ingénierie, c’est littéralement un jeu de compromis. Cela ne devrait pas être étranger aux gens ici.
Soudain, HN est rempli d’experts en sécurité pétris de certitude rétrospective et de biais lié à l’événement le plus récent, qui expliquent comment les entreprises auraient pu éviter cette balle, sans prendre en compte les vraies balles qu’elles évitaient justement en utilisant Falcon au départ.
C’est quelque chose qui pourrait servir de preuve vidéo au tribunal ou dans un procès, et ce n’est pas drôle.
À l’origine, cela aurait sans doute été un moment fermé, entre passionnés de sécurité, mais c’est désormais public, et le grand public qui a subi de lourds préjudices peut s’en moquer à loisir.
Je pense que le fait que ce dirigeant ait accepté ce prix était vraiment une attitude très digne. Bien sûr, dire cela ne signifie absolument pas que CrowdStrike soit exonérée de sa responsabilité dans l’incident ni de son obligation d’indemnisation.
When I use
REGEXP
I use it in my
KERNEL CODE
La tragédie et la comédie sont les deux faces d’une même pièce.
Via xcancel : https://xcancel.com/singe/status/1822324795645575263
Les problèmes de sécurité informatique existaient déjà à l’époque de la guerre du Vietnam, et les États-Unis ont réellement travaillé à trouver un modèle efficace de sécurité informatique. Pourtant, nous vivons dans une société qui a pour ainsi dire effacé cela de sa mémoire.
Pourquoi un scanner doit-il tourner 24 h/24 et 365 jours par an au-dessus de tout ce qu’un ordinateur tente d’exécuter ?
Pourquoi les systèmes d’exploitation doivent-ils dépendre de droits périphériques ?
Blâmer CrowdStrike ne fait que détourner l’attention de l’échec de conception fondamental que nous ignorons chaque jour dans les systèmes d’exploitation comme Linux, macOS ou Windows.
Je continue de blâmer Microsoft : il n’est pas impossible d’exécuter le code mis à jour en dehors du noyau, et de n’utiliser le code en mode noyau que pour l’observation et l’action, pas pour la logique.
Je travaille dans l’IT, et j’étais le pauvre type d’astreinte au moment où Clown Strike a fait tomber la majeure partie de l’infrastructure.
Personnellement, le fait d’avoir tenu bon en refusant d’utiliser des conneries basées sur le cloud nous a probablement permis de rétablir la situation en quelques heures, plutôt qu’en quelques jours.
Ce qui m’inquiète pas mal, c’est que des gens comme les directeurs IT ne voient pas cela comme un problème et ne prennent aucune mesure pour empêcher ce genre de conneries ; on risque donc de devoir gérer bientôt une autre panne majeure liée au cloud.
Je répète jusqu’à l’écœurement que « seuls les idiots dépendent des ordinateurs des autres », et je suis d’accord à 100 % avec cette phrase.
On dirait que, dès qu’ils signent un contrat et paient, ils pensent que ce sont des surhumains, incapables de faire des erreurs contrairement aux ingénieurs internes, qui construisent et maintiennent le tout. Je ne comprends pas cette confiance mal placée.
Avec seulement une partie du budget cloud annuel, une entreprise pourrait construire elle-même une infrastructure très stable et capable de fonctionner hors ligne.
Peut-être que tu ferais mieux passer ton message en t’exprimant moins agressivement.
Liste des précédents lauréats des Pwnie Awards pour comparaison : https://en.wikipedia.org/wiki/Pwnie_Awards
On peut continuer à faire circuler la honte, mais si l’on considère que cette panne en production est due à de mauvais processus, Microsoft a clairement joué un rôle important ici aussi.
Je me demande vraiment comment le CEO et le CTO ont pu conserver leur poste après un tel fiasco.
Le 911 ne fonctionnait plus dans plusieurs villes et le fonctionnement des hôpitaux a ralenti au point d’être paralysé, mais ils ont le temps d’aller à la Defcon faire des blagues ?
Avertir les gens pour qu’ils ne répètent pas la même erreur ne me semble pas être une mauvaise utilisation du temps.
Cela dit, la personne qui l’a fait savait probablement qu’elle pourrait échapper à toute responsabilité, donc elle n’avait sans doute aucune raison de s’en soucier.