Aller au contenu

« Discussion:Panne informatique mondiale de juillet 2024 » : différence entre les versions

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Contenu supprimé Contenu ajouté
JuanManuel Ascari (discuter | contributions)
Évaluation : Multiprojet (B) Informatique|moyenne Sécurité informatique|élevée Technologies|moyenne)
Ligne 192 : Ligne 192 :


Homogénéité et uniformité ont valeurs d'équivalences et, dans ce secteur, peuvent faire références à des notions de standards et de normes, censés fournir quelques garanties. [[Utilisateur:Darviche|Darviche]] ([[Discussion utilisateur:Darviche|discuter]]) 26 juillet 2024 à 16:50 (CEST)
Homogénéité et uniformité ont valeurs d'équivalences et, dans ce secteur, peuvent faire références à des notions de standards et de normes, censés fournir quelques garanties. [[Utilisateur:Darviche|Darviche]] ([[Discussion utilisateur:Darviche|discuter]]) 26 juillet 2024 à 16:50 (CEST)
:{{u|Darviche}} centralisation est inadéquat ici. Cela n'est pas dans la source. Si c'était une panne physique des baies du cloud oui ça aurait sens. Le cloud c'est des milliers des machines virtuelles indépendantes les unes des autres qui sont sur le même espace physique sans lien entre elle. L'article le dit c'est le fait d'avoir uniformiser les structures, d'utiliser les mêmes logiciels crowdriver, cloud qui crée un point de fragilité unique. C'est justement la standardisation qui ici est dit poser problème. Si un des élements du standard devient défectueux c'est provoque une panne identique sur tout les systémes ayant la même structure [[Spécial:Contributions/176.167.210.59|176.167.210.59]] ([[Discussion utilisateur:176.167.210.59|discuter]]) 27 juillet 2024 à 11:24 (CEST)

Version du 27 juillet 2024 à 11:24

Microsoft Azure

D’après Bloomberg :

« To add to the confusion, an apparently separate incident involving Microsoft’s Azure cloud services also caused disruption on Friday. In a status update, Microsoft said it had fixed the underlying issue but that users would still feel “residual impact.” »

« While cybersecurity professionals say CrowdStrike’s technology is a strong way to defend against ransomware, its cost — which in some cases can be more than $50 per machine — means that most organizations don’t install it on all of their computers. What that means, however, is that the computers that have the software installed on them are among the most important to protect, and if they go down, key services can fall with them. »

— (en) « Global IT Collapse Puts Cyber Firm CrowdStrike in Spotlight », Bloomberg News,‎ (lire en ligne [archive du ] Accès payant, consulté le )

Il est clair que cela concerne un logiciel de CrownStrike qui est installé sur les postes de travail et non sur des serveurs Microsoft Azure. J’ai donc retiré ce paragraphe sourcé par la RTBF qui n'a pas mis à jour son article ou qui confond les deux évènements. — Thibaut (discuter) 19 juillet 2024 à 15:47 (CEST)[répondre]

Il peut avoir des clients qui ont installé CrowdStrike sur Azure. Trigenibinion (discuter) 19 juillet 2024 à 16:29 (CEST)[répondre]
Alors comme ça, on jette un œil sur mes contributions ? Émoticône
Le logiciel en question est Falcon Sensor qui est un logiciel « endpoint detection and response » (ou de « protection des terminaux »), il ne peut être installé que sur des postes de travail d'utilisateurs finaux (d'où le endpoint).
Un paragraphe à part sur Azure peut être rédigé sans faire de lien entre les deux évènements, comme ce qui est fait sur la Wikipédia en anglais. — Thibaut (discuter) 19 juillet 2024 à 16:35 (CEST)[répondre]
C'est le CEO de CrowdStrike qui a mentionné cela (le client installe Windows sur Azure avec Falcon). Trigenibinion (discuter) 19 juillet 2024 à 16:39 (CEST)[répondre]
Vous avez un lien ? La seule déclaration du CEO que j'ai trouvée est celle-ci. — Thibaut (discuter) 19 juillet 2024 à 16:46 (CEST)[répondre]
Ok c'est cette entrevue par CNBC, il disent texto :

« — I want to be sure about this. This did or did not get to Azure, which is Microsoft's cloud? Because if it did, maybe that would explain things, but maybe they're separate?
— Well, Azure can run -- customers running Azure and they can run our software there. If there was a customer that was running in Azure that had our software, it could have been impacted, but that's the extent of what i know specific to Microsoft piece.
— You do not know whether this is impacting Azure or not?
— Well, when you say Azure, it has impacted customers that are running in Azure. that's what i know.
 »

