IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

CrowdStrike accuse un bogue dans le logiciel de test d'avoir mis hors service 8,5 millions de machines Windows
Car il n'a pas validé correctement la mise à jour du contenu qui a été diffusée sur les machines

Le , par Anthony

37PARTAGES

6  0 
CrowdStrike a réagi à l'incident récent au cours duquel une mise à jour défectueuse a perturbé 8,5 millions de machines Windows. L'analyse de l'entreprise après l'incident attribue le problème à un bogue dans son logiciel de test, qui n'a pas réussi à valider correctement une mise à jour de contenu diffusée le vendredi 19 juillet dernier. En promettant d'améliorer les protocoles de test et d'échelonner les déploiements, CrowdStrike entend prévenir des perturbations similaires à l'avenir.

Le 19 juillet 2024, une panne informatique chez Microsoft a touché des entreprises, des aéroports et des médias à travers le monde entier. Microsoft a confirmé qu'elle était consciente de ces problèmes, mais de nombreux experts en cybersécurité ont indiqué que la source potentielle du problème était l'entreprise de cybersécurité CrowdStrike, qui fournit une surveillance et une protection contre les cyberattaques à de nombreuses entreprises de premier plan. Les écrans bleus de la mort ont perturbé le fonctionnement normal de millions de machines Windows, affichant le message : “Recovery: It looks like Windows didn’t load correctly.”

CrowdStrike a publié une analyse post incident (PIR) de la mise à jour boguée qu'elle a publiée et qui a entraîné la mise hors service de 8,5 millions de machines Windows la semaine dernière. Le rapport détaillé accuse un bogue dans le logiciel de test qui n'a pas validé correctement la mise à jour de contenu qui a été envoyée à des millions d'ordinateurs vendredi. CrowdStrike promet de tester plus minutieusement ses mises à jour de contenu, d'améliorer sa gestion des erreurs et de mettre en œuvre un déploiement échelonné afin d'éviter que ce désastre ne se reproduise.


L'Analyse préliminaire après incident (PIR) de CrowdStrike est présentée ci-dessous :

Ceci est l'analyse préliminaire après incident (PIR) de CrowdStrike. Nous détaillerons notre enquête complète dans l'analyse des causes fondamentales qui sera rendue publique. Tout au long de ce PIR, nous avons utilisé une terminologie généralisée pour décrire la plateforme Falcon afin d'améliorer la lisibilité. La terminologie utilisée dans d'autres documents peut être plus spécifique et technique.

Que s'est-il passé ?

Le vendredi 19 juillet 2024 à 04:09 UTC, dans le cadre des opérations régulières, CrowdStrike a publié une mise à jour de la configuration du contenu pour le capteur Windows afin de recueillir des données télémétriques sur d'éventuelles nouvelles techniques de menace.

Ces mises à jour font partie intégrante des mécanismes de protection dynamique de la plateforme Falcon. La mise à jour problématique de la configuration de Rapid Response Content a entraîné un crash du système Windows.

Les systèmes concernés sont les hôtes Windows utilisant la version 7.11 et supérieure du capteur qui étaient en ligne entre le vendredi 19 juillet 2024 04:09 UTC et le vendredi 19 juillet 2024 05:27 UTC et qui ont reçu la mise à jour. Les hôtes Mac et Linux n'ont pas été touchés.

Le défaut dans la mise à jour du contenu a été annulé le vendredi 19 juillet 2024 à 05:27 UTC. Les systèmes mis en ligne après cette heure, ou qui ne se sont pas connectés pendant la fenêtre, n'ont pas été affectés.

Qu'est-ce qui n'a pas fonctionné et pourquoi ?

CrowdStrike fournit des mises à jour de configuration du contenu de sécurité à ses capteurs de deux manières : Sensor Content qui est livré directement avec nos capteurs, et Rapid Response Content qui est conçu pour répondre à l'évolution du paysage des menaces à la vitesse opérationnelle.

Le problème survenu vendredi concernait une mise à jour Rapid Response Content avec une erreur non détectée.

Sensor Content

Sensor Content fournit un large éventail de capacités pour aider à la réponse de l'adversaire. Il fait toujours partie de la publication d'un capteur et n'est pas mis à jour de manière dynamique à partir du cloud. Sensor Content comprend des modèles d'IA et d'apprentissage automatique sur le capteur, et comprend du code écrit expressément pour fournir des capacités réutilisables à plus long terme pour les ingénieurs de CrowdStrike chargés de la détection des menaces.

