Deux banques suisses ont, pour ainsi dire, eu leurs quinze minutes de gloire en matière de cybersécurité hier matin sur les écrans et les imprimés de la presse gratuite. Au vu des réactions proposées à l'Internaute, l'opportunité d'un décryptage s'impose.


Un peu de contexte

Le portail Le Matin publiait hier un article intitulé "Les failles que nos banques ignorent", dans lequel il est reproché à deux banques suisses, ci-après dénommées la banque B. et la banque R., de ne pas avoir correctement protégé leur e-banking contre l'attaque informatique "POODLE".

L'article met en avant la prétendue position de "mauvais élève" de ces deux banques, laissant sous-entendre que les autres établissements de la place financière suisse auraient appliqué les mesures de protection adéquates pour se protéger contre cette attaque (aucun élément factuel n'est toutefois proposé au lecteur).

Pour rappel, l'attaque POODLE a été découverte en mai 2014. Elle fut rendue publique en septembre de la même année, donc quatre mois plus tard. La publication était accompagnée de recommandations relativement simples à mettre en oeuvre (cocher des cases, en décocher d'autres) destinées à faciliter une prise en charge rapide par toute organisation en pleine maîtrise de ses systèmes IT (ou de ses fournisseurs, j'y reviendrai plus tard).

L'attaque POODLE exploite une faiblesse présente dans des protocoles habituellement mis en oeuvre lors de nos échanges à caractère confidentiel (achats en ligne, messageries, gestion de systèmes à distance, e-banking, etc.). Plus précisément, l'attaque cible spécifiquement la troisième version du protocole SSL (et depuis quelques jours, certaines implémentations particulières du protocole TLS) et son dispositif de sélection transparente du système cryptographique fonctionnant par élimination, allant du plus fort niveau de sécurité au plus faible (algorithmes et longueurs de clés).

Selon les chercheurs, une exploitation réussie de la vulnérabilité permet à un attaquant de déchiffrer le contenu d'un extrait de l'échange prétendument protégé entre le navigateur et le serveur web, constituant dès lors une brèche de confidentialité en bonne et due forme. Cela peut sembler peu lorsque je dis "le contenu de l'extrait" mais il ne faut pas oublier que selon ce que l'on obtient dans cet extrait, l'accès de l'utilisateur visé peut être totalement compromis.

Bien que complexe à mettre en oeuvre pour le néophyte que je suis, l'aspect pratique de l'attaque a été démontré lors de plusieurs congrès de sécurité informatique et de nombreuses vulgarisations textuelles ou par vidéo sont facilement accessibles sur le web.

La question posée ici est donc relativement simple: faut-il accuser les banques B. et R. d'ingérence parce qu'elles n'ont pas encore corrigé la faille sur leurs systèmes e-banking?


Que dit la banque B.?

L'élément le plus intéressant à observer dans ces rares mais tout autant dévastateurs moments de crise est la réponse que choisit de formuler la "victime" pour se défendre des attaques proférées contre elle. L'organisation va-t-elle démentir? Botter en touche? Y aura-t-il diversion? Ou va-t-elle tout simplement admettre son tort?

La banque R. a directement répondu à une sollicitation du journaliste avant la publication de l'article, sa position est donc citée "la faille sera corrigée début 2015". Aucune autre réponse officielle ne semble avoir été communiquée au moment de cette rédaction (H+24). La banque s'adressant en priorité à la région Suisse alémanique (c'est du moins ce que laissent supposer le site web, la page Facebook, et le compte Twitter), il ne serait pas fallacieux d'imaginer que l'institution puisse nécessiter de plus de temps pour répondre. Accessoirement, il est également probable qu'elle n'y réponde pas du tout...

La banque B. a, elle, de son côté, communiqué par voie de communiqué de presse, aux alentours de 15 heures le même jour. Comme nous allons le voir sous peu, le contenu de ce communiqué a à la fois amélioré la position de la banque B., tout comme il l'a aggravée.


La stratégie du refus

Nous nous trouvons ici dans un cas de communication de crise légère: crise, car la réponse est urgente (une accusation a été prononcée sur la voie publique); légère, car finalement, admettons-le, cela reste un combat de coqs. Tout cela n'a rien de nouveau, les consultants dans le domaine de la communication de crise sont une commodité tout comme le sont les ouvrages transformant le moindre quidam en expert en moins de quinze minutes [haters gonna hate].

En admettant que la banque B. était conseillée, elle disposait globalement de trois stratégies de réponse: reconnaître, refuser ou dévier.

Regardons donc ce communiqué de plus près:
1. "La banque B. tient à souligner que Le Matin présente la situation de manière erronée."
C'est un démenti.
2. "Concernant l'imperfection des protocoles de communication internet mentionnée dans l'article, elle est connue de la Banque B."
C'est une reconnaissance de la présence d'une vulnérabilité.
3. "Elle [l'imperfection] a immédiatement été étudiée dans le détail et n'est en pratique pas exploitable. [...]Les clients peuvent donc continuer d'utiliser XXX [l'e-banking] normalement."
C'est une justification.
4. "Par principe de précaution, la banque B. introduira un nouveau protocole de communication dès le début 2015."
C'est une assurance.

On identifie ici assez facilement l'application académique d'un schéma de communication de crise dit du "refus": l'article incriminant est démenti, aucune faute n'est admise par l'organisation, ses actions sont justifiées.

Il est à noter ici que la stratégie du "refus" a ceci de particulier qu'elle est soumise à une condition qui la différencie des deux autres stratégies: lors d'un mensonge (le refus peut indépendamment servir à démentir une accusation dont on est coupable, ou pas), le destinataire du message ne doit pas pouvoir disposer d'éléments techniques lui permettant de vérifier les propos de l'organisation. C'est le célèbre schéma d'arbitrage du type: - Tu es coupable! contre Prouve-le!

C'est d'ailleurs sur cet insignifiant petit détail que repose toute la stratégie de communication de crise de nombreuses entreprises qui adoptent le "refus" (généralement celles que l'on voit apparaître dans des pages intitulées "CAC40" ou "Dow Jones") lorsqu'elles doivent se défendre contre des accusations d'ingérence, de négligence, de malversation voire de fraude ou de manipulation à grande échelle. En cas de mensonge, la stratégie du refus consiste à promulguer des arguments techniquement invérifiables pour le destinataire du message: l'individu se retrouve ainsi pris en otage entre deux acteurs aux intérêts divergents: l'organisation, d'un côté, est fortement motivée à cacher certaines vérités, alors que la presse, de l'autre côté, a pour objectif de vendre des encarts publicitaires en échange d'un semblant d'information.

Dans le cas de la sécurité informatique, cette stratégie est dangereuse lorsque l'organisation ment, ou lorsqu'elle ne communique pas avec une extrême précision. La raison est simple: la sécurité informatique est un domaine ouvert, par opposition à des activités plus nébuleuses telles que l'énergie, le transport, l'agroalimentaire, la chimie, la finance, etc. Chaque individu peut librement et rapidement accéder à de l'information et des outils fiables et éprouvés (n'importe qui peut évaluer la configuration cryptographique des échanges d'un site transactionnel et sans connaissances techniques). En clair: n'importe quel individu sachant correctement utiliser le moteur de recherche de Google (ou ses pseudo-concurrents) peut investiguer le contenu d'un communiqué de presse parlant de sécurité informatique.


Vérifions donc les propos de la banque B.


"Il [l'article de Le Matin] parle d'une vulnérabilité qui, en pratique, n'en est pas une."
Vrai ou faux?

Faux. L'attaque Poodle a fait l'objet d'une couverture technique à large échelle lors de sa publication. En raison du risque induit, les chercheurs ont contacté les fournisseurs de service majeurs avant la publication de la vulnérabilité afin qu'ils puissent mettre des correctifs à disposition de leurs clients. En pratique, la majorité des constructeurs concernés par cette vulnérabilité a rapidement publié des correctifs de sécurité.
La banque B. communique ici à travers son analyse de risque (non publique): elle estime individuellement que la faute de configuration dans ses système ne doit pas être interprétée comme une vulnérabilité. Le lecteur du communiqué est donc maintenu dans le flou car toute l'information qui lui est disponible à l'extérieur lui montre le contraire.

"Concernant l'imperfection des protocoles de communication internet mentionnée dans l'article, elle est connue de la Banque. Elle a immédiatement été étudiée dans le détail et n'est en pratique pas exploitable."
Vrai ou faux?

Ça dépend.

Premièrement, la banque a ici manqué une opportunité importante d'être précise (règle de communication: qui a fait quoi, quand et sur la base de quels motifs?). L'imprécision chronologique ternit la confiance du lecteur: quand la banque a-t-elle étudié la faille dans le détail? A la lecture de l'article? En septembre dernier? Plus tard? Si cela a été fait en temps opportun, pourquoi la banque n'a-t-elle pas communiqué sa décision? Qu'entend-elle par "non exploitable"? Le communiqué s'adresse-t-il à des experts en sécurité informatique ou aux clients de la banque ou à la presse? C'est le flou total.

Deuxièmement, la banque confirme que la faiblesse est présente dans ses systèmes accessibles du public mais qu'elle n'est pas exploitable en pratique. C'est le scénario du "personne ne fera jamais ça": un scénario que tout professionnel de la sécurité ne connaît que trop bien et dans lequel il sait qu'il ne doit jamais s'engager (les vendeurs de solutions de sécurité font généralement le contraire, mais ceci est un tout autre débat).

Nous approchons ici le moment inéluctable où il devient nécessaire de répondre à une question cruciale: faut-il croire la banque B. lorsqu'elle prétend que cette faille de sécurité n'est pas exploitable dans la pratique?

La réponse est cette fois "ça dépend pour qui" [le lecteur devra se contenter de cette prise de position: c'est mon opinion et je ne suis absolument pas qualifié pour répondre mais Internet fait que je peux m'exprimer à haute voix tout de même]. Je soutiens toutefois ma position par les éléments suivants:
- L'attaque est documentée et l'information est en libre accès sur Internet.
- Les conditions de réalisation sont connues, et en libre accès sur Internet.
- Les compétences nécessaires pour réaliser l'attaque sont connues, et elles sont rares.
- L'accès à une démonstration effective de l'attaque est restreint à un cercle d'initiés.
- L'accès à du code permettant d'exécuter l'attaque est restreint à un cercle d'initiés encore plus initiés que les initiés.

En résumé: on recense tous les experts en sécurité informatique dans le monde. De ceux-ci, on ne retient que ceux qui comprennent ce qu'est un oracle cryptographique et savent comment implémenter du code pour l'interroger. De ce lot, on soustrait tous ceux qui n'ont pas choisi une carrière rayonnante dans la criminalité informatique ainsi que ceux qui n'ont pas placé les institutions financières vaudoises dans leur collimateur. Voici la population réellement "menaçante", d'un point de vue technique...

Si je devais prendre le risque de spéculer avec une analogie médicale, je dirais qu'il faut un spécialiste en neurologie pour s'occuper du patient en question (c'est-à-dire, 1% de la population des médecins diplômés et en âge de pratiquer, statistique INSEE 2014).

A ce stade de l'analyse on serait donc tenté de soutenir et défendre la position de la banque B.:
- L'établissement affirme avoir eu connaissance de l'attaque
- L'établissement affirme avoir évalué son risque: il a déterminé que les personnes capables et motivées d'exploiter la faille de sécurité constituent une menace mineure et donc, un risque acceptable pour la banque
- L'établissement affirme avoir pris la décision documentée d'attendre début 2015 pour corriger la faille.


Pourquoi donc fait-on autant de bruit?

Il y a une réponse courte: parce qu'il y en a qui ont du temps à perdre.

Mais aventurons-nous tout de même dans une réponse plus élaborée...

Les lecteurs habitués de ce blog connaissent mon intérêt tout particulier pour l'activité dite de "modélisation de menaces". A mon avis, et ceci n'est que totale spéculation, la banque B. a tout simplement oublié de prendre en compte un élément majeur dans le modèle de menaces (MdM) de son e-banking (ou elle l'a volontairement ignoré).

Lors de l'établissement d'un MdM, une étape consiste à identifier les différentes catégories d'acteurs qui pourraient constituer une source de menace pour l'e-banking de la banque. De nombreux établissements conçoivent leur liste d'acteurs ou sources de menace sur la base d'un critère arbitraire: les acteurs qui tenteront d'exploiter intentionnellement une faille de sécurité afin d'en tirer un profit. Ces acteurs sont ensuite segmentés, généralement selon leur source de financement et leur niveau technique.

Dans le concret, cela donne plus ou moins la liste suivante:
- Les pirates en herbe
- Les pirates informatiques expérimentés
- Les cellules organisées, pluridisciplinaires, et financées de l'extérieur

Selon contre qui l'on souhaite se défendre, les moyens à mettre en oeuvre seront bien évidemment différents. Par extension, si l'on se trompe dans cette liste, on risque de dépenser inutilement, ou de ne pas être protégé contre un certain agent.

Malheureusement, cette segmentation par le critère "exploitation" exclut ipso facto un acteur bien plus menaçant que le pirate informatique en herbe: le justicier de la cybersécurité.

Le cyberjusticier peut être caractérisé comme suit:
- Il se tient informé des failles de sécurité [composante technique]
- Il inspecte les systèmes avec lesquels le grand public interagit [composante technique]
- Il place la barre très haute en matière d'exigence de sécurité [composante opportunité]
- Il se voit en défenseur de la cause citoyenne [composante opportunité]
- Il veut être entendu et reconnu [composante égo]
- La difficulté n'est pas de le détecter, il sonne à la porte [composante égo]
- La presse en raffole [composante je-ne-sais-quoi]

Un exemple du rôle particulièrement saboteur que peut jouer le cyberjusticier dans un projet est le vote électronique. Le vote électronique étant un système comme un autre, il est donc soumis à la loi "la sécurité à 100% n'existe pas." Le cyberjusticier qualifie tout système informatique d'insuffisant dès lors qu'il peut y déceler une vulnérabilité qu'il estime lui-même comme importante. Cette situation rend le service de vote électronique incompatible avec la vision ultra-sécuritaire du cyberjusticier: il s'y opposera donc assez bruyamment. La presse ne manquera pas une opportunité d'y faire appel pour autant qu'il n'y ait pas d'incohérence technique, et comme indiqué plus haut, le cyberjusticier est techniquement à jour.

La différence entre le cyberjusticier et les autres agents de menace dans la liste ci-dessus est double: il se contente de la simple existence d'une faille (il ne l'exploite pas) et il est doté d'un porte-voix (la presse, contrairement aux autres qui souhaitent ne pas être repérés) (l'affaire Sony Pictures déroge à la règle mais il y a une raison, autre sujet).

Tout cela perturbe plusieurs indicateurs dans les systèmes d'évaluation du risque: le dommage à la réputation est accru, le dommage à la confidentialité/intégrité/disponibilité est nul, et la facilité d'identification de la faille devient un critère binaire (oui/non). Le cyberjusticier n'étant généralement pas un criminel mais un délateur (reste à savoir pour qui), le système d'évaluation du risque doit dès lors incorporer une dimension spécifique:
- Le cyberjusticier peut-il identifier la faille facilement?
- Est-il probable qu'il s'en serve pour monter la presse contre l'organisation?

Comme on le verra tout de suite, les calculs sont compromis...


L'impact du cyberjusticier lors de l'évaluation d'une faille de sécurité

Le cyberjusticier est une menace pour la réputation de l'organisation: si la faille n'est pas corrigée dans les délais qu'il estime adéquats, il en révélera publiquement l'existence. L'organisation doit donc mettre en oeuvre des mesures destinées non pas à empêcher l'exploitation de la faille mais à empêcher la découverte. C'est ce qu'il se passe avec la banque B.: la faille est réputée ne pas être exploitée, mais un cyberjusticier l'a tout de même identifiée. Il a communiqué ce manquement aux banques concernées, elles n'y ont pas accordé l'importance qu'il estime adéquate, il a donc fait appel à la presse.

La limite que présente le système d'évaluation d'une vulnérabilité peut être facilement démontrée. L'exemple ci-après avec le standard d'évaluation de la gravité d'une faille de sécurité (indice CVSSv2), où l'on voit le score calculé par plusieurs acteurs crédibles pour l'attaque POODLE:
- Score CVSSv2 selon Juniper Networks: 4.3
- Score CVSSv2 selon Tenable: 4.3
- Score CVSSv2 selon NIST: 4.3
- Score CVSSv2 selon moi (pas crédible): 2.9
(mon score est plus bas parce que j'ai coché la case adjacent network, POODLE est un man-in-the-middle exploit avant tout, votre assistance est la bienvenue ici!) (détail)

Ces scores sont relativement bas lorsque l'on sait que la note maximale est 10.

Si l'on tente à présent d'intégrer une notion relative à l'impact d'une communication à la presse: l'indice CVSSv2 n'offre aucune variable. Pire, le score va encore baisser dans le scénario du cyberjusticier car son action n'entraînera pas de brèche de confidentialité (rappelons-le: le cyberjusticier n'exploite pas la faille, il la trouve). Dans ce scénario, l'index va donc à l'encontre des intérêts de la banque B.

Reprenons le même exercice, avec l'indice OWASP cette fois (Risk Rating Methodology):
Score OWASP RRM calculé (selon la rédaction):
- Overall score, technical: LOW (3 points)
- Overall score, business: MEDIUM (4 points)

En appliquant cette fois le profil du cyberjusticier (impact réputation maximisé à 9 points, impact technique minimisé à 1 point), l'indice prend les valeurs suivantes:
Score OWASP RRM calculé, agent "cyberjusticier" (selon la rédaction):
- Overall score, technical: LOW (3 points)
- Overall score, business: MEDIUM (4 points)

Là aussi, l'index OWASP RRM ne reflète plus les intérêts de l'organisation, le score est resté identique. En passant le reputation impact de 1 à 9 points, l'indice business impact, qui est composé de 36 points, a pris du poids. Malheureusement, chaque plage Low/Medium/High comporte 12 points. Douze points sont donc nécessaires pour basculer au niveau supérieur. Cela induit deux choses: 1) il est mathématiquement possible de basculer de LOW à HIGH en modifiant la valeur reputation 2) Il faut au minimum 16 points au business impact pour que la modification du facteur reputation fasse basculer le score à HIGH.

Dans le cas POODLE, l'index business impact était de 3/1/5/5=14 points vs. 3/9/5/5=22 points, il en fallait donc 24 pour que la banque voit un risque "HIGH", c'est ce qui s'appelle communément voler sous les radars.

Que conclure? Certaines formules de calcul de risque pour les failles de sécurité actuellement mises à disposition des organisations tablent sur l'hypothèse finale d'une exploitation de la faille de sécurité. Elles n'intègrent pas encore pleinement cette configuration découlant d'un objectif de divulgation de la faille combiné à un accroissement du nombre de "cyberjusticiers" dans le paysage. Toute organisation qui utilise ces modèles de calcul doit connecter intimement l'équation à son modèle de menace et y effectuer les pondérations nécessaires à chaque source. Le cas échéant, l'organisation obtiendra des scores incorrects, et la gestion de risque ne pourra pas prendre les bonnes décisions.

La vulnérabilité associée à l'attaque POODLE est un cas exemplaire: n'importe quel internaute peut en détecter la présence et elle est très facilement corrigée, pour autant que l'on ait le contrôle du système concerné. A cela s'ajoutent les outils de recherche automatique de vulnérabilités: certains sont extrêmement sévères avec la faille POODLE. C'est le cas par exemple du service proposé par la société Qualys: il dégrade immédiatement la note d'un serveur web configuré avec HTTPS de 3 points (sur 6) si le protocole SSLv3 est laissé actif, et il dégrade la note de 6 points (sur 6, donc pire note possible) dans le cas où l'organisation utilise le boîtier (appliance) de certains éditeurs dont l'implémentation est encore vulnérable à l'attaque. Pourtant, dans ces cas, la banque ne peut rien faire: elle dépend de son fournisseur.


Quid des cellules organisées?

Pour rappel, la liste des agents de menace comportait à sa fin l'entrée "cellules organisées, pluridisciplinaires et financées de l'extérieur." Il est temps de s'intéresser un peu à ce groupe.

Évaluer la menace que constitue cet acteur exige tout d'abord d'accepter qu'il est attribué d'une sophistication maximale à la fois sur les plans techniques, organisationnels et financiers. La seule et unique question que l'établissement doit donc se poser ici est: "est-ce que j'ai des raisons de supposer que cette entité profiterait activement d'une telle vulnérabilité dans mes systèmes?"

Les établissement financiers "réveillés" utilisent plusieurs canaux d'information pour répondre à cette question: ils font régulièrement appel à des prestataires externes afin de bénéficier de leur vision transversale, ils reçoivent des alertes qui leur sont remontées par les organismes étatiques et la défense nationale (enfin, ça dépend du pays en question, mais c'est une autre histoire), ils analysent le trafic généré par leurs systèmes, ils reçoivent des bulletins d'intelligence provenant de services de renseignement criminel et mettent en place des sondes technologiques à la recherche de signaux ou données présentant un risque, etc.

Cette information n'est pas fournie dans le communiqué de presse de la banque B. (ce qui est, admettons-le, tout à fait normal !). Une chose est certaine, si la banque a fait appel à ces services, elle n'a probablement pas reçu de notification lui intimant de modifier sa décision.


Et si un impératif technique empêchait la correction de la vulnérabilité?

Le dernier scénario, à mon avis le plus probable, allant dans le sens de la banque est le cas de l'externalisation: le système à corriger n'appartient pas à la banque, il est contrôlé par un prestataire et le prestataire prend son temps pour proposer le correctif.

Cette configuration est fréquente pour les dispositifs technologiques en charge du chiffrement des communications sur le web (le susmentionné canal HTTPS): ces boîtiers sont vendus aux organisations à un coût exorbitant et il est contractuellement interdit d'en modifier certains paramètres ou même le fonctionnement interne. Comme une minorité d'acteurs se partage ce marché et que les établissements financiers doivent y faire appel par contrainte réglementaire, l'écosystème est tel que les clients disposent d'un faible pouvoir de négociation sur leur fournisseur.

L'un des éléments à prendre en compte ici est le concept d'exploitation dite "in the wild", c'est-à-dire: est-ce que quelqu'un observe concrètement sur le terrain une réelle mise en exécution de l'attaque POODLE?

Les grands éditeurs diffusent leurs correctifs à des dates convenues d'avance. Pour certains, le cycle est mensuel, d'autres éditeurs adoptent des cycles trimestriels voire semestriels. Dans le cas où une vulnérabilité est activement exploitée sur le terrain, un éditeur consciencieux va généralement diffuser un correctif d'urgence en dehors de son cycle de mises à jours. Microsoft, à titre d'exemple, vient d'ailleurs de le faire pas plus tard que hier.

L'exploitation de l'attaque POODLE contre des organisations n'est pour l'instant pas observée. Ironiquement, il est un peu difficile de le savoir puisque le correctif vise dans certains cas à doter les systèmes de capacités de détection de cette exploitation (p.ex.: implémentation du draft IETF TLS Fallback Signaling Cipher Suite Value)...

Dans les cas où le prestataire répond très amicalement à ses clients "la mise à jour arrivera dans trois mois", la banque ne peut malheureusement que prendre son mal en patience, et espérer qu'aucun cyberjusticier ne déclenchera une attaque médiatique d'ici-là ;)


Pour conclure

La question posée initialement était de savoir si la banque B. commettait une faute en ne corrigeant pas la vulnérabilité.

D'un point de vue technique, l'analyse ci-dessus conclut sur l'absence d'éléments factuels montrant que la vulnérabilité est activement exploitée par des pirates informatiques et qu'il y aurait eu une mise en danger des données des clients. En espérant que la banque ait au moins placé des dispositifs permettant la détection d'une éventuelle tentative d'exploitation de cette faille, l'analyse technique ici soutient la décision de la banque.

D'un point de vue métier, en revanche, la banque B. a peut-être sous-estimé sa position de haute visibilité auprès de la population (et c'est mon humble avis). Cet élément la place dans une configuration particulière: en plus des pirates informatiques, elle se trouve dans le collimateur d'individus qui ne toléreront pas le moindre manquement en matière de sécurité. Deux stratégies possibles: on ferme le moindre trou, quelque soit sa taille, ou on communique. La banque B. n'a adopté aucune des deux stratégies.