On peut effectivement installer Windows sur un serveur Azure et installer Falcon Sensor dessus, mais ce n'est pas spécifique à Azure, on peut aussi le faire sur AWS, OVH, etc.
Ça me parait sans lien avec la panne qui a été signalée par Microsoft. — Thibaut (discuter) 19 juillet 2024 à 17:00 (CEST)[répondre]
On ne peut pas ATTENDRE un peu que des sources de synthèse apparaissent ? Il faut donc tout traiter sur-le-champ, et enquêter nous même ? Ce qui n'est pas clair ou douteux peut ATTENDRE. Jean-Christophe BENOIST (discuter) 19 juillet 2024 à 17:00 (CEST)[répondre]
Oui, ajouter des informations dans l'article à partir de vidéos d'entrevues à chaud, c'est pas terrible.
Je préfère attendre que ce soit analysé avec du recul par des sources secondaires comme Bloomberg. — Thibaut (discuter) 19 juillet 2024 à 17:04 (CEST)[répondre]
Le nuage de Microsoft est tombé le même jour pour une raison inconnue, ce qui expliquerait les problèmes des compagnies aériennes avec Office 365. Trigenibinion (discuter) 26 juillet 2024 à 12:15 (CEST)[répondre]

Réparation

Dans certain cas systèmes peuvent être réparés en réinitialisant l'ordinateur (le fichier de contenu qui pose problème est remplacé automatiquement par la version antérieure). Dans d'autre cas, il faut faire des manipulations manuelles, ce qui peut prendre quelques jours a déployer sur toutes les machines. Trigenibinion (discuter) 19 juillet 2024 à 18:13 (CEST)[répondre]

Quelques sources indiquent que la réparation totale pourrait prendre des semaines. Trigenibinion (discuter) 19 juillet 2024 à 23:55 (CEST)[répondre]
Quelques sources indiquent qu'il faut réinitialiser jusqu'a 15 fois dans le cas "automatique". Trigenibinion (discuter) 20 juillet 2024 à 00:33 (CEST)[répondre]

Réactions

Avec aussi peu de recul ? Demain on n'en parle plus. Attendons de voir ce qu'en diront les sources de synthèse, et elles viendront un jour si c'est un Y2K --Jean-Christophe BENOIST (discuter) 19 juillet 2024 à 23:04 (CEST)[répondre]
Y2K pourrait avoir été un beaucoup gros probleme si l'on n'avait pas dépensé des centaines de milliards de dollars pendant des années pour s'en préparer.
Techniquement, la seule similarité que l'on peut trouver c'est d'écrire "PIC 99" en COBOL. Trigenibinion (discuter) 19 juillet 2024 à 23:30 (CEST)[répondre]
La fin du monde Unix est en 2038 (Y2K 2.0) Trigenibinion (discuter) 20 juillet 2024 à 01:33 (CEST)[répondre]

Rapport du Homeland Security et POV pushing

Darviche persiste sur ses deux modifications (1 et 2) à ajouter un passage sur un rapport du CSRB (dépendant du département de la Sécurité intérieure des États-Unis). Je noterai que vu que ce n'est pas le sujet de l'article, il n'a rien à faire ici ; que l'auteur des modifications ne fournit aucune preuve d'un lien avec le sujet de l'article (à part un vague « condition de préexistence de la panne » en commentaire de la 2e modification) ; que le sujet parle de la sécurité du réseau de Microsoft, tandis que les conséquences de cette panne sont dues à leur non-disponibilité ; et que la cause de la panne est une mise à jour fautive d'un logiciel tiers. Le lien entre ce rapport et la panne n'a pas pu être établie par Darviche, donc ça s'apparente clairement à de l'imposition de point de vue. Comme indiqué dans ma précédente révocation, cet article n'est pas le lieu pour régler ses comptes avec Microsoft ou une autre entreprise. 0xC0000005 (discuter) 20 juillet 2024 à 06:32 (CEST)[répondre]

