L’omniprésence de l’IA est un phénomène auquel nous sommes confrontés au quotidien. Il suffit de parcourir la Route 101 à travers San Francisco pour voir des dizaines de panneaux publicitaires vantant des produits d’IA. Dans notre vie quotidienne, nous voyons l’IA dans la médecine, dans le commerce, et même pour laver notre linge. Comme pour toute nouvelle technologie, il existe un versant inquiétant, et des personnes mal intentionnées, bien entendu, utilisent l’IA pour commettre des actes criminels.
Chez Okta, notre mission consiste à lutter contre les cybercriminels, qu'ils bénéficient ou non de l'appui de l'IA. La modélisation des menaces fait partie des techniques de cybersécurité que nous utilisons pour renforcer nos produits face aux attaquants. C’est un contexte naturel pour appliquer l’IA.
Comprendre la modélisation des menaces en cybersécurité
La modélisation des menaces peut sembler complexe, mais elle est en réalité simple. Nous évaluons les attaques potentielles, leur probabilité et leur impact, ainsi que les moyens de les atténuer. C’est une pratique que beaucoup d’entre nous adoptent dans d’autres contextes sans même s’en rendre compte.
Un exemple concret de modélisation et de réduction des menaces
J’ai récemment acheté un nouveau vélo électrique. Déterminer comment éviter qu’il ne soit volé relève d’un exercice d’analyse des menaces. Je gare le vélo dans mon garage, c’est donc une situation que je dois analyser. Là où nous vivons, il est peu probable qu’une personne mal intentionnée s’introduise dans notre garage, ce qui ne serait peut-être pas le cas si je vivais dans un immeuble en centre-ville, où l’accès au garage pourrait être plus facile. La probabilité que mes enfants adolescents laissent la porte du garage ouverte, en revanche, est très élevée. Pour ma part, il me suffit d’utiliser un simple antivol en U pour éviter qu’une personne mal intentionnée ne puisse s’emparer du vélo et partir avec. En revanche, si j’utilise mon vélo dans le centre de San Francisco, je pourrais préférer un antivol résistant à la meuleuse pour dissuader les voleurs les plus déterminés.
La démarche d’Okta en matière de modélisation des menaces
Chez Okta, nous appliquons le même exercice à nos logiciels. Nous réfléchissons à la manière dont une personne malveillante pourrait contourner nos défenses et à la façon dont nous pouvons les renforcer.
Nous disposons d’un processus formalisé, mais en constante évolution, pour modéliser les menaces chez Okta. Nous schématisons les flux des données dans le système et les interactions entre les différents composants. Nous répertorions avec précision les différentes façons dont un attaquant pourrait compromettre notre système et les moyens de nous protéger. Après avoir rédigé notre modèle de menace, nous le soumettons à une relecture interne par des pairs et des spécialistes de la sécurité, comme nous le faisons pour le code. Nous venons de commencer à utiliser l’IA dans le cadre de notre processus de modélisation des menaces, et je vais partager ici quelques premiers constats.
Utiliser Claude IA pour la modélisation des menaces
La nouvelle fonctionnalité d’authentification unique (SSO) liée à l’appareil d’Okta utilise une clé privée spécifique pour signer une charge utile envoyée au back-end d’Okta. La signature de la charge utile avec cette clé permet à Okta de vérifier certains détails spécifiques concernant l’ordinateur de l’utilisateur final.
J’ai demandé à Claude by Anthropic de m’aider à élaborer le modèle de menace pour la version macOS de la fonctionnalité d’authentification unique (SSO) liée à l’appareil. Nous avons rédigé plusieurs spécifications techniques pour la fonctionnalité, notamment un document d’architecture général, des détails d’implémentation pour les clients Windows et macOS, ainsi qu’un modèle de menace pour un client Windows.
Rédiger l’invite pour l’IA
J’ai fourni tout cela en guise de contexte et utilisé l’invite suivante, assez simple :
Le dossier ressources contient une description de la fonctionnalité Special Key que nous développons. Dans le annuaire ressources, il y a une spécification technique de la fonctionnalité pour macOS et Windows. Ce fichier s’appelle SpecialKeySpec.pdf. Il existe également une spécification propre à macOS, intitulée macOSSpecialKeySpec.pdf.
Vous êtes un expert en cybersécurité chargé d’élaborer un modèle de menace pour cette fonctionnalité à l’aide du framework STRIDE.
Je souhaite obtenir le résultat suivant :
* un diagramme de contexte de niveau 0 réalisé au format Mermaid ;
* un diagramme de séquence conçu au format Mermaid ;
* une liste des menaces identifiées accompagnée de suggestions de mesures d’atténuation, rédigée au format Markdown.
Analyse des résultats du modèle de menace lié à l’IA
La modélisation des menaces peut sembler décourageante, mais utiliser l’IA de manière efficace permet de réduire l’appréhension que l’on ressent face à une page blanche sur Google Doc. Claude n’a ressenti aucune inquiétude de ce type et a rapidement dressé une liste d’environ 20 menaces. Le résultat ressemblait à ce que l’on pourrait attendre d’une personne de 12 ans passionnée de cybersécurité : beaucoup d’enthousiasme, quelques bonnes idées, mais un manque général de nuance.
Points forts : les domaines dans lesquels l’IA excelle en modélisation des menaces
Claude excelle pour lancer les initiatives et prendre en charge les tâches opérationnelles.
Claude a fait preuve d’une grande maîtrise dans la rédaction des premiers brouillons des schémas que nous utilisons pour la modélisation des menaces. Nous réalisons des schémas à l’aide du langage de balisage Mermaid, et les diagrammes Mermaid comportent généralement une part importante de code répétitif. Le fait de confier l’amorçage du workflow à Claude permet d’obtenir un schéma fonctionnel plus rapidement que si vous partiez de zéro ou même en copiant-collant un schéma existant. Dans l’ensemble, le diagramme de séquence et les diagrammes de flux de données étaient corrects. Comme j’ai consacré très peu de temps à la structure initiale, j’ai pu me concentrer davantage sur la révision et l’amélioration des schémas afin de les rendre plus précis.
Exemple de diagramme de flux de données
Exemple de diagramme de séquence
Claude a bien identifié les menaces liées à la compromission de notre clé privée. Claude a également bien recensé les attaques de type Man-In-The-Middle (MITM). Une telle attaque se produit lorsqu’une personne ou un système intercepte le trafic internet entre les composants de votre système.
Enfin, Claude a fait la liste de plusieurs attaques susceptibles de se produire si une personne malveillante compromettait l’un de nos composants logiciels. Je suis convaincu que nous n’aurions pas manqué ces éléments si nous étions partis de zéro, mais cela nous a fait gagner beaucoup de temps.
Limitations : suggestions de sécurité en matière d’IA moins pertinentes
Les résultats de Claude manquaient cependant souvent de nuance. Elle a identifié plusieurs menaces liées à la fuite de données non confidentielles. Par exemple, nous disposons d’un identifiant de session, qui est une chaîne unique et absolument pas confidentielle. Nous ne l’avons pas précisé dans notre prompt, cependant, et Claude a souligné à plusieurs reprises que la divulgation de cet identifiant posait problème.
D’autres menaces n’étaient tout simplement pas pertinentes, et nous pouvions les ignorer complètement. Claude nous a demandé de remplacer HTTPS par XPC, ce qui n’est en réalité pas envisageable. Claude a rédigé quelques messages sur les risques liés à la divulgation de mots de passe, mais aucun mot de passe n’est impliqué dans le flux de données.
Réaliser une analyse des lacunes du modèle de menace
Après avoir passé plusieurs heures à modifier la liste initiale de menaces de Claude ainsi que l’ensemble des schémas, j’ai soumis mon brouillon à notre atelier de modélisation des menaces. Là, des spécialistes chevronnés de la modélisation en sécurité ont analysé la conception et partagé des observations précieuses que j’ai intégrées directement au modèle. Je suis ensuite retourné vers Claude et je lui ai demandé d’analyser mon modèle partiellement finalisé afin d’identifier les lacunes, en utilisant à nouveau le modèle de menace Windows comme contexte.
Claude s’est à nouveau montré particulièrement prolixe et m’a fourni une longue liste de problèmes potentiels. La plupart n’étaient pas pertinents, mais quelques-uns valaient vraiment le détour. Par exemple, comme nous avions bien renforcé un composant spécifique du système, je n’avais pas envisagé les menaces qui pourraient survenir sans ce renforcement.
Une bonne règle en matière de modélisation des menaces consiste à supposer qu’une menace particulière ne dispose d’aucune mesure d’atténuation et à envisager les conséquences. J’avais ignoré cette règle, mais Claude ne l’a pas fait.
Claude a partagé quelques autres informations utiles : l’une concernant le chiffrement des communications inter-processus et une autre sur le détournement de session. J’aurais probablement fini par les intégrer en recoupant avec le modèle de menace Windows, mais le fait d’avoir un regard extérieur m’a fait gagner du temps.
Principaux points à retenir sur l’utilisation de l’IA dans les workflows de cybersécurité
Il existe bien entendu des risques liés à l’utilisation de l’IA pour la modélisation des menaces. Pour commencer, vous devez veiller à ce que les outils d’IA n’exfiltrent pas vos données. Même si vous avez sécurisé votre chaîne d’outils d’IA afin que les résultats malveillants ne posent pas de problème, les résultats peuvent néanmoins être incohérents. Vous devez accomplir votre travail avec autant de rigueur qu’auparavant. Il est facile d’obtenir quelques bons résultats grâce à l’IA — un e-mail bien rédigé ou une fonction bien codée, par exemple — et de penser que les résultats sont toujours excellents. De même, Claude ne doit pas être la seule personne à réfléchir : le fait que Claude n’ait pas évoqué une menace en particulier ne signifie pas que vous pouvez l’ignorer.
L’IA excelle pour amorcer les choses. Cela suscite une multitude d’idées. Certaines de ces idées sont utiles pour élaborer le modèle final, d’autres incitent la personne chargée de la modélisation des menaces à envisager d’autres aspects, et certaines peuvent être ignorées. L’IA peut éviter les biais cognitifs, comme le fait d’ignorer certaines menaces parce que l’on suppose qu’une partie du système est sécurisée.
Chez Okta, nous voyons clairement la valeur de l’IA pour la modélisation des menaces, mais nos emplois sont toujours sécurisés (du moins pour les personnes chargées de la modélisation des menaces). L’IA reste clairement un outil utile dans notre workflow, sans en être le moteur ni le propriétaire.
Vous souhaitez découvrir comment d’autres équipes utilisent ces technologies ? Découvrez comment les collaboratrices et collaborateurs d’Okta utilisent l’IA pour stimuler l’innovation.