La grande majorité des banques suisses adopte le "on achète tout, on teste tout et on réfléchira plus tard si nécessaire." Cette approche, souvent défendue comme une bête application du principe de défense en profondeur, induit bien évidemment des dépenses discutables d'un point de vue sécuritaire. Elle présente toutefois l'avantage de permettre à ces établissements de se maintenir à l'abri d'attaques médiatiques les contraignant à la justification, comme a dû le faire la banque B, et pire encore: les rendant parfois trop visibles.

Triste ironie du sort: cette faille de sécurité se règle par une simple case à cocher, pour autant que l'on ait la maîtrise technique de ses propres systèmes. Ici encore, le bât blesse: le service informatique des entreprises traverse en ce moment une phase de transition, les services sont de plus en plus externalisés chez le Claude (à prononcer avec un accent suédois) ou dans des boîtiers propriétaires tout en étant réglementés par des contrats de service et de support dans lesquels les aspects de sécurité ne sont pas encore maîtrisés.

Les fournisseurs connaissent parfaitement ces pièges, et les clients qui tiennent leurs experts sécurité à l'écart des négociations contractuelles sont encore légion. Claude a encore de belles années devant lui !


Pour finir, deux réflexions personnelles sur l'affaire dans son ensemble.

Je crois qu'il y a eu ici une légère exacerbation du risque technique. La position exacte des experts cités est écorchée dans l'article, comme on peut s'y attendre. Il est toutefois possible de consulter la vision de l'un d'entre eux directement sur un site dénué de toute perturbation journalistique. Au final, à part faire peut-être paniquer quelques lecteurs/clients facilement influençables, l'intervention de la presse aura probablement fourni les munitions nécessaires à deux banques suisses pour qu'elles puissent sortir leur prestataire de son confortable hamac avec toute la courtoisie qui s'impose. Un mal pour un bien? L'humiliation, elle, sera oubliée d'ici 24 heures: l'attaque n'était pas contre un individu mais contre une entreprise, les consommateurs ont la mémoire particulièrement courte lorsqu'il s'agit de consommer...