Aucun lien avec l'article ? C'est vous qui persistez à ne voir "aucun lien avec l'article". Ouvrez les yeux. Il y a une panne de sécu informatique mondiale sur un système bien identifié et on se presse de jeter la faute à un sous-traitant. Inutile d'essayer de passer le rapport sous silence ou de minimiser les responsabilités. La chaîne de responsabilité n'est pas qu'un bête problème technique comme vous essayez de le faire croire. Je vous invite à agréger davantage de source pour améliorer l'article au lieu de le caviarder. Darviche
Vous persistez à imposer votre point de vue en ajoutant à nouveau cette section, toujours avec un résumé de modification pas clair (« rapport du CSRB en lien avec les événements »). Je rappelle, d'une part, que l'incident n'a pas été causé par une cyberattaque contre les systèmes de CrowdStrike ou de Microsoft, donc parler d'un « précédent » parlant de la mauvaise sécurité de Microsoft n'est absolument pas approprié pour cet article. D'autre part, un article des Échos indique que CrowdStrike compte environ 23 000 clients au 28 février 2024. Microsoft n'est donc pas la seule entreprise à être affectée. L'argument du « sous-traitant » est caduque : Microsoft n'est pas responsable des dégâts causés par des logiciels tiers défectueux sur ses systèmes d'exploitation, loin de là. Pareil pour la supposée « chaîne de responsabilité ». Personne ici ne minimise les responsabilités, que le PDG de CrowdStrike a lui-même admis. Enfin, le lien entre un rapport suivant une intrusion dans Microsoft Online Exchange de 2023 et une panne un an après sur des systèmes utilisant Windows ? L'article de CNN ne l'établit pas, le rapport du CSRB non plus. C'est du hors sujet et la section sur le rapport n'a rien à faire dans l'article. Je m'en tiens à mon avis précédent selon lequel vous faites de l'imposition de point de vue.
Prétendre que je « caviarde » alors que je vous ai fait part d'un problème au niveau du contenu que vous avez ajouté dans l'article relève de la mauvaise foi. M'inviter à « agréger davantage de source [sic] » également (sachant que ce n'est pas le sujet de cette discussion). 0xC0000005 (discuter) 20 juillet 2024 à 07:56 (CEST)[répondre]
Je soutiens également @0xC0000005, voir aussi mes remarques et arguments sur le bistro du jour. Jean-Christophe BENOIST (discuter) 20 juillet 2024 à 10:31 (CEST)[répondre]

Précédents

Les commentaires rapportant des problèmes sur les produits de crowdstrike déployés sur Linux sont à vérifier. La première source est un commentaire du labo d'une civic-tech, dans un forum, paru il y a 13h et qui indique "Debian stable running version n-1, I think". Le commentaire sur Rocky Linux remonte au 13 Mai et le bug apparaît quand ce sont les utilisateurs qui font l'upgrade de Rocky. à revérifier donc. Darviche (discuter) 20 juillet 2024 à 04:44 (CEST)[répondre]

Hindustan Times informe que le CEO était CTO de McAfee quand ils ont eu une panne similaire en 2010. Trigenibinion (discuter) 20 juillet 2024 à 14:01 (CEST)[répondre]

Bonjour, je pense qu'il serait plus logique de déplacer le contenu de la section Précédents vers la section Contexte. Qu'en pensez vous ? — VVLLAACC 21 juillet 2024 à 11:10 (CEST)[répondre]

Dans le sens où ça donnerait des pistes à des analystes forensic, oui, mais ceux là saurait où aller chercher. Je pense que le lecteur a besoin de comprendre et de connaître l'état de la situation plus générale, notamment la gravité et l'ampleur du phénomène, avant d'entrer dans le détail et de procéder à l'analyse contextuelle. Darviche (discuter) 21 juillet 2024 à 19:40 (CEST)[répondre]
À mon sens « l'état de la situation plus générale, notamment la gravité et l'ampleur du phénomène » est le rôle du Résumé Introductif, et non d'une des sections de l'article en particulier. Le lecteur aura donc déjà ces éléments généraux s'il lit la section Contexte — VVLLAACC 21 juillet 2024 à 19:49 (CEST)[répondre]
les références fournies dans la section Précédents sont beaucoup moins solides que les évènements qui ont été constatés. Darviche (discuter) 21 juillet 2024 à 20:09 (CEST)[répondre]
Utilise le modèle [source insuffisante] sur les éléments concernés, on peut toujours améliorer le contenu — VVLLAACC 21 juillet 2024 à 20:23 (CEST)[répondre]

Préventions (utilité encyclopédique?)

Hello! Wikipedia comme conseiller informatique pour la prévention d'incident d'exploitation? Pourquoi les OS non windows ne sont pas affectés par une MAJ d'un produit pour OS Windows? L'opportunité d'en mettre une couche sur les démêlés d'actualité entre MS et l'UE... Est ce pertinent? Est ce utile à cet article? (en admettant qu'on a suffisamment de recul pour débuter ce type de rédaction aujourd'hui). Mon avis est Non au deux questions. Je peux argumenter davantage si nécessaire. Mais je cherche plutôt un minimum de consensus pour la supprimer en l'état, ça serait tout simplement plus simple. Les contributeurs en.wikipedia n'ont par exemple pas (encore?!) ce type de section, par contre ils ont su lier 3 articles génériques qui pourraient s'assimiler à de la prévention : IT risk management, Patch management, Security management. Illustration de l'ampleur du sujet « Préventions » dans un tel contexte! Est ce raisonnable ici?! ;-)

