Aller au contenu principal
Métier MSP

L'IA ne crée pas de failles, elle raccourcit le délai

L'IA ne crée pas de failles, elle compresse le délai avant exploitation. Ce qui change pour un MSP : pas la liste des fondamentaux, leur fréquence de vérification.

L'équipe Vigicap5 min de lecture

Un article du Figaro de ce mois-ci décrit des modèles capables de conduire seuls une chaîne d'attaque : reconnaissance, choix de la faille, exploitation, déplacement latéral. Les ordres de grandeur avancés donnent une compromission de réseau en une dizaine d'heures là où le même travail demandait une à deux semaines, sur fond de forte hausse du nombre de vulnérabilités publiées chaque année.

La tentation, en lisant ça, est d'en conclure qu'il faut une nouvelle catégorie d'outil. Le Defense Center d'Orange Cyberdefense dit l'inverse, et c'est la phrase la plus utile de l'article : « La technologie oblige justement à retourner aux bases. »

Ce n'est pas une formule rassurante. C'est une contrainte opérationnelle, et elle est plus exigeante que la précédente.

Qu'est-ce qui change exactement ?#

Pas la nature des failles. Un mot de passe réutilisé, un compte de prestataire resté actif, un correctif appliqué avec six semaines de retard, une sauvegarde jamais restaurée pour vérification : c'était exploitable avant, ça l'est toujours, par les mêmes chemins.

Ce qui change est le délai entre l'apparition d'une faiblesse et son exploitation. Ce délai était votre marge de manœuvre réelle. Il absorbait les imperfections d'organisation : le correctif passé au prochain créneau, l'audit prévu au trimestre, le compte désactivé quand quelqu'un y penserait.

Une marge de plusieurs semaines rend une vérification trimestrielle acceptable. Une marge de quelques heures ne la rend pas insuffisante — elle la rend hors sujet. Entre deux vérifications trimestrielles, il s'est écoulé quatre-vingt-dix jours pendant lesquels personne n'a rien su.

Pourquoi le tableur trimestriel ne suffit-il plus ?#

La plupart des prestataires que je croise tiennent l'état de sécurité de leurs clients dans un fichier. Ce n'est pas de la négligence : c'est ce que le rythme des menaces permettait jusqu'ici, et un fichier tenu sérieusement valait mieux que beaucoup d'outils.

Le problème du fichier n'est pas sa forme, c'est sa date. Il décrit un état constaté un jour donné, par une personne, sur déclaration. Trois choses s'y dégradent en silence :

Il vieillit sans le dire. Une ligne « MFA activé » cochée en juin ne se décoche pas quand un administrateur crée en septembre un compte de service qui en est dispensé. Le fichier reste vert.

Il enregistre une intention, pas un état. « Sauvegardes quotidiennes » signifie que la tâche est planifiée. Pas qu'elle s'est exécutée hier, ni qu'une restauration a été testée. C'est la différence entre une politique et une preuve — le sujet de prouver sa conformité dans la durée.

Il ne résiste pas à la question suivante. Un assureur ou un donneur d'ordre ne demande plus « avez-vous le MFA ? » mais « sur quel périmètre, depuis quand, et comment le savez-vous ? ». Un tableur ne répond pas à la troisième question.

Les fondamentaux deviennent-ils plus complexes ?#

Non, et c'est ce qui rend la situation gérable. La liste est courte et stable. Les 42 mesures d'hygiène de l'ANSSI n'ont pas changé parce que des modèles savent enchaîner des étapes ; le référentiel ReCyF non plus.

Ce qui change est la fréquence à laquelle il faut pouvoir dire où on en est. Le travail se déplace de l'évaluation vers la surveillance : moins de temps passé à établir un état initial, plus à savoir quand il se dégrade.

Pour un prestataire, la conséquence est concrète. Sur cinquante clients, personne ne vérifie manuellement l'état du MFA, des sauvegardes et des correctifs toutes les semaines — ni le budget ni la patience n'y sont. Donc soit la vérification s'automatise à partir des outils déjà déployés, soit elle reste trimestrielle et devient décorative.

Faut-il ajouter un outil de détection ?#

C'est la mauvaise question, et elle coûte cher. Un EDR, un SOC, de la détection temps réel : ce sont des réponses à l'intrusion en cours. Utiles, souvent nécessaires, et sans rapport avec le problème décrit ici.

Le problème décrit ici est en amont : la faiblesse qui rend l'intrusion possible, et le fait que personne ne sache qu'elle existe. Un SOC qui détecte l'exploitation d'un compte sans MFA fait son travail — mais le compte sans MFA était visible depuis des mois, sans qu'aucune alerte ne le signale, parce que ce n'est pas une alerte.

La couche qui manque à la plupart des portefeuilles n'est pas la détection. C'est la gouvernance outillée : savoir en permanence quels fondamentaux sont en place, chez qui, depuis quand, et avec quelle preuve. C'est aussi ce qui se facture en récurrent plutôt qu'en audit ponctuel, sujet traité dans bâtir une offre de gouvernance cyber récurrente.

Quelles erreurs voit-on le plus souvent ?#

Confondre accélération et nouveauté. Réécrire une politique de sécurité parce que « l'IA change tout » fait perdre des semaines sur un document que personne ne lira, pendant que les comptes dormants restent actifs.

Mesurer ce qui est facile plutôt que ce qui compte. Le nombre de postes à jour est simple à sortir et rarement le point faible. Le délai moyen d'application d'un correctif critique est plus difficile à obtenir et bien plus parlant.

Croire qu'un état déclaré vaut un état constaté. C'est l'erreur structurante. Un client de bonne foi répond « oui » à une question sur le MFA en pensant aux comptes nominatifs, sans inclure les comptes de service, les prestataires ni les boîtes partagées.

Verrouiller un périmètre sans le tenir à jour. Un inventaire d'actifs juste à la signature et jamais revu produit exactement le faux sentiment de maîtrise que la compression des délais rend coûteux. La chaîne d'approvisionnement est le cas le plus fréquent : les accès des prestataires entrent et sortent sans passer par l'inventaire.

Que faut-il en retenir ?#

Si la marge se compte désormais en heures, la seule variable réellement sous votre contrôle est le temps qu'il vous faut pour savoir. Pas pour corriger — pour savoir.

C'est une question d'outillage et de rythme, pas de compétence supplémentaire. Les fondamentaux n'ont pas bougé. Seule la fréquence à laquelle il faut pouvoir les prouver a changé, et c'est précisément ce que « retourner aux bases » veut dire dans ce contexte.

SujetsMSPIAvulnérabilitésfondamentauxgouvernance