Ces capacités comprennent des Template Types (types de modèle), qui comportent des champs prédéfinis que les ingénieurs de détection des menaces peuvent exploiter dans le Rapid Response Content Les Template Types sont exprimés en code. Tous les Sensor Content, y compris les Template Types, sont soumis à un processus d'assurance qualité approfondi, qui comprend des tests automatisés, des tests manuels, des étapes de validation et de déploiement.

Le processus de mise à disposition des capteurs commence par des tests automatisés, avant et après l'intégration dans notre base de code. Cela comprend des tests unitaires, des tests d'intégration, des tests de performance et des tests de stress. Cela aboutit à un processus de déploiement du capteur par étapes, qui commence par un test interne chez CrowdStrike, suivi par les utilisateurs précoces. Le capteur est ensuite mis à la disposition des clients. Les clients ont alors la possibilité de sélectionner les parties de leur flotte qui doivent installer la dernière version du capteur (« N »), ou une version plus ancienne (« N-1 ») ou deux versions plus anciennes (« N-2 ») par le biais des politiques de mise à jour des capteurs.

L'événement du vendredi 19 juillet 2024 n'a pas été déclenché par Sensor Content, qui n'est livré qu'avec la sortie d'une mise à jour du capteur Falcon. Les clients ont un contrôle total sur le déploiement du capteur - qui comprend le Sensor Content et les Template Types.

Rapid Response Content

Rapid Response Content est utilisé pour effectuer une variété d'opérations de mise en correspondance de modèles comportementaux sur le capteur à l'aide d'un moteur hautement optimisé. Le Rapid Response Content est une représentation des champs et des valeurs, avec le filtrage associé. Ce Rapid Response Content est stocké dans un fichier binaire propriétaire qui contient des données de configuration. Il ne s'agit pas d'un code ou d'un pilote de noyau.

Le Rapid Response Content est fourni sous la forme de Template Instances (instances de modèles), qui sont des instanciations d'un Template Type donné. Chaque Template Instance correspond à des comportements spécifiques que le capteur doit observer, détecter ou prévenir. Les Template Instances disposent d'un ensemble de champs qui peuvent être configurés pour correspondre au comportement désiré.

