Quels sont les risques de sécurité liés à l’IA ?

Qu'est-ce que l'IA ?

L’intelligence artificielle, ou IA, désigne la faculté qu’ont certains logiciels et ordinateurs à résoudre des problèmes et à prendre des décisions. Ils s’appuient pour cela sur les prouesses du traitement avancé des données. Les capacités de l’IA ne sont pas sans rappeler l’intelligence humaine, mais à des niveaux qui dépassent largement nos capacités.

Quels sont les avantages de l’IA pour les entreprises ?

L’IA promet de révolutionner les fonctions métier à une échelle presque infinie. On ne connaît pas encore toute l’étendue de ses capacités, mais elle soutient déjà des secteurs tels que la logistique, la santé et la finance – parmi beaucoup d’autres. Elle les aide à optimiser des processus pour fluidifier la circulation des produits d’un point à un autre, à traiter de grands volumes de données médicales pour identifier des modèles et des anomalies à des fins de diagnostic et de traitement, à détecter plus intelligemment la fraude et à bloquer les transactions suspectes pour assurer la sécurité des actifs financiers. Et ce n’est que la partie émergée de l’iceberg.

L’IA en quelques exemples

L’IA est un terme générique qui englobe plusieurs variantes de la technologie, chacune offrant un avantage spécifique aux entreprises et à la société dans son ensemble. Voici quelques exemples de technologies d’IA :

Machine learning (ML) : avec l’apprentissage automatique, les machines découvrent leurs propres algorithmes, ou modèles, sur la base de données qui leur permettent « d’apprendre » le problème qu’elles tentent de résoudre. Plus elles reçoivent de données, plus le potentiel des résultats est important. Au début, le processus d’apprentissage peut impliquer l’intervention d’humains qui vont « étiqueter » les résultats corrects. Au fil du temps, cet élément humain devient moins nécessaire, les résultats obtenus gagnant progressivement en précision.

Grand modèle de langage (LLM) : basés sur l’apprentissage profond – un sous-ensemble du ML, les LLM sont pré-entraînés. Ils s’appuient sur des réseaux neuronaux composés de dizaines de millions de paramètres pour traiter de grands volumes de données en parallèle. Qu’ils fonctionnent en mode d’apprentissage autosupervisé ou semi-supervisé, leur objectif n’est pas seulement d’obtenir des connaissances. Ils cherchent en effet à reproduire des facettes contextuelles de la connaissance : la syntaxe, la sémantique et d’autres traits ontologiques des êtres humains, comme nos façons de penser et de communiquer.

IA générative : technologie capable de générer des médias (texte, images, etc.) en réponse à une invite, ou « prompt », après avoir appris les structures de ses données d’entraînement. Sur la base des données fournies par les utilisateurs dans le prompt, l’IA applique des techniques de ML en traitant les données via des réseaux neuronaux. Le média qui en résulte peut être utilisé dans de multiples applications : création d’œuvres d’art inspirées, code pour la conception de logiciels, rédaction de documentation, d’articles et de rapports, enrichis de citations – et bien d’autres choses encore.

Risques de sécurité liés à l’IA

Face à tous les avantages qu’elle peut offrir aux organisations du monde entier, l’IA représente tout autant un risque important pour chaque secteur d’activité. Les risques de cybersécurité n’ont rien de nouveau, mais l’impact qu’exerce actuellement l’IA sur le risque l’est assurément, de même que son évolution à mesure que l’IA gagnera du terrain dans l’entreprise.

Et ce n’est pas seulement la conviction d’une minorité ou l’intrigue d’un film à succès dépeignant l’essor de l’IA comme le début de la fin de l’humanité. En fait, la majorité des professionnels de la cybersécurité s’accordent sur un point : l’IA sera militarisée à une échelle et à une vitesse qui dépassent largement ce que nous comprenons et connaissons aujourd’hui. Mais par une ironie du sort, les défenses basées sur l’IA seront indispensables « pour lutter contre ces attaques sophistiquées avec des tactiques avancées qui détectent, interprètent et traitent la menace avant qu’elle n’ait une chance d’avoir un impact. »

Et quels sont exactement ces risques liés à l’IA qui pèsent sur la sécurité des ressources des organisations ?

