Là, les pbrs de sécurité étaient visiblement signalés sur ralblog.com et le patron d’entreparticuliers ayant fait censurer ce blog, on suppose donc qu’il l’avait lu, ils ont été signalés dans l’enquête de Que choisir, on va supposer qu’il a dû la lire, pourquoi alors nier la faille, la corriger puis agir en justice?

Bref 1 an pour corriger les soucis et toujours rien, ça fait donc bien 1 an que les gens sur le site on de quoi se faire voler leurs informations assez facilement. Et rien n’est fait …

- Guillermito VS Tegam
- Jérôme Crétaux VS Carte Vitale
- Serge Humpich VS Visa

Il est clair qu’ à l’avenir, gardez l’anonymat.

Cordialement

Les entreprises françaises et la gestion de crise…

Encore un bel exemple de non préparation. Toute entreprise proposant des services en ligne doit prévoir un package de gestion de crise minimum. Soit pour répondre à des problèmes externes (phishing, hacking, virus…), soit pour répondre à des défaillances internes (failles comme ici, défaut de service, problèmes de connexion ou d’accès)… En France, c’est très rarement le cas.

Et comme souvent dans les entreprises françaises, on recherche plus un responsable qu’une solution. Dans le cas d’espèce, l’entreprise aurait du prendre contact avec le blogueur, identifier conjointement l’erreur, la corriger, et utiliser le même canal pour communiquer sur la réussite de l’entreprise.

Je vois déjà les billets: “un acteur majeur du net (;-)), fait preuve d’une grande réactivité pour corriger une faille mineure avec l’aide du blogueur l’ayant constatée: le web collaboratif, c’est aussi ça!” Le buzz aurait phénoménal, et probablement le futur cas d’école de la gestion de crise de ce type.

Mais il est plus facile de chercher un responsable. Pour rassurer sa hiérarchie, et ses actionnaires. Surtout si le responsable à figure de fléau incontournable et sournois. Quoi de pire qu’une horde de hackers sur-entrainés, probablement payés par un concurrent peu scrupuleux? Le risque imparable. Plutôt que l’erreur de code d’un développeur en régie ou un stagiaire, qui n’est même plus là, dont la présence était justifiée par l’économie d’un salarié performant et fidèle. D’ou le communiqué, typiquement rédigé par un avocat, sûrement pas au fait de ce que peut-être un buzz négatif. Pourquoi Eolas n’est pas toujours disponible pour ce genre d’entreprises?

La leçon a retenir:
- si vous constatez une faille, n’en parlez pas
- pour qu’elle soit découverte et corrigée, diffusez discrètement l’information a ceux qui pourront l’exploiter
- une fois que l’entreprise s’en apercevra, elle réagira.

Et si elle ne réagit pas? Et bien une telle entreprise, qui manifestement ne serait pas compétente sur son périmètre n’a pas droit d’exister. Principe Darwinien de base. Je m’adapte, ou je meurs.

::

Si c’est trop troll, merci de me le préciser par mail. Je le publierais sur mon blog et ferait un trackback.

::

Pour compléter votre énumération des recommandations de la CNIL concernant le traitement des données bancaires, j’ajouterais que les commerçants traitant des données bancaires doivent se conformer au PCI Data Security Standard (PCI DSS) [1].

La conformité des commerçant à ces exigences arrive doucement (la France souffre d’un grand retard) mais sûrement sous pression des Banques.

Le PCI-DSS impose (entre autres) :

3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

3.4 Render PAN, at minimum, unreadable anywhere it is stored (et on peut largement supposer que ce n’est pas le cas)

Cdt,

[1] https://www.pcisecuritystandards.org/tech/index.htm

(Faut chercher par contre…)