En d'autres termes, les Template Types représentent une capacité de capteur qui permet de nouvelles télémétries et détections, et leur comportement en cours d'exécution est configuré dynamiquement par un Template Instance (c'est-à-dire un Rapid Response Content).

Rapid Response Content fournit une visibilité et des détections sur le capteur sans qu'il soit nécessaire de modifier le code du capteur. Cette capacité est utilisée par les ingénieurs chargés de la détection des menaces pour recueillir des données télémétriques, identifier les indicateurs du comportement de l'adversaire et effectuer des détections et des préventions. Rapid Response Content est une heuristique comportementale, séparée et distincte des capacités de prévention et de détection de l'IA sur le capteur de CrowdStrike.

Test et déploiement du Rapid Response Content

Le Rapid Response Content est fourni sous forme de mises à jour de la configuration du contenu au capteur Falcon. Il existe trois systèmes principaux : le Content Configuration System (système de configuration du contenu), le Content Interpreter (interpréteur de contenu) et le Sensor Detection Engine (moteur de détection du capteur).

Le Content Configuration System fait partie de la plateforme Falcon dans le cloud, tandis que le Content Interpreter et le Sensor Detection Engine sont des composants du capteur Falcon. Le Content Configuration System est utilisé pour créer des instances de modèles, qui sont validées et déployées sur le capteur par le biais d'un mécanisme appelé « Channel Files ». Le capteur stocke et met à jour ses données de configuration de contenu par le biais de fichiers de canaux, qui sont écrits sur le disque de l'hôte.

Le Content Interpreter du capteur lit le fichier de canal et interprète le Rapid Response Content, ce qui permet au moteur de détection du capteur d'observer, de détecter ou de prévenir les activités malveillantes, en fonction de la configuration de la politique du client. L'interprète de contenu est conçu pour gérer de manière élégante les exceptions liées à un contenu potentiellement problématique.

Les Template Types nouvellement publiés sont soumis à des tests de résistance sur de nombreux aspects, tels que l'utilisation des ressources, l'impact sur les performances du système et le volume d'événements. Pour chaque Template Types, une Template Instance spécifique est utilisée pour tester le Template Types en le comparant à toutes les valeurs possibles des champs de données associés afin d'identifier les interactions négatives du système.

Les Template Instances sont créées et configurées à l'aide du Content Configuration System, qui comprend le Content Validator qui effectue des contrôles de validation sur le contenu avant qu'il ne soit publié.

Chronologie des événements : Essais et déploiement du Template Type InterProcessCommunication (IPC)

Publication de Sensor Content : Le 28 février 2024, le capteur 7.11 a été mis à la disposition générale des clients, introduisant un nouveau Template Type IPC pour détecter les nouvelles techniques d'attaque qui abusent des Named Pipes. Cette version a suivi toutes les procédures de test du Sensor Content décrites ci-dessus dans la section Sensor Content.

Test de stress du Template Type : Le 05 mars 2024, un test de stress du Template Type IPC a été exécuté dans notre environnement de préparation, qui se compose d'une variété de systèmes d'exploitation et de charges de travail. Le Template Type IPC a réussi le test de stress et a été validé pour l'utilisation.

Publication du Template Instance via le Channel File 291 : Le 5 mars 2024, après la réussite du test de stress, une Template Instance IPC a été mise en production dans le cadre d'une mise à jour de la configuration du contenu. Par la suite, trois autres Template Instances IPC ont été déployées entre le 8 avril 2024 et le 24 avril 2024. Ces Template Instances ont fonctionné comme prévu en production.

Que s'est-il passé le 19 juillet 2024 ?

Le 19 juillet 2024, deux Template Instances IPC supplémentaires ont été déployées. En raison d'un bogue dans le Content Validator, l'une des deux Template Instances a passé la validation bien qu'elle contienne des données de contenu problématiques.

Sur la base des tests effectués avant le déploiement initial du Template Type (le 05 mars 2024), de la confiance dans les vérifications effectuées dans le Content Validator et des précédents déploiements réussis des Template Instances IPC, ces instances ont été déployées en production.

Lorsqu'il a été reçu par le capteur et chargé dans le Content Interpreter, le contenu problématique du Channel File 291 a entraîné une lecture hors limites de la mémoire, ce qui a déclenché une exception. Cette exception inattendue n'a pas pu être gérée de manière élégante, ce qui a entraîné un plantage du système d'exploitation Windows (BSOD).

Comment éviter que cela ne se reproduise ?

Résilience des logiciels et tests

  • Améliorer les tests Rapid Response Content en utilisant des types de tests tels que :
    • Tests auprès des développeurs locaux
    • Mise à jour du contenu et rollback des tests
    • Tests de stress, fuzzing et injection de fautes
    • Tests de stabilité
    • Tests d'interface de contenu
  • Ajout de contrôles de validation supplémentaires au Content Validator pour le Rapid Response Content. Un nouveau contrôle est en cours pour éviter que ce type de contenu problématique ne soit déployé à l'avenir.
  • Améliorer la gestion des erreurs dans le Content Interpreter.

Déploiement du Rapid Response Content

  • Mettre en œuvre une stratégie de déploiement échelonné pour le Rapid Response Content dans laquelle les mises à jour sont progressivement déployées sur des parties plus importantes de la base de capteurs, en commençant par un déploiement Canary.
  • Améliorer la surveillance des performances des capteurs et du système, en recueillant des feedbacks pendant le déploiement de Rapid Response Content afin d'orienter un déploiement progressif.
  • Offrir aux clients un plus grand contrôle sur la diffusion des mises à jour de Rapid Response Content en permettant une sélection granulaire du moment et de l'endroit où ces mises à jour sont déployées.
  • Fournir des détails sur les mises à jour de contenu par le biais de notes de mise à jour, auxquelles les clients peuvent s'abonner.

En plus de cette analyse préliminaire après incident, CrowdStrike s'engage à rendre publique l'analyse complète des causes profondes une fois l'enquête terminée.

État de la classification du dossier

Le fichier de canal responsable des pannes du système le vendredi 19 juillet 2024 à partir de 04:09 UTC a été identifié et déprécié sur les systèmes opérationnels. Lorsqu'il y a dépréciation, un nouveau fichier est déployé, mais l'ancien fichier peut rester dans le répertoire du capteur.

Par excès de prudence, et pour éviter que les systèmes Windows ne subissent d'autres perturbations, la version impactée du fichier de canal a été ajoutée à la liste des erreurs connues de Falcon dans le Cloud de CrowdStrike.

Aucune mise à jour de capteur, aucun nouveau fichier de canal ni aucun code n'a été déployé à partir du Cloud CrowdStrike.

Pour les machines opérationnelles, il s'agit d'une mesure d'hygiène. Pour les systèmes impactés disposant d'une forte connectivité réseau, cette action pourrait également entraîner la récupération automatique des systèmes en boucle de démarrage.

Ceci a été configuré en US-1, US-2, et EU le 23 juillet, 2024 UTC. Les clients de Gov-1 et Gov-2 peuvent demander la classification known-bad du fichier 291 de channel en contactant le support de CrowdStrike.
Face aux dommages causés, George Kurtz, fondateur et PDG de CrowdStrike, a rédigé une déclaration destinée aux clients et partenaires de la société de cybersécurité.

Chers clients et partenaires,

Je tiens à m'excuser sincèrement auprès de vous tous pour la panne. Tout le personnel de CrowdStrike comprend la gravité et l'impact de la situation. Nous avons rapidement identifié le problème et déployé un correctif, ce qui nous a permis de nous concentrer avec diligence sur la restauration des systèmes des clients, qui est notre priorité absolue.

La panne a été causée par un défaut trouvé dans une mise à jour du contenu de Falcon pour les hôtes Windows. Les hôtes Mac et Linux ne sont pas concernés. Il ne s'agit pas d'une cyberattaque.

Nous travaillons en étroite collaboration avec les clients et les partenaires concernés pour veiller à ce que tous les systèmes soient restaurés, afin que vous puissiez fournir les services sur lesquels vos clients comptent.

CrowdStrike fonctionne normalement et ce problème n'affecte pas les systèmes de notre plateforme Falcon. Il n'y a pas d'impact sur la protection si le capteur Falcon est installé. Les services Falcon Complete et Falcon OverWatch ne sont pas perturbés.

Nous fournirons des mises à jour continues via notre portail d'assistance à l'adresse https://supportportal.crowdstrike.com/s/login/.

Nous avons mobilisé l'ensemble de CrowdStrike pour vous aider, vous et vos équipes. Si vous avez des questions ou si vous avez besoin d'une assistance supplémentaire, veuillez contacter votre représentant CrowdStrike ou l'assistance technique.

Nous savons que les adversaires et les mauvais acteurs essaieront d'exploiter des événements comme celui-ci. J'encourage tout le monde à rester vigilant et à s'assurer que vous vous adressez à des représentants officiels de CrowdStrike. Notre blog et notre support technique resteront les canaux officiels pour les dernières mises à jour.

Rien n'est plus important pour moi que la confiance que nos clients et partenaires ont placée en CrowdStrike. Alors que nous résolvons cet incident, je m'engage à vous fournir une transparence totale sur la façon dont cela s'est produit et sur les mesures que nous prenons pour éviter qu'une telle situation ne se reproduise.

George Kurtz
Fondateur et PDG de CrowdStrike
Source : "Remediation and guidance hub: Falcon content update for Windows hosts" (CrowdStrike)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Le PDG de CrowdStrike est appelé à témoigner devant le Congrès sur le rôle déterminant de l'entreprise spécialiste en cybersécurité dans la panne qui a affecté de nombreux services à l'échelle mondiale

Microsoft annonce que 8,5 millions de systèmes ont été touchés par le BSOD de CrowdStrike et lance un outil de récupération USB pour les entreprises affectées

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de floyer
Membre éclairé https://www.developpez.com
Le 29/08/2024 à 15:33
N’importe quel OS qui permet des extensions en mode noyau s’expose à ce risque. Les différents OS type UNIX n’y échappent pas. (D’ailleurs une mise à jour de Crowdstrike a provoqué des kernel panic sur Linux).

L’architecture de Windows depuis NT n’a rien à voir avec DOS, contrairement à ce que tu sembles dire.

L’approche qui changera vraiment quelque chose est le micronoyau (Mach, QNX, SeL4…) et encore, si un module est un SPOF (typiquement un système de fichier), un défaut dans ce module compromet le fonctionnement du système. Cette approche pourrait rogner un peu les performances… mais pour des applications critiques, pourquoi pas. (Cela me rappelle l’arrivée d’OS/2 où la presse s’indignait oh là là, on perd 2% de performances par rapport à un OS non sécurisé)

Et le principe de mise à jour automatique est vraiment le cœur du problème. Imaginons Oracle « pousser » une nouvelle pile Java à l’insu des développeur et exploitant… même si elle ne tourne qu’en mode utilisateur, cela peut bloquer beaucoup d’applications potentiellement critiques.
5  0 
Avatar de AaâÂäÄàAaâÂäÄàAaâÂäÄ
Membre expérimenté https://www.developpez.com
Le 24/07/2024 à 19:34
Les procédures de test ne sont pas testées...
Ce qui est assez drôle mais que ne m'aurait pas fait rire vendredi !
3  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 29/07/2024 à 13:22
Mais le changement le plus important consisterait à verrouiller l'accès au noyau de Windows afin d'empêcher les pilotes tiers de faire planter un PC entier. Ironiquement, Microsoft a essayé de faire exactement cela avec Windows Vista, mais s'est heurté à la résistance des fournisseurs de cybersécurité et des régulateurs de l'UE.
ça ressemble à de la com' de mauvaise foi de microsoft.

J'ai vite fait balayé du regard cet accord. Je ne sais pas ce qu'en diraient les juristes, mais le législateur peut imposer des objectifs mais (en principe) pas des solutions techniques.
En gros l'accord dit que microsoft doit documenter ses API et les ouvrir aux concurrents comme à ses propres produits. Il n'est pas dit que microsoft doit donner les privilèges kernel à quiconque le demande, ni que le noyaux doit planter s'il n'arrive pas à charger un pilote.
3  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 15/08/2024 à 18:06
La vision des choses de Mr Sterone, rien à commenter tout est dit:

3  0 
Avatar de PomFritz
Membre confirmé https://www.developpez.com
Le 16/08/2024 à 21:42
Face à l'incompétence généralisée, ça panique chez les gratte-papier, zéro mise en perspective et Microsoft se frotte les mains. On dirait une communication du service marketing, pas d'experts.
3  0 
Avatar de OrthodoxWindows
Membre expert https://www.developpez.com
Le 25/08/2024 à 15:19
CrowdStrike découvre qu'il vaut mieux tester une mise à jour avant de la déployer, surtout sur un logiciel qui se place à un stade critique de l'OS, sur un ordi utilisé pour un usage critique.
CrowdStrike découvre qu'en cas de problème grave, la seul confiance avec le client ne fonctionne plus.
Désormais CrowdStrike découvre qu'il existe un système concurrentiel, où chaque concurrent attend qu'un concurrent fasse une connerie.

Bientôt CrowdStrike découvrira qu'il est une entreprise spécialisé dans le domaine de la cybersécurité, dans un contexte d'économie capitaliste libérale.

Ah moins que CrowdStrike se foute tout simplement de la g**** du monde.
3  0 
Avatar de ddoumeche
Membre extrêmement actif https://www.developpez.com
Le 25/07/2024 à 9:53
Citation Envoyé par i5evangelist Voir le message
Je n'ai pas été longtemps à l'école, mais bon, dans leurs procédures de validation, est-ce qu'il ne serait pas judicieux de (en plus) mettre à jour quelque centaines de PC de test contenant des configurations diverses et variées ?
Inutile de mettre à jour des centaines de serveurs, un échantillon représentatif suffit mais encore faut-il que les tests fonctionnels suivent.
2  0 
Avatar de bmayesky
Membre régulier https://www.developpez.com
Le 29/07/2024 à 22:43
Bla, bla, bla, nous n'avons rien testé parce que c'est trop cher et c'est long et ça demande de faire confiance à des gens, tout ce dont nous ne voulons pas dans notre société (ça coûte de l'argent et ça oblige à mettre des vraies personnes qui réfléchissent et risque de nous contredire), bla, bla, bla, c'est pas nous, c'est le logiciel de test, croyez-nous et achetez nos produits pareil qu'avant, bla, bla, bla, même Microsoft disent que c'est pas eux, c'est l'UE, alors croyez-les et achetez, bla, bla, bla,