Remercions l’OWASP et son projet Top 10 for Large Language Model Applications for 2023, un rapport complet conçu pour « éduquer les développeurs, les concepteurs, les architectes, les responsables et les organisations sur les risques de sécurité potentiels associés au déploiement et à la gestion des grands modèles de langage (LLM). » La liste comprend :

• les vulnérabilités les plus critiques affectant l’IA
  • leur impact potentiel
  • leur facilité d’exploitation
  • leur prévalence dans les applications du monde réel

LLM01 : Injection de prompt

Vous connaissez les attaques par injection SQL ? Les vulnérabilités d’injection de prompt dans l’IA fonctionnent de façon similaire. Le prompt est rédigé de manière à manipuler le modèle et à provoquer des actions involontaires. Les injections directes sont capables d’écraser les réponses du système, tandis que les attaques par injection indirecte cherchent à manipuler les entrées reçues de sources externes.

Comme dans le cas des attaques par injection SQL, les stratégies d’atténuation reposent sur la mise en œuvre de pratiques de validation des entrées et d’assainissement des données pour les données fournies par les utilisateurs. De plus, le formatage de sortie permet de filtrer les réponses tout en réduisant davantage le risque de manipulation des prompts.

LLM02 : Traitement non sécurisé des sorties

Les attaquants ont souvent recours à des tactiques de fuzzing pour déterminer la meilleure façon d’attaquer un logiciel. En examinant les réponses à des entrées spécialement élaborées, des acteurs malveillants peuvent déduire des informations critiques et obtenir des indices sur les vulnérabilités exploitables en vue de compromettre des systèmes. Sans un examen attentif de la sortie du LLM, le système sous-jacent peut être exposé à des vulnérabilités comme la falsification de requêtes côté serveur (SSRF). Il est essentiel minimiser ce risque et éviter les exploitations susceptibles de contourner les contrôles d’accès pour accéder sans autorisation à des données sensibles. Pour cela, il faut à la fois valider et assainir les entrées pour atténuer les menaces initiées par des requêtes malveillantes. On recommande aussi d’examiner fréquemment les données d’audit pour que les ressources restent protégées contre l’IA.

LLM03 : Empoisonnement des données d’apprentissage

Dans la mesure où les données d’entraînement sont l’élément vital du processus d’apprentissage en profondeur de l’IA, la qualité des résultats générés par l’IA dépend de celle des données d’entrée. Ce précepte est particulièrement important car il devient alors possible d’introduire des vulnérabilités susceptibles de compromettre la sécurité, l’intégrité et l’efficacité des données. Les organisations doivent donc impérativement s’assurer que les données d’entraînement proviennent de sources fiables. Elles doivent vérifier leur intégrité afin de garantir qu’elles n’ont pas été empoisonnées ou falsifiées, et ne comportent aucun biais susceptible d’avoir un impact sur le comportement éthique du système.

LLM04 : Déni de service du modèle (DoS)

Les LLM représentent une cible précieuse pour les acteurs malveillants, qui procèdent de façon similaire aux attaques DoS. Attaquer des opérations fortement consommatrices de ressources peut entraîner des interruptions de service et une augmentation des coûts. Et la situation est d’autant plus complexe lorsque tout, des opérations commerciales à la cybersécurité, repose sur des outils d’IA. Si l’on ajoute à cela la diversité des entrées des utilisateurs, le nombre de variables ne fait que croître de manière exponentielle. Les professionnels de la sécurité ont fort à faire, et ils devraient avant tout mettre en place des plafonds de ressources afin d’éviter que des demandes excessives n’épuisent les ressources. En associant cette pratique à une surveillance continue de l’utilisation des ressources et à des limites strictes en entrée, les administrateurs vont éviter tout risque de saturation et préserver l’accessibilité des outils d’IA.

LLM05 : Chaîne d’approvisionnement

