Comment faire des LLM un avantage défensif sans créer une nouvelle surface d’attaque

Les grands modèles de langage (LLM) sont apparus dans le domaine de la sécurité sous trois formes différentes à la fois : en tant qu’outils de productivité placés aux côtés des analystes, en tant que composants intégrés dans les produits et les flux de travail et en tant que cibles que les attaquants peuvent sonder, manipuler et voler.

Cette convergence est la raison pour laquelle la conversation semble compliquée. La même capacité qui peut résumer un incident en quelques secondes peut également générer un prétexte crédible pour un spear phishing. Le même assistant qui peut rédiger une logique de détection peut également être amené à divulguer un contexte sensible s’il est connecté à des bases de connaissances internes sans garde-fous.

Je considère les LLM comme un autre système à fort impact : définir les résultats, modéliser les menaces et créer des contrôles qui supposent que le modèle sera erroné ou manipulé.

Comment les LLM changent le travail des équipes de sécurité

Lorsque les gens disent « LLM dans le SOC », ils imaginent souvent une interface de chat. Le changement le plus significatif est d’ordre architectural : les LLM rendent peu coûteuse la traduction de données de sécurité non structurées en hypothèses, récits et étapes suivantes structurés. C’est important car une grande partie du travail de sécurité n’est pas techniquement difficile. C’est de l’assemblage de contexte.

Si je déployais une fonctionnalité LLM dans un programme de sécurité, je commencerais par un ensemble restreint de flux de travail dont le résultat est consultatif et facile à vérifier. Ensuite, je ne développerais qu’une fois que l’équipe pourra mesurer la qualité et gérer les modes de défaillance.

Voici des cas d’utilisation à forte valeur ajoutée, bien adaptés à une adoption précoce :

• Des résumés de tri des alertes qui transforment la télémétrie brute en un bref récit « ce qui s’est passé, pourquoi c’est important et ce que je devrais vérifier ensuite »
• Copilotes d’enquête qui génèrent une chronologie à partir des journaux, des tickets et des transcriptions de chat, puis mettent en évidence les lacunes et les pivots recommandés
• Assistance à l’ingénierie de détection pour la rédaction d’extraits de langage Sigma, YARA ou de requête qu’un ingénieur peut examiner et tester
• Copilotes de gestion des vulnérabilités qui regroupent des résultats similaires, expliquent l’exploitabilité en termes commerciaux et proposent des fenêtres de correctifs
• Questions et réponses sur les politiques et les normes, où l’assistant répond aux questions en citant le langage exact du contrôle interne sur lequel il s’est appuyé

Même dans ces scénarios sûrs, la règle de fonctionnement que j’utilise est simple : traiter la sortie LLM comme non fiable. Si un modèle est autorisé à écrire du code, à recommander une action de confinement ou à référencer des données internes, vous devez supposer qu’il peut halluciner, être socialement conçu ou être incité à adopter un comportement dangereux.

La communauté OWASP a répertorié les modes de défaillance courants pour les applications compatibles LLM, notamment l’injection rapide, la gestion des sorties non sécurisée, la divulgation d’informations sensibles, l’agence excessive et la dépendance excessive. Ce ne sont pas des concepts académiques. Ils correspondent directement aux manières dont les LLM échouent dans les flux de travail de sécurité. Voir OWASP Top 10 pour les applications LLM.

En pratique, je considère un déploiement LLM en sécurité comme trois couches : le modèle, les données qu’il peut voir et les actions qu’il peut entreprendre. Vous pouvez obtenir une valeur significative en élargissant la première couche (par exemple, en utilisant de meilleurs modèles ou invites) tout en gardant les deux autres couches contraintes.

Trois choix de conception réduisent systématiquement les risques sans tuer la valeur :