Comme si une décision d'interopérabilité des années avant pouvait prédire un crash qui n'avait pas été ni écrit ni voulu par qui que ce soit à l'époque ou maintenant. Et qu'un logiciel de test empêche de faire le test de base que fait tout informaticien, même idiot: un test réel. Et il est clair qu'un PC sous windows n'est pas vraiment difficile et cher à trouver pour le faire (sans compter qu'on peut le réutiliser). Franchement on nous prend pour des c**s.

En fait c'est la défense classique en cas de crise lorsque vous vous êtes fait prendre la main dans le sac:
- Nier, nier même l'évidence, ça prendra pour un 50-50 ceux qui ne sont pas attentifs à votre cas au lieu d'un 100 à 0 en votre défaveur.
- Reporter la faute ailleurs, même si c'est capillotracté, c'est ce que fait Crowdstrike avec son logiciel de test et Microsoft avec l'UE; c'est de leur faute entière mais, là encore il y a une frange qui fera du 50-50 au lieu du 100-0 qui les desserts.
- Accepter, bien après la vague médiatique, que c'était peut-être éventuellement un peu de votre faute mais seulement pour montrer tout ce que vous avez fait (et prouver que vous avez fait) pour que cela ne puisse pas se reproduire. Mentir est une option possible si vous vous assurer que personne ne puisse vous contredire. Ça c'est que pour les fainéants qui voudrait reprendre affaire avec vous et vos commerciaux puissent balayer les suspicieux qui rappelleraient l'incident et continuer le business as usual.

En fait, tout ces articles avec de vrais ou de faux coupables masquent très bien quelque chose de plus important à mon avis: l'échec structurel des systèmes propriétaires à livrer du logiciel fiable.

Effectivement, l'utilisation de logiciels propriétaires demande à faire confiance au propriétaire et aucune garantie n'est possible que cela soit vrai et dure dans le temps. Et plus vous multipliez le nombre de logiciels propriétaires nécessaires à votre solution informatique, plus elle est fragile parce que vous multipliez les points de fragilités et ils se combinent et diminuent d'autant la fiabilité de votre solution.

Alors pourquoi prendre cet angle du logiciel propriétaire ? Parce que le logiciel libre fonctionne sur des principes différents qui augmentent la qualité de manière drastique. Le "c'est prêt quand c'est prêt" n'est pas très amis avec les projets de lancement et autres actions planifiées mais très fiable et d'une qualité logicielle très supérieure. Le fait que l'ensemble des couches logicielles soient connues évite radicalement les erreurs de conceptions qui font planter les autres couches logicielles proches. Et évidemment, les process de boot et autres n'ayant aucun besoin d'être cachés sont beaucoup plus souples et laissent beaucoup plus de moyens d'agir.

Cela m'étonne toujours que ce plantage mondial ne soit pas abordé par l'angle du process de construction du logiciel alors que c'est manifestement là qu'il y a eu un problème et qu'une analyse sur la façon de construire le logiciel avec un esprit ouvert permet de trouver une solution à ce type de problèmes.
2  0 
Avatar de bmayesky
Membre régulier https://www.developpez.com
Le 30/07/2024 à 0:04
Il n'y a pas de réduction des coûts: les banques prélèvent de l'argent sur chaque paiement fait en carte. Ce qui se retrouve directement dans la facture de tout ceux qui achètent parce que les commerçants doivent répercuter les frais bancaires sans compter les frais d'abonnement et d'entretien des terminaux. Le paiement par carte est tout sauf gratuit.
C'est à comparer avec le service de la monnaie de l'état qui ne produit aucun frais d'aucune sorte lors de transaction avec des commerçants pas plus qu'entre personnes. Comment allez vous faire pour donner de l'argent à vos enfants ? Ah oui, vous allez leur ouvrir un compte ... payant pour vous.

Il n'y a rien de gratuit dans le paiement par carte, même votre carte est soumise à abonnement et vous payez cet abonnement.

Imaginer un monde sans liquide c' est imaginer un monde où les banques auraient le monopole de l'argent et alors que nous payons déjà, ils auraient un intérêt de classe à faire encore augmenter les prix.

Mais contentons nous de constater les frais actuels pour demander une correction de l'article parce que le paiement par carte coûte à tout le monde et n'est en aucun cas gratuit !
2  0 
Avatar de chris_FR
Membre régulier https://www.developpez.com
Le 08/08/2024 à 19:17
Citation Envoyé par 23JFK Voir le message
Sauf que CrowdStrike a également fait planter des système Linux et MacOs de par le passé, la différence tient uniquement en l'hégémonie du système Windows sur le monde.
Pourrais tu fournir la source de ton information s'il te plaît ?
2  0