Chronomiam (discuter) 22 juillet 2024 à 20:55 (CEST)[répondre]

Je rejoins cet avis, je pense même qu'il faudrait faire un nettoyage global de la section Correctifs… — VVLLAACC 23 juillet 2024 à 13:01 (CEST)[répondre]
J'ai le même avis. - Evynrhud (discuter) 23 juillet 2024 à 13:04 (CEST)[répondre]
Notification Chronomiam + Notification Evynrhud : j'ai souligné les passages qui me semblent problématiques avec différents modèles (suppositions avec verbes au conditionnel, infos qui semblent anecdotiques, etc.). Malheureusement, ne maîtrisant pas bien le sujet, je ne me sens pas de faire plus. — VVLLAACC 23 juillet 2024 à 13:35 (CEST)[répondre]
Sur la section "Intel", il faudrait faire aussi mention au cas IPMI. Sur des motherboards AMD Supermicro il y a eu derniérement des problémes de sécurité, alors peut-être la seule option actuellement valable est vPro. Est-ce que cela veut dire que les clients Mac ne sont pas une option dans beaucoup de cas? Trigenibinion (discuter) 23 juillet 2024 à 15:59 (CEST)[répondre]
en.wikipedia est plus politisé. Ce qui m'interesse est comment on évite que cela se reprodusse.
Le fichier problematique a été envoyé seulement à Windows. Linux aurait pu crasher, Mac aurait pu rester sans protection. Trigenibinion (discuter) 23 juillet 2024 à 16:05 (CEST)[répondre]
en.wikipedia mentionne aussi l'excuse UE et la prévention sur Linux. Trigenibinion (discuter) 23 juillet 2024 à 16:15 (CEST)[répondre]
J'ai créé une section dédiée au point MS / UE (antitrust) pour que ça soit plus clair.
J'ai supprimé ce qui restait de préventions qui s'était déplacé dans la section correctif, encore une fois l'intérêt de transposer l'incident sur des OS non windows n'a pas d'intérêt direct pour cet article. Surtout si c'est partiel et / ou partial, voir erroné avec confusion IME et Vpro. Mieux vaut s'abstenir à mon avis. Chronomiam (discuter) 23 juillet 2024 à 20:10 (CEST)[répondre]
Ca a de l'intérêt. On pourrait remplacer quelques machines par des Macs, et si CrowdStrike change leur implémentation ou s'il y a des alternatives par Linux. Trigenibinion (discuter) 23 juillet 2024 à 20:18 (CEST)[répondre]
D’accord avec Chronomiam, WP:Wikipédia n'est pas un guide pratique, Wikipédia n'a pas à conseiller des alternatives à CrowdStrike. — Thibaut (discuter) 23 juillet 2024 à 20:41 (CEST)[répondre]
CrowdStrike sur Mac ou Linux ne sont pas des alternatives a CrowdStrike. Trigenibinion (discuter) 23 juillet 2024 à 20:51 (CEST)[répondre]
La page (en) inclut une section Operating system design and antitrust enforcement, ce qui me semble une bonne approche pour rentrer dans le détail de la prévention. Si les symptômes sont un point de départ constitués à partir des observations, il n'est pas nécessaire de trop s'y attarder car l'observation est la même à peu près partout.
Wikipédia peut se prononcer sur les causes et les préexistences de conditions à l'incident, avec tout le recul nécessaire en exposant des éléments sur un modèle de "sécurité globale", l'accent mis sur les risques d'interrompre de vastes ensembles de services au lieu de les laisser continuer à fonctionner même très brièvement ou localement et avec des sécurités numériques amoindries. Démonstration est faite que l'imposition de ce modèle ne fait pas l'unanimité. Un manque de coopération explique les démêlés entre gouvernements fédéraux et corporations multinationales.
Même si cela a du sens pour qui a le contrôle de son exploitation, lire, dans une section "Patch management", qu'en définitive le protocole de mise jour était défaillant et que la solution est de distribuer des patch fonctionnels, au moyen de bonne pratiques ou autres, mais avec les mêmes responsabilités, degrés d'ouvertures et d'opacités, ne fera que pointer l'évidence de la défaillance, dont on peut conclure qu'elle peut se répéter et pour d'autres raisons.
En cela, garder la section nommée "correctifs" me semble plus à propos que de parler de prévention. On peut y voir apparaître des cas anecdotiques de solutions avec des niveau de vérifiabilité variables, et des retours sur des explications aux problèmes réels rencontrés. Darviche (discuter) 24 juillet 2024 à 12:53 (CEST)[répondre]
En bref, depuis que j'ai créé cette discussion il y a 2 jours, il y a eu pas mal de modifs, et dans l'état actuel de l'article, les points abordés et leur enchaînement dans l'article se tiennent mieux qu'initialement (je trouve).On pourrait faire mieux, pour ma part je serais généralement plus synthétique, mais je crois que ce travail aura éventuellement du sens... dans quelques mois! Merci à ceux qui ont aidé. Chronomiam (discuter) 24 juillet 2024 à 21:37 (CEST)[répondre]
En effet, c'est le cas, générique, de la grande majorité des discussions et des articles, car les jours se suivent après l'évènement et la discussion. Les questions posées restent valables. Darviche (discuter) 25 juillet 2024 à 12:05 (CEST)[répondre]