• Rendre les sources explicites : Utilisez la génération augmentée par récupération pour que l’assistant réponde à partir de documents, de tickets ou de playbooks sélectionnés et montre les extraits cités à l’analyste.
• Gardez le modèle hors du rayon d’explosion : Le modèle ne doit pas avoir de secrets. Utilisez des informations d’identification de courte durée, des jetons étendus et un accès négocié aux outils.
• Actions de porte : Tout ce qui modifie l’état d’un système (blocage, mise en quarantaine, suppression, envoi de courrier électronique) doit nécessiter une approbation humaine ou un moteur de stratégie distinct.

Les dirigeants doivent encore être lucides en matière de mesure. Si vous ne pouvez pas quantifier si l’assistant réduit le temps de réponse ou améliore la qualité du signal, vous assumez une nouvelle classe de risque opérationnel pour un gain incertain.

Comment les attaquants utilisent la même capacité pour évoluer et personnaliser

Les défenseurs ne sont pas les seuls à automatiser l’assemblage de contexte. Les attaquants peuvent utiliser les LLM pour effectuer des reconnaissances, créer un langage et itérer rapidement. Le résultat n’est pas tant de nouvelles attaques qu’un changement dans la situation économique des attaquants : une personnalisation moins chère, une itération plus rapide et moins de barrières linguistiques.

L’impact le plus immédiat concerne l’ingénierie sociale. Un bon e-mail de phishing ne se limite pas à une grammaire correcte. C’est la pertinence situationnelle : le bon ton, le bon jargon interne et le bon moment dans un processus métier. Les LLM rendent ce type de personnalisation trivial à grande échelle.

Une étude réalisée en 2024 par Heiding, Lermen, Kao, Schneier et Vishwanath a évalué des campagnes de spear phishing entièrement automatisées validées sur des sujets humains. Dans leur expérience, les e-mails générés par l’IA ont été comparables à ceux d’experts humains et bien meilleurs qu’un groupe témoin de phishing générique. Le document mérite d’être lu dans son intégralité car il quantifie le problème et rend tangibles les aspects économiques de l’attaquant.

Dans le même temps, les organisations créent un nouvel ensemble de cibles souples en intégrant les LLM dans des bases de connaissances internes, des systèmes de tickets et des outils de workflow. Si un attaquant peut provoquer une injection rapide via une entrée contrôlée par l’utilisateur, un document dans un référentiel partagé ou une page Web compromise que l’assistant est autorisé à lire, le modèle peut devenir un canal de fuite de données ou d’actions dangereuses.

C’est pourquoi je traite la sécurité LLM comme une discipline à la fois offensive et défensive. Vous défendez votre organisation contre les menaces LLM et vous défendez vos propres systèmes LLM contre vous. Le ministère britannique de la Science, de l’Innovation et de la Technologie a cartographié les vulnérabilités tout au long du cycle de vie de l’IA, de la conception à la maintenance, ce qui constitue un modèle mental utile pour les équipes de sécurité.

Pour que cela reste exploitable, je regroupe les opportunités des attaquants en trois catégories :

1. Les LLM comme moteurs de persuasion : de meilleurs prétextes, de meilleures escroqueries multilingues, une meilleure usurpation d’identité et de meilleurs scripts de fraude
2. Les LLM comme moteurs de productivité : itération plus rapide sur les logiciels malveillants de base, les scripts, les rapports de reconnaissance et l’adaptation des exploits
3. Les LLM comme cibles et pivots : voler des invites, extraire des instructions système, empoisonner des sources de données ou manipuler des agents utilisant des outils

L’implication défensive est inconfortable : certains de vos contrôles existants sont plus importants que jamais, notamment la vérification, la vérification de l’identité et le renforcement des processus. Si un flux de travail d’approbation de la direction peut être contourné avec un message convaincant, un LLM aidera les attaquants à trouver et à exploiter cette faiblesse plus rapidement.

Les LLM compliquent également la détection basée sur le contenu. Lorsque les attaquants parviennent à générer un langage clair, j’accorde plus d’importance aux signaux techniques et comportementaux (authentification de l’expéditeur, connexion inhabituelle, modèle de demande de paiement anormal) qu’aux indices de ton ou de grammaire.

