Le pirate du sous-sol ne dort plus

Bruce Schneier recommande sur son blogue la lecture de l’analyse de Melissa Hathaway dans le Cyber Defense Review.

Voici l’essentiel que j’ai retenu.

En résumé: Les outils IA trouvent maintenant des failles dans du code en quelques heures, sur des milliers de produits à la fois. Le délai entre « faille découverte » et « attaque possible » se compte désormais en heures, plus en mois. Les entreprises ont une fenêtre de 12 à 24 mois pour rattraper le retard.

Le changement de modèle

Pendant 40 ans, l’industrie a vécu sur un principe : on livre vite, on corrige plus tard. Ça fonctionnait parce que trouver une faille était long et difficile.

Les entreprises s’accordaient 30 jours pour corriger une faille, parfois beaucoup plus. Les fournisseurs aussi prenaient leur temps avant de publier un correctif. C’est fini, ce temps-là.

Le nouveau modèle est direct: on corrige vite, ou on se fait exploiter. Trois faits qui le prouvent :

  • En trois mois, l’équipe du logiciel cURL a corrigé plus de failles que pendant chacune des deux années précédentes.
  • 28 % des failles publiées sont exploitées dans les 24 heures.
  • Le Patch Tuesday d’avril de Microsoft a été le deuxième plus gros de l’histoire.

L’ennemi de la sécurité est la complexité. On vient d’ajouter une machine capable d’en exploiter chaque recoin à grande échelle.

Mythos, l’outil d’IA qui fait les manchettes, est peut-être un coup de marketing. Mais je ne me fie pas qu’aux annonces : je développe moi-même un outil d’analyse de code source basé sur un LLM et je trouve déjà des vulnérabilités. La capacité est réelle et accessible à un individu avec les bons outils.

Et ce n’est plus hypothétique. OpenAI a déjà sorti GPT-5.5, jugé aussi performant que Mythos pour trouver des vulnérabilités. Quand les modèles chinois vont arriver, et ils arrivent, on change de vitesse pour de bon. Ce n’est plus un seul outil qui soulève les passions, c’est une capacité qui se banalise chez tous les grands joueurs. Le volume et la rapidité des découvertes n’auront plus rien à voir avec aujourd’hui.

Doit-on vraiment s’inquiéter?

La faille en soi n’est pas nouvelle. Le vrai changement, c’est qui tient l’outil.

Avant, le danger, c’était un jeune dans son sous-sol qui avait tout le temps du monde. Talentueux, patient, mais seul, et limité par le nombre d’heures dans une journée. Aujourd’hui, ce sont des agents qui n’ont même pas besoin de dormir. Les outils de piratage se retrouvent entre les mains de beaucoup plus de gens, et ces outils travaillent 24 heures sur 24, sans fatigue ni distraction. Le vrai danger est une capacité d’attaque 10x et à tous.

C’est cohérent avec la culture du milieu techno : « bouger vite et tout casser » (move fast and break things). C’était la façon de construire les logiciels. C’est devenu la façon de les attaquer.

Ce qu’il faut savoir

Personne n’est trop petit. Ces failles touchent des produits sérieux et largement utilisés.

Les systèmes en fin de support sont des bombes à retardement. Les failles deviennent plus faciles à trouver, mais ces systèmes ne seront jamais corrigés.

Préparez-vous à des incidents multiples. Deux failles critiques la même semaine, sur deux produits différents, ce n’est plus de la science-fiction. Fini le rançongiciel isolé tous les trois ans.

Quoi faire : le minimum sur 12 à 18 mois

La base, c’est de savoir ce qu’on possède. Ça paraît évident. Ça ne l’est pas.

Quand je mène un test de sécurité, ma première question est toujours la même : « Avez-vous une liste de vos cibles accessibles publiquement? » Je m’attends à une liste de domaines, d’URL, de sites web. Dans une entreprise de 250 personnes, l’obtenir prend souvent une ou deux semaines, parce qu’il faut faire le tour des équipes. Si on ne connaît même pas sa propre surface d’attaque, on ne peut pas la défendre. Ça commence là!

Voici un plan pour vous:

Mois 1 à 3 : Faire notre liste

  1. Inventaire des actifs. Un chiffrier suffit : postes, serveurs, équipements réseau, SaaS critiques. On ne protège pas ce qu’on ne connaît pas.
  2. Repérez les vieux systèmes. Surlignez tout ce qui ne reçoit plus de mises à jour. C’est votre liste rouge.
  3. Multi-facteur partout. Courriel, accès distants, comptes admin.

Mois 4 à 9 : Corriger

  1. Cycle de correctifs mensuel. Une fenêtre de maintenance fixe. Pour une faille critique activement exploitée : moins de 7 jours.
  2. Testez vos sauvegardes. Une copie hors ligne, et un vrai test de restauration. Un seul, mais réel.
  3. Réglez la liste rouge. Chaque système non supporté : remplacer, ou isoler et restreindre. Décision documentée, approuvée par la gestion.

Mois 10 à 18 : se préparer

  1. Plan de réponse d’une page. Qui appeler, comment débrancher, qui parle aux clients, qui contacte l’assureur. Une page.
  2. Exercice sur table d’une heure. Scénario : faille critique sur un logiciel commun, rançongiciel trois jours après. On fait quoi, qui décide? Avons-nous toute l’information? Bonifier notre documentation ou formation.
  3. Contrats à jour. Avec votre fournisseur MSP : quels systèmes il corrige, dans quels délais, qui répond du legacy. Ne présumez rien.

Donc?

L’avantage est temporaire et penche encore du bon côté. Profitez-en. Le minimum n’a rien de spécial: inventaire, double authentification, correctifs plus rapides, sauvegardes testées, fin des vieux systèmes, plan d’une page. Ce qui change, c’est l’urgence et le fait que ce n’est plus négociable.

Sources