L’année 2022 a été marquée par non pas une, mais plusieurs failles de la chaîne d’approvisionnement très médiatisées. Ces failles ont eu un impact considérable, et les analystes prévoient pour 2023 une multiplication des attaques de ce type, qui représentent de nombreuses opportunités pour les pirates. Selon l’OWASP, « les vulnérabilités de la chaîne d’approvisionnement des LLM peuvent affecter l’ensemble du cycle de vie des applications » – bibliothèques, instances conteneurisées, images et paquets. Cela concerne également les fournisseurs de services cloud qui peuvent héberger des modèles ou fournir des services d’interface, comme les plug-ins (mais nous en reparlerons plus tard car ils ont leurs propres vulnérabilités). Pour protéger vos modèles d’IA contre les menaces de la chaîne d’approvisionnement, il faut une approche multicouches de votre plan de sécurité. Tout d’abord, une sélection rigoureuse des partenaires est indispensable pour jeter des fondations solides. Il faut également procéder à des audits réguliers des sources pour garantir la primauté de la sécurité. Les bonnes pratiques en matière de signature de modèle et de code sont plus efficaces lorsqu’elles sont associées à des sources fiables. Bien entendu, une surveillance active est indispensable pour détecter les vulnérabilités, les composants non conformes et les anomalies qui pourraient présenter un risque pour la sécurité de vos LLM. Enfin, on tiendra l’inventaire des composants utilisés en conjonction avec les opérations de machine learning (MLOps) pour assurer la fiabilité, l’efficacité et la sécurité du déploiement et de la gestion des modèles.

LLM06 : Divulgation d’informations sensibles

Autre problème de cybersécurité bien connu, la fuite de données représente un facteur de risque exponentiel pour la sécurité des données. Encore une fois, rien de très nouveau pour le secteur de la sécurité – mais les ramifications des risques liés à l’IA sont impossibles à quantifier. Les informations partagées avec les outils d’IA peuvent révéler (et l’ont déjà fait) des données confidentielles dans leurs réponses, comme le montrent trois problèmes récents de fuite de données exclusives appartenant à Samsung. Les applications de ML apprennent à partir de toutes les données d’entrée et construisent une base sur laquelle elles s’appuient pour résoudre une requête. Les conséquences de ce mécanisme peuvent être lourdes : accès non autorisés aux données, violations de la conformité ou de la confidentialité et, bien sûr, violations de données. C’est pourquoi il est essentiel que les utilisateurs connaissent et comprennent les conséquences potentielles de leurs actions en les sensibilisant à ce qui ne doit pas être communiqué à une IA et pourquoi.notwhy De plus, les organisations ont tout intérêt à former les utilisateurs aux règles de l’organisation afin de renforcer la sécurité des pratiques métier.

LLM07 : Conception de plug-ins non sécurisée

Abordés dans le cadre des vulnérabilités de la chaîne d’approvisionnement, les plug-ins présentent, par leur fonctionnement même, un risque critique pour les données auxquelles l’IA accède et qu’elle génère. Dans de nombreux cas, les LLM s’appuient sur des plug-ins ou des API pour travailler directement avec les données d’entrée et les sorties générées par les modèles d’IA. Les plug-ins non sécurisés peuvent être la proie de requêtes malveillantes aux finalités diverses : fuite de données, exposition des systèmes sous-jacents ou exécution de codes à distance. Ils peuvent également conduire à l’empoisonnement des résultats : le modèle produit alors des résultats compromis ou des informations sensibles sur le système, utilisables dans le cadre d’une attaque. Par mesure de précaution, on considérera donc toutes les données d’entrée comme non sécurisées. On associera la validation des données d’entrée (avec des exigences d’entrée paramétrées) à des contrôles d’accès explicites pour limiter les risques de sécurité. De plus, les plug-ins doivent être testés de manière approfondie pour valider leur code. Les bonnes pratiques de développement de code sécurisé doivent être appliquées à chaque phase du pipeline.

LLM08 : Excès de pouvoir de décision

La vision de l’IA et, dans une certaine mesure, celle que véhicule son marketing, est celle d’un assistant personnalisé constamment disponible pour effectuer le « gros du travail » à notre place. Un peu comme le JARVIS de Tony Stark/Iron Man, les IA doivent pouvoir tout gérer, des playlists de musique aux calculs scientifiques à la volée face à un élément inconnu. L’IA a en effet à son actif quelques exploits de ce genre, comme les voitures autonomes. Et le pouvoir de décision accordé directement au modèle, comme les actions automatisées qui résultent du traitement des données par l’IA et sont exécutées par des plug-ins ou des outils (décision indirecte) ont un point commun : l’absence de contribution ou d’autorisation humaine. Ce point pose à lui seul l’un des problèmes les plus effrayants qui soit. En effet, les LLM ou les plug-ins associés peuvent réaliser des opérations inutiles, voire imprévues, simplement parce qu’on leur a accordé un pouvoir de décision ou une autorisation. Et les opérations en question pourraient être indésirables. Ou encore, comme l’indique le projet de loi sur l’IA de l’Union européenne, « les systèmes d’IA devraient être supervisés par des personnes, plutôt que par l’automatisation, afin d’éviter des résultats préjudiciables. »