Une pile de contrôle qui vous permet d’utiliser les LLM sans perdre l’intrigue

Je ne pense pas que les organisations aient besoin d’un tout nouveau régime de gouvernance pour les LLM. Ils doivent appliquer la gouvernance existante aux nouveaux modes de défaillance. Ce qui se rapproche le plus est la gestion des risques, et non l’adoration du modèle.

Un point d’ancrage utile est le cadre de gestion des risques de l’intelligence artificielle du NIST, qui organise les activités en fonction de la gouvernance, de la cartographie, de la mesure et de la gestion. La valeur réside moins dans les étiquettes que dans la discipline : définir la responsabilité, comprendre le contexte et les impacts, mesurer les risques, puis opérationnaliser les mesures d’atténuation.

Si je conseillais un comité de sécurité et des risques sur un programme LLM, je proposerais la pile de contrôle suivante. Il est volontairement pragmatique et suppose un environnement mixte de modèles tiers, de données internes et d’intégrations d’outils :

• Gouverner: Définissez ce que le modèle est autorisé à faire, à qui il appartient et ce que signifie dangereux dans votre contexte (classes de données, flux de travail réglementés, décisions critiques)
• Carte: Documenter le système de bout en bout, y compris les invites, les sources de données, les pipelines de récupération, les plug-ins et les actions en aval ; pas seulement le point final du modèle
• Sécurisez les données : Formation à l’inventaire, mise au point et récupération des corpus, application des contrôles d’accès et surveillance des empoisonnements, des fuites et des réutilisations non autorisées
• Modèle de menace avec des techniques spécifiques à l’IA : Cartographiez les comportements probables des adversaires à l’aide de MITRE ATLAS et incluez l’injection rapide et l’abus d’outils dans vos scénarios.
• Construire des garde-corps aux limites : Validation des entrées, filtrage de contenu, contraintes de sortie et analyse basée sur un schéma pour toute sortie alimentant l’automatisation
• Actions à fort impact : Exiger des approbations explicites, une authentification renforcée ou des vérifications du moteur de politique avant qu’un agent puisse changer d’état en production
• Testez comme vous le pensez : Faites équipe avec l’assistant, exécutez des suites de jailbreak et d’injection rapide et mesurez les taux d’erreur sous des charges réalistes
• Instrumenter, surveiller et réagir : Enregistrez les invites, les appels et les sorties des outils, détectez les modèles d’utilisation anormaux et maintenez un kill switch pour une automatisation dangereuse.

Autres étapes

Deux documents d’orientation publique méritent d’être lus car ils traduisent l’IA sécurisée en étapes opérationnelles. Premièrement, les « Lignes directrices pour le développement de systèmes d’IA sécurisés » – un document publié par le National Cyber ​​Security Centre (NCSC) du Royaume-Uni et l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) – fournissent des conseils sur le cycle de vie, depuis la conception sécurisée jusqu’à l’exploitation et la maintenance sécurisées. Deuxièmement, « Déployer des systèmes d’IA en toute sécurité » – publié conjointement par l’Artificial Intelligence Security Center (AISC) de l’Agence nationale de sécurité des États-Unis et la Cybersecurity and Infrastructure Security Agency (CISA), ainsi que d’autres agences nationales et internationales – se concentre sur les meilleures pratiques pour déployer et exploiter des systèmes d’IA développés en externe.

Enfin, je traite l’agence excessive comme une ligne que vous franchissez délibérément. Plus vous accordez d’autonomie à un agent basé sur LLM, plus vous construisez une nouvelle classe de logiciels privilégiés. Si vous ne souhaitez pas accorder à un script junior un accès illimité à l’API, vous ne devez pas non plus l’accorder à un modèle probabiliste.

La convergence des LLM et de la cybersécurité n’est pas facultative. Les attaquants utiliseront ces outils et les employés le font déjà. L’avantage vient de capter les gains de productivité tout en gardant le contrôle des données, de l’identité et de la gestion du changement.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?