Une approche ‘cobaye’ pour tester les logiciels pourrait entraîner des actions collectives contre les entreprises technologiques
Reconnaître publiquement un échec demande du courage. Dans une tentative de limiter les dommages à la réputation de son entreprise de cybersécurité, le président de CrowdStrike, Michael Sentonas, a fait preuve d’audace en acceptant un prix pour le Plus Grand Échec lors des récents Pwnie Awards. Cette stratégie a semblé porter ses fruits : Sentonas a été acclamé par les participants de l’événement DEF CON pour avoir reconnu publiquement les erreurs de son entreprise.
« Ce n’est certainement pas un prix dont on peut être fier, » a déclaré Sentonas lors de son discours d’acceptation. « Je pense que l’équipe a été surprise quand j’ai dit tout de suite que je viendrais le chercher parce que nous avons fait une énorme erreur. Nous l’avons reconnu à plusieurs reprises, et il est crucial de l’admettre quand on réussit, mais aussi quand on se trompe gravement, ce que nous avons fait dans ce cas. »
Cependant, au-delà de ce coup de communication astucieux, l’incident de CrowdStrike soulève des questions sérieuses. Le 19 juillet, le monde a connu l’une des plus grandes pannes informatiques de l’histoire, causée par une mise à jour défectueuse du scanner de vulnérabilités de CrowdStrike, le Falcon Sensor, qui a provoqué le crash de 8,5 millions de systèmes fonctionnant sous Microsoft Windows. À l’échelle mondiale, l’infrastructure informatique a failli, entraînant des perturbations et des pertes financières pour des millions d’individus et d’organisations.
Événement le plus grave depuis l’attaque NotPetya en 2022, son impact a été colossal : la mise à jour défectueuse a causé des pannes informatiques mondiales qui ont perturbé le transport aérien, le secteur bancaire, la diffusion, les hôtels, les hôpitaux et d’autres services essentiels. Les pertes assurées sont estimées à plus de 10 milliards de dollars, tandis que les pertes réelles pourraient être bien plus élevées, des milliers de PME n’ayant pas de couverture.
La question de la prévisibilité sera centrale pour déterminer où repose la responsabilité. De nombreuses personnes savaient que ce logiciel était crucial pour des organisations interconnectées à travers le monde et qu’elles seraient gravement affectées par une mise à jour défectueuse. Il est donc évident que les fournisseurs devraient disposer de procédures adéquates pour mettre à jour les logiciels, y compris des protocoles sur la manière dont chaque mise à jour est développée et testée avant d’être distribuée aux utilisateurs.
L’incident de CrowdStrike était-il un événement ‘Cygne Noir’ ?
Alors, cet incident était-il un événement imprévisible, au-delà de ce qui pourrait raisonnablement être anticipé ? Ces événements se caractérisent généralement par leur rareté, la gravité de leur impact et la perception générale qu’ils étaient évidents en rétrospective.
Les opinions divergent sur la question de savoir si des événements comme celui de CrowdStrike deviennent plus fréquents et donc plus prévisibles. Il est certain que les innovateurs qui expérimentent de manière désordonnée sont plus susceptibles d’augmenter l’incidence de tels événements, les rendant moins imprévisibles. Bien que des restrictions puissent freiner la créativité, les innovateurs qui ne prennent pas les précautions nécessaires pour éviter des événements prévisibles pourraient également faire face à de graves conséquences juridiques.
Le débat fait rage sur les processus de test qui devraient être obligatoires pour ceux qui lancent des mises à jour de cybersécurité, surtout lorsque la rapidité de ces mises à jour est nécessaire pour se protéger contre de nouvelles menaces. En expliquant la vulnérabilité potentielle des différents systèmes, les commentateurs de l’industrie informatique soulignent invariablement que ces mises à jour peuvent devoir être lancées plusieurs fois par jour.
De même, d’autres systèmes interdépendants peuvent également être mis à jour plusieurs fois par jour, avec des appareils recevant des mises à jour dans un ordre ou un calendrier différent. Les commentateurs soutiennent que le monde réel ne peut pas offrir un environnement de test parfait, et si les mises à jour échouent, une exposition de tiers et de quatrièmes parties peut être attendue, ainsi qu’un potentiel effondrement de la chaîne d’approvisionnement. Du point de vue juridique, cette approche « cobaye » de la technologie crée un scénario cauchemardesque d’actions collectives potentielles.
Risques de points de défaillance uniques
Les risques sont encore amplifiés par toute technologie ayant une part de marché importante. Ici, des points de défaillance uniques peuvent entraîner des événements systémiques qui produisent finalement des réclamations simultanées d’un très grand nombre de plaignants : un petit rouage défectueux peut paralyser l’infrastructure informatique mondiale.
Un tel point de défaillance unique peut avoir un impact extraordinairement large avec des pertes cumulées potentiellement catastrophiques. D’un point de vue juridique, des questions se posent sur la manière de réduire les risques d’un point de défaillance unique dans une chaîne d’approvisionnement informatique complexe et mondiale, et si ces risques sont correctement évalués.
Des problèmes d’agence et de délégation se posent également. La sécurité représentée d’un système lors de l’interface peut non seulement bloquer le système, mais aussi l’exposer à des attaques. En termes d’ampleur et d’échelle, l’effet net de la panne de CrowdStrike était équivalent à une attaque sur une chaîne d’approvisionnement mondiale par un acteur malveillant.
Peut-être que les problèmes rencontrés à la suite de NotPetya et d’autres cyberattaques malveillantes préfigurent simplement l’impact que pourraient avoir de futurs événements cybernétiques.
Microsoft aurait-il pu rejeter la mise à jour ?
Il est également important de considérer le lien entre CrowdStrike et Microsoft. En particulier, la question se pose de savoir si le système d’exploitation de Microsoft était capable de rejeter la mise à jour et de revenir à une version antérieure. Si c’était le cas, pourquoi cela ne s’est-il pas produit ?
Bien qu’il ne soit pas clair comment le système Microsoft aurait pu revenir à la version précédente pour atteindre ce résultat, les experts en IA nous rappellent constamment que le système peut être comparé à un super cerveau qui se calibre pour résoudre des problèmes. Si cela est vrai, ce super cerveau est-il toujours engagé ou écoutons-nous les mauvais experts en IA ?
Dans un récent article de blog, des commentateurs de l’industrie évoquent les commentaires de Microsoft sur le défi que représentent les fournisseurs tiers qui déploient des mises à jour fonctionnant dans le système d’exploitation de bas niveau. Ils suggèrent que des modifications pourraient être apportées pour que les applications tierces fonctionnent plus haut dans le système d’exploitation, facilitant ainsi la gestion de tels problèmes : par exemple, la capacité de rejeter des mises à jour qui provoquent des écrans bleus et la nécessité de revenir à la version précédente.
Échecs prévisibles
Dans le secteur informatique, certains soutiennent que la catastrophe aurait pu être évitée par des tests plus rigoureux des mises à jour de sécurité et par le déploiement échelonné des mises à jour à des groupes plus restreints ou à des « cercles » de mise à niveau. D’un point de vue juridique, il est impossible d’ignorer le fait que tout semble trop prévisible, surtout compte tenu des discussions interminables au fil des ans sur les redoutables écrans bleus.
Étant donné la complexité, la nouveauté (et la prévisibilité) des pratiques de l’industrie, ainsi que l’ampleur des risques associés (y compris les droits et obligations juridiques), le secteur informatique doit prendre pleinement en compte ses responsabilités pour prévenir d’autres pertes catastrophiques résultant d’échecs systémiques et de risques de cybersécurité.