Comment atténuer ce type de risque ? En mettant en œuvre d’une approche fondée sur le risque. Comme dans le modèle zero-trust, « Les LLM ne devraient pas être considérés comme capables de s’auto-réguler ou de s’auto-limiter. » Pour y parvenir, on visera à limiter l’accès des plug-ins et des outils aux seules fonctionnalités requises. Pour renforcer la surface d’attaque, évitez également les fonctions ouvertes et toutes les fonctions inutiles. Renforcez les contrôles d’accès pour limiter les interactions et les opérations aux seules requises par l’achèvement des processus.

LLM09 : Excès de confiance

Si l’excès de pouvoir de décision est source d’angoisse, l’excès de confiance l’est tout autant, voire plus. Je m’explique. De nombreux utilisateurs se sont appropriés les outils d’IA générative tels que ChatGPT pour créer du contenu : articles, images captivantes, compilation de contenus vidéo hyperréalistes – tous entièrement produit par l’IA. La capacité à générer un média est un exploit en soi. Mais comme toujours, c’est l’intention de l’utilisateur qui détermine si l’outil sert à construire ou à détruire. Vous pensez peut-être que c’est de la dramatisation à outrance. Pourtant, quand les utilisateurs font des contenus générés par l’IA une parole d’évangile, les conséquences peuvent être désastreuses. Une hallucination de l’IA peut introduire de la désinformation dans un document technique généré. Imaginez alors les conséquences pour des secteurs majeurs tels que la santé, l’informatique ou la cybersécurité. Pensez aussi avec quelle facilité on peut produire de faux enregistrements audios de personnes réelles à partir de quelques secondes seulement d’extraits sonores. Imaginez maintenant que vous diffusiez ce faux enregistrement en ligne. Selon le contenu, cela pourrait suffire à ruiner la réputation publique de quelqu’un. L’enregistrement « truqué » pourrait également être utilisé pour commettre un crime.

En d’autres termes, nous n’avons aucune idée de l’ampleur des conséquences d’un excès de confiance dans l’IA. Mais il existe des tactiques qui peuvent aider à distinguer ce qui est réel des contenus générés par les LLM. On peut tout d’abord vérifier les faits auprès de sources externes de confiance pour déterminer l’exactitude et la validité du contenu généré. Comme pour le développement de plug-ins, la mise en place et le respect de pratiques de codage sécurisées minimisent le risque d’introduire des vulnérabilités dans l’environnement de développement. Outre les mécanismes de validation et la vérification croisée des informations, il faut une communication claire et concise des risques, des problèmes connus et des limites propres à l’utilisation de l’IA et des contenus générés. Les efforts d’éthique et de transparence des créateurs comme des utilisateurs doivent être encadrés, un peu comme les lois de la FCC régissent la publicité.

LLM10 : Vol de modèle

Cette vulnérabilité est l’une des plus simples. Relevant de l’exfiltration non autorisée de données, on parle cette fois de l’acquisition du LLM lui-même par des acteurs malveillants. On pense bien sûre aux menaces d’exfiltration de données, qui n’ont pas attendu l’apparition l’IA : les pirates savaient déjà cibler des données sensibles, privées et confidentielles et les extraire des appareils ou des réseaux dans le but de les divulguer, de les exploiter ou d’alimenter une campagne d’espionnage. Le vol de modèles d’IA, comme tout vol de données confidentielles, peut être plus ou moins grave, tant du point de vue économique que de celui de la continuité des activités. Il peut entraîner une perte de revenus ou d’avantages concurrentiels en cas d’utilisation non autorisée du modèle, ou être mis à profit dans le cadre d’une attaque ciblant l’organisation victime. La clé consiste à sécuriser votre LLM à l’aide de stratégies de sécurité à plusieurs niveaux. Combinez des contrôles d’accès forts, la segmentation du réseau et le sandboxing pour limiter l’accès aux ressources, la surveillance active des ressources, et des audits réguliers des journaux et des activités liés à votre LLM. Les tactiques de réponse aux incidents doivent être déclenchées et déployées en cas de comportement suspect. Outre les contrôles d’accès, l’atténuation rapide d’autres vulnérabilités touchant les LLM (et abordées dans cet article) peut réduire le risque de pivotement et de déplacement latéral des acteurs malveillants après une attaque d’un autre type.

