Si vous avez suivi l’actualité récemment, le discours autour de l’IA laisse entendre que des agents en grand nombre découvrent et exploitent de nouvelles vulnérabilités à une vitesse record. Cependant, les données issues du terrain en matière de sécurité de l’identité racontent une tout autre histoire. Bien que l’IA soit utilisée de manière suffisamment répandue pour que l’on suppose un certain niveau d’augmentation dans chaque attaque observée, l’IA n’est pas le catalyseur des attaques d’identité : elle en est l’accélérateur.
Les cybercriminels utilisent principalement l’IA pour augmenter la vitesse et l’ampleur de méthodes d’attaque bien connues, comme le phishing, mais pas pour en inventer de toutes nouvelles. Puisque les conditions sous-jacentes à l’accès initial n’ont pas fondamentalement évolué, les principes architecturaux qui protègent les entreprises contre les attaques menées par des personnes restent tout aussi efficaces face aux menaces amplifiées par l’IA.
Pour résister aux attaques actuelles, les fondamentaux de la sécurité sont plus essentiels que jamais. Les équipes sécurité doivent se concentrer sur la réduction de leur surface d’attaque globale et sur la gouvernance de l’utilisation de l’IA au sein de leur entreprise, plutôt que d’essayer de devancer l’utilisation de l’IA par les attaquants. En mettant en place quelques contrôles clés, notre étude montre que les responsables de la sécurité peuvent mieux se prémunir contre ces menaces liées à l’IA.
Il suffit de quelques contrôles pour éviter la plupart des brèches
En 2024, l’informaticien Niels Provos a introduit le concept d’invariants de sécurité : des politiques automatisées, applicables par machine, qui réduisent systématiquement la surface d’attaque d’une organisation sans que chaque collaborateur ou collaboratrice ait à prendre de décisions en matière de sécurité.
L’ analyse des brèches de données publiques réalisée par Provos a révélé qu’un petit nombre de contrôles appliqués de manière systématique — comme l’obligation d’utiliser des facteurs matériels secondaires, les restrictions de sortie et l’autorisation préalable des applications — pourrait permettre d’éviter jusqu’à 65 % des brèches recensées.
Niels Provos a constaté que 65 % des brèches pourraient être évitées grâce à seulement trois contrôles. L’analyse est détaillée dans un article de blog Plan d'action pour la sécurité.
Comme un invariant fonctionne automatiquement sur l’infrastructure informatique, il permet de décharger l’utilisateur final de la responsabilité en matière de sécurité, évitant ainsi qu’il ait à se préoccuper en permanence de prendre des mesures comme créer des mots de passe plus robustes ou détecter des tentatives de phishing sophistiquées.
Nous mettons la résistance au phishing à l’épreuve
En s’appuyant sur l’étude de Provos comme framework, Okta Threat Intelligence a mené des recherches afin de vérifier notre hypothèse selon laquelle un nombre restreint d’invariants de sécurité pourrait contribuer à prévenir les attaques d’identité. Pour évaluer l’efficacité des facteurs et politiques résistants au phishing sur le terrain, nous avons analysé environ 6000 événements réels de social engineering issus d’un jeu de données interne comprenant plus de 10 000 campagnes.
Nous avons évalué les configurations cibles, les paramètres de politique et les résultats de session lors des tentatives d’usurpation de compte (ATO), que nous avons définies comme toute session IdP compromise, même si l’attaquant n’a pas accédé aux ressources protégées. Nous avons exclu les attaques dans les cas suivants :
L’appareil de l’utilisateur était déjà compromis.
La principale méthode d’accès initial consistait à inciter un utilisateur à télécharger un logiciel malveillant ou des outils RMM.
La principale méthode d’accès initial consistait à inciter un utilisateur à autoriser une application contrôlée par un attaquant dans une application SaaS en aval.
Cela n’aurait aucune incidence sur l’efficacité de l’authentification résistante au phishing.
Les premières observations ont confirmé les hypothèses courantes du secteur concernant la vulnérabilité des mots de passe : 87 % des usurpations de compte ont impliqué des mots de passe, tandis que 58 % ont validé des notifications push, 36 % ont complété des mots de passe à usage unique (OTP) via une application et 22 % ont utilisé des OTP par SMS. Les combinaisons de facteurs les plus fréquentes étaient mot de passe + push (47 %) et mot de passe + OTP via application (27 %), aucune d’entre elles n’étant résistante au phishing.
Résultats obtenus par les invariants de sécurité
Ensuite, nous avons examiné si nos invariants de sécurité résistants au phishing auraient empêché l’usurpation de compte s’ils avaient été en place. Lorsque l’on mesure l’impact direct des authentificateurs résistants au phishing, les chiffres révèlent des couches de protection claires :
Inscription obligatoire : exiger que les utilisateurs s’inscrivent à des facteurs résistants au phishing aurait permis d’arrêter 88 % des tentatives d’usurpation de compte.
Application des politiques de connexion aux applications : exiger une résistance au phishing dans les politiques de connexion des applications aurait permis de combler la majeure partie de la faille restante, portant la protection à 99,75 %.
Les politiques de connexion aux applications définissent comment un utilisateur ou une utilisatrice doit s’authentifier pour accéder à une application, et leur configuration est une étape indispensable pour veiller à ce que les utilisateurs et utilisatrices puissent uniquement s’authentifier avec un facteur résistant au phishing, et non avec un facteur moins robuste. Imposer la résistance au phishing dans les politiques de connexion aux applications est essentiel, car la rétrogradation de la MFA fait depuis longtemps partie du playbook des ingénieurs sociaux. Les cybercriminels feront tout leur possible pour dissuader les utilisateurs de choisir un facteur résistant au phishing.
Même avec une inscription obligatoire et des politiques strictes de connexion aux applications appliquées, 0,25 % des événements de social engineering étudiés ont tout de même abouti à une session compromise.
Ce risque résiduel provient de la complexité de l’initialisation des comptes, c’est-à-dire du processus d’inscription sécurisée d’un nouvel utilisateur ou d’un nouvel appareil. Les entreprises sont confrontées au dilemme de l’œuf et de la poule : comment peuvent-elles vérifier de manière sécurisée l’identité d’un utilisateur avant de lui permettre d’enregistrer un authentificateur robuste et résistant au phishing ? Si cette vérification initiale repose sur des facteurs faibles comme les mots de passe, les OTP ou les notifications push, le compte reste exposé aux attaques de rétrogradation de la MFA avant même que la protection renforcée ne soit appliquée. Si une personne malveillante parvient à se connecter en utilisant le facteur MFA le moins robuste, elle peut exploiter cet accès pour s’auto-enregistrer un facteur résistant au phishing qu’elle contrôle et conserver un accès persistant.
Pour atteindre une protection proche de 100 % contre les attaques de social engineering, les exigences de résistance au phishing doivent s’étendre aux politiques de gestion des comptes (AMP). En contrôlant strictement l’ajout, la modification ou la suppression des facteurs, les entreprises empêchent les attaquants de s’octroyer un accès autonome aux comptes. Les AMP peuvent assurer cette protection en exigeant :
Un utilisateur ou une utilisatrice doit vérifier son identité à l’aide de facteurs résistants au phishing avant qu’un nouveau facteur ne soit ajouté (pour cela, les nouveaux comptes utilisateur peuvent être initialisés à l’aide de clés de sécurité physiques préenregistrées)
La partie requérante doit utiliser un appareil géré
L’utilisation d’un service d’IdV tiers
La partie requérante doit se trouver sur un réseau de confiance
Si vous ne pouvez pas dépasser l’IA, limitez ses vecteurs d’attaque
Tenter de contrer l’exploitation pilotée par l’IA avec une défense réactive est une stratégie vouée à l’échec. Comme Provos l’a souligné dans ses travaux de suivi sur les menaces liées à l’IA, les équipes sécurité devraient se concentrer sur l’utilisation d’invariants de sécurité pour limiter les vecteurs d’attaque, plutôt que d’essayer de se défendre à la vitesse des machines.
En associant l’inscription obligatoire des utilisateurs à des politiques strictes de résistance au phishing, appliquées aussi bien lors de la connexion aux applications que dans les workflows de gestion de compte, les organisations créent une barrière architecturale qui reste solide, quelle que soit la rapidité ou le degré d’automatisation des outils des attaquants.
Ce contenu est fourni à titre informatif uniquement, ne constitue pas un conseil professionnel et est proposé sans garantie ni responsabilité. Veuillez consulter vos propres conseillers pour toute décision d’implémentation.