Référence au passage informatique à l'an 2000

Bonjour, Je retire la référence au passage à l'an 2000, qui me semble hors de propos car faisant référence a un problème qui aurait pu se produire. Me semble être juste une façon d'afficher "Slate". Cf. D'après Slate, c'est un léger aperçu de ce qui aurait pu se passer avec le passage informatique à l'an 2000. N'hésitez pas à défaire la suppression si vous estimez que je me fourvoie. Bien à vous, Florian Lévêque (discuter) 25 juillet 2024 à 09:26 (CEST)[répondre]

Quel à propos pour "solutions de préventions évoquées portent sur le niveau de privilège des sondes de sécurités"

Bonjour, Je ne comprends pas l'à propos du passage suivant, le problème affectant uniquement Windows a priori. Je serai preneur d'une explication pour ma bonne compréhension, ou au moins confirmation que le passage est à maintenir.

Les solutions de préventions évoquées portent sur le niveau de privilège des sondes de sécurités :

* sur Linux, la possibilité d'utiliser eBPF au lieu d'un module du noyau pour ce type de programme ;

* sur macOS, depuis la version Catalina, l'utilisation d'un framework endpoint security (en) dédié au lieu d'une extension du noyau ; Florian Lévêque (discuter) 25 juillet 2024 à 10:01 (CEST)[répondre]

CrowdStrike est aussi disponible sur ces plateformes, mais le fichier problematique était seulement pour Windows. Comme CrowdStrike a déjà crashé Linux il y a quelques mois, ont peut penser qu'ils n'utilisent pas encore eBPF e que Linux pourrait similairement tomber. Dans le cas du macOS actuel, la machine n'aurait pas crashé, mais seulement CrowdStrike, ce qui aurait pu laisser l'ordinateur sans protection si un mode dégradé n'est pas prévu. Trigenibinion (discuter) 25 juillet 2024 à 10:24 (CEST)[répondre]
Merci, je touche à rien du coup 😉 Et au passage merci pour toutes tes contributions sur la page ! Florian Lévêque (discuter) 25 juillet 2024 à 10:28 (CEST)[répondre]

polémiques

"déclaration dont le fondement juridique et la cohérence sont contredits83, l'accord ne portant pas sur un accès au noyau, mais seulement aux API que leurs programmes de sécurité utilisent84." _c'est pas exactement ça que dise les sources.176.167.196.80 (discuter) 25 juillet 2024 à 17:34 (CEST)[répondre]

Analyse

Remplacer "centralisation" par "homogénéité et uniformité" ?

Homogénéité et uniformité ont valeurs d'équivalences et, dans ce secteur, peuvent faire références à des notions de standards et de normes, censés fournir quelques garanties. Darviche (discuter) 26 juillet 2024 à 16:50 (CEST)[répondre]

Darviche (d · c · b) centralisation est inadéquat ici. Cela n'est pas dans la source. Si c'était une panne physique des baies du cloud oui ça aurait sens. Le cloud c'est des milliers des machines virtuelles indépendantes les unes des autres qui sont sur le même espace physique sans lien entre elle. L'article le dit c'est le fait d'avoir uniformiser les structures, d'utiliser les mêmes logiciels crowdriver, cloud qui crée un point de fragilité unique. C'est justement la standardisation qui ici est dit poser problème. Si un des élements du standard devient défectueux c'est provoque une panne identique sur tout les systémes ayant la même structure 176.167.210.59 (discuter) 27 juillet 2024 à 11:24 (CEST)[répondre]