Autres risques de sécurité liés à l’IA

Sandboxing insuffisant

Le sandboxing des données est un excellent moyen de séparer les processus sensibles du reste d’un système. On peut ainsi traiter efficacement des données tout en les isolant en toute sécurité du système sous-jacent. Elles sont inaccessibles aux menaces extérieures et isolées des risques présents en dehors du bac à sable. En raison de la relative nouveauté de l’IA, un certain nombre de questions entourent la conception d’un sandbox universellement accepté ou réglementé. Mais une chose est claire : les organisations qui souhaitent exploiter l’IA aujourd’hui ont tout intérêt à isoler les modèles, outils et systèmes d’IA dans un sandbox pour permettre des expérimentations sûres et éthiques. Elles minimiseront les risques tout en relevant de nombreux défis, comme l’absence de garanties formelles, les conséquences imprévues ou le manque d’homogénéité d’une solution à l’autre.

Désalignement de l’IA

On parle d’alignement de l’IA pour désigner « researchl’orientation des systèmes d’IA selon les objectifs, les préférences ou les principes éthiques des humains », selon Wikipédia. Si, malgré ses compétences, un système d’IA ne permet pas de progresser vers les objectifs visés, on considère alors qu’il est mal aligné. Ce défaut d’alignement peut entraîner des comportements indésirables, et notamment des actions et des dysfonctionnements potentiellement dommageables pour les entreprises voir, pire encore, sur la vie humaine. Considérons un instant un système d’IA utilisé pour générer le code d’un service web. L’objectif du développeur est de créer un code complexe et sécurisé pour fournir un service destiné à simplifier des tâches informatiques. L’IA peut, de son côté, être détournée de façon à générer un puissant code malveillant, susceptible de constituer une menace pour ce service web – ou pour tout autre service web d’ailleurs. Il faut donc maintenir l’IA sous surveillance constante en identifiant ce qui fonctionne et en améliorant ce qui ne fonctionne pas, afin de rendre les modèles plus sûrs. La surveillance humaine joue un rôle clé dans le processus d’alignement. On ne peut pas se contenter de cocher une case lorsque l’IA produit un résultat correct ou erroné. Il faut adopter une approche plus pragmatique et scientifique, en documentant les problèmes, en misant sur un entraînement continu, en examinant les retours et en évaluant les systèmes. Et toutes ces techniques clés – et bien d’autres – doivent être soumises à une exigence de transparence.

Principaux points à retenir :

• Développez des pratiques de validation des entrées et d’assainissement des sorties afin de réduire les fuites de données sensibles et les vulnérabilités liées à l’injection de prompts
• Contrôlez minutieusement les partenaires de la chaîne d’approvisionnement pour s’assurer de leur respect des pratiques de sécurité et d’éthique
• Veillez l’intégrité des données d’entraînement et assurez-vous qu’elles n’ont pas été altérées ou compromises en travaillant exclusivement avec des sources de confiance
• Auditez tous les systèmes utilisés pour l’IA
• Imposez des limites au partage des données, en particulier des informations privées et confidentielles
• Implémentez des contrôles de sécurité des données et d’accès, conformément aux meilleures pratiques du secteur
• Renforcez le matériel et les logiciels avec des mises à jour et des correctifs, et équipez-vous d’outils modernes de gestion des vulnérabilités et de la sécurité (ce qui inclut les outils basés sur l’IA/ML).
• Pensez à l’entraînement contradictoire pour faire face aux menaces IA et améliorer la résilience des modèles
• Formez régulièrement le personnel pour qu’il sache reconnaître et éviter les risques liés aux menaces générées par l’IA.
• Mettez en place une équipe de réponse aux incidents qui va détecter et prendre en charge des risques liés à l’IA.