Atos fait la plus belle connerie imaginable...
Jusqu'où les laisserons-nous aller?
| Bull: 1er papier Kitetoa dévoile un trou béant de sécurité chez Bull |
| Bull: 2éme papier Kitetoa remet les pendules à l'heure |
| Bull: 3éme papier Kitetoa répond point par point aux contre-vérités des responsables de Bull |
| Bull: 4éme papier Bull tire les leçons d'une erreur humaine... A sa façon... |
| Bull: 5éme papier Bull répare à moitié son serveur anglais et instale un nouveau serveur n'importe comment... |
| Récapitulatif
des papiers sur le monde étrange des administrateurs réseau et systèmes |
| Récapitulatif
de nos copies d'écran sur ce même monde étrange Cette page n'est plus mise à jour depuis août 2001 |
| Taijiquan style Haking (dot com) |
| Sasak style Haking (dot com) |
| Le Match Kitetoa versus Ugly Discoursmarketing |
| It's a funky job. But Kitetoa's digital clone does it... |
| Do you know info-hack Kung-Fu? |
| La hotte du Kitetopapanoël |
| Ze Mega
Kite-Teuf! La fête de l'été de Kitetoa... Les sites les plus nazes de l'été 2000 |
| La
Loi de 78 impose aux entreprises de protéger les bases de données qu'elles constituent... |
Nous avions déjà proposé une piste de réflexion sur la manière dont les problèmes évoqués dans les pages de ce serveur pourraient être résolus.
Le délire auquel nous avons assisté hier soir nous a poussé à aller plus loin dans notre réflexion. La proposition que nous ferons dans les lignes qui suivent est radicale.
Mais il n'y a, à notre sens, aucune autre solution possible pour imposer aux SSII et autres Web Agencies de prendre en compte les problèmes de sécurité...
Prennez une de ces boites auxquelles vous sous-traitez le développement de votre site. Imaginez qu'elle vous fasse une grosse merde façon ZeBank... Vous allez vous retourner contre elle, lui demander, peût-être de prendre à sa charge les frais de remise à niveau etc. Mais dans l'histoire, vous aurez frôlé la catastrophe. Tout ça parce que la boite en question se fout complètement de l'aspect sécurité. Elle a mis des firewalls, elle a un serveur https et ça lui suffit. Le truc de base, la hack de sandwich au jambon par un pauvre internaute débile, elle ne l'a même pas imaginé et elle est persuadée que cela n'a aucune conséquences.
Souvenez-vous... Le nombre d'admins qui nous ont envoyé des mails, ou se sont répandus dans la presse pour dire que notre histoire de lister le contenu des répertoires n'avait aucune conséquence. Le patron de Zebank ne nous a-t-il pas traité de simples paparazzo? Rabachant à loisir que ce que nous avions fait ne mettait pas en danger la sécurité du site et, partant, des futurs clients de ZeBank...
Bien entendu puisque nous avons alerté tout le monde (et eux avant les autres) avant que le serveur ne s'ouvre au public.
Voici maintenant une nouvelle démonstration de la manière dont on peut hacker une pizza et mettre en péril tout le monde. Plus simple on ne fait pas. Et vous n'allez pas me croire, mais c'est en listant les répertoires d'un journal financier que nous sommes arrivés là...
En 5 minutes montre en mains, nous sommes partis du site des Echos déjà épinglé dans cas pages (et qui ne réparent pas) pour arriver dans un répertoire où sont stockés tous les identifiants et mots de passe des clients du service d'une grosse banque en ligne. Vous vous êtes connecté récemment au site Web de cette banque? N'importe qui peut accéder à votre compte! Merci qui? Non, non, pas merci la banque, merci Atos...
Soyons constructifs !
Afin d'éviter les critiques récurrentes (dénoncer ne sert à rien, soyez force de proposition et patati et patata...) nous allons donc encore une fois tenter une réflexion intelligente pour améliorer radicalement la sécurité des sites du commerce électronique de la e-nouvelle économie de dedans le réseau Internet du Web.
Ce n'est pas parce que l'on va vous offrir une séance de consulting gratuit, que l'on va être aussi conciliants que des consultants. Nous n'avons personne à ménager...
Bien. Partons du principe que 99% des gens qui travaillent sur un projet Internet (hormis les techniciens) ne connaissent rien à la technique. Le responsable projet de telle ou telle grosse boite a la trentaine, il surfe et fait ses courses en ligne, ce qui lui a valu le titre convoité d'expert Internet de l'entreprise. Il a lentement gravi les echelons jusqu'à occuper son poste de responsable du projet de site Internet et de la réflexion sur la mise en place de l'Intranet. Personne ne contrôle la validité de ses affirmations parce que personne n'y comprend rien. Il va donc aller négocier des accords et/ou des contrats avec les boites qui aurtont, par exemple, répondu à ses appels d'offres. Dans toutes ces discussions, il n'y aura rien de technique. Tout est "fonctionnalités", "ergonomie", "graphisme", "usabilité" (si, si... je vous jure), "marketing", etc. En face, les commerciaux et consultants de la SSSI, de la Web Agency ou à ses côtés, même le consultant d'Arthur ou autre Big 5 dont il s'est doté pour essayer de mieux comprendre, auront exactement la même approche. Tout le monde se conprend à peu près et c'est tant mieux. Personne ne sait comment, techniquement, tout cela sera mis en place et d'ailleurs, tout le monde s'en fout. Personne ne parle d'audit sécurité parce que "des assurances" dans ce domaine ont ét édonnées par la SSII... Ils hébergent des applications bancaires et ils ont 40 firewalls en cascade, alors vous pensez!...
Sauf que l'on finit par aboutir sur des systèmes tellement intelligents que les logins et mots de passe des clients de la banque sont stockés sur un serveur public, accessible à tous, sans aucune protection.
Alors que faire? Devons-nous, en tant que clients, exiger un audit sécurité de notre application chez Atos, Sema, Experian, Alaban et tous les autres prestataires de services?
Ben non... Finalement, je ne vois pas poourquoi les clients paieraient pour les conneries réalisées par les prestataires de services...
Ben oui...
Notre réflexion nocturne nous a donc amené là:
Il n'y aura aucune sécurité pour les serveurs hébergés tant que les clients accepteront de bosser avec des gens qui ne peuvent pas fournir une attestation prouvant qu'ils ont été audité et testé régulièrement par une, ou mieux, plusieurs sociétés de sécurité indépendantes et donc, externes.
La solution passe donc, selon nous, par le refus de travailler avec des prestataires qui ne font pas auditer (pas simplement avec ISS hein....?!) TOUT leur réseau régulièrement.
A force de perdre des clients, ils finiront bien par faire un petit effort...
Non?
PS: il y a une suite à ce papier ici