La seconde réflexion: le métier des banques est la gestion de risques. Jusqu'à preuve du contraire, elles pratiquent cet art à merveille. En tant que client et citoyens, il nous incombe simplement de veiller à ce que cette gestion ne soit pas réalisée à notre détriment. Cela ne veut pas dire qu'il n'y a rien à dire, loin de là, juste qu'il s'agit d'un autre combat.


Vos commentaires sont les bienvenus. J'imagine que mes opinions (c'est le risque lorsque l'on prend position sur Internet) et la longueur de l'article (c'est pour faire fuir les impatients) ont dû en agacer plus d'un. Je serai bien entendu plus qu'heureux de défendre mon point de vue ou d'admettre un éventuel tort!



PS: si un représentant de la sécurité à la banque B. me lit, je recommande fortement de rapidement corriger la phrase "ne jamais se connecter à XXX en cliquant sur un lien, mais toujours via www.XXX.ch", à défaut de corriger la vulnérabilité sous-jacente. L'utilisateur qui suit la recommandation du communiqué est en effet exposé à une autre attaque, bien plus grave, et actuellement activement exploitée (au final, la banque R. se retrouve presque mieux lotie pour ne pas avoir communiqué, ce qui est un peu ironique vu les circonstances). Pour la mesure corrective, je recommande un peu de lecture sur la directive HSTS ou, en dernier ressort, de contacter rapidement le prestataire habituel pour un soutien dans cette démarche.