L’intelligence artificielle s’impose désormais comme un levier structurant pour les entreprises : 70%¹ l’ont déjà placée au cœur de leur stratégie. Jusqu’ici, la majorité des déploiements reposaient sur des assistants conversationnels capables de restituer de l’information, parfois enrichie par des données internes, mais dont les interactions avec le système d’information restaient limitées.

Une rupture est désormais en cours : l’essor de l’IA agentique. Contrairement aux simples chatbots, les agents IA ne se contentent plus de répondre ; ils raisonnent, décident d’appeler des outils et déclenchent des actions. Ils peuvent envoyer un courriel, planifier un déplacement, mettre à jour un dossier, initier une transaction ou, demain, exécuter des opérations plus sensibles encore. Leur promesse en matière d’automatisation est considérable. Leur impact potentiel sur la surface d’attaque du système d’information l’est tout autant.

Car dès lors qu’un système d’IA agit, une question devient centrale : au nom de qui agit-il, avec quels droits, dans quel périmètre, et sous quel contrôle ?

Cette question est d’autant plus critique que les usages progressent rapidement : 51 %² des organisations ont déjà déployé un agent IA à destination de leurs collaborateurs, tandis que 59 %³ des salariés reconnaissent utiliser des agents IA non officiellement autorisés. Au-delà des usages individuels, chaque direction métier peut être tentée de déployer ses propres agents pour répondre à des besoins locaux. Ce phénomène alimente un Shadow IT agentique, dans lequel les agents se multiplient de manière fragmentée, avec des architectures hétérogènes, des contrôles variables et une gouvernance souvent lacunaire.

Dans ce contexte, l’Identity and Access Management (IAM) doit redevenir le centre de gravité de la stratégie de sécurité. Toute donnée qu’un agent peut consulter, toute ressource qu’il peut modifier, toute action qu’il peut exécuter doivent relever d’un dispositif de contrôle d’accès, de traçabilité et de gouvernance centralisé.

Cet article propose d’analyser la sécurisation des agents IA à travers le prisme de l’IAM, non comme une brique parmi d’autres, mais comme l’un des garde-fous structurants pour encadrer leurs usages et protéger durablement le système d’information.

Des assistants conversationnels aux agents IA : comment ils interagissent avec le SI

Par quels mécanismes un agent IA peut-il agir sur une application ?

La capacité d’un agent IA à interagir avec les applications du système d’information repose sur l’émergence de nouveaux protocoles, parmi lesquels le Model Context Protocol (MCP) occupe aujourd’hui une place croissante. Ce type de protocole permet à un agent IA de dialoguer avec des applications tierces via une couche intermédiaire, souvent matérialisée par une brique IT appelé serveur MCP.

Ce serveur MCP agit comme un composant d’exposition et d’orchestration. Il reçoit des requêtes émises par un modèle d’IA, les traduit en appels exploitables, puis les relaie vers les API de l’application cible.  Pour cela, le serveur MCP met à disposition du modèle des outils (“tools”) décrivant les actions qu’il est autorisé à invoquer. Une fois le serveur déclaré dans l’interface conversationnelle ou dans l’environnement de l’agent, le modèle peut décider, en fonction de la demande utilisateur et de son raisonnement, d’appeler un ou plusieurs de ces outils.

D’un point de vue sécurité, cela introduit une question d’identité : comment l’utilisateur final est-il authentifié, et comment cette identité est-elle propagée — ou non — jusqu’aux services cibles ? Dans les architectures modernes, l’authentification utilisateur repose généralement sur OpenID Connect (OIDC), tandis que l’autorisation d’accès aux API repose sur OAuth 2.x via des jetons d’accès. L’enjeu, pour un agent, est de garantir que les appels aux outils et aux API soient réalisés dans un modèle contrôlé de délégation : l’agent agit-il avec ses propres droits, avec les droits de l’utilisateur, ou selon un mécanisme hybride ?

Illustrons ce fonctionnement à travers un cas d’usage : la planification d’une réunion par un agent IA. L’utilisateur formule sa demande dans l’interface conversationnelle : « Planifie une réunion avec l’équipe demain à 10h ». L’agent IA analyse la requête et décide d’utiliser l’outil « Calendrier » mis à disposition par le serveur MCP. Il envoie alors une requête structurée à ce serveur, contenant uniquement les informations nécessaires à la création de l’événement (participants, date, heure, sujet). Le serveur MCP relaie cette demande à l’API du calendrier d’entreprise, qui permet de créer la réunion.

En apparence, le mécanisme est simple. En pratique, il introduit un changement majeur : le modèle ne se contente plus d’assister l’utilisateur ; il devient un intermédiaire actif entre l’intention humaine et l’exécution technique dans le SI.

Un mode de fonctionnement opaque

Cette architecture soulève immédiatement une difficulté de sécurité : dans de nombreux cas, le composant d’intégration ne dispose que d’une visibilité partielle sur le contexte d’origine. Il reçoit une requête structurée, mais pas nécessairement l’intégralité de la requête initiale, des arbitrages du modèle ou des éléments qui ont conduit au choix de l’outil invoqué. Le système d’information voit alors arriver une action, sans toujours pouvoir reconstituer de manière fiable la chaîne complète qui relie la demande utilisateur, le raisonnement du modèle, l’appel d’outil et l’effet final produit. Cette perte de contexte est d’autant plus critique lorsque l’appel à l’API est porté par un jeton OAuth : selon l’architecture, le service cible peut ne voir qu’une identité applicative (compte de service / application) et non l’utilisateur réel à l’origine de la demande. Cela fragilise l’attribution, la détection d’abus et la capacité à appliquer des politiques conditionnelles différenciées entre action humaine et action agentique.

Autrement dit, l’agent interagit avec le SI selon une logique partiellement opaque, qui rompt avec les schémas plus traditionnels d’interaction applicative. Cette opacité complique le contrôle en temps réel, la traçabilité ex post, ainsi que l’attribution claire de responsabilité.

Une technologie émergente qui pose des défis de sécurité

L’IA agentique introduit des cas d’usage nouveaux, mais aussi des risques nouveaux, qui doivent être analysés et traités au niveau de l’IAM. Quatre défis apparaissent comme particulièrement structurants.

Défi 1 : Recenser les agents IA 

Le premier défi est celui de la visibilité. Dans de nombreuses organisations, il n’existe aujourd’hui ni cartographie exhaustive des agents IA déployés, ni inventaire consolidé des outils auxquels ils sont connectés.

Cette situation résulte de deux dynamiques :

• D’une part, les usages se développent souvent en dehors des circuits de gouvernance historiques : certaines équipes déploient des agents pour leurs besoins propres, sans associer en amont les équipes sécurité, IAM ou architecture et dans parfois dans des solutions plateformes qui permettent à chacun de construire ses propres usages.
• D’autre part, les modalités techniques d’intégration sont diverses. Le MCP constitue une approche montante, mais il coexiste avec des intégrations propriétaires, des connecteurs natifs à certains écosystèmes, des mécanismes d’exécution locale de code, ou encore des capacités embarquées directement dans les plateformes des éditeurs.

Le sujet n’est donc pas seulement celui du recensement des agents eux-mêmes, mais celui de l’identification de l’ensemble de la chaîne d’exécution : agent, interface, outils exposés, applications cibles, comptes utilisés, données manipulées et flux générés. Sans cette visibilité, aucune gouvernance sérieuse n’est possible.

Défi 2 : Attribuer et gouverner les droits des agents IA

Le deuxième défi concerne l’autorisation. Les modèles IAM traditionnels ne disposent pas encore, dans la plupart des environnements, d’un objet natif et généralisé permettant de représenter proprement un agent IA comme une identité gouvernable à part entière.

En pratique, les composants intermédiaires sont fréquemment enregistrés comme des applications techniques ou opèrent à l’aide de comptes de service. Il en résulte plusieurs dérives connues : droits trop larges, absence de séparation fine entre les capacités d’un agent et celles du composant qui l’héberge, difficulté à appliquer le moindre privilège, et impossibilité de différencier clairement une action humaine directe d’une action exécutée par un agent.

Le risque est majeur : l’agent n’exécute plus seulement une intention métier ; il devient un vecteur d’accès indirect au SI, parfois avec un niveau de privilège supérieur à ce qui serait acceptable pour un utilisateur ou une application classique.

Défi 3 : Authentifier un agent IA

L’authentification constitue le troisième défi, à deux niveaux distincts. Il faut d’abord authentifier correctement l’utilisateur final, afin de garantir que l’agent n’agit pas dans un vide identitaire. Mais il faut également authentifier l’agent lui-même, ou à tout le moins le composant qui agit pour son compte, afin de pouvoir lui appliquer des politiques spécifiques, des restrictions adaptées et des exigences de supervision proportionnées.

Cette double exigence est nouvelle par son intensité : avec les agents IA, le système doit simultanément gérer l’identité du demandeur, l’identité du système exécutant, et la relation précise entre les deux.

Défi 4 : Tracer les actions réalisées par les agents IA

Le dernier défi est celui de la traçabilité. Dans de nombreuses architectures actuelles, les journaux permettent surtout d’observer l’appel technique émis vers le service cible. En revanche, il reste difficile de reconstituer de manière fiable :

• quel utilisateur est à l’origine de la demande ;
• quel agent a décidé ou exécuté l’action ;
• dans quel contexte métier l’appel a été réalisé ;
• quelles étapes intermédiaires ont conduit à l’exécution finale.

Ce déficit d’auditabilité fragilise à la fois la détection, l’investigation et la responsabilité. Lorsqu’une action sensible est déclenchée, il doit être possible de déterminer si elle résulte d’une instruction légitime, d’une mauvaise interprétation, d’une dérive autonome, d’un abus de privilège ou d’une compromission du contexte d’entrée, par exemple via une attaque de type prompt injection.

L’IAM comme cadre de référence pour sécuriser les agents IA

Les grands principes IAM restent inchangés

Face à cette transformation, un point doit être clairement affirmé : les fondamentaux de l’IAM ne disparaissent pas avec l’IA agentique. Au contraire, ils redeviennent essentiels.

Un système d’information maîtrisé repose sur quelques principes simples et robustes :

• centraliser l’authentification autant que possible autour d’un fournisseur d’identité de référence ;
• éviter les comptes génériques lorsqu’un usage nominatif est possible ;
• limiter les privilèges au strict nécessaire ;
• gouverner les habilitations dans la durée ;
• tracer les accès et les actions ;
• distinguer clairement les rôles, les responsabilités et les périmètres d’exécution.

L’arrivée des agents IA ne remet pas en cause ces principes. En revanche, elle révèle leurs angles morts actuels et impose de faire évoluer la gouvernance comme les mécanismes techniques. Ce n’est pas l’IAM qu’il faut réinventer ; c’est son modèle d’application qu’il faut adapter à une nouvelle catégorie d’acteurs numériques, capables de prendre des initiatives et de déclencher des effets dans le SI.

Une trajectoire de sécurisation en quatre étapes

1. Recenser les cas d’usage et les agents

La première étape consiste à obtenir une visibilité exhaustive. Cela suppose d’identifier :

• les agents déployés ;
• les environnements dans lesquels ils opèrent ;
• les outils et connecteurs qu’ils utilisent ;
• les applications qu’ils peuvent atteindre ;
• les comptes, identités techniques ou jetons qu’ils mobilisent ;
• les données qu’ils peuvent lire, modifier ou transmettre.

Cette cartographie n’est pas un exercice documentaire accessoire : elle constitue la condition préalable à toute politique de contrôle d’accès cohérente. Pour la réaliser, des outils du marché émerge, comme la solution Agent 365 de Microsoft.

2. Introduire un type d’identité spécifique pour les agents IA

La deuxième étape consiste à reconnaître les agents IA comme une catégorie spécifique d’identités non humaines. Ce marquage est essentiel, car il permet d’appliquer des politiques différenciées : interdiction de certaines actions, limitation à certains périmètres, exigences de validation préalable, surveillance renforcée ou restrictions conditionnelles.

Cette distinction est structurante. Une application classique n’a pas le même niveau d’autonomie, ni le même profil de risque, qu’un agent IA capable de sélectionner lui-même un outil, d’enchaîner plusieurs actions ou de réagir à un contexte ambigu. L’IAM doit donc être en mesure de dire non seulement qui agit, mais aussi de quelle manière le système agit.

À titre d’exemple, un utilisateur peut disposer du droit d’envoyer un courriel ou de créer un ordre de modification. Cela ne signifie pas qu’un agent puisse exécuter cette action sans garde-fou. Selon la sensibilité du processus, une politique dédiée peut imposer une validation humaine, un périmètre restreint ou une interdiction pure et simple.

3. Rattacher l’authentification et la gestion des droits à un fournisseur d’identité unique et à l’utilisateur final

La troisième étape consiste à ramener l’authentification dans le giron d’un fournisseur d’identité central, afin que les droits soient gouvernés de manière homogène. L’objectif est double : éviter le recours incontrôlé à des comptes techniques sur-privilegiés, et faire en sorte que l’agent opère, autant que possible, dans la limite des habilitations de l’utilisateur à l’origine de la demande.

Cela ne signifie pas que l’agent doit être transparent du point de vue de la sécurité. Au contraire, l’enjeu est de pouvoir appliquer une logique du type : « même si l’utilisateur a le droit, l’agent n’a pas nécessairement le droit de le faire seul, dans n’importe quel contexte, et sans contrôle complémentaire ».

4. Mettre en place une approbation humaine avant certaines actions initiées par les agents

La sécurisation des agents IA ne peut pas reposer exclusivement sur l’authentification et l’autorisation. Elle suppose aussi de définir le niveau d’autonomie acceptable selon la criticité des actions concernées.

Trois modèles sont classiquement distingués.

Human-in-the-loop

C’est le mode le plus protecteur. L’agent prépare l’action, mais son exécution reste conditionnée à une validation explicite. Ce schéma doit être privilégié pour les opérations sensibles : mouvement financier, modification de droits, envoi externe engageant l’entreprise, accès à des données sensibles, action à effet irréversible, etc.

Son intérêt est majeur : la validation finale est portée par une interface de contrôle indépendante du raisonnement de l’agent. Même si le modèle a été influencé, manipulé ou simplement trompé, l’utilisateur ou l’opérateur conserve la maîtrise de la décision.

Human-over-the-loop

Dans ce modèle, l’humain ne valide pas chaque action individuellement, mais supervise l’exécution et conserve une capacité d’interruption immédiate. Ce schéma peut convenir à des processus fréquents, encadrés et faiblement risqués, à condition que la surveillance soit réelle et que le mécanisme d’arrêt soit effectivement opérationnel.

Human-out-of-the-loop

Ici, l’agent exécute de manière autonome, sans intervention humaine immédiate. Ce niveau d’autonomie ne devrait être envisagé que pour des usages à très faible criticité, dans des environnements strictement bornés, avec des périmètres d’action réduits, des mécanismes de contrôle compensatoires solides et une tolérance explicite au risque résiduel.

Pour un RSSI, la logique est simple : plus l’impact métier, réglementaire ou sécurité est élevé, plus la boucle humaine doit être proche de l’exécution.

Une cible claire, mais encore freinée par plusieurs limites

Obstacles fonctionnels

La cible de sécurisation peut être formulée de manière claire. Sa mise en œuvre se heurte toutefois à plusieurs obstacles majeurs d’un point de vue fonctionnel.

Le premier concerne le manque de granularité des autorisations. Aujourd’hui, un utilisateur peut vouloir demander à un agent d’effectuer une action précise sur une ressource précise. Pourtant, les mécanismes disponibles imposent souvent des permissions bien plus larges que nécessaire. Traiter un courriel peut conduire à ouvrir l’accès à toute une boîte de messagerie ; planifier une réunion peut impliquer un accès étendu à l’agenda ; interagir avec un référentiel peut nécessiter des droits de lecture ou d’écriture bien au-delà du besoin exprimé. Ce décalage est particulièrement problématique dans un contexte agentique. Une IA étant par nature non déterministe dans sa manière de sélectionner et d’enchaîner ses actions, un accès trop large devient mécaniquement un risque disproportionné. Une adoption sécurisée suppose donc d’évoluer vers des mécanismes d’autorisation plus fins, contextualisés, temporaires et proportionnés à la requête réellement formulée.

Le second obstacle porte sur l’authentification et la propagation de l’identité. Dans beaucoup de cas, les architectures actuelles reposent encore sur des comptes techniques, des secrets partagés ou des mécanismes d’authentification peu satisfaisants au regard d’une gouvernance IAM mature. La cible consiste au contraire à faire en sorte que chaque action soit reliée de manière explicite à (i) l’utilisateur à l’origine de la demande, et (ii) au fait qu’elle a été exécutée par un agent — ce qui implique de distinguer l’identité du demandeur et l’identité du système exécutant, tout en documentant la relation de délégation entre les deux.  En pratique, cela renvoie à des mécanismes de délégation contrôlée tels que les flux OAuth “On‑Behalf‑Of (OBO)” : l’agent (ou sa couche d’orchestration) appelle une API en portant une autorisation dérivée de l’utilisateur, mais avec des contraintes supplémentaires (portée limitée, durée réduite, contexte, politiques conditionnelles). L’objectif est de réduire la dépendance aux comptes techniques sur‑privilégiés tout en conservant une chaîne de responsabilité exploitable.  À ce stade, le marché ne propose toutefois pas encore un modèle totalement homogène et interopérable couvrant à la fois l’authentification, l’autorisation fine, la traçabilité et la gouvernance des agents à grande échelle.

Dernier obstacle fondamental, la traçabilité : chaque action doit être liée de façon explicite à une chaîne de responsabilité intelligible. Sans cette capacité, il n’y a ni auditabilité robuste, ni contrôle effectif, ni gouvernance défendable devant les métiers, les auditeurs ou le régulateur. Et cela a un coût pour les SIEM…

Un marché encore fragmenté, qui complique la sécurisation

Du point de vue des entreprises, la difficulté n’est pas seulement technique : elle est aussi liée à la maturité du marché. Les capacités agentiques se diffusent plus vite que les standards de sécurité et de gouvernance capables de les encadrer de manière homogène. Résultat : les organisations doivent composer avec des solutions hétérogènes, dont le modèle d’identité, d’audit et de contrôle varie fortement d’un éditeur à l’autre.

Le MCP peut-il s’imposer comme standard de marché ?

Certains éditeurs exposent leurs applications via des serveurs MCP ou des mécanismes comparables, tandis que d’autres privilégient des intégrations natives, plus fermées, au sein de leur propre écosystème. Dans les faits, il n’existe pas encore de cadre pleinement homogène couvrant de manière satisfaisante les enjeux d’authentification, d’autorisation, de traçabilité, de gouvernance et de nomenclature des capacités exposées.

Deux trajectoires peuvent être envisagées :

• La première serait celle d’une convergence vers un socle standardisé, permettant l’interopérabilité des agents, des outils et des plateformes. Une telle évolution faciliterait le déploiement à grande échelle, améliorerait l’expérience utilisateur et rendrait possible une gouvernance plus cohérente à l’échelle de l’entreprise.
• La seconde serait celle d’une fragmentation durable du marché. Dans ce scénario, chaque éditeur continuerait à privilégier ses propres mécanismes, ses propres objets de sécurité et ses propres modèles d’intégration. Les conséquences seraient lourdes pour les entreprises : multiplication des angles morts, hétérogénéité des contrôles, difficulté à centraliser la supervision et impossibilité pratique d’appliquer une politique IAM homogène sur l’ensemble du périmètre agentique.

À court terme, les signaux du marché suggèrent une co‑existence : des initiatives d’interopérabilité émergent, mais les grands éditeurs conservent des logiques d’écosystèmes intégrés. Pour un RSSI, cela impose de raisonner non seulement “outil par outil”, mais aussi en termes de capacité à gouverner un portefeuille d’agents sur un périmètre multi‑éditeurs.

Vers des registres d’agents IA

La montée en puissance des agents IA justifie l’émergence d’un nouvel objet de gouvernance : le registre d’agents. Parce qu’un agent est un système autonome capable de déclencher des actions, il ne peut plus être traité comme un simple composant applicatif invisible. Il doit être identifié, qualifié, rattaché à un propriétaire, inscrit dans un cycle de vie, évalué en fonction de son périmètre d’action et soumis à des règles spécifiques.

Ce registre doit, à terme, permettre de répondre à des questions simples mais décisives :

• quels agents existent dans l’organisation ;
• qui en est responsable ;
• dans quel environnement opèrent-ils ;
• à quels outils et à quelles données ont-ils accès ;
• quels mécanismes d’authentification utilisent-ils ;
• quelles validations humaines sont exigées ;
• quels journaux produisent-ils ;
• quand doivent-ils être revus, requalifiés, suspendus ou retirés.

Certains fournisseurs d’identité commencent à introduire des capacités dédiées à cette nouvelle catégorie d’identités non humaines. C’est un signal important. Mais la maturité du marché reste naissante, et la gouvernance ne pourra pas être déléguée aux seuls éditeurs. Le vrai sujet est avant tout d’entreprise : définir un modèle de responsabilité, de contrôle et de sécurité adapté à l’autonomie croissante des systèmes d’IA.

Quand s’attaquer à l’IAM des agents IA ? Maintenant !

L’essor des agents IA marque une évolution majeure dans la transformation des systèmes d’information. En passant d’une logique d’assistance à une logique d’action, ces systèmes déplacent profondément les enjeux de sécurité : il ne s’agit plus seulement de maîtriser les données qu’une IA peut consulter, mais bien les actions qu’elle est en mesure d’exécuter, les droits qu’elle mobilise et les responsabilités qu’elle engage.

Dans ce contexte, l’IAM s’impose comme un levier structurant. Il constitue le socle permettant de rendre visibles les agents, de maîtriser leurs habilitations, de tracer leurs actions et de définir les conditions dans lesquelles leur autonomie peut être acceptée. Autrement dit, la sécurisation des agents IA ne pourra pas reposer sur des mesures périphériques : elle suppose une approche de gouvernance intégrée, articulant identité, contrôle d’accès, supervision et validation humaine.

Pour les organisations, l’enjeu n’est pas de freiner l’adoption de l’IA agentique, mais de l’encadrer dans un modèle de confiance soutenable. Cela implique dès aujourd’hui de poser des choix structurants : cartographier les usages, intégrer les agents dans les dispositifs IAM, distinguer les identités humaines et non humaines, adapter les politiques d’autorisation, et définir des garde-fous proportionnés à la criticité des actions confiées.

À mesure que les architectures se standardiseront et que les offres du marché gagneront en maturité, les entreprises les mieux préparées seront celles qui auront traité les agents IA non comme de simples assistants innovants, mais comme de nouveaux acteurs du SI, soumis aux mêmes exigences de sécurité, de traçabilité et de gouvernance que tout composant critique.

La question n’est donc plus de savoir si les agents IA trouveront leur place dans l’entreprise, mais dans quelles conditions de maîtrise. Pour les RSSI, le sujet est clair : la capacité à industrialiser l’IA agentique dépendra moins de la performance des modèles que de la robustesse du cadre IAM et de gouvernance mis en place pour l’encadrer.

Si, vous aussi, vous vous interrogez sur la gestion des accès des agents IA ou souhaitez approfondir la sécurisation de ces nouveaux usages, nous serions ravis d’échanger avec vous. N’hésitez pas à nous solliciter pour partager vos enjeux ou explorer ensemble des pistes adaptées à votre contexte.

1. Wavestone – Global AI Survey 2025  – AI Adoption and Its Paradoxes: Global AI survey 2025 | Wavestone)
2. PagerDuty (2025) More than Half of Companies (51%) Already Deployed AI Agents. Pager Duty, March 2025. Available at: 2025 Agentic AI ROI Survey Results (Accessed: 2 January 2026)
3. Cybernews (2025) Unapproved AI Tools in the Workplace. September 2025. Available at: https://cybernews.com/ai-news/ai-shadow-use-workplace-survey/ (Accessed: 2 January 2026).

Cet article Sécuriser les agents IA : pourquoi l’IAM devient central est apparu en premier sur RiskInsight.

Le défi du choix des guardrails

Du fait de la multiplication des solutions de protection pour les applications d’IA, les organisations sont confrontées à un défi: sélectionner des moyens de protection permettant de réduire efficacement les risques sans compromettre l’expérience utilisateur ou la gestion de l’application.

La sélection des guardrails ne se limite pas à bloquer les prompts malveillants, elle nécessite de trouver un équilibre entre la précision de la détection, les faux positifs, la latence et la capacité à adapter le filtrage au contexte spécifique de l’application, aux sources de données et à l’exposition aux menaces de chaque application. Dans la pratique, aucune solution unique ne répond aussi bien à tous les cas d’utilisation, ce qui fait du choix de ces solutions une décision contextuelle et axée sur les risques.

Une grande diversité de solutions

En 2025, le paysage de la sécurité IA et des guardrails LLM a connu une consolidation importante. Les principaux fournisseurs de cybersécurité ont cherché de plus en plus à élargir leurs offres avec des protections dédiées à l’IA générative, à l’utilisation des modèles et aux interactions avec les agents. Plutôt que de développer ces capacités à partir de zéro, beaucoup ont choisi d’acquérir des start-ups spécialisées afin d’intégrer rapidement des fonctionnalités de sécurité IA dans leurs plateformes existantes, comme SentinelOne avec Prompt Security ou CheckPoint avec Lakera.

Cette tendance illustre une évolution plus large du marché de la cybersécurité: les protections pour les applications basées sur le LLM deviennent une composante standard des offres de sécurité des entreprises, au même titre que les contrôles plus traditionnels. Les guardrails et les protections IA en temps réel ne sont plus des solutions de niche, mais sont progressivement intégrés dans les piles de sécurité classiques afin de soutenir l’adoption de l’IA à l’échelle des entreprises.

Critères de comparaison

Devant une telle diversité de solutions de filtrage IA, choisir la meilleure option devient un défi important. Les principaux critères devant être retenus sont :

• L’efficacité du filtrage, pour réduire l’exposition de l’application aux prompts malveillants tout en limitant les faux positifs.
• La latence, pour préserver l’expérience utilisateur.
• La capacité de personnalisation, pour adapter les filtres au contexte et aux risques spécifiques de l’application.
• Le coût opérationnel de la solution, pour s’assurer de la viabilité du passage à l’échelle dans le temps.

Résultats principaux et profils observés

Pour avoir une idée des performances des guardrails sur le marché, nous avons testé plusieurs solutions selon ces critères et plusieurs types de profils se sont démarqués :

• Certaines solutions offrent un déploiement rapide et une protection de base efficace avec une configuration minimale, ce qui les rend adaptées aux organisations qui cherchent à obtenir une première réduction rapide des risques. Ces solutions fonctionnent généralement bien dès leur installation, mais offrent des possibilités de personnalisation limitées.
• D’autres solutions mettent l’accent sur la flexibilité et le contrôle précis. Bien que ces frameworks permettent des stratégies de filtrage avancées, ils affichent souvent des performances par défaut médiocres et nécessitent un effort de configuration important pour atteindre de bons niveaux de protection.

Par conséquent, le choix d’une solution de guardrails dépend moins des scores de détection bruts que du niveau de personnalisation attendu, de la maturité opérationnelle et de l’effort de configuration acceptable.

Focus sur les guardrails proprosés par les Cloud Providers

Étant donné que la plupart des applications intégrant des LLMs sont déployées dans des environnements cloud, les guardrails natifs proposés par les fournisseurs cloud constituent une première couche de protection pragmatique. Ces solutions sont faciles à implémenter, rentables et s’intègrent facilement aux workflows cloud existants.

À l’aide d’outils automatiques spécialisés dans les tests de sécurité pour les applications d’IA (« AI Red Teaming »), nous avons observé que les filtres natifs proposés par les fournisseurs cloud bloquaient systématiquement la plupart des tentatives de prompt injection et de jailbreak. Et peu de différences de performances ont été observées, ce qui confirme leur pertinence en tant que mécanismes de protection de base pour les charges de travail de production.

Configuration de la sensibilité de filtrage

La configuration de plusieurs solutions de fournisseurs de services cloud permettent de définir un niveau de sensibilité pour les guardrails configurés afin d’adapter la détection au niveau requis pour le cas d’usage considéré.

Nos tests montrent que même les configurations les plus permissives offrent une protection significative, tandis que les paramètres de sensibilité plus élevés, doivent être réservés aux cas d’usage critiques où la sécurité prime sur l’expérience utilisateur, puisque l’augmentation de la sensibilité de détection entraîne également davantage de faux positifs, où les messages légitimes des utilisateurs peuvent être bloqués. Le besoin d’arbitrage lié à cette première capacité de personnalisation des filtres illustre le besoin d’adapter chaque filtre au contexte de l’application.

Personnalisation

Au-delà du réglage de la sensibilité, une personnalisation fine est essentielle pour garantir l’efficacité des protections. Chaque application a des exigences spécifiques en matière de filtrage, qui dépendent du contexte de l’organisation, des contraintes réglementaires et de l’exposition aux menaces.

L’adaptation des filtres est requise à plusieurs niveaux:

• Le contexte de l’organisation: afin de bloquer des sujets spécifiques à l’application, tels que des entreprises concurrentes, des projets confidentiels ou des informations sensibles.
• La réduction des risques: pour permettre aux filtres de bloquer les attaques à fort impact telles que les prompt injections
• Les spécificités techniques de l’application, puisque chaque source de données et chaque outil demande une stratégie de filtrage différente. En effet, les entrées utilisateurs, extraits de documents récupérés (RAG) et résultats d’outils ne doivent pas être filtrés de la même manière.

L’application d’un filtrage uniforme à toutes les sources limite considérablement l’efficacité et peut créer des angles morts. Les garde-fous doivent donc être conçus comme faisant partie intégrante de l’architecture de l’application, et non comme un filtre monolithique unique.

Principaux constats

Notre étude met en évidence plusieurs points clés :

• Il n’existe pas de solution de guardrails unique adaptée à tous les cas d’usages, il faut trouver un compromis entre facilité de déploiement, performances et personnalisation.
• Les guardrails natifs du cloud constituent une base efficace et peu contraignante pour la plupart des applications hébergées dans le cloud.
• Les cas d’usages avancés nécessitent d’adapter la logique de filtrage au contexte de l’application et aux flux de données.

Les garde-fous doivent être sélectionnés en fonction de l’exposition au risque, de la maturité opérationnelle et de la maintenabilité à long terme, plutôt que sur la base des seuls scores de détection bruts.

Les guardrails sont devenus un élément indispensable des applications intégrant des LLM, et il existe désormais un large éventail de solutions. Pour choisir la plus adaptée à votre contexte, il faut identifier la solution qui correspond le mieux aux risques, aux contraintes et à l’architecture applicative spécifiques de votre application.

• Si votre application est déjà déployée dans un environnement cloud, l’utilisation des guardrails fournis par le fournisseur de cloud est une bonne solution.
• Si vous souhaitez plus de contrôle sur la solution de filtrage, le déploiement d’une des solutions open source peut être l’option la plus appropriée.
• Si vous voulez ce qu’il y a de mieux et que vous en avez les moyens, vous pouvez lancer un RFP ou RFI afin de comparer différentes solutions et sélectionner celle qui correspond le mieux à vos besoins.

Enfin, les garde-fous ne suffisent pas à eux seuls à protéger vos applications. La sécurité des applications LLM repose également sur des outils correctement configurés, des politiques IAM strictes et une architecture de sécurité robuste afin d’éviter des scénarios d’exploitation plus graves.

Cet article Comment choisir votre solution de Guardrails IA? est apparu en premier sur RiskInsight.

Aujourd’hui, les impacts sont limités car la latitude donnée au système d’IA est encore faible. Demain, avec l’essor de l’IA agentique, l’accélération de l’adoption de l’IA générative et la multiplication des usages, les impacts augmenteront. A l’instar des failles exploitées massivement par le rançongiciel WannaCry en 2017, des attaques cyber majeures auront certainement lieu sur les systèmes d’IA et pourraient se traduire par des blessés ou des faillites financières.

Ces risques, ils s’anticipent. Un des moyens les plus pragmatiques d’y arriver, c’est d’endosser le rôle d’une personne malveillante en tentant de détourner un système d’IA pour étudier sa robustesse. Cela permet de mettre en lumière les failles du système et la façon de les corriger. Spécifiquement dans le cas de l’IA générative, cette discipline est appelée RedTeaming IA. Dans cet article, nous vous proposons d’en découvrir les contours. Nous insisterons particulièrement sur nos retours terrains concernant les principales vulnérabilités rencontrées.

Afin d’être au plus proche de ce qui se fait sur le marché, l’article se concentre exclusivement sur le RedTeaming de systèmes d’IA générative.

La GenAI, comment ça marche ?

La GenAI s’appuie sur des composants qui sont souvent distribués entre des environnements cloud et on-premise. Généralement, plus un système d’IA générative offre de fonctionnalités (rechercher des informations, lancer des actions, exécuter du code, etc.), plus les composants sont nombreux. D’un point de vue cybersécurité, cela expose à de multiples risques :

 Schéma d’un système d’IA générative et des problématiques soulevées par composant

En règle générale, un attaquant n’a uniquement accès qu’à une interface Web sur laquelle il peut interagir (cliquer, écrire du texte sur des champs, …). A partir de là, il peut :

• Mener des attaques de cybersécurité classiques (insertion de script malveillant – XSS, etc.) en s’appuyant sur les failles des composants du système d’IA ;
• Mener des attaques d’un genre nouveau, en écrivant en langage naturel pour détourner les fonctionnalités offertes par le système d’IA générative derrière l’interface Web : exfiltration de données, réalisation d’actions malveillantes à l’aide des privilèges du système d’IA générative, etc.

Techniquement, chacun des composants est protégé par la mise en place de mesures de sécurité définies par les processus d’Intégration de la Sécurité dans les Projets. Il est ensuite intéressant, d’évaluer en pratique le niveau de sécurité effectif lors d’un audit Redteam IA.

Le RedTeaming IA, l’art de trouver les failles des systèmes d’IA

Les audits de RedTeaming IA sont similaires aux audits de sécurité classiques. Néanmoins, afin de répondre nouveaux enjeux de la GenAI, ils s’appuient sur une méthodologie, des référentiels et un outillage spécifique. En effet, lors d’un audit RedTeam IA, il s’agit de chercher à contourner le système d’IA générative en réalisant des attaques sur ses composants ou en écrivant des instructions malveillantes en langage naturel. Cette deuxième typologie d’attaque s’appelle le prompt injection, l’art de formuler des requêtes malveillantes à un système d’IA pour en détourner ses fonctionnalités.

Lors d’un audit RedTeam IA, lors des tests d’attaques en langage naturel (propre à l’IA), deux typologies de tests sont réalisées en parallèle :

• Des tests manuels. Ils permettent une phase de reconnaissance en s’appuyant sur des bibliothèques de questions malveillantes consolidées en amont.
• Des tests outillés. Il s’agit généralement d’une IA générative qui attaque le système d’IA générative cible en générant une série de prompts malveillants et en analysant automatiquement la cohérence de la réponse du chatbot. Ils permettent de tester la robustesse du système d’IA sur un grand nombre de scénarios.

Ces tests permettent généralement d’identifier plusieurs vulnérabilités et de mettre en lumière des risques de cybersécurité souvent sous-estimés.

Quelles sont les vulnérabilités les plus rencontrées chez nos clients ?

 Nous avons couvert trois grandes catégories de déploiement chez nos clients :

• Chatbot simple : ces solutions servent principalement à la redirection et au triage des demandes utilisateurs ;
• Chatbot en RAG (Retrieval-Augmented Generation): ces systèmes plus sophistiqués consultent des bases documentaires internes pour enrichir leurs réponses ;
• Chatbot agentique : ces solutions avancées peuvent interagir avec d’autres systèmes et exécuter des actions.

La consolidation des vulnérabilités identifiées lors de nos interventions ainsi que leur criticité relative nous permettent de définir le classement suivant :

Détournement du modèle et génération de contenu illégitime 

Il s’agit du contournement des garde-fous techniques mis en place dans le développement du chatbot afin de générer du contenu offensant, malveillant, ou inadapté. C’est ainsi la crédibilité et la réputation de l’entreprise qui risquent d’être impactées puisqu’elle est responsable de la production de contenu réalisée par son chatbot.

À noter que le contournement des mécanismes de sécurité du modèle cible peut aller jusqu’à un débridage complet. On parle alors de jailbreak du modèle, ce qui le fait basculer dans un mode sans restriction. Ce dernier peut alors produire du contenu hors du cadre souhaité par l’entreprise.

Accès au preprompt

On entend par preprompt l’ensemble des instructions qui alimentent le modèle et le façonne pour l‘utilisation souhaitée. Tous les modèles ont pour consigne de ne pas divulguer ce preprompt sous quelle que forme que ce soit.

Un attaquant parvenant à accéder à ce preprompt voit son attaque facilitée car cela lui permet de cartographier les capacités du modèle du chatbot. Cette cartographie est notamment utile pour les systèmes complexes interfacés avec des APIs ou autres systèmes externes. De plus, l’accès à ce preprompt par un attaquant lui permet de visualiser la manière dont les filtres et limitations du chatbot ont été mis en place, ce qui lui permet de les contourner plus aisément.

Intégration web et intégration des tiers

Les solutions GenAI sont souvent présentées aux utilisateurs au travers d’une interface web. Les activités de RedTeaming AI mettent ainsi régulièrement en lumière des problématiques classiques des applications web, notamment le cloisonnement des sessions utilisateurs ou des attaques visant à les piéger.

Dans le cas de l’agentique, ces vulnérabilités peuvent également affecter des composants de tiers interconnectés au système GenAI.

Fuites de données sensibles

Si les données alimentant la base de connaissance interne d’un chatbot RAG sont insuffisamment consolidées (sélection, gestion, anonymisation, …), les modèles sont susceptibles de révéler involontairement des informations sensibles ou confidentielles.

Cette problématique est connexe aux aspects de gestion des droits, de classification de la donnée, et de durcissement des pipelines de préparation et de transit des données (MLOps).

Injection stockée (stored injection)

En cas d’injection stockée, l’attaquant est en mesure d’alimenter la base de connaissance d’un modèle en y incluant des instructions malveillantes (via un document piégé). Celle-ci servant aux réponses du chatbot, tout utilisateur interagissant avec le modèle et sollicitant ledit document verra sa session compromise (fuite des données d’historique de conversation des utilisateurs, redirections malveillantes, participation à une attaque d’ingénierie sociale, …).

Les documents piégés pourront être particulièrement compliqués à identifier, notamment dans le cas de bases de connaissances larges ou peu maitrisées. Cette attaque est ainsi persistante et furtive.

Mention honorable : parasitisme et explosion des coûts

On parle de parasitisme lorsqu’un utilisateur est en mesure de débrider le chatbot afin d’utiliser pleinement les capacités du modèle, et ce gratuitement. Couplé à une absence de restriction volumétrique, un utilisateur peut réaliser un nombre prohibitif de requêtes, sans lien avec le cas d’usage initial et néanmoins facturés.

De manière générale, certaines des vulnérabilités mentionnées concernent des risques relativement mineurs, dont l’impact métier pour les systèmes d’information (SI) est limité. Néanmoins, avec les avancées des technologies IA, ces vulnérabilités prennent une autre dimension, notamment dans les cas suivants :

• Les solutions agentiques ayant accès à des systèmes sensibles
• Les applications RAG impliquant des données confidentielles
• Les systèmes pour lesquels les utilisateurs ont la main sur les documents de la base de connaissance, ouvrant la porte aux injections stockées

Les systèmes GenAI testés sont débridables en très large majorité, bien que l’exercice se complexifie avec le temps. Cette incapacité persistante des modèles à mettre en place des restrictions efficaces incite l’écosystème IA à se tourner vers des briques de sécurité externes.

Quelles nouvelles surfaces d’attaque ?

L’intégration croissante de l’IA dans des secteurs d’activité sensibles (santé, finance, défense, …) augmente les surfaces d’attaque des systèmes critiques, ce qui renforce le besoin de filtrage et d’anonymisation des données sensibles. Là où les applications IA étaient jusqu’à présent très cloisonnées, l’IA agentique met fin à ce cloisonnement puisqu’elle déploie une capacité d’interconnexion, ce qui ouvre la porte à de possibles propagations de menaces au sein des SI.

La baisse du niveau technique requis pour créer un système d’IA, notamment au travers de l’usage des plateformes SaaS et services Low/no code, en facilite l’usage tant pour des utilisateurs légitimes que pour des attaquants.

Enfin, la généralisation des « copilotes » directement sur les postes des collaborateurs se traduit par un usage croissant de composants de plus en plus autonomes qui agissent à la place de et avec les privilèges d’un humain, accélérant l’apparition de périmètres IA non-maitrisés ou Shadow IT IA.

Vers des systèmes de plus en plus difficiles à maitriser

Bien qu’imitant l’intelligence humaine en apparence, les modèles de GenAI (LLM, pour Large Langage Model) ont pour fonction unique d’imiter le langage et agissent finalement bien souvent comme des systèmes d’auto-complétion textuelle hautement performants. Ces systèmes ne sont nativement pas entrainés pour raisonner et leur utilisation se heurte à un fonctionnement en « boite noire ». Il est en effet complexe d’expliquer de manière fiable leur raisonnement, ce qui se traduit régulièrement par des hallucinations dans leurs productions, ou des contresens logiques. En pratique, il est également impossible de prouver l’absence de « porte dérobées » (backdoor) dans ces modèles, limitant encore davantage notre confiance dans ces systèmes.

L’émergence de l’IA agentique complexifie la situation. En interconnectant des systèmes au fonctionnement opaque, elle rend l’ensemble du processus de raisonnement généralement invérifiable et inexplicable. Les cas de modèle entrainant, auditant ou attaquant d’autres modèles se généralisent, ce qui induit une problématique de confiance majeure lorsqu’ils sont intégrés aux systèmes d’information des entreprises.

Quelles perspectives pour la suite ?

Les audits de RedTeaming IA menés sur des systèmes d’IA générative révèlent une réalité contrastée. D’un côté, l’innovation est fulgurante, portée par des cas d’usage de plus en plus puissants et intégrés. De l’autre, les vulnérabilités identifiées démontrent que ces systèmes, souvent perçus comme intelligents, restent largement manipulables, instables et peu explicables.

Ce constat s’inscrit dans un contexte plus large de démocratisation des outils IA couplée à leur autonomie croissante. L’IA agentique, en particulier, fait apparaître des chaînes d’action difficilement traçables, agissant avec des privilèges humains. Dans un tel paysage, le risque n’est plus uniquement technique : il devient aussi organisationnel et stratégique, impliquant une gouvernance et une supervision continue de ses usages.

Face à ces défis, le RedTeaming IA s’impose comme un levier essentiel pour anticiper les déviances possibles, en adoptant le point de vue de l’attaquant pour mieux prévenir les dérives. Il s’agit de tester les limites d’un système pour concevoir des mécanismes de protection robustes, pérennes, et alignés avec les nouveaux usages. C’est à ce prix que l’IA générative pourra continuer à évoluer dans un cadre de confiance, au service des utilisateurs comme des organisations.

Cet article Red Teaming IA : État des lieux des risques IA en 2025   est apparu en premier sur RiskInsight.

Nous détaillerons dans cet article les impacts de l’IA sur la conformité des traitements aux grands principes réglementaires mais aussi sur la sécurité des traitements sur laquelle pèsent de nouveaux risques. Nous partagerons ensuite notre vision d’un outil de PIA adapté afin de répondre à des questionnements et enjeux remaniés par l’arrivée de l’IA dans les traitements de données personnelles.

L’impact de l’IA sur les principes de protection des données

Bien que l’IA se développe rapidement depuis l’arrivée de l’IA générative, elle n’est pas nouvelle dans les entreprises. Les nouveautés résident dans les gains d’efficacité des solutions, dont l’offre est plus étoffée que jamais, et surtout dans la multiplication des cas d’usages qui viennent transformer nos activités et notre rapport au travail.

Ces gains ne sont pas sans risques sur les libertés fondamentales et plus particulièrement sur le droit à la vie privée. En effet, les systèmes d’IA nécessitent des quantités massives de données pour fonctionner efficacement, et ces bases de données contiennent souvent des informations personnelles. Ces larges volumes de données font par la suite l’objet de multiples calculs, analyses et transformations complexes : les données ingérées par le modèle d’IA deviennent à partir de ce moment indissociables de la solution d’IA^[1]. Outre cette spécificité, nous pouvons mentionner la complexité de ces solutions qui diminue la transparence et la traçabilité des actions opérées par celles-ci. Ainsi, de ces différents aspects caractéristiques de l’IA, en résulte une multitude d’impacts sur la capacité des entreprises à se conformer aux exigences réglementaires en matière de protection des données personnelles.

Figure 1 : exemples d’impacts sur les principes de protection des données.

En complément de la Figure 1, trois principes peuvent être détaillés pour illustrer les impacts de l’IA sur la protection des données ainsi que les nouvelles difficultés auxquelles les professionnels de ce domaine seront confrontés :

1. Transparence: Assurer la transparence devient bien plus complexe en raison de l’opacité et de la complexité des modèles d’IA. Les algorithmes de machine learning et de deep learning peuvent être des « boîtes noires », où il est difficile de comprendre comment les décisions sont prises. Les professionnels doivent relever le défi de rendre ces processus compréhensibles et explicables, tout en garantissant que les informations fournies aux utilisateurs et aux régulateurs soient claires et détaillées.
2. Principe d’exactitude: Appliquer le principe d’exactitude est particulièrement difficile avec l’IA en raison des risques de biais algorithmiques. Les modèles d’IA peuvent reproduire ou même amplifier les biais présents dans les données d’entraînement, ce qui conduit à des décisions inexactes ou injustes. Les professionnels doivent donc non seulement s’assurer que les données utilisées sont précises et à jour, mais aussi mettre en place des mécanismes pour détecter et corriger les biais algorithmiques.
3. Durée de conservation: La gestion de la durée de conservation des données devient plus complexe avec l’IA. L’entraînement des modèles d’IA avec des données crée une dépendance entre l’algorithme et les données utilisées, rendant difficile, voire impossible, de dissocier l’IA de ces données. Aujourd’hui, il est pratiquement impossible de faire « oublier » à une IA des informations spécifiques, ce qui complique la conformité avec les principes de minimisation des données et de durée de conservation.

Les nouveaux risques soulevés par l’IA

Outre les impacts sur les principes de conformité abordés à l’instant, l’IA produit également des effets significatifs sur la sécurité des traitements, modifiant ainsi les approches en matière de protection des données et de gestion des risques.

L’utilisation de l’intelligence artificielle fait alors ressortir 3 types de risques sur la sécurité des traitements :

• Risques traditionnels: Comme toute technologie, l’utilisation de l’intelligence artificielle est sujette à des risques de sécurité traditionnels. Ces risques incluent, par exemple, des failles au niveau des infrastructures, des processus, des personnes et des équipements. Qu’il s’agisse de systèmes traditionnels ou de solutions basées sur l’IA, les vulnérabilités en matière de sécurité des données et de gestion des accès persistent. Les erreurs humaines, les pannes matérielles, les mauvaises configurations de systèmes ou les processus insuffisamment sécurisés demeurent des préoccupations constantes, indépendamment de l’innovation technologique.
• Risques amplifiés: L’utilisation de l’IA peut également exacerber des risques déjà existants. Par exemple, l’utilisation d’un grand modèle de langage, comme Copilot, pour assister dans les tâches quotidiennes peut poser des problèmes. En se connectant à toutes vos applications, le modèle d’IA centralise toutes les données en un seul point d’accès, ce qui augmente considérablement le risque de fuite de données. De la même manière, une gestion des identités et des droits des utilisateurs imparfaite aboutira à des risques accrus d’actes malveillants en présence d’une solution d’IA capable d’accéder et d’analyser avec une efficacité singulière à des documents illégitimes pour l’utilisateur.
• Risques émergents: De la même manière que pour les risques liés à la durée de conservation, il devient de plus en plus difficile de dissocier l’IA de ces données d’entrainements. Cela peut parfois rendre l’exercice de certains droits comme le droit à l’oubli bien plus difficile, entrainant un risque de non-conformité.

Un contexte réglementaire en mutation

Avec la prolifération mondiale des outils basés sur l’intelligence artificielle, divers acteurs ont intensifié leurs efforts pour se positionner dans ce domaine. Pour répondre aux préoccupations, plusieurs initiatives ont vu le jour : le Partnership on AI réunit des géants technologiques comme Amazon, Google, et Microsoft pour promouvoir une recherche ouverte et inclusive sur l’IA, tandis que l’ONU organise l’AI for Good Global Summit pour explorer l’IA au service des objectifs de développement durable. Ces initiatives ne sont que des exemples parmi de nombreuses autres initiatives visant à encadrer et guider l’utilisation de l’IA, assurant ainsi une approche responsable et bénéfique de cette technologie.

Figure 2 : exemples d’initiatives liées au développement de l’IA.

Le changement récent et le plus impactant est l’adoption de l’AI Act (ou RIA, règlement européen sur l’IA), qui introduit une nouvelle exigence dans l’identification des traitements de données à caractère personnel devant bénéficier d’un soin particulier : en plus des critères classiques des lignes directrices du G29, l’utilisation d’une IA à haut risque nécessitera systématiquement la réalisation d’une PIA. Pour rappel, le PIA est une évaluation qui vise à identifier, évaluer et atténuer les risques que certains traitements de données peuvent poser à la vie privée des individus, en particulier lorsqu’ils impliquent des données sensibles ou des processus complexes​​. Ainsi, l’utilisation d’un système d’IA requerra souvenant la réalisation d’un PIA.

Cette nouvelle législation complète l’arsenal réglementaire européen pour encadrer les acteurs et solutions technologiques, elle vient en complément du RGPD, du Data Act, du DSA ou encore du DMA. Bien que l’objectif principal de l’AI Act soit de promouvoir une utilisation éthique et digne de confiance de l’IA, elle partage de nombreuses similitudes avec le RGPD et renforce les exigences existantes. Nous pouvons par exemple citer les exigences renforcées en matière de transparence ou bien la mise en place obligatoire d’une surveillance humaine pour les systèmes d’IA, soutenant le droit à l’intervention humaine du RGPD.

Une adaptation nécessaire des outils et méthodes

Dans ce contexte évolutif où l’IA et les réglementations continuent de se développer, la veille réglementaire et l’adaptation des pratiques par les différents acteurs sont essentielles. Cette étape est cruciale pour comprendre et s’adapter aux nouveaux risques liés à l’utilisation de l’IA, en intégrant ces évolutions efficacement au sein de vos projets d’IA.        

Afin d’adresser les nouveaux risques induits par l’utilisation de l’IA, il devient nécessaire d’adapter nos outils, méthodes et pratiques afin de répondre efficacement à ces défis. De nombreux changements doivent être pris en compte, tels que :

• l’amélioration des processus d’exercice des droits ;
• l’intégration d’une méthodologie Privacy By Design adaptée :
• la mise à niveau des mentions d’information fournis aux utilisateurs ;
• ou encore l’évolution des méthodologies de PIA.

Nous illustrerons dans la suite de cet article ce dernier besoin en matière de PIA à l’aide du nouvel outil interne PIA² conçu par Wavestone et né de la jonction de ses expertises Privacy et en intelligence artificielle, et qui a été alimenté par de nombreux retours terrain. Son objectif est de garantir une gestion optimale des risques pour les droits et libertés des personnes liés à l’utilisation de l’intelligence artificielle en offrant un outil méthodologique capable d’identifier finement les risques sur ces-derniers.

Un nouvel outil de PIA au service d’une meilleure maîtrise des risques Privacy issus de l’IA

La réalisation d’un PIA sur des projets d’IA exige une expertise plus pointue que celle requise pour un projet classique, avec des questionnements multiples et complexes liés aux spécificités des systèmes d’IA. Outre ces points de contrôles et questionnements qui s’ajoutent à l’outil, c’est toute la méthodologie de déclinaison du PIA qui se trouve adaptée au sein du PIA² de Wavestone.

A titre d’illustration, les ateliers avec les parties prenantes s’élargissent à de nouveaux acteurs tels que les data scientists, des experts en IA, des responsables éthiques ou les fournisseurs de solutions d’IA. Mécaniquement, la complexité des traitements de données reposant sur des solutions d’IA requière donc davantage d’ateliers et un temps de mise en œuvre plus important pour cerner finement et pragmatiquement les enjeux de protection des données de vos traitements.

Figure 3 : représentation des différentes étapes du PIA².

Le PIA² renforce et complète la méthodologie de PIA traditionnelle. L’outil conçu par Wavestone est ainsi constitué de 3 étapes centrales :

1. Analyse préliminaire du traitement

Dans la mesure où l’IA revêt des risques pouvant être significatifs pour les personnes et dans un contexte où l’AI Act vient exiger la réalisation d’un PIA pour les solutions d’IA à haut risque traitant de données à caractère personnel, le premier questionnement d’un DPO est d’identifier son besoin ou non de réaliser une telle analyse. L’outil PIA² de Wavestone s’ouvre donc sur une analyse des critères traditionnels du G29 venant requérir la mise en œuvre d’un PIA et est ensuite complétée de questionnements associés à l’identification du niveau de risque de l’IA. L’analyse se complète classiquement d’une étude générale du traitement. Cette étude complétée de points de connaissance précis sur la solution d’IA, de son fonctionnement et de son cas d’usage, servant de fondation à l’ensemble du projet (notons que l’AI Act vient également exiger que de telles informations soient présentes dans le PIA portant sur des IA à haut risque). A l’issue de cette étude, le DPO dispose d’une vue d’ensemble des données personnelles traitées, de la manière dont les données personnelles circulent au sein du système et des différentes parties prenantes.

2. Evaluation de la protection des données

L’évaluation de conformité permet ensuite d’examiner la conformité de l’organisation vis-à-vis des réglementations applicables en matière de protection des données. L’objectif est d’examiner en profondeur toutes les pratiques mises en place par rapport aux exigences légales, tout en identifiant les lacunes à combler. Cette évaluation se concentre sur les mesures techniques et organisationnelles adoptées pour se conformer aux réglementations et sécuriser les données personnelles au sein d’un système d’IA. Cette partie de l’outil a été spécialement développée pour répondre aux nouveaux enjeux et défis de l’IA en termes de conformité et de sécurisation, prenant en compte les nouvelles contraintes et normes imposées aux systèmes d’IA. Cette évaluation comporte à la fois des points de contrôle classiques d’un PIA et issues du RGPD et se complète des questionnements spécifiques associés à l’IA qui ont profité des retours terrains observés par nos experts en IA.

3. Remédiation des risques

Après avoir recensé l’état de la conformité du projet et identifié les lacunes présentes, il est possible d’évaluer les impacts potentiels sur les droits et libertés des personnes concernées par le traitement. Une étude approfondie de l’impact de l’IA sur les différents éléments de conformité et de sécurité a été effectuée pour nourrir cet outil de PIA². Cette approche opérée par Wavestone, si elle est optionnelle, nous a permis de gagner en facilité de réalisation du PIA en permettant une automatisation de notre outil PIA² qui propose automatiquement des risques spécifiques liés à l’utilisation de l’IA au sein du traitement, en fonction des réponses remplies en parties 1 et 2. Les risques étant identifiés, il convient ensuite de réaliser leur traditionnelle cotation en évaluant leur vraisemblance et leurs impacts.

Toujours dans cette optique d’automatisation, l’outil PIA de Wavestone identifie et propose également automatiquement des mesures correctives adaptées aux risques détectés. Quelques exemples : des solutions comme le Federated Learning, le chiffrement homomorphique (qui permet de traiter des données chiffrées sans les déchiffrer) et la mise en place de filtres sur les entrées et sorties peuvent être suggérées pour atténuer les risques identifiés. Ces mesures permettent de renforcer la sécurité et la conformité des systèmes d’IA, assurant ainsi une meilleure protection des droits et libertés des personnes concernées.

Une fois ces trois grandes étapes franchies, il sera nécessaire de faire valider les résultats et de mettre en œuvre des actions concrètes pour garantir la conformité et les risques liés à l’IA.

Ainsi, lorsqu’un traitement implique de l’IA, la réduction des risques devient encore plus complexe. Une veille constante sur le sujet et l’accompagnement d’experts dans le domaine deviennent indispensables. À l’heure actuelle, de nombreuses inconnues subsistent, comme en témoigne la posture de certains organismes encore en phase d’étude ou des positions des régulateurs qui restent à préciser.

Pour mieux appréhender et gérer ces défis, il devient alors essentiel d’adopter une approche collaborative entre différentes expertises. Chez Wavestone, nos expertises en intelligence artificielle et en protection des données ont dû coopérer étroitement pour cerner et répondre à ces enjeux majeurs. Nos travaux d’analyse des solutions d’IA, des nouvelles réglementations afférentes et des risques en matière de protection des données ont nettement mis en lumière l’importance pour les DPO de bénéficier d’une expertise toujours plus pluridisciplinaire.

Remerciements

 Nous remercions Gaëtan FERNANDES pour son travail dans la rédaction de cet article.

Notes

[1] : Bien que des expérimentations ambitionnent d’offrir une forme de réversibilité et la possibilité de retirer les données de l’IA, comme le désapprentissage machine, ces techniques restent encore assez peu fiables aujourd’hui.

Cet article IA et protection des données personnelles : de nouveaux enjeux demandant une adaptation des outils et des procédures est apparu en premier sur RiskInsight.

MITRE, connu pour son cadre ATT&CK, une taxonomie largement adoptée par les centres d’opérations de sécurité (SOC) et les équipes de renseignement sur les menaces, a développé un cadre spécifique appelé MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems). Ce cadre constitue une base de connaissances sur les tactiques et techniques employées par les adversaires ciblant les systèmes d’intelligence artificielle. Il permet de classifier les attaques et menaces tout en offrant un outil structuré pour évaluer ces dernières de manière cohérente.

Cependant, le paysage des menaces liées à l’IA est complexe, et il n’est pas toujours facile de déterminer les actions que les équipes doivent entreprendre pour protéger un système d’IA. Le cadre ATLAS de MITRE identifie 56 techniques susceptibles d’être exploitées par des adversaires, rendant l’atténuation des risques d’autant plus difficile en raison de la nécessité de déployer des contrôles tout au long de la chaîne d’exécution. Les équipes devront mettre en place des contrôles ou des mesures d’atténuation couvrant plusieurs phases, allant de la reconnaissance à l’exfiltration, en passant par l’évaluation de l’impact.

Fig. 1. Chaîne d’exécution de MITRE ATLAS.

Cette complexité a amené bon nombre de nos clients à se poser des questions telles que : « Je suis responsable de la gestion des identités et des accès. Que dois-je savoir et, surtout, que dois-je faire au-delà de ce que je fais actuellement ?

Pour répondre à ces préoccupations, nous avons analysé en détail le cadre MITRE ATLAS afin d’identifier les types de contrôles que les différentes équipes doivent envisager pour atténuer les effets de chaque technique répertoriée. Cette analyse nous permet d’évaluer si les contrôles en place sont suffisants ou si de nouveaux contrôles doivent être développés et mis en œuvre pour sécuriser les systèmes et applications d’IA. Nous estimons que les contrôles d’atténuation des menaces pesant sur les systèmes d’IA se répartissent comme suit : 70 % reposent sur des contrôles existants, qui peuvent être adaptés à l’IA, tandis que 30 % nécessitent le développement de nouveaux contrôles, spécifiquement conçus pour répondre aux menaces uniques liées à l’IA. 

Pour simplifier l’articulation des besoins en matière de contrôle, nous avons défini trois catégories : 

• Domaines verts : les contrôles existants suffisent pour couvrir certaines menaces posées par l’IA. Bien qu’il puisse y avoir des ajustements mineurs, le principe de base reste inchangé, sans besoin d’évolution majeure.
• Domaines jaunes : les contrôles en place doivent être adaptés ou ajustés pour couvrir efficacement les menaces spécifiques à l’IA.
• Domaines rouges : de nouveaux contrôles doivent être entièrement conçus et mis en œuvre pour répondre aux menaces inédites introduites par l’IA.

Ce cadre permet aux organisations de prioriser leurs efforts et de s’assurer que leurs systèmes d’IA sont protégés de manière proactive et complète. 

Fig. 2. Analyse RAG des contrôles d’atténuation pour les techniques MITRE ATLAS.

Domaines verts

Les domaines verts correspondent aux risques déjà couverts par les contrôles existants. Trois domaines principaux appartiennent à cette catégorie : la gestion des identités et des accès (IAM), la sécurité des réseaux et la sécurité physique.

Dans le cadre de la gestion des identités et des accès (IAM), le principe fondamental reste de garantir que seules les personnes autorisées ont accès aux ressources appropriées. Toutefois, lorsqu’il s’agit d’une application d’IA, des nuances supplémentaires doivent être prises en compte. Il est essentiel de gérer non seulement l’accès à l’application elle-même, en précisant qui peut l’utiliser, accéder au code source et à l’environnement, mais aussi l’accès aux données utilisées pour entraîner le modèle et aux données d’entrée nécessaires à la génération des résultats.

En matière de sécurité des réseaux, les mécanismes de détection et de réponse continuent de jouer un rôle clé, en signalant toute activité inhabituelle, telle que des requêtes provenant d’emplacements suspects ou l’exfiltration de grandes quantités de données. Bien que les principes restent les mêmes, les types d’attaques peuvent différer dans le contexte de l’IA. Par exemple, un volume important de requêtes dans une application traditionnelle pourrait indiquer une attaque par force brute, alors que pour une application d’IA, cela pourrait refléter une tentative de « récolte de coûts ». Cette dernière consiste à envoyer des requêtes inutiles pour augmenter les coûts d’exécution de l’application, une menace qui peut être atténuée en limitant le nombre de requêtes autorisées. Bien que la détection au niveau de l’application et l’analyse forensic des systèmes d’IA soient plus complexes que pour des applications traditionnelles, les processus de détection au niveau réseau restent similaires. Par ailleurs, les API intégrées au modèle doivent être sécurisées afin de garantir la sécurité des interactions réseau, en particulier lorsqu’elles concernent des applications accessibles publiquement.

Les contrôles de sécurité physique restent les mêmes ; il s’agit de sécuriser les personnes qui ont un accès physique à l’infrastructure clé.

Domaines jaunes

Les contrôles et les mesures d’atténuation qui relèvent des domaines jaunes suivront les mêmes principes que pour les logiciels traditionnels, mais devront être adaptés pour assurer la sécurité contre la menace posée par l’IA. Les équipes qui entrent dans cette catégorie sont l’éducation et la sensibilisation, la résilience, le centre d’opérations de sécurité et le renseignement sur les menaces.

Pour les équipes responsables de la sensibilisation et de l’éducation, les techniques utilisées resteront les mêmes, comme les campagnes de sensibilisation ou les tests d’hameçonnage. Toutefois, il sera essentiel de mettre à jour ces initiatives pour refléter les nouvelles menaces. Par exemple, intégrer des « deepfakes » dans les simulations de tests d’hameçonnage ou inclure des formations spécifiques pour les équipes de développement sur les menaces émergentes liées à l’IA. Ces ajustements garantiront que les équipes sont préparées à détecter et à gérer les risques associés à l’utilisation de l’IA.

Pour les équipes chargées de la résilience, bien que les changements soient limités, des ajustements devront être apportés aux processus existants. Par exemple, si un système critique repose sur une application utilisant l’IA, les scénarios de test devront inclure des menaces spécifiques à l’IA. De plus, les conséquences potentielles d’une attaque contre un système basé sur l’IA, comme les résultats inattendus ou inappropriés d’un chatbot interactif avec des clients, devront être intégrées à la documentation relative à la gestion des crises et incidents. Les lignes directrices en matière de communication devront également être mises à jour pour anticiper et gérer ces nouveaux risques de manière proactive.

Dans le cas des centres d’opérations de sécurité (SOC) et des équipes de renseignement sur les menaces, les principes des contrôles restent centrés sur la collecte de renseignements sur les vulnérabilités et la surveillance des systèmes pour détecter des comportements ou des trafics inhabituels. Cependant, des ajouts spécifiques liés à l’IA seront nécessaires, comme la surveillance des informations concernant les modèles déployés en ligne ou d’autres données exploitables par les attaquants pour accéder au modèle. Cette surveillance est particulièrement critique lorsque le modèle repose sur des solutions open source, telles que ChatGPT, car cela augmente l’exposition potentielle aux menaces.

Domaines rouges

Les domaines rouges regroupent les contrôles et techniques entièrement nouveaux qui doivent être introduits pour répondre aux nouvelles menaces liées à l’IA. Ces contrôles relèvent principalement de la compétence de l’équipe chargée de la sécurité des données et des applications. Il est important de préciser qu’il ne s’agit pas des équipes dédiées à la protection des données, qui se concentrent principalement sur des problématiques telles que le GDPR. 

L’équipe chargée de la sécurité des applications dispose de nombreux contrôles dans ce domaine, ce qui souligne l’importance de concevoir les applications basées sur l’IA en appliquant les principes de la sécurité dès la conception. Cependant, certains contrôles spécifiques à l’IA ne relèvent pas des équipes existantes. L’équipe responsable de ces contrôles doit être définie par chaque organisation, mais dans les entreprises les plus avancées, ces contrôles sont souvent pris en charge par un centre d’excellence en matière d’IA.

Les équipes chargées de la sécurité des données jouent un rôle crucial pour garantir que les ensembles de données utilisés pour l’entraînement et les entrées des modèles d’IA ne sont ni empoisonnés ni biaisés, et qu’ils restent fiables et dignes de confiance. Bien que ces contrôles puissent s’inspirer des techniques existantes, ils nécessitent des adaptations spécifiques. Par exemple, les contrôles contre l’empoisonnement des données sont étroitement liés aux mécanismes classiques de gestion de la qualité des données, mais doivent aller au-delà des pratiques standards d’assainissement ou de filtrage.

La qualité des données est un pilier fondamental de la sécurité des applications d’IA. Pour atteindre un niveau de sécurité élevé, il est possible d’intégrer une couche supplémentaire d’IA capable d’analyser les données d’entraînement et d’entrée afin de détecter d’éventuelles manipulations malveillantes. De plus, la tokenisation des données peut offrir un double avantage : elle réduit le risque d’exposition de données privées pendant l’apprentissage ou l’inférence d’un modèle, et elle complique la tâche des attaquants souhaitant introduire des données empoisonnées, en raison de la nature brute des données tokenisées (souvent des caractères ASCII ou Unicode). Par exemple, des algorithmes de tokenisation comme **Byte Pair Encoding (BPE)**, utilisés par OpenAI lors de l’entraînement des modèles GPT, permettent de tokeniser efficacement de grands ensembles de données. 

Il est important de garder à l’esprit que l’objectif ne se limite pas à sécuriser les données en tant qu’artefact, mais inclut également l’évaluation de leur contenu et la prévention de leur utilisation malveillante dans la création de résultats biaisés ou ciblés.

Au-delà de la sécurisation des données en entrée, les mesures de sécurité des données doivent être intégrées tout au long du cycle de vie de l’application, notamment lors de la conception et de la construction de l’application, ainsi que lors du traitement des données en entrée et en sortie du modèle. 

Dans le cas des applications utilisant un modèle d’apprentissage continu, les contrôles de sécurité des données doivent être maintenus en permanence pendant le fonctionnement de l’application pour garantir la robustesse du modèle. Bien que la sécurisation des données d’entraînement et d’entrée constitue une base essentielle, une couche supplémentaire de sécurité peut être ajoutée en instaurant une équipe d’experts en IA dédiée. Cette équipe testerait régulièrement le modèle en production avec des données adverses, afin d’évaluer et de renforcer sa résilience face à des tentatives de manipulation malveillante. 

De plus, des garde-fous paramétriques peuvent être instaurés pour limiter le type de résultats que le modèle est autorisé à produire. Ces mesures renforcent non seulement la sécurité de l’application, mais également la confiance dans les résultats générés par le modèle.

Outre les tests continus pour identifier les vulnérabilités des modèles, les équipes chargées de la sécurité des applications doivent veiller à ce que le système soit conçu selon les principes de **sécurité dès la conception**, tout en intégrant des mesures spécifiques à l’IA. Lors de la création d’une application en interne, il est essentiel que les exigences de sécurité soient appliquées à tous les composants, qu’il s’agisse de composants logiciels traditionnels, comme l’infrastructure hôte, ou de composants spécifiques à l’IA, tels que la configuration des modèles et les données d’entraînement. Si des modèles open-source sont utilisés, il est également indispensable de tester la fiabilité du code afin d’identifier d’éventuelles faiblesses de sécurité, des défauts de conception ou des écarts par rapport aux normes de codage sécurisé.

Les équipes doivent également veiller à ce qu’aucune porte dérobée ne puisse être intégrée au modèle. Par exemple, un système pourrait être manipulé pour produire un résultat prédéterminé à l’aide d’un déclencheur spécifique. Ces scénarios doivent être anticipés et prévenus dès la phase de conception.

Certains contrôles de sécurité des applications resteront inchangées, mais devront être adaptées au contexte de l’IA. Par exemple, la surveillance des vulnérabilités publiques devra inclure non seulement les logiciels traditionnels, mais également les modèles d’IA, en particulier s’ils reposent sur des solutions open-source.

La formation des développeurs doit se poursuivre avec quelques ajustements. Les principes fondamentaux restent les mêmes : tout comme il est déconseillé de publier la version exacte d’un logiciel utilisé, les développeurs ne devraient pas divulguer les détails du modèle ou les paramètres d’entrée utilisés. Ils doivent également suivre les directives de sécurité existantes et mises à jour, comprendre les nouvelles menaces propres à l’IA, et intégrer ces connaissances dans leurs processus de développement. Ces efforts garantiront que les applications d’IA sont construites sur des bases solides et sécurisées.

Les applications d’IA présentent des risques inhérents qui nécessitent la mise en place de contrôles spécifiques tout au long de leur cycle de vie afin de garantir leur sécurité. Ces contrôles, souvent nouveaux, ne relèvent pas des responsabilités habituelles d’une équipe existante. Dans les organisations les plus matures, ils sont généralement gérés par un centre d’excellence en matière d’IA. Cependant, dans certaines structures, ils sont pris en charge par l’équipe de sécurité mais exécutés par des scientifiques des données.

Lors de la phase de construction du modèle, des contrôles spécifiques doivent être mis en place pour garantir une conception appropriée du modèle, la sécurité du code source, l’absence de biais dans les techniques d’apprentissage utilisées, ainsi que la mise en place de paramètres clairs concernant les entrées et sorties du modèle. Par exemple, des techniques comme le bagging peuvent être utilisées pour renforcer la résilience du modèle. Cette méthode consiste à diviser le modèle en plusieurs sous-modèles indépendants pendant la phase d’apprentissage, le modèle principal s’appuyant ensuite sur les prédictions les plus fréquentes des sous-modèles. Si l’un des sous-modèles est compromis, les autres peuvent compenser ses failles. D’autres techniques, comme la reconstruction des déclencheurs, peuvent également être appliquées pendant la phase de construction pour protéger contre les attaques par empoisonnement des données. La reconstruction des déclencheurs consiste à identifier des événements dans un flux de données, comme chercher une aiguille dans une botte de foin. Pour les modèles prédictifs, cette technique aide à détecter et à neutraliser les portes dérobées en analysant les résultats du modèle, son architecture et ses données d’entraînement. Les déclencheurs avancés détectent, analysent et atténuent les portes dérobées en identifiant les points sensibles potentiels dans un réseau neuronal profond. Cela inclut l’analyse des chemins de données pour repérer des prédictions inhabituelles (comme des résultats systématiquement erronés ou des temps de décision anormalement rapides), l’évaluation des activations suspectes en étudiant le comportement des données concernées, et la réaction à ces anomalies en filtrant les neurones problématiques ou en neutralisant efficacement la porte dérobée identifiée.

Fig 3. Bagging, une technique de construction pour améliorer la fiabilité et la précision d’un modèle.

En cours d’exécution, il est essentiel de s’assurer que les données introduites dans le modèle sont sûres et ne sont pas empoisonnées. Pour ce faire, on peut ajouter une couche supplémentaire d’IA qui a été formée à la détection des données malveillantes afin de filtrer et de superviser toutes les entrées de données et de détecter les attaques adverses.

Les équipes doivent comprendre comment le modèle s’intègre dans l’écosystème global de la sécurité de l’IA à chaque étape de son cycle de vie : construction, exécution et test. Cette compréhension inclut la connaissance de la disponibilité des informations sur le modèle, l’identification des nouvelles vulnérabilités et des menaces spécifiques à l’IA. Ces éléments permettent aux équipes d’appliquer les correctifs nécessaires et d’effectuer les tests appropriés pour maintenir la sécurité du modèle. Pour les modèles d’apprentissage continu, qui sont conçus pour s’adapter à de nouvelles données, des tests réguliers sont indispensables. Ces tests peuvent inclure une analyse de méta-vulnérabilité, une méthode permettant de modéliser le comportement du modèle à l’aide de spécifications formelles et de l’évaluer en fonction de scénarios de compromission identifiés précédemment. Des techniques d’apprentissage contradictoire, ou des approches similaires, doivent être mises en œuvre pour garantir la fiabilité et la résilience continues des modèles face à des menaces évolutives.

Conclusion

Nous avons démontré que malgré les nouvelles menaces que pose l’IA, les mesures de sécurité existantes continuent de fournir les bases d’un écosystème sécurisé. Dans l’ensemble de la fonction RSSI, nous constatons un équilibre entre les contrôles existants qui protégeront les applications d’IA de la même manière qu’ils protègent les logiciels traditionnels et les domaines qui doivent s’adapter ou ajouter à ce qu’ils font actuellement pour se protéger contre les nouvelles menaces.

Notre analyse nous permet de conclure que pour sécuriser pleinement votre écosystème au sens large, y compris les applications d’IA, vos contrôles seront constitués à 70 % de contrôles existants et à 30 % de nouveaux contrôles.

Cet article L’utilisation pratique du cadre ATLAS de MITRE pour les équipes du RSSI est apparu en premier sur RiskInsight.

 Microsoft a annoncé qu’en Q2 2024 « plus de la moitié des entreprises du classement Fortune 500 utilisent Azure OpenAI ». [1] En parallèle, AWS propose Bedrock [2], concurrent direct d’Azure OpenAI. 

Ce type de plateforme permet de créer des applications basées sur les modèles d’IA générative comme des LLM (GTP-3.5, Mistral, etc.). 

Néanmoins, l’adoption de cette technologie n’est pas sans risque : de l’assistant virtuel qui critique son entreprise [3] à la fuite de donnée [4], les exemples ne manquent pas. 

Pour soutenir les nombreux déploiements en cours, il faut donc rapidement réfléchir à sa sécurité, notamment quand des données sensibles sont utilisées. Nous vous proposons de revenir, au travers de cet article, sur les risques et remédiations liés à l’utilisation de ces plateformes. 

Quel modèle convient à votre besoin ? 

Trois types d’IA génératives peuvent être utilisées pour créer une application. La différence s’observe dans la précision des réponses apportées :  

1. Simple : modèle d’IA générique (GPT-4, Mistral, etc.) branché comme tel, avec une interface utilisateur. C’est un GPT interne. 
2. Boosté : modèle d’IA générique qui fait levier sur les données de l’entreprise, par exemple via du RAG (Retrieval Augmented Generation). Ce sont les compagnons spécialisés pour un usage, RH GPT, Opération GPT, CISO GPT…). 
3. Spécialisé : le modèle d’IA réentraîné pour une utilisation particulière. Par exemple l’Inde a réentraîné Llama 3 sur ses 22 langues officielles pour en faire un traducteur spécialisé. 

Ces trois modes de déploiement induisent des risques. Nous vous proposons dans un premier temps de décrire les différents modes. Nous verrons ensuite les risques, puis les remédiations associées. 

Modèle simple 

Ce modèle est le plus simple à déployer. Il permet aux utilisateurs d’interagir avec les modèles d’IA proposés par les plateformes. Il simplifie l’intégration d’envoi de prompt et de réception des réponses dans une application. Il s’agit d’un ChatGPT interne, l’intérêt étant de limiter la fuite de donnée sensible insérée dans un prompt, à contrario de la version web. Aussi, dans ce cas, les échanges avec les utilisateurs ne sont pas utilisés pour réentraîner et améliorer le modèle. Vos données sont protégées. Les plateformes Cloud proposées par Azure, AWS ou GCP permettent un déploiement rapide de ces solutions. 

Exemples d’utilisation : résumé de texte, assistant de développement. 

Fonctionnement du modèle simple

Modèle boosté 

Le modèle reste générique mais aura accès à des données de l’entreprise sélectionnées. L’IA pourra par exemple consulter la PSSI du groupe pour fournir la politique de mots de passes. 

Exemples d’utilisation : chatbot d’entreprise, analyse de données. 

Fonctionnement du modèle boosté

Modèle spécialisé 

L’application ne repose plus sur un modèle générique (GPT-4, Mistral, etc.). En amont de son exploitation, vous devrez entraîner votre propre modèle sur les données de votre entreprise. Il pourra toujours consulter les données de l’entreprise et en aura une meilleure compréhension pour générer sa réponse. 

Exemples d’utilisation : détection de défaut sur une ligne de production, diagnostic médical. 

 Fonctionnement du modèle spécialisé

A quels risques êtes-vous exposés ? 

Qu’importe le modèle sélectionné, il existe plusieurs risques transverses ou spécifiques. Il est important d’en tenir compte pour assurer l’intégration sécurisée de la solution. 

Détournement du modèle 

Les modèles d’IA sont exposés au risque de mauvaise utilisation. Imaginez un scénario où quelqu’un utilise cette technologie pour générer du contenu nuisible. Cela peut entraîner des conséquences réelles comme la propagation de contenu toxique. L’une des attaques connues pour cet objectif est le Prompt Injection [5]. 

 Exemple – Détournement du modèle (Prompt Injection)

Hallucination 

Lorsque l’IA affirme une information qui est fausse, elle hallucine. Pensez-y comme si l’IA « rêvassait » : si elle n’a pas la réponse, elle va « inventer » des choses pour remplir le vide. Cela peut être particulièrement problématique dans des situations où la précision est cruciale : génération de rapports, prise de décisions. Les utilisateurs pourraient propager sans le savoir ces fausses informations, ou prendre de mauvaises décisions.  

 Exemple – Hallucination du modèle

Fuite de données 

Il existe plusieurs façons de faire fuiter la donnée. Un attaquant peut injecter un prompt malicieux pour la récupérer, un employé peut se voir attribuer plus de droits que nécessaires et accéder à des informations sensibles (exemple : compte rendu stratégique d’un comité exécutif). La sécurisation de la base de données sous-jacente doit donc être proportionnelle à la donnée stockée. 

A savoir que le modèle a accès à certaines données de l’entreprise. Si ses droits sont par exemple trop importants, il pourra consulter des données confidentielles. Ces réponses incluront donc des informations sensibles n’ayant pas vocation à être communiquées. 

Exemple – Fuite de données

Vol du modèle 

Si le modèle est spécialisé, c’est désormais la propriété intellectuelle de votre entreprise. À ce titre, il pourrait attiser la convoitise de l’attaquant. Les données d’entraînement confidentielles peuvent par exemple être ciblées. La question de confiance en l’hébergeur Cloud peut aussi se poser : ne vaut-il pas mieux l’héberger en local ? 

 Exemple – Vol du modèle

Empoisonnement du modèle 

Sans prétendre voler le modèle, l’objectif de l’attaquant pourrait être de le rendre non fiable. Les réponses générées ne pourraient donc plus être exploitées par les équipes. 

L’empoisonnement peut se produire dans deux cas de figures :  

• Modèle boosté : l’attaquant accèdent au RAG et modifie les informations. Alors le modèle s’appuie sur des données empoisonnées pour fournir ses réponses.  

• Modèle spécialisé : l’attaquant empoisonne les données de réentraînement du modèle. Soit directement sur la base de données qu’il met à disposition sur une plateforme publique (type Hugging face), soit en accédant à la base de données d’entraînement hébergé dans votre système d’information. 

Exemple – Empoisonnement du modèle

Risques principaux : quelles remédiations ? 

Parmi les 5 risques présentés, 3 prédominent dans les analyses de risques effectuées par nos équipes. Nous vous proposons d’étudier les remédiations associées. 

Le caractère nouveau de la technologie offre l’opportunité de construire des bases de sécurité solide. Pour aboutir à une solution efficace et sécurisée, plusieurs itérations seront nécessaires. 

Risque #1 : Détournement du modèle 

 Détournement du modèle : clé de remédiation

Pour faire face au détournement du modèle, nous conseillons les mesures suivantes : 

#1 – Durcir la configuration suivant deux axes. Premièrement, la gestion du prompt maître (fenêtre de discussion avec le modèle). Certains mots clés peuvent par exemple être bannis afin d’éviter les dérives. Deuxièmement, le nombre de jetons et donc la taille des réponses. Un modèle moins verbeux aura moins de chance d’être détourné. D’autres paramètres peuvent être pris en compte : la température, la langue utilisée, etc. 

#2 – Filtrer les réponses en appliquant par exemple un simple algorithme filtrant les réponses. Pour aller plus loin, il est envisageable de déployer des pares-feux LLM spécialisés. Cela permettra par exemple de se prévenir de potentiels abus (on parle dans ce cas-là d’Abuse monitoring). 

#3 – Limiter les sources auxquels le modèle à accès pour générer ses réponses. Dans l’hypothèse où l’accès aux données de l’entreprise est accordé au modèle, il est possible de le limiter uniquement à ces données. Ainsi, il ne pourra pas chercher d’autres informations sur Internet par exemple.  

Risque #2 : Hallucination 

Hallucination : clé de remédiation

Pour faire face aux hallucinations, nous conseillons les mesures suivantes : 

#1 – Former et sensibiliser les utilisateurs sur le fonctionnement des modèles, leurs limites et les meilleures pratiques. Cela permet aux utilisateurs d’utiliser les Large Language Model de manière responsable et de reconnaître les utilisations abusives ou les menaces de sécurité potentielles. 

#2 – Durcir la configuration suivant deux axes. Premièrement, un ajustement du paramétrage incluant le réglage de la température du modèle (degré de créativité du modèle) et la limitation des jetons (nombre de mots par questions/réponses). Deuxièmement, l’utilisation d’un modèle plus récent (GPT-4 plutôt que GPT 3.5 par exemple). 

#3 – Optionnel – Ré-entrainer le modèle lui donne un contexte. La fiabilité des réponses sera donc positivement impactée. Utiliser un large éventail de données d’entraînement peut aider à couvrir plus de scénarios et réduire les biais, ce qui aide l’IA à mieux comprendre et générer des réponses appropriées. Il est de même important d’éliminer les erreurs et les incohérences dans les données d’entraînement peut réduire la probabilité que l’IA apprenne et répète ces mêmes erreurs. 

Risque #3 : Fuite de données 

Fuite de données : clé de remédiation

Pour faire face aux fuites de données sensibles, nous conseillons les mesures suivantes : 

#1 – Impliquer le délégué à la protection des données afin d’assurer la conformité aux lois et protocoles de protection des données en impliquant le Délégué à la Protection des Données (DPO) dans les projets accédant aux plateformes de Large Language Model est important pour protéger les données personnelles et sensibles. En adhérant à ces normes, les organisations protègent non seulement la vie privée individuelle mais renforcent également leur défense contre les violations de données et la mauvaise utilisation. 

#2 – Gérer les droits et les accès sur l’ensemble des composantes interagissant avec le modèle. Comprendre quelles données quelles données peuvent être accéder par le modèle n’est pas trivial. Auditer et recertifier ces données dans le temps permet de limiter les écarts potentiels. 

#3 – Réduire la verbosité du modèle via la limitation du nombre de jetons de sortie. Moins un modèle est verbeux, plus la probabilité qu’il partage de la donnée confidentielle par inadvertance est faible. 

#4 – Anonymiser la donnée, ou la rendre générique, si le cas d’usage le permet. L’IA pourra par exemple travailler sur les tendances d’une population sans qu’un nom explicite ne puisse être cité. En plus de réduire fortement le risque de fuite de donnée, cela réduira les normes auxquelles se conformer (exemple : RGPD). 

#5 – Limiter les données sensibles utilisées, il faut ici réfléchir aux données nécessaires et suffisantes pour que le modèle fonctionne. Un traitement préalable de la donnée peut être effectuée pour supprimer ou modifier les données sensibles et ainsi en réduire l’exposition (exemple : anonymisation de la donnée). 

Remédiations transverses 

Certaines mesures s’appliquent à tous les risques cités ci-dessus. Deux d’entre elles apparaissent comme fondamentales.  

#1 – Intégrer la sécurité aux projets via, par exemple, une analyse de sécurité contextualisée. Cela permet aux organisations peuvent identifier et atténuer préventivement les vulnérabilités potentielles, assurant ainsi que seuls les projets sécurisés et vérifiés accèdent aux applications d’IA génératives.  

#2 – Documenter chaque application afin d’établir un cadre opérationnel facilitant non seulement une supervision et une gestion plus aisées, mais réduit également le risque d’utilisation non autorisée ou malveillante.  

Le développement d’applications d’IA est accéléré par les plateformes disponibles. Cependant, la sophistication qu’il apporte n’est pas sans risque.  

Reconnaissant ces défis, la priorité est l’établissement d’une gouvernance robuste pour la plateforme. Cela implique une délimitation des rôles et responsabilités, assurant une approche structurée pour gérer et atténuer les risques. 

La gouvernance s’étend au-delà de la plateforme elle-même. Sécuriser la myriade de cas d’utilisation d’application d’IA est tout aussi important. Il s’agit de garantir que l’application de cette technologie d’IA est à la fois responsable et alignée sur les normes éthiques, se prémunissant contre la mauvaise utilisation et les conséquences non intentionnelles. 

Cela appelle à un modèle de responsabilité partagée, où tous les acteurs — développeurs, utilisateurs et organes de gouvernance — collaborent pour maintenir l’intégrité et la sécurité des applications d’IA. 

Références 

1. https://synthedia.substack.com/p/microsoft-azure-ai-users-base-rose 
2. https://www.usine-digitale.fr/article/amazon-fait-son-entree-sur-le-marche-de-l-ia-generative-avec-bedrock.N2121081  
3. https://www.theguardian.com/technology/2024/jan/20/dpd-ai-chatbot-swears-calls-itself-useless-and-criticises-firm 
4. https://openai.com/blog/march-20-chatgpt-outage 
5. https://www.riskinsight-wavestone.com/2023/10/quand-les-mots-deviennent-des-armes-prompt-injection-et-intelligence-artificielle/ 

Cet article Applications d’IA générative : risques et remédiations  est apparu en premier sur RiskInsight.

L’intelligence artificielle (IA) occupe désormais une place centrale dans les produits et services offerts par les entreprises et les services publics, en grande partie grâce à l’essor de l’IA générative. Pour soutenir cette croissance et favoriser l’adoption de l’IA, il a été nécessaire d’industrialiser la conception des systèmes d’IA en adaptant les méthodes et procédures de développement de modèles. 

C’est ainsi qu’est né le MLOps, une contraction de “Machine Learning” (le cœur des systèmes d’IA) et “Operations”. À l’instar du DevOps, le MLOps facilite la réussite des projets de Machine Learning tout en assurant la production de modèles performants. 

Cependant, il est crucial de garantir la sécurité des algorithmes pour qu’ils demeurent performants et fiables dans le temps. Pour ce faire, il est nécessaire de faire évoluer le MLOps vers le MLSecOps, en intégrant la sécurité dans les processus, à l’image du DevSecOps. Peu d’entités ont adopté et déployé un processus MLSecOps complet. Dans cet article, nous explorerons en détail la forme que pourrait prendre le MLSecOps. 

Le MLOps, les fondamentaux de développement de modèle d’IA 

Rapprochement avec le DevOps 

Le DevOps est une approche qui combine le développement logiciel (Dev) et les opérations informatiques (Ops). Son objectif est de raccourcir le cycle de vie du développement tout en assurant des livraisons continues de haute qualité. Les principes clés incluent l’automatisation des processus (développement, test et mise en production), la livraison continue (CI/CD) et des boucles de rétroaction rapides. 

MLOps, quant à lui, est une extension des principes DevOps appliqués spécifiquement aux projets de Machine Learning (ML). Les flux de travail sont simplifiés et automatisés au maximum, de la préparation des données d’entraînement à la gestion des modèles en production. Le MLOps se distingue du DevOps sur plusieurs points : 

• Importance des données et des modèles : Dans le Machine Learning, les données et les modèles sont cruciaux. Le MLOps va plus loin en automatisant toutes les étapes du Machine Learning, de la préparation des données aux phases d’entraînement. De plus, un volume de données plus important est souvent utilisé dans les projets de Machine Learning. 
• Nature expérimentale du développement : Le développement en Machine Learning est expérimental et implique de tester et d’ajuster continuellement les modèles pour trouver les meilleurs algorithmes, paramètres et données pertinentes pour l’apprentissage. Cela pose des défis pour l’adaptation du DevOps au Machine Learning, car le DevOps se concentre sur l’automatisation et la stabilité des processus. 
• Complexité des tests et de la recette : La nature évolutive des modèles et la complexité des données rendent les phases de test et de recette plus délicates en Machine Learning. De plus, la surveillance des performances est essentielle pour garantir le bon fonctionnement des modèles en production. Ainsi, en Machine Learning, il faut adapter les procédures de Maintenance en Conditions Opérationnelles pour maintenir la stabilité et la fiabilité des systèmes. 

En somme, une chaîne MLOps partage des éléments communs avec une chaîne DevOps, mais introduit des étapes supplémentaires et accorde une importance particulière à la gestion et à l’utilisation des données. Le graphique suivant souligne en jaune toutes les étapes supplémentaires que le MLOps introduit : 

• Accès et utilisation des données : Cette étape inclut toutes les phases du Data Engineering (collecte, transformation et versionnement des données utilisées pour l’entraînement). L’enjeu est d’assurer l’intégrité des données et la reproductibilité des tests. 
• Recette du modèle : Les recettes et les tests d’intégration en ML sont plus complexes et se déroulent sur trois couches différentes : la pipeline des données, la pipeline du modèle de ML et la pipeline applicative. 
• Monitoring en production : Il s’agit de garantir la performance du modèle dans le temps et d’éviter le “model drifting” (déclin de la performance dans le temps). Pour cela, toutes les déviations (changement instantané, changement graduel, changement récurrent) doivent être détectées, analysées et corrigées si nécessaire. 

 Figure 1 – Adaptation des étapes du DevOps au Machine Learning 

Mettre en place le MLOps nécessite de créer un dialogue entre ingénieur des données et les opérateurs de DevOps 

Le passage au MLOps implique de créer de nouvelles étapes organisationnelles spécifiquement adaptée à la gestion des données. Cela inclut notamment la collecte et la transformation des données d’entrainement, ainsi que les processus de suivi des différentes versions de données.  

En ce sens, la collaboration entre les experts en MLOps, Data Scientists et les Data Engineers est essentielle pour réussir dans ce domaine en constante évolution. L’enjeu principal d’une mise en place d’une chaine MLOps réside donc dans l’intégration des Data Engineers dans les processus DevOps. Ces derniers sont responsables de préparer les données dont les ingénieurs MLOps ont besoin pour entraîner et exécuter des modèles.  

Et la sécurité dans tout ça ? 

L’adoption massive des IA génératives en 2024 nous a fourni une variété d’exemples de compromissions de terme de sécurité. En effet, la surface d’attaque est grande : un acteur malveillant peut à la fois attaquer le modèle en lui-même (vol de modèle, reconstruction de modèle, détournement de l’usage initial) mais également attaquer ses données (extraire des données d’entraînement, modifier le comportement en ajoutant des fausses données, etc.). Pour illustrer ces derniers, nous avons simulé deux attaques réalistes dans de précédents articles : Attaquer une IA ? Un exemple concret ! ou Quand les mots deviennent des armes : prompt injection. 

En parallèle, le MLOps, introduit une automatisation qui accélère la mise en production. Bien que cela puisse réduire le time to market (délais de mise sur le marché), cela augmente également les risques (attaque par supply chain, massification). Il est donc crucial de s’assurer que les risques liés à la cybersécurité et à l’IA sont correctement gérés. 

Comme le fait le DevSecOps pour le DevOps, la chaine de production du MLOps doit être sécurisée. Voici un panorama des principaux risques sur la chaine MLOps : 

Adopter le MLSECOPS 

Intégrer la sécurité dans les équipes MLOPS et renforcer la culture sécurité 

Les principes du MLSecOps doivent être compris par les Data Scientists et les Data Engineers. Pour cela, il est crucial que les équipes de sécurité soient intégrées dès le début du projet. Cela peut se faire de deux manières : 

• Lors de la création d’un nouveau projet, un membre de l’équipe de sécurité est assigné en tant que responsable de la sécurité. Il supervise les avancées et répond aux questions des équipes du projet. 
• Une approche plus agile, similaire au DevSecOps, consiste à désigner un membre de l’équipe comme “Security Champion”. Ce référent cybersécurité au sein de l’équipe projet devient l’interlocuteur privilégié des équipes cyber. Cette méthode permet une intégration plus réaliste de la sécurité dans le projet, mais nécessite une formation adéquate pour le Security Champion. 

Pour que ce changement soit efficace, il est également nécessaire de modifier la perception de la cybersécurité par les équipes projets : 

• En fournissant une formation de base aux équipes pour mieux comprendre les enjeux de la cybersécurité. 
• En intégrant la cybersécurité dans les plateformes de collaboration et de connaissances. 
• En organisant régulièrement des campagnes de sensibilisation. 

Sécuriser les outils de la chaîne MLOPS 

Pour garantir la sécurité des produits, il est essentiel de sécuriser la chaîne de production. Dans le cadre du MLOps, cela signifie s’assurer que tous les outils sont correctement utilisés avec des pratiques intégrant la cybersécurité, qu’il s’agisse du traitement et de la gestion des données (comme MongoDB, SQL, etc.), des outils de surveillance (tel que Prometheus), ou des outils de développement plus ou moins spécifiques (comme MLFlow ou GitHub). 

Par exemple, il est crucial que les équipes restent vigilantes sur des thématiques telles que l’identification et la gestion des identités, la continuité d’activité, la surveillance, et la gestion des données. Les possibilités offertes par les différents outils utilisés tout au long du cycle de vie, ainsi que leurs spécificités, doivent être examinées en lien avec ces enjeux. Idéalement, les caractéristiques de cybersécurité devraient servir de critères de sélection pour choisir l’outil le plus adapté. 

Définir des pratiques en matière de sécurité de l’IA 

Au-delà de la sécurité des outils qui permettent de construire les systèmes d’IA, il convient d’intégrer des mesures de sécurité permettant de prévenir les vulnérabilités spécifiques aux systèmes d’IA. Ces mesures doivent être incorporées dès la conception et tout au long du cycle de vie de l’application, suivant une approche MLSecOps. De la collecte des données à la surveillance du système, il existe de nombreuses mesures de sécurité à intégrer : 

Figure 2 – Les mesures de sécurité applicables tout au long du cycle de vie 

Trois mesures de sécurité à implémenter dans vos processus MLSecOps 

Selon la stratégie de sécurité adoptée, diverses mesures de sécurité peuvent être intégrées tout au long du cycle de vie du MLOps. Nous avons détaillé les principaux mécanismes de défenses pour sécuriser l’IA dans l’article suivant : Sécuriser l’IA : Les Nouveaux Enjeux de Cybersécurité.  

Dans cette partie, nous allons nous attarder sur 3 mesures spécifiques qui peuvent être mises en œuvre pour renforcer la sécurité du MLOps : 

 Figure 3 – Mesures de sécurité sélectionnées 

Contrôler la pertinence des données et les risques d’empoisonnement 

Dans le cadre du Machine Learning, la sécurité des données est primordiale pour prévenir les risques d’empoisonnement et garantir l’intégrité des données traitées.  

Avant de procéder au traitement des données collectées, un contrôle continu de l’origine des données est essentiel afin d’en garantir leur qualité et leur pertinence. Cela est d’autant plus complexe lors de l’utilisation de flux de données externes, dont la provenance et la véracité peut parfois être incertain. Ainsi, le risque majeur réside dans l’intégration de données utilisateurs lors d’un apprentissage en continu. Cela peut conduire à des résultats imprévisibles, comme illustré par l’exemple du ChatBot TAY de Microsoft en 2016. Ce dernier, était conçu pour apprendre à travers les interactions utilisateurs. Cependant, sans une modération adéquate, il a rapidement adopté des comportements inappropriés, reflétant les entrées négatives reçues. Cet incident souligne l’importance d’une surveillance et d’une modération constantes des données d’entrée, en particulier lorsqu’elles proviennent d’interactions humaines en temps réel. 

Diverses techniques d’analyse peuvent être utilisées pour nettoyer un ensemble de données. L’objectif étant de vérifier l’intégrité des données et de supprimer toute données pouvant avoir un impact négatif sur les performances du modèle. Deux méthodes principales sont possibles :  

• D’une part, nous pouvons vérifier individuellement l’intégrité de chacune des données par contrôle des valeurs aberrantes, validation du format ou de métriques caractéristiques… 
• D’autre part, avec une analyse globale, des approches comme la validation croisée et le clustering statistique sont efficaces pour identifier et éliminer les éléments inappropriés de l’ensemble de données. 

Introduire des exemples contradictoires 

Les exemples contradictoires sont des entrées corrompues, modifiées pour induire en erreur les prédictions d’un algorithme de Machine Learning. Ces modifications sont construites pour être indétectables à l’œil humain mais suffisantes pour tromper l’algorithme. Ce type d’attaque exploite les vulnérabilités ou failles présentes dans l’entrainement du modèle pour provoquer des erreurs de prédiction. Pour les réduire, il est alors possible d’apprendre au modèle à identifier et ignorer ce type d’entrée. 

Pour cela, nous pouvons délibérément ajouter des exemples contradictoires aux données d’entraînements. L’objectif est de présenter au modèle des données légèrement altérées, afin de le préparer à identifier et gérer correctement les erreurs potentielles. La création de ce type de données dégradée est complexe. La génération de ces exemples contradictoires, devra être adapté au problème et aux menaces identifiées. Il est crucial de surveiller attentivement la phase d’entraînement afin de s’assurer que le modèle reconnaît efficacement ces entrées incorrectes et sache réagir correctement.  

Modifier les entrées utilisateurs 

La sécurisation des entrées est essentielle pour minimiser les risques liés aux manipulations malveillantes. Une faiblesse importante des LLM (Large Language Models) est leur manque de compréhension contextuelle approfondie et leur sensibilité à la formulation précise des prompts. Une des techniques les plus connue pour exploiter cette vulnérabilité est l’attaque par prompt injection. Il est donc nécessaire d’introduire une étape intermédiaire de transformation des données utilisateur avant leur traitement par le modèle. 

Il est possible de modifier légèrement l’entrée afin de contrer ce type d’attaque, tout en préservant la précision du modèle. Cette transformation peut se faire via diverses techniques (e.g. codage, ajout de bruit, reformulation, compression des caractéristiques, etc.). L’objectif est de conserver uniquement ce qui est essentiel à la réponse. Ainsi, toute information superflue potentiellement malicieuse est écartée. De plus, cette méthode prive l’attaquant de la possibilité d’accéder à la véritable entrée du système. Ce qui empêche toute analyse approfondie des relations entre entrées et sorties et complique ainsi la conception de futures attaques. Il reste toutefois essentiel de tester les différentes mesures implémentées, pour s’assurer qu’elles ne dégradent pas les performances du modèle, garantissant ainsi une sécurité renforcée sans compromettre l’efficacité. 

Avec l’industrialisation de la production d’applications basées sur le Machine Learning et l’IA, la sécurité à grande échelle devient une question organisationnelle cruciale pour le marché. Il est impératif d’entreprendre une transition vers le MLSecOps. Cette transformation repose sur trois piliers principaux : 

• Renforcer la culture de sécurité des équipes de Data Scientists : Il est essentiel que les Data Scientists comprennent et intègrent les principes de sécurité dans leur travail quotidien. Cela permet de créer une culture de sécurité partagée et de renforcer la collaboration entre les différents acteurs. 
• Sécuriser les outils qui produisent les algorithmes de Machine Learning : Il est essentiel de sélectionner des outils de MLOps sécurisés et d’appliquer des bonnes pratiques au sein de outils (gestion des droits, etc.) pour sécuriser « l’usine » à algorithmes de Machine Learning et ainsi réduire la surface de compromission. 
• Intégrer des mesures de sécurité spécifiques à l’IA : Adapter les mesures de sécurité aux particularités des systèmes d’IA est crucial pour prévenir les attaques potentielles et assurer la fiabilité des modèles dans le temps. Il convient donc d’intégrer ces mesures de sécurité dans la chaîne de MLOps à l’aide du MLSecOps. 

Engagez-vous dès aujourd’hui dans la transition vers le MLSecOps. Formez vos équipes, sécurisez vos outils et intégrez des mesures de sécurité spécifiques à l’IA. A ce titre, vous pourrez bénéficier de systèmes d’IA produits industriellement et sécurisés by design.  

Remerciements à Louis FAY et Hortense SOULIER qui ont également contribué à la rédaction de cet article. 

Cet article Adopter le MLSecOps : la clé pour des modèles d’IA fiables et sécurisés  est apparu en premier sur RiskInsight.

Pour répondre à cette question, des chercheurs et des ingénieurs du monde entier ont mis au point un système standardisé pour tester les LLM dans divers contextes, domaines de connaissance, et les quantifier de manière objective. Ces tests sont communément appelés des « Benchmarks », et différents benchmarks reflètent des cas d’utilisation très variés.

Cependant, pour l’utilisateur moyen, ces benchmarks seuls ne signifient pas grand-chose. Il existe un manque évident de sensibilisation pour l’utilisateur final : un résultat de 97,3 % dans le benchmark « MMLU » est difficile à comprendre et à transposer dans leurs tâches quotidiennes.

Pour éviter de telles confusions, l’article présente des facteurs qui limitent les choix d’un utilisateur en matière de LLM, les benchmarks de LLM les plus populaires et largement utilisés, leurs cas d’utilisation, et comment ils peuvent aider les utilisateurs à choisir le LLM le plus optimal pour eux.

Facteurs qui impactent le choix des LLM

Différents facteurs impactent la qualité du modèle : la date limite de connaissance, l’accès à Internet, la multimodalité, la confidentialité des données, la fenêtre contextuelle ainsi que la vitesse et la taille des paramètres. Ces facteurs doivent être bien établis avant de passer aux évaluations des benchmarks et aux comparaisons de modèles, car ils limitent les modèles que vous pouvez utiliser en premier lieu.

Date limite de connaissances et accès à Internet

Presque tous les modèles sur le marché ont une date limite de connaissance. Il s’agit de la date à laquelle la collecte de données pour la formation du modèle prend fin. Par exemple, si la date limite est septembre 2021, le modèle n’a aucun moyen de connaître les informations après cette date. Les dates limites sont généralement fixées un à deux ans avant la publication du modèle.

Cependant, pour surmonter ce problème, certains modèles tels que Copilot (GPT-4) et Gemini ont été dotés d’un accès à Internet, leur permettant de naviguer sur le web. Cela a permis à des modèles ayant une date limite de connaissances de continuer à accéder aux nouvelles et aux articles les plus récents. Cet accès permet également aux LLM de fournir des références aux utilisateurs, ce qui réduit le risque d’hallucinations et rend les réponses plus fiables.

Enfin, l’accès à Internet est une fonctionnalité ajoutée au modèle plutôt qu’une caractéristique intrinsèque du modèle lui-même. Il est donc limité aux modèles disponibles sur Internet, principalement ceux en source fermée et hébergés dans le cloud. Pour cette raison, il est important de déterminer vos besoins et de vérifier si disposer d’informations à jour est réellement essentiel pour atteindre vos objectifs.

Multimodalité

Différentes applications nécessitent des usages variés des LLM. Alors que la plupart d’entre nous les utilisent principalement pour leurs capacités de génération de texte, de nombreux LLM sont en réalité capables d’analyser des images, des voix, et de répondre avec des images également.

Cependant, tous les LLM n’ont pas cette capacité. La capacité d’analyser différentes formes d’entrée (texte, image, voix) est ce que l’on appelle la « multimodalité ». C’est un facteur important à prendre en compte, car si votre tâche nécessite l’analyse de messages vocaux ou de diagrammes d’entreprise, il est essentiel de rechercher des modèles qui sont multimodaux, tels que Claude 3 et ChatGPT.

Protection des données

L’un des risques liés à l’utilisation de la plupart des modèles actuellement disponibles sur le marché est la confidentialité et la fuite des données. Plus précisément, la confidentialité et la sécurité des données dans les LLM peuvent être divisées en deux parties :

1. Confidentialité des données lors de l’entraînement et de l’ajustement : il s’agit de savoir si le modèle a été formé sur des données contenant des informations personnelles identifiables (PII) et s’il pourrait divulguer ces informations personnelles lors des échanges avec les utilisateurs. Cela dépend de l’ensemble de données utilisé pour l’entraînement du modèle et du processus d’ajustement.
2. Confidentialité des données lors du réentraînement et de la mémorisation : il s’agit de savoir si le modèle utilise les conversations avec les utilisateurs pour se réentraîner, ce qui pourrait potentiellement entraîner la divulgation d’informations d’une conversation à une autre. Cependant, ce risque est limité à certains modèles en ligne. Cela dépend de la manière dont le modèle est configuré et des couches logicielles entre le modèle et l’utilisateur.

Fenêtre contextuelle

La fenêtre contextuelle fait référence au nombre de jetons d’entrée qu’un modèle peut accepter. Ainsi, une fenêtre contextuelle plus grande signifie que le modèle peut accepter un texte d’entrée plus important. Par exemple, le dernier modèle de Google, le Gemini 1.5 pro, dispose d’une fenêtre contextuelle d’un million de jetons, ce qui lui permet de lire des manuels entiers et de vous répondre sur la base des informations qu’ils contiennent.

Pour donner un contexte, une fenêtre de 1 million de jetons permet au modèle d’analyser environ 60 livres entiers simplement à partir des entrées de l’utilisateur avant de répondre à la demande de l’utilisateur.

Ainsi, il est donc évident que les modèles avec des fenêtres contextuelles plus grandes peuvent souvent être personnalisés pour répondre à des questions basées sur des documents d’entreprise spécifiques sans avoir recours à la génération augmentée par récupération (RAG), qui est la solution la plus courante pour ce problème sur le marché.

Cependant, les LLM facturent souvent les utilisateurs en fonction du nombre de jetons d’entrée utilisés et il est donc à prévoir que les frais soient plus élevés lorsqu’on utilise une fenêtre contextuelle plus grande. De plus, il n’est pas courant que les modèles prennent plus de 10 minutes avant de répondre lorsqu’ils utilisent une fenêtre contextuelle plus grande.

Vitesse et taille des paramètres

Les LLM présentent des variations techniques qui peuvent influencer la rapidité de traitement de la demande de l’utilisateur et la vitesse de génération de la réponse. La variation technique la plus importante qui affecte la vitesse des LLM est la taille des paramètres, qui fait référence au nombre de variables internes que le modèle possède. Ce nombre, généralement en milliards, reflète la sophistication du modèle, mais indique également que le modèle pourrait nécessiter plus de temps pour générer une réponse.

Toutefois, l’architecture interne du modèle a également son importance. Par exemple, certains des derniers modèles à plus de 70 milliards de paramètres sur le marché peuvent répondre en temps réel, tandis que certains modèles à 8 milliards de paramètres ont besoin de quelques minutes pour générer une réponse.

Globalement, il est important de prendre en compte le compromis entre la vitesse d’une part et la taille des paramètres (sophistication et complexité) d’autre part, bien que cela dépende aussi fortement de l’architecture interne du modèle et de l’environnement dans lequel il est utilisé (API, service cloud, ou auto-déploiement, etc.).

Néanmoins, la vitesse est un élément clé qui se situe à la frontière entre le facteur et le critère de référence puisqu’elle est mesurée et utilisée pour comparer les différents modèles STOA. Cependant, la vitesse n’est pas une forme d’évaluation pragmatique standardisée et, pour cette raison, elle n’est pas considérée comme un critère de référence.

Prochaines étapes

Après avoir examiné les facteurs, les utilisateurs peuvent maintenant limiter leur choix de LLM et utiliser les critères d’évaluation présentés dans la section suivante pour les aider à choisir le modèle le plus optimal. Cela permet à l’utilisateur de maximiser son efficacité et de ne comparer que les modèles qui sont pertinents pour lui (en termes de date limite de connaissances, de vitesse, de confidentialité des données, etc.)

Comment les benchmarks sont-ils menés ?

Les benchmarks sont des outils utilisés pour évaluer la performance des LLM dans un domaine spécifique. Ils peuvent être réalisés de différentes manières, le facteur clé étant le nombre de paires question-réponse d’exemples fournies au LLM avant qu’il ne soit invité à résoudre une question réelle.

Les benchmarks évaluent la capacité du LLM à accomplir une tâche spécifique. La plupart des benchmarks posent une question au LLM et comparent sa réponse avec une réponse correcte de référence. Si la réponse correspond, le score du LLM augmente. À la fin, les benchmarks fournissent un score de précision (Acc/Accuracy), qui est un pourcentage du nombre de questions auxquelles le LLM a répondu correctement.

Cependant, en fonction de la méthode d’évaluation, le LLM peut obtenir un certain contexte sur le benchmark, le type de questions ou d’autres éléments. Cela se fait par le biais de tests à répétition ou d’exemples multiples.

Tests à répétition

Les benchmarks sont réalisés de trois manières distinctes.

1. Zéro répétition
2. Une répétition
3. Multi-répétition (souvent des multiples de 2 ou de 5)

Le terme « répétition » se réfère au nombre de fois qu’une question exemple est donnée au LLM avant son évaluation.

La raison pour laquelle nous avons différents types de tests (zéro répétition, une répétition, multi-répétitions) est que certains LLM surpassent d’autres en termes de mémoire à court terme et d’utilisation du contexte. Par exemple, le LLM1 pourrait avoir été formé avec plus de données et donc surpasser le LLM2 dans les tests zéro répétition. Cependant, la technologie sous-jacente du LLM2 lui permet de bénéficier d’une capacité de raisonnement et de contextualisation supérieure, qui ne serait mesurée que par des évaluations d’une répétition ou de plusieurs répétitions.

Figure 1 : illustration de 3-shots vs 0-shot prompting

Pour cette raison, chaque fois qu’un LLM est évalué, des réglages à plusieurs répétitions sont utilisés pour garantir une compréhension complète du modèle et de ses capacités. Par exemple, si vous êtes intéressé par la recherche d’un modèle qui contextualise bien et est capable de raisonner logiquement à travers de nouveaux et divers problèmes, envisagez d’examiner comment la performance du modèle s’améliore à mesure que le nombre de répétitions augmente. Si un modèle montre une amélioration significative, cela signifie qu’il possède une forte capacité à raisonner et à apprendre des exemples précédents.

Principaux benchmarks et facteurs de différenciation

De nombreux benchmarks évaluent souvent les mêmes aspects. Il est donc important, lors de l’examen des benchmarks, de comprendre ce qu’ils évaluent, comment ils le font et quelles sont les implications de ces évaluations.

Compréhension du Langage Multitâche Massif (MMLU)

Figure 2 : exemple d’un questionnaire à choix multiple

Le MMLU est l’un des benchmarks les plus largement utilisés. Il s’agit d’un ensemble de données au format de questions à choix multiple couvrant 57 sujets uniques à un niveau de licence. Ces sujets incluent les humanités, les sciences sociales, les STIM (Sciences, Technologie, Ingénierie et Mathématique) et plus encore. Pour cette raison, le MMLU est considéré comme le benchmark le plus complet pour tester les connaissances générales d’un LLM dans tous les domaines. De plus, il est également utilisé pour identifier les lacunes dans les données d’entraînement du LLM, car il n’est pas rare qu’un LLM soit exceptionnellement bon dans un sujet et moins performant dans un autre.

Cependant, le MMLU ne contient que des questions en anglais. Ainsi, un excellent résultat au MMLU ne se traduit pas nécessairement par de bonnes performances lorsqu’il s’agit de répondre à des questions de culture générale en français ou en espagnol. De plus, le MMLU est exclusivement basé sur des questions à choix multiple, ce qui signifie que le LLM est testé uniquement sur sa capacité à choisir la bonne réponse. Cela ne signifie pas nécessairement que le LLM est compétent pour générer des réponses cohérentes, bien structurées et sans hallucinations lorsqu’il est confronté à des questions ouvertes.

En règle générale, un score MMLU moyen élevé pour l’ensemble des 57 champs indique que le modèle a été entraîné sur une grande quantité de données contenant des informations sur de nombreux sujets différents. Ainsi, un modèle qui obtient de bons résultats en MMLU est un modèle qui peut être utilisé efficacement (éventuellement avec un peu d’ingénierie) pour répondre aux FAQ, aux questions d’examen et à d’autres questions courantes de la vie quotidienne.

HellaSwag (HS)

Figure 3 : exemple d’une question HellaSwag

HellaSwag est un acronyme pour « Harder Endings, Longer contexts, and Low-shot Activities for Situations with Adversarial Generations ». Il s’agit d’un autre benchmark massif (plus de 10 000 questions) axé sur l’anglais et basé sur des questions à choix multiple. Cependant, contrairement au MMLU, le HS n’évalue pas les connaissances factuelles ou spécifiques à un domaine. Au lieu de cela, le HS se concentre sur la cohérence et le raisonnement des LLM.

Les questions comme celle ci-dessus mettent le LLM au défi en lui demandant de choisir la suite de la phrase qui a le plus de sens humain. Grammaticalement, ces phrases sont toutes valables, mais seule l’une d’entre elles respecte le bon sens.

La raison pour laquelle ce critère a été choisi est qu’il fonctionne en tandem avec le MMLU. Alors que le MMLU évalue les connaissances factuelles, le HS évalue si le LLM serait capable d’utiliser ces connaissances factuelles pour vous fournir des réponses cohérentes et sensées.

Une bonne façon de visualiser l’utilisation de MMLU et HS est d’imaginer le monde dans lequel nous vivons aujourd’hui. Nous avons des ingénieurs et des développeurs qui possèdent une grande compréhension et des connaissances techniques, mais qui n’ont aucun moyen de les communiquer correctement en raison des barrières linguistiques et sociales. Pour cette raison, nous avons des consultants et des gestionnaires qui ne possèdent peut-être pas des connaissances aussi approfondies, mais qui ont la capacité d’organiser et de communiquer les connaissances des ingénieurs de manière cohérente et concise.

Dans ce cas, le MMLU représente l’ingénieur, tandis que le HS joue le rôle du consultant. L’un évalue les connaissances, tandis que l’autre évalue la communication.

HumanEval (HE)

Alors que le MMLU et le HS évaluent la capacité du LLM à raisonner et à répondre avec précision, HumanEval est le benchmark le plus populaire pour évaluer uniquement la capacité du LLM à générer du code utilisable pour 164 scénarios différents. Contrairement aux deux précédents, HumanEval n’est pas basé sur des questions à choix multiple et permet au LLM de générer sa propre réponse. Cependant, toutes les réponses ne sont pas acceptées par le benchmark. Chaque fois qu’un LLM est invité à coder une solution pour un scénario, HumanEval teste le code du LLM avec une variété de tests et de cas limites. Si l’un de ces tests échoue, le LLM échoue également.

De plus, HumanEval exige que le code généré par le LLM soit optimisé en termes de temps et d’espace. Ainsi, si un LLM propose un certain algorithme alors qu’un algorithme plus optimal est disponible, il perd des points. Pour cette raison, HumanEval teste également la capacité du LLM à comprendre précisément la question et à y répondre de manière exacte.

HumanEval est un benchmark important, même pour les cas d’utilisation non techniques, car il reflète de manière indirecte la sophistication et la qualité générales d’un LLM. Pour la plupart des modèles, le public cible est composé de développeurs et des passionnés de technologie. Pour cette raison, il existe une forte corrélation positive entre des scores élevés à HumanEval et des scores élevés dans de nombreux autres benchmarks, ce qui indique que le modèle est de haute qualité. Cependant, il est important de garder à l’esprit qu’il s’agit simplement d’une corrélation, et non d’une causalité, ce qui signifie que les choses pourraient évoluer à mesure que les modèles commencent à cibler de nouveaux utilisateurs.

Chatbot Arena

Figure 4 : exemple de l’interface Chatbot Arena

Figure 5 : classement Chatbot Arena, juillet 2024

Contrairement aux trois benchmarks précédents, Chatbot Arena n’est pas un benchmark objectif, mais un classement subjectif de tous les LLM disponibles sur le marché. Chatbot Arena recueille les votes des utilisateurs et détermine quel LLM offre la meilleure expérience utilisateur globale, y compris la capacité à maintenir des dialogues complexes, comprendre les demandes des utilisateurs et d’autres facteurs de satisfaction client. La nature subjective de Chatbot Arena en fait le meilleur benchmark pour évaluer l’expérience utilisateur finale. Cependant, cette subjectivité le rend également non reproductible et difficile à quantifier réellement.

Les classements actuels placent GPT-4o d’OpenAI en tête de liste avec une marge importante par rapport à la deuxième place. Ce classement est très pertinent puisqu’il est basé sur l’opinion de 1,3 million de votes d’utilisateurs.Cependant, ces votants proviennent principalement d’un milieu technologique, et le classement pourrait donc être biaisé en faveur des modèles ayant de meilleures compétences en codage.

Les classements sont établis sur la base du système ELO, un système à somme nulle où les modèles gagnent des points ELO en produisant des réponses meilleures que celles de leur modèle concurrent, tandis que ce dernier perd des points ELO.

Évaluation globale des benchmarks

Les benchmarks peuvent présenter des biais et des limites internes. Ils peuvent être utilisés conjointement pour mieux représenter les capacités du modèle. Les modèles plus récents bénéficient d’avantages en raison de leur architecture, de la taille de leurs données d’entraînement et de la divulgation des questions de benchmark.

Les trois benchmarks mentionnés plus un (Chatbot Arena) sont les plus populaires et les plus utilisés dans la recherche pour comparer les LLM. La combinaison de ces benchmarks (MMLU, HellaSwag, HumanEval et Chatbot Arena) évalue de nombreux aspects du LLM, de sa compréhension factuelle et de sa cohérence, à ses compétences en codage et à l’expérience utilisateur. C’est pourquoi, ces quatre benchmarks sont largement utilisés dans de nombreux classements en ligne, car ils reflètent véritablement la nature du LLM.

Cependant, il est important de considérer que les modèles LLM les plus récents bénéficient d’un avantage considérable pour deux raisons principales :

1. Ils sont construits sur des architectures plus robustes, disposent de meilleures technologies sous-jacentes et ont accès à davantage de données pour l’entraînement en raison de dates limites plus récentes et d’une capacité matérielle plus grande.
2. De nombreuses questions des benchmarks mentionnés précédemment ont été divulguées dans les données d’entraînement des modèles.

Néanmoins, il existe de nombreux autres benchmarks disponibles sur Internet qui évaluent différents aspects des LLM et sont souvent utilisés ensemble pour offrir une vue complète de la performance du modèle.

Facteurs, Benchmarks et comment choisir votre LLM

En utilisant les facteurs et benchmarks mentionnés, vous pouvez comparer efficacement les LLM de manière quantifiable et objective, ce qui vous aidera à prendre une décision éclairée et à choisir le modèle le plus optimal pour vos besoins professionnels et vos tâches.

De plus, chacun des benchmarks mentionnés possède des points forts et des faiblesses qui les rendent uniques et efficaces dans différents aspects. Chez Wavestone, nous reconnaissons cependant l’importance de la diversification pour minimiser les risques. C’est pourquoi nous avons développé une liste de vérification permettant aux utilisateurs de prendre des décisions plus éclairées lors du choix d’un ensemble de benchmarks à suivre et de leur utilisation pour comparer les derniers modèles. La liste de vérification couvre une grande variété de domaines, de benchmarks et de facteurs, offrant à l’utilisateur final un contrôle plus granulaire sur son choix de benchmarks.

Cet outil, qui est également un suivi des priorités, permet aux utilisateurs d’attribuer différents poids aux benchmarks afin de refléter avec précision leurs besoins professionnels et la nature des tâches. Par exemple, un consultant pourrait privilégier la multi-modalité pour l’analyse de diagrammes et de graphiques par rapport aux compétences mathématiques, et ainsi attribuer un poids plus élevé à la multi-modalité

Réflexions finales

Dans le paysage en évolution rapide des LLM, comprendre les nuances entre les différents modèles et leurs capacités est crucial. Avant de considérer un LLM, plusieurs facteurs doivent être pris en compte, tels que la date limite de connaissance, la confidentialité des données, la vitesse, la taille des paramètres, la fenêtre contextuelle et la multimodalité. Une fois ces facteurs examinés, les utilisateurs peuvent consulter différents benchmarks pour prendre une décision plus éclairée. Ceux abordés dans cet article, à savoir MMLU, HellaSwag, HumanEval et Chatbot Arena, offrent un système robuste pour évaluer quantitativement ces modèles dans divers domaines.

En conclusion, la course à l’IA ne consiste pas seulement à développer de meilleurs modèles, mais aussi à tirer parti de ces modèles de manière efficace. Le choix du LLM le plus optimal n’est pas un sprint mais un marathon, nécessitant un apprentissage continu, une adaptation et une prise de décision stratégique à travers le benchmarking et les tests. Alors que nous continuons à explorer le potentiel des LLM, rappelons-nous que la véritable mesure du succès ne réside pas dans la sophistication de la technologie, mais dans sa capacité à ajouter de la valeur à notre travail et à nos vies.

Remerciements

Nous remercions Awwab Kamel Hamam pour son travail dans la rédaction de cet article.

Lectures complémentaires et références

[1] D. Hendrycks et al., “Measuring Massive Multitask Language Understanding.” arXiv, 2020. doi: 10.48550/ARXIV.2009.03300. Disponible sur : https://arxiv.org/abs/2009.03300 
[2] D. Hendrycks et al., “Aligning AI With Shared Human Values.” arXiv, 2020. doi: 10.48550/ARXIV.2008.02275. Disponible sur : https://arxiv.org/abs/2008.02275
[3] M. Chen et al., “Evaluating Large Language Models Trained on Code.” arXiv, 2021. doi: 10.48550/ARXIV.2107.03374. Disponible sur : https://arxiv.org/abs/2107.03374
[4] R. Zellers, A. Holtzman, Y. Bisk, A. Farhadi, and Y. Choi, “HellaSwag: Can a Machine Really Finish Your Sentence?” arXiv, 2019. doi: 10.48550/ARXIV.1905.07830. Disponible sur : https://arxiv.org/abs/1905.07830
[5] W.-L. Chiang et al., “Chatbot Arena: An Open Platform for Evaluating LLM by Human Preference.” arXiv, 2024. doi: 10.48550/ARXIV.2403.04132. Disponible sur : https://arxiv.org/abs/2403.04132

Cet article Quel LLM vous convient ? Optimiser l’utilisation des benchmarks des LLM en interne. est apparu en premier sur RiskInsight.

Alors que l’Intelligence Artificielle est de plus en plus présente dans notre quotidien, des inquiétudes concernant l’éthique de cette technologie se font entendre de la part du secteur public ainsi que du secteur privé à propos de la vie privée, les biais, la responsabilité et la transparence.

Aujourd’hui, alors que les gouvernements rédigent activement des orientations et des législations sur l’IA, les responsables politiques font face au défi de trouver un équilibre entre encourager l’innovation et garantir la responsabilité. Un cadre réglementaire qui privilégie l’innovation mais s’appuie trop fortement sur l’autorégulation du secteur privé pourrait conduire à un manque de surveillance et de responsabilité. En revanche, tandis que des garde-fous robustes sont essentiels pour atténuer les risques, une approche trop restrictive pourrait ralentir le progrès technologique.

Cet article explorera les approches proposées par les gouvernements des États-Unis et du Royaume-Uni en ce qui concerne la gouvernance de l’IA dans les secteurs public et privé.

L’approche américaine envers la régulation de l’IA

En octobre 2023, la Maison Blanche a publié l’“AI Executive Order”. L’ordonnance spécifie les principales priorités à court terme. Elle introduit l’obligation de produire des rapports pour les développeurs d’IA dépassant une certaine puissance de calculs, le lancement d’initiatives de recherche, le développement de projets pour une utilisation responsable de l’IA et l’établissement d’une gouvernance de l’IA au sein du gouvernement fédéral. Les efforts à plus long terme se concentrent sur la coopération internationale, les normes mondiales et la sécurité de l’IA.

Concernant la garantie de responsabilité, l’ordonnance demande au Secrétaire au Commerce d’appliquer les dispositions de déclaration aux :

• Entreprises qui développent des modèles fondamentaux d’IA à double usage
• Organisations qui achètent des clusters informatiques à grande échelle
• Fournisseurs d’infrastructures IaaS qui permettent à des entités étrangères de mener certains entraînements de modèles d’IA.

Bien que ces critères excluent probablement la plupart des petites et moyennes entreprises de ces directives, les acteurs majeurs du domaine comme Open AI, Anthropic et Meta pourraient être affectés s’ils dépassent le seuil de calcul établi par l’ordonnance.

En parallèle, d’autres sections de l’ordonnance réaffirment l’objectif du gouvernement américain de promouvoir l’innovation et la concurrence en matière d’IA en soutenant les initiatives de R&D et les partenariats public-privé, en simplifiant les processus de visa pour attirer les talents en IA aux États-Unis, en priorisant le recrutement axé sur l’IA au sein du gouvernement fédéral et en clarifiant les problèmes de propriété intellectuelle liés à l’IA.

Dans l’ensemble, la nature des documents publiés par les États-Unis est principalement non contraignante. Cela semble indiquer une stratégie visant à encourager le secteur privé à s’autoréguler et à s’aligner sur les meilleures pratiques courantes en matière d’IA. La Maison Blanche a été constante dans son message selon lequel elle s’engage à encourager l’innovation, la recherche et le leadership dans ce domaine, tout en contrebalançant avec la nécessité d’un écosystème d’IA sécurisé et responsable.

L’approche britannique envers la régulation de l’IA

La Déclaration de Bletchley, adoptée lors du Sommet sur la Sécurité de l’IA 2023 tenu à Bletchley Park, dans le Buckinghamshire, marque un effort international pionnier visant à assurer le développement sûr et responsable des technologies d’IA. Cette déclaration représente l’engagement de 29 gouvernements dont le Royaume-Uni, les Etats-Unis, la Chine et les principaux États membres européens, à collaborer pour développer une IA centrée sur l’humain, digne de confiance et responsable. L’accent est mis sur l’IA de pointe, qui désigne des modèles d’IA très puissants et généralistes qui pourraient présenter des risques majeurs, notamment dans des domaines tels que la cybersécurité et la biotechnologie.

La déclaration souligne la nécessité pour les gouvernements de prendre des mesures proactives pour garantir le développement sûr de l’IA, reconnaissant le déploiement omniprésent de la technologie dans la vie quotidienne, y compris le logement, l’emploi, l’éducation et les soins de santé. Elle appelle au développement de politiques basées sur les risques, de métriques d’évaluation appropriées, d’outils pour les tests de sécurité, ainsi qu’à la construction de capacités pertinentes dans le secteur public et la recherche scientifique.

En prime de la déclaration, un document politique sur les « Tests de sécurité” de l’IA a également été signé par dix pays, dont le Royaume-Uni et les États-Unis, ainsi que par des grandes entreprises technologiques. Ce document donne un cadre général pour le test des modèles d’IA de nouvelle génération par les agences gouvernementales, promeut la coopération internationale et permet aux agences gouvernementales de développer leurs propres approches en matière de réglementation de la sécurité de l’IA.

Les principaux enseignements de la Déclaration de Bletchley envoient un signal clair des gouvernements concernant l’urgence de s’intéresser au développement d’une IA sûre. Cependant, la manière dont ces engagements se traduiront par des propositions législatives spécifiques et le rôle de l' »AI Safety Institute “(AISI) récemment annoncé dans le paysage réglementaire du Royaume-Uni restent à voir. La mission de l’AISI est de limiter les surprises liées aux avancées rapides et inattendues de l’IA en se concentrant sur le test et l’évaluation des systèmes d’IA avancés, la recherche fondamentale sur la sécurité de l’IA et l’encouragement des échanges d’informations.

Alors qu’ils cherchent à s’établir en tant que leaders de l’IA dans la communauté mondiale pour tendre vers des IA de confiance, tant les États-Unis que le Royaume-Uni cherchent l’équilibre entre la promotion de l’innovation en matière d’IA et la garantie d’une gouvernance éthique. Bien que la plupart des efforts actuels se focalisent sur la proposition de lignes directrices et de cadres pour l’utilisation sûre et responsable de l’IA, la mention de réglementations futures potentielles dans les deux documents devrait servir d’incitations pour que les entreprises commencent à aligner leurs pratiques sur les principes et les recommandations énoncés.

Pour garder leur avance, les organisations devront développer des méthodologies strictes pour surveiller efficacement les risques liés à l’IA. Cela signifie qu’il faudra adapter leur stratégie d’IA pour prioriser la limitation des risques, identifier les dommages potentiels qui peuvent découler du déploiement de systèmes d’IA et se préparer aux mesures réglementaires futures en mettant en œuvre un programme de gestion des risques sécurisé et complet.

Cependant, l’approche opportuniste des États-Unis et du Royaume-Uni en matière de législation sur l’IA n’est pas suivie par tous. La Chine a opté pour une approche ciblée et évolutive en rédigeant une loi sur l’IA générative qui est entrée en vigueur en 2023. En Europe, l’AI Act montre que l’UE ne veut pas perdre le contrôle face à l’IA.

Cet article Panorama réglementaire sur l’IA dans le monde: quelles sont les approches des Etat-Unis et de l’Angleterre est apparu en premier sur RiskInsight.

Bien que les avis soient partagés entre les enthousiastes, les craintifs et les sceptiques de l’IA, les plus optimistes avancent que l’intelligence artificielle peut améliorer nos processus de travail et faciliter des actions parfois répétitives en se posant comme un facilitateur à la réalisation de nos tâches.

Mais ces avancées sont-elles applicables en matière d’IAM ? Peut-on déléguer partiellement ou entièrement la gestion de nos identités et de nos accès lorsque la protection des données des utilisateurs est devenue une préoccupation majeure ?

IA et IAM : un nouveau défi pour les entreprises

Une question fondamentale apparaît lorsqu’il s’agit de réfléchir à la relation entre IA et IAM :  dans la mesure où les systèmes IAM existent pour instaurer une confiance numérique, que ce soit envers nos collaborateurs, clients ou partenaires, est-il possible de garantir que des solutions basées sur l’IA assureront ce même niveau de confiance ?

Malgré les interrogations possibles, nous estimons qu’il est impératif d’envisager les possibilités offertes par l’IA. Les équipes IAM doivent s’ouvrir à ces nouveaux enjeux et adopter une approche de « Test & Learn » sur la base de cas d’usage concrets. La collaboration avec les éditeurs IAM, les intégrateurs ou les équipes internes Data ou IA est nécessaire afin d’explorer toutes les possibilités.

En outre, nous sommes convaincus que l’environnement actuel offre un terrain propice à l’adoption de cette approche :

• Les directions et les métiers de l’entreprise cherchent à comprendre l’impact potentiel de l’IA sur différents aspects de l’entreprise et les équipes IAM doivent être en mesure de fournir des réponses.
• Le développement des offres Cloud pour la gestion des identités et des accès, ainsi que la convergence renforcée des solutions d’Access Management (AM) et d’Identity Governance and Administration (IGA), créent un environnement favorable au développement de l’IA. Les algorithmes d’entraînement peuvent accéder à davantage de données, facilitant ainsi la production de valeur.
• Le paysage des menaces évolue toujours plus vite – avec l’IA notamment – et les équipes IAM sont confrontées à toujours plus de besoins en termes de conformité, sécurité, expérience utilisateur ou encore efficacité opérationnelle.

Il semble donc naturel de se demander si l’IA peut contribuer à résoudre ces défis en s’intéressant à des cas d’usage concrets. Dans cet article, nous allons regarder de plus près les possibilités offertes par l’IA, les leviers clés susceptibles d’être impactés par son utilisation et comment elle pourrait (ou non) changer nos modes de fonctionnement autour de l’IAM.

La contribution de l’IA aux 3 enjeux essentiels de l’IAM

L’analyse de différents cas d’usage prenant en compte l’IA pour l’IAM a été pensée autour des 3 moteurs de l’IAM :

• La cybersécurité et la conformité
• L’expérience utilisateur
• L’efficacité opérationnelle et business

Les cas d’usage présentés ci-dessous sont le fruit de la réflexion d’une quarantaine de consultants et professionnels de l’IAM amenés à s’interroger sur la contribution que peut avoir l’IA pour l’IAM au travers de différents ateliers.

Être un levier pour la cybersécurité et la conformité

Cas d’usage 1 : Vérification continue

Actuellement de nombreux mécanismes permettent de contrôler le comportement d’un utilisateur via différents critères (localisation, appareil utilisé, etc.). L’ajout de l’intelligence artificielle dans un processus de vérification en continu permettrait de maximiser le potentiel de surveillance pendant et après l’authentification de l’utilisateur en agrégeant une multitude d’informations au sujet de l’utilisateur (analyse comportementale des frappes clavier ou cliques souris, horaire habituel de connexion, comportement suspect au sein de l’application, etc.) et d’apporter une remédiation automatique adaptée (demande de réauthentification, arrêt de session, alerte aux équipes sécurité, etc.).

A l’heure actuelle, certains éditeurs proposent ou prévoient de proposer des fonctionnalités sur la vérification continue. Le but étant d’utiliser l’IA pour évaluer en continu les risques et appliquer des politiques de sécurité à la connexion, mais aussi durant la session d’un utilisateur actif. Ces fonctionnalités réduisent le risque d’accès non autorisés et les menaces dites « post-authentification », comme le détournement de session, le piratage de compte ou encore la fraude lors de l’authentification.

Cas d’usage 2 : Aide à la décision

La prise de décision peut poser des défis tant pour un manager que pour l’utilisateur lui-même, notamment lorsqu’il s’agit d’assigner ou de demander des droits.

Les managers, par exemple, peuvent ne pas toujours avoir une connaissance approfondie des droits spécifiques à accorder à un membre de leur équipe, et il peut être nécessaire de solliciter de l’aide pour déterminer la meilleure approche lors de l’attribution de ces droits.

De plus, la revue des droits est un processus généralement peu apprécié par les différents métiers, d’autant plus lorsqu’elle est faite de manière manuelle. Les managers peuvent parfois opter pour une validation des droits de leur équipe « par défaut » par manque de temps ou de connaissance.

C’est là que l’intelligence artificielle peut intervenir en offrant une assistance rapide et efficace aux responsables concernés. Elle peut ainsi fournir des recommandations pour un utilisateur en tenant compte de divers facteurs tels que le nombre de personnes de son équipe ayant des droits similaires, les droits récemment attribués aux collaborateurs travaillant avec lui ou encore les droits requis pour son activité. Cette assistance dans l’attribution des droits et des accès ainsi que dans leur revue constitue une orientation précieuse pour les responsables. Elle permet de renforcer la légitimité des droits d’accès des utilisateurs ainsi que la sécurité.

Notons que l’aide à la décision basée sur l’IA fait partie des cas d’usage les plus mis en avant par les éditeurs en ce moment.

Améliorer l’expérience utilisateur

Cas d’usage 3 : Documentation des droits accès

Il est essentiel pour les utilisateurs d’avoir une compréhension exhaustive et détaillée de leurs autorisations et de leurs accès. Cela leur permet non seulement de connaître leurs droits d’accès, mais aussi d’identifier les éventuels manques au sein de leurs activités. Une simple liste de droits peut parfois être peu explicite pour la plupart des utilisateurs. Cependant, l’utilisation de l’intelligence artificielle générative pourrait permettre la création rapide d’un schéma « intelligent », offrant une visualisation claire des droits accessibles à l’utilisateur, avec une distinction visuelle selon certains critères tels que :

• Le niveau de droits (consultation, modification, administration, etc.)
• Le domaine d’application (gestion des achats, validation des paiements, etc.)
• La criticité du droit
• La durée de validité des droits
• Les conditions d’octroi des droits (cycle d’approbation)
• L’historique des droits utilisés

Ainsi, l’IA pourrait grandement faciliter la compréhension des droits par les utilisateurs en offrant une vision claire, structurée et contextualisée de leurs autorisations.

Cas d’usage 4 : Autorisation dynamique

Se retrouver bloquer par manque de droits pour accéder à un document, une application ou un groupe SharePoint n’est pas une situation anodine et peut fortement nuire à l’expérience utilisateur, d’autant plus lorsque les délais de traitement sont importants. Cependant, lorsque les ressources accédées ne sont pas critiques, l’intelligence artificielle a un vrai rôle à jouer afin d’automatiser l’accès de manière efficace. Par exemple, basé sur le fait que des personnes de la même équipe ou travaillant sur le même projet aient certains accès, l’IA pourrait temporairement accorder l’accès à un utilisateur pour éviter tout blocage. En parallèle, des suggestions pourraient être proposées à l’utilisateur afin d’effectuer la demande et avoir un accès prolongé.

Par ailleurs, cette approche dynamique de l’autorisation peut présenter des avantages en termes d’économie de licences. Si l’attribution d’un droit dans une application nécessite l’utilisation d’une licence, une attribution temporaire (« juste à temps ») permet à l’utilisateur de n’utiliser la licence que pendant la durée nécessaire à ses tâches, avant de la réattribuer à un autre utilisateur. Au-delà de l’amélioration de l’expérience utilisateur, cette approche peut également générer des économies budgétaires significatives.

Être un facilitateur business et améliorer l’efficacité

Cas d’usage 5 : Automatisation des droits d’arrivée

Les processus Joiner-Mover-Leaver (JML) revêtent une importance cruciale au sein des processus IAM des entreprises. Ils visent entre autres à contrôler et à faciliter les changements de statut d’un utilisateur conformément à un ensemble de règles définies. Cela inclut notamment l’activation ou la désactivation des accès et l’attribution du niveau de droits approprié en suivant le principe du moindre privilège, par exemple, en supprimant les droits obsolètes à la suite d’une mobilité interne.

L’utilisateur ne doit donc pas être « bloqué » (par manque ou absence de droits) lors de son arrivée ou lors d’une mobilité, car cela impacterait fortement ses activités.

L’intelligence artificielle pourrait jouer un rôle majeur dans ces processus JML en analysant le passé des utilisateurs occupant un même poste/service, ayant déjà reçu un ensemble de droits à leur arrivée. Ces analyses pourraient générer des suggestions de droits et d’accès à attribuer à un nouvel arrivant dans le même service. De plus, l’intelligence artificielle pourrait proposer des améliorations pour les processus de mobilité en suggérant un ensemble de droits correspondant aux rôles attribués dans le nouveau service, voire même faciliter l’évolution des rôles métiers en proposant des modifications de leurs compositions.

Cas d’usage 6 : Support IAM

Les chatbots interactifs gagnent une place croissante au sein des entreprises en assistant les utilisateurs dans divers processus tels que la création d’incidents ou la recherche de documents.

Toutefois, grâce à l’intelligence artificielle, ces chatbots pourraient également apporter un soutien précieux aux équipes de cybersécurité et de support en accélérant la récupération d’informations. Par exemple, les équipes de cybersécurité pourraient demander au chatbot de fournir toutes les autorisations sensibles d’un utilisateur, tandis que les équipes de support pourraient demander pourquoi un utilisateur est en attente d’habilitation pour une application.

Le temps considérable actuellement consacré par ces équipes à rechercher les informations pertinentes, à récupérer les bons tickets d’incident et à examiner l’historique des utilisateurs pourrait ainsi être significativement réduit. Ces chatbots seraient en mesure d’interroger les solutions IAM, les outils de gestion des incidents et d’autres outils de l’entreprise pour récupérer les données nécessaires. Cela permettrait ainsi aux équipes de se concentrer sur des tâches à plus forte valeur ajoutée et de résoudre les incidents de manière plus efficace.

***

Loin d’être exhaustifs, ces quelques exemples illustrent la diversité des domaines d’application de l’IA au sein de l’IAM. D’autres cas d’usage pourraient également tirer partie de l’IA, tels que :

• La détection de droits d’accès incompatibles (Segregation of Duties) : Suggérer des droits incompatibles suivant les activités de l’entreprise, identifier de manière proactive les conflits dans les autorisations des utilisateurs et proposer des remédiations.
• L’optimisation de la qualité des données : Améliorer la qualité des données en effectuant des rapprochements automatiques d’un grand nombre de données, en corrigeant les doublons ou les données orphelines, en signalant les divergences ou les volumes anormaux, en nettoyant automatiquement les données et en les corrigeant.
• La vérification de la conformité du système IAM : Évaluer la configuration du système IAM par rapport aux normes, aux meilleures pratiques, aux recommandations des fournisseurs et aux observations externes, et proposer des suggestions pour renforcer la sécurité.

Il est important de noter que la facilité de mise en œuvre et l’intérêt pour l’ensemble des cas d’usage mentionnés varient selon les secteurs d’activité des entreprises. Par exemple, dans le secteur industriel, l’accent peut être mis sur l’efficacité des processus et la sécurité, au détriment parfois de l’expérience utilisateur, en raison de processus complexes et historiques reposant sur des technologies plus anciennes.

Pour autant, dans le cadre des ateliers organisés autour des sujets IA et IAM,  voici ce qu’il ressort en termes d’estimation de la faisabilité et de la valeur ajoutée sur les 9 cas d’usage présentés précedemment :

Que peut-on espérer à l’avenir ?

L’IA permet et va permettre de plus en plus de répondre aux 3 piliers de l’IAM (sécurité & conformité, expérience utilisateur et efficacité opérationnelle). Certains cas d’usage sont déjà proposés par des éditeurs et vont continuer d’évoluer, d’autres sont sur leur feuille de route, et d’autres encore se limitent à des contraintes techniques et restent pour l’instant au stade d’ambitions prometteuses.

Cependant, ne s’intéresser qu’aux promesses serait se mettre des œillères, il est impératif de reconnaitre et d’anticiper d’ores et déjà les risques induits par l’utilisation de l’IA dans l’IAM : notamment la possibilité de tromper les mesures d’authentification, le développement d’attaques innovantes basées sur l’identité (phishing de haute qualité, voix modifiée, etc.) et la capacité à exploiter les données et les vulnérabilités au sein des systèmes et des politiques IAM. On peut également craindre une prise de décision biaisée dans l’octroi des accès ou encore la gestion des accès d’une IA qui doit être interconnectée de toute part. Ces risques sont également complétés par les risques inhérents à l’IA : corruption des données en sortie, vol d’informations en comprenant les limites/faiblesses du modèle IA, possibilité de tromper la capacité de reconnaissance de l’IA… Ces risques ont été abordés de manière plus approfondie dans un autre article que nous vous conseillons : Sécuriser l’IA : Les nouveaux Enjeux de Cybersécurité.

En raison des risques associés, du manque de réglementation, du rôle fondamental de l’IAM et d’une forte dépendance au contexte de chaque entreprise, la tendance actuelle en matière d’IA dans l’IAM penche davantage vers la suggestion et l’aide à la décision plutôt que vers une prise de décision autonome, mais pour combien de temps ? L’émergence rapide de l’IA et son intégration de plus en plus fréquente dans notre paysage amènent à se demander combien de temps nous avons avant de devoir faire confiance à l’IA pour avoir le bon niveau de réactivité, de détection et de résolution… pour faire face à l’IA. 

Cet article L’intelligence artificielle, une révolution pour l’IAM ? est apparu en premier sur RiskInsight.

Bien qu’il y ait eu des avancées significatives en la matière, il existe également des défis. Par exemple, des données sensibles de Samsung ont été exposées sur ChatGPT par des employés (l’intégralité du code source d’un programme de téléchargement d’une base de données)[1]. Pour ne rien arranger, ChatGPT [OpenAI], a subi une faille de sécurité qui a touché plus de 100 000 utilisateurs entre juin 2022 et mai 2023, et les informations d’identification compromises sont désormais échangées sur le Dark Web[2].

Ainsi, il n’est par surprenant qu’il y ait à la fois de l’enthousiasme et de la prudence à l’égard du potentiel de l’IA générative. Compte tenu de ces complexités, il est compréhensible que de nombreuses personnes soient confrontées à la difficulté de déterminer l’approche optimale de l’IA. Dans cette optique, cet article cherche à répondre aux questions les plus posées par nos clients.

Question 1 : L’IA générative n’est-elle qu’un effet de mode ?

L’IA est un ensemble de théories et de techniques mises en œuvre afin de créer des machines capables de simuler les fonctions cognitives de l’intelligence humaine (vision, écriture, mouvement…). Un sous-domaine de l’IA, particulièrement intéressant, est « l’IA générative ». Elle peut être définie comme une discipline utilisant des algorithmes avancés, notamment les réseaux de neurones artificiels, pour générer de manière autonome du contenu, qu’il s’agisse de textes, d’images ou de musique. Au-delà du chatbot bancaire qui répondant à vos interrogations, l’IA générative ne se limite pas à reproduire nos capacités de manière impressionnante, elle les améliore dans certains cas.

Notre observation du marché indique que : la portée de l’IA générative est large et profonde. Elle contribue à divers domaines tels que la création de contenu, l’analyse de données, la prise de décision, le support client et même la cybersécurité (par exemple, en identifiant des structures de données anormales pour contrer les menaces). Nous avons identifié trois domaines dans lesquels l’IA générative est particulièrement utile.

Personnalisation du marketing et de l’expérience client

L’IA générative permet de mieux comprendre les comportements et les préférences des clients. En analysant les modèles de données, elle permet aux entreprises d’élaborer des messages et des visuels sur mesure, améliorant ainsi l’engagement et garantissant des interactions personnalisées.

Solutions no-code et amélioration du support client

Dans un monde numérique en constante évolution, les concepts de solutions no-code et d’amélioration du service client sont de plus en plus mis en avant. Bouygues Telecom est un bon exemple d’entreprise exploitant des outils avancés. Ils analysent activement les interactions vocales enregistrées lors de conversations entre les conseillers et les clients, dans le but d’améliorer la relation client[3]. Dans le même registre, Tesla utilise l’outil d’IA « Air AI » pour une interaction fluide avec les clients, qui permet de gérer les appels commerciaux avec des clients potentiels, allant même jusqu’à programmer des essais de conduite.  

En ce qui concerne la programmation, une expérience intéressante menée par l’un de nos clients se démarque. Impliquant 50 développeurs, le test a révélé que 25% des suggestions de code générées par l’IA ont été acceptées, entraînant une augmentation de 10% de la productivité. Cependant, il est encore tôt pour conclure sur l’efficacité réelle de l’IA générative en matière de programmation, mais les premiers résultats sont prometteurs et devraient s’améliorer. De plus, le problème lié aux droits de propriété intellectuel concernant le code généré par l’IA demeure un sujet de discussion.

Veille documentaire et outil de recherche

L’utilisation de l’IA en tant qu’outil de recherche peut permettre de gagner des heures de travail, notamment dans les domaines où les corpus réglementaires et documentaires sont vastes (ex : secteur financier). Chez Wavestone, nous avons développé en interne, deux outils d’IA. Le premier, CISO GPT, permet aux utilisateurs de poser des questions spécifiques sur la sécurité dans leur langue maternelle. Une fois la question posée, l’outil parcourt la documentation afin d’extraire et de présenter les informations pertinentes. Le second outil, la bibliothèque de références GPT, fournit des CV d’employés de Wavestone ainsi que des références relatives à des missions antérieures pour la rédaction de propositions commerciales.

Cependant, bien que des outils comme ChatGPT (qui utilise des données provenant de bases de données publiques) soient indéniablement bénéfiques, c’est lorsque les entreprises exploitent leurs propres données qu’elles peuvent changer la donne. Pour cela, les entreprises doivent intégrer des capacités d’IA générative en interne ou mettre en place des systèmes assurant la protection de leurs données (comme des solutions cloud telles qu’Azure OpenAI ou des modèles propriétaires). Selon nous, l’IA générative vaut plus que le simple buzz qui l’entoure et est destinée à s’installer durablement. Il existe de réelles applications commerciales et une véritable valeur ajoutée, mais également des risques de sécurité. Votre entreprise doit initier cette dynamique pour pouvoir mettre en œuvre des projets d’IA générative de manière sécurisée.

Question 2 : Quelle est la réaction du marché à l’utilisation de ChatGPT ?

Pour approfondir le point de vue de ceux qui sont en première ligne en matière de cybersécurité, nous avons demandé aux CISO de nos clients leur avis sur les implications et les opportunités de l’IA générative. Par conséquent, le graphique ci-dessous illustre les opinions des CISO sur le sujet.

Selon notre enquête, les retours des CISO peuvent être regroupés en trois catégories distinctes :

Les pragmatiques (65%)

La plupart de nos répondants reconnaissent les risques potentiels de fuite de données avec ChatGPT, mais les assimilent aux risques rencontrés sur les forums ou lors d’échanges sur des plateformes telles que Stack Overflow (pour les développeurs). Ils estiment que le risque de fuites de données n’a pas changé de manière significative avec ChatGPT. Cependant, le buzz actuel justifie des campagnes de sensibilisation dédiées pour souligner l’importance de ne pas utiliser des données spécifiques à l’entreprise ou des données sensibles.

Les visionnaires (25%)

Un quart des personnes interrogées considère ChatGPT comme un outil révolutionnaire. Ils ont constaté son adoption dans des départements tels que la communication et les services juridiques. Ils ont pris des mesures proactives pour comprendre son utilisation (quelles données, quel cas d’usage) et ont ensuite établi un ensemble de lignes directrices. Il s’agit d’une approche plus collaborative pour définir un cadre d’utilisation.

Les sceptiques (10%)

Une partie du marché émet des réserves concernant ChatGPT. Pour eux, il s’agit d’un outil trop facile à utiliser à mauvais escient, qui fait l’objet d’une attention médiatique excessive et qui comporte des risques inhérents selon divers secteurs d’activité. Ainsi, en fonction de votre activité, cela peut être pertinent lorsque vous jugez que le risque de fuite de données et de perte de propriété intellectuelle est trop élevé par rapport aux bénéfices potentiels.

Question 3 : Quels sont les risques liés à l’IA générative ? 

En évaluant les différents points de vue sur l’IA générative au sein des organisations, nous avons classé les préoccupations en quatre catégories distinctes de risques, du moins grave au plus critique :

Altération et dénaturation du contenu

Les organisations utilisant l’IA générative doivent protéger l’intégrité de leurs systèmes intégrés. Lorsque l’IA est manipulée de manière malveillante, cela peut conduire à la déformation de contenu authentique, conduisant à la désinformation. Cela peut produire des résultats biaisés, ce qui nuit à la fiabilité et à l’efficacité des solutions basées sur l’IA. Plus spécifiquement, pour les grands modèles de langage (Large Language Models – LLM) comme l’IA générative, il existe une préoccupation notable concernant l’injection d’invite (prompt injection). Pour atténuer cela, les organisations devraient :

1. Développer un système de classification des entrées (inputs) malveillantes qui évalue la légitimité de l’entrée d’un utilisateur, en veillant à ce que seuls les prompts légitimes soient traités.
2. Limiter la taille et modifier le format des entrées utilisateur. En ajustant ces paramètres, les chances de réussite de l’injection d’invite sont considérablement réduites.

Menaces de tromperie et de manipulation

Même si une organisation décide d’interdire l’utilisation de l’IA générative, elle doit rester vigilante face à l’augmentation potentielle de l’hameçonnage, des escroqueries et des attaques de type « deepfake ». Bien que ces menaces existent depuis un certain temps dans le domaine de la cybersécurité, l’introduction de l’IA générative intensifie leur fréquence et leur sophistication.

Ce potentiel est clairement illustré par une série d’exemples frappants. Ainsi, Deutsche Telekom a publié une vidéo de sensibilisation montrant la capacité de l’IA générative à vieillir l’image d’une jeune fille à partir de photos/vidéos disponibles sur les réseaux sociaux.

De plus, HeyGen est un logiciel d’IA générative capable de doubler des vidéos dans plusieurs langues tout en conservant la voix originale. Il est désormais possible d’entendre Donald Trump s’exprimer en français ou Charles de Gaulle converser en portugais.

Ces exemples illustrent clairement comment les attaquants peuvent exploiter ces outils pour imiter la voix d’un PDG, élaborer des emails d’hameçonnage convaincants ou créer des vidéos « deepfake » d’un réalisme saisissant, ce qui intensifie les défis en matière de détection et de défense.

Pour plus d’informations sur l’utilisation de l’IA générative par les cybercriminels, consultez l’article dédié sur RiskInsight.

Confidentialité des données et protection de la vie privée

Si les organisations décident d’autoriser l’utilisation de l’IA générative, elles doivent être conscientes que les immenses capacités de traitement de données offertes par cette technologie peuvent engendrer des risques non négligeables en matière de confidentialité et de protection de la vie privée. Ces modèles, bien qu’excellents dans la génération de contenu, sont susceptibles de divulguer des données d’entraînement sensibles ou de reproduire des contenus soumis au droit d’auteur.

De plus, en ce qui concerne la protection des données personnelles, si l’on se réfère à la politique de confidentialité de ChatGPT, le chatbot est susceptible de collecter des informations comme les détails du compte, les données d’identification provenant de votre appareil ou navigateur, ainsi que les informations saisies dans le chatbot (qui pourraient être utilisées pour entraîner l’IA générative)[4]. Selon l’article 3(a) des conditions générales d’Open AI, les entrées et sorties (inputs/outputs), appartiennent à l’utilisateur. Cependant, étant donné que ces données sont stockées et enregistrées par OpenAI, des préoccupations émergent quant à la propriété intellectuelle et aux éventuelles fuites de données (comme mentionné supra dans le cas de Samsung). Ces risques peuvent nuire considérablement à la réputation et à l’activité d’une organisation.

C’est pour ces raisons qu’OpenAI a mis en place l’abonnement ChatGPT Business, proposant un contrôle accru sur les données de l’organisation (avec, par exemple, le chiffrement AES-256 pour les données au repos, TLS 1.2+ pour les données en transit, l’authentification SSO SAML et une console d’administration dédiée)[5]. Mais en réalité, tout dépend de la confiance que vous accordez à votre fournisseur et du respect des engagements contractuels. De plus, il existe aussi la possibilité de développer ou de former des modèles d’IA internes en utilisant les données de l’organisation pour une solution adaptée aux besoins spécifiques.

Vulnérabilités des modèles et attaques

Alors que de plus en plus d’organisations utilisent des modèles d’apprentissage automatique, il est essentiel de comprendre que ces modèles ne sont pas infaillibles. Ils peuvent être confrontés à des menaces qui affectent leur fiabilité, leur précision ou leur confidentialité, comme cela sera expliqué dans la section suivante.  

Question 4 : Comment un modèle d’IA peut-il être attaqué ?

L’IA introduit des complexités supplémentaires qui s’ajoutent aux vulnérabilités existantes du réseau et de l’infrastructure. Il est crucial de noter que ces complexités ne sont pas spécifiques à l’IA générative, mais qu’elles sont présentes dans divers modèles d’IA. Comprendre ces modèles d’attaque est essentiel pour renforcer les défenses et garantir le déploiement sécurisé de l’IA. Il existe trois principaux modèles d’attaque (liste non exhaustive) :

Pour des informations détaillées sur les vulnérabilités des grands modèles de langage et de l’IA générative, référez-vous au “OWASP Top 10 for LLM” de l’Open Web Application Security Project (OWASP).

Attaques par évasion

Ces attaques ciblent l’IA en manipulant les entrées des algorithmes d’apprentissage automatique afin d’introduire des perturbations mineures qui entraînent des modifications significatives des sorties. De telles manipulations peuvent amener le modèle d’IA à classer de manière inexacte ou à ignorer certaines entrées. Un exemple classique serait de modifier des panneaux de signalisation pour tromper les voitures autonomes (identifier un panneau « stop » comme un panneau « priorité »). Cependant, les attaques par évasion peuvent également s’appliquer à la reconnaissance faciale. Une personne pourrait utiliser des motifs de maquillage subtils, des autocollants placés de manière stratégique, des lunettes spéciales ou des conditions d’éclairage spécifiques pour tromper le système, entraînant une mauvaise identification.

En outre, les attaques par évasion ne se limitent pas à la manipulation visuelle. Dans les systèmes de commande vocale, les attaquants peuvent intégrer des commandes malveillantes dans du contenu audio ordinaire, de manière à ce qu’elles soient imperceptibles pour les humains mais reconnaissables par les assistants vocaux. Par exemple, des chercheurs ont démontré l’existence de techniques audio contradictoires ciblant des systèmes de reconnaissance vocale utilisés dans des enceintes intelligentes, telles qu’Alexa d’Amazon. Ainsi, une chanson ou une publicité apparemment ordinaire pourrait contenir une commande dissimulée ordonnant à l’assistant vocal d’effectuer un achat non autorisé ou de divulguer des informations personnelles, le tout à l’insu de l’utilisateur[6].

Empoisonnement

L’empoisonnement est un type d’attaque dans lequel l’attaquant modifie les données ou le modèle pour influencer le comportement de l’algorithme d’apprentissage automatique (par exemple, pour saboter ses résultats ou insérer une porte dérobée). C’est comme si l’attaquant conditionnait l’algorithme en fonction de ses motivations. Ces attaques sont également appelées : attaques causatives.

Conformément à cette définition, les attaquants utilisent des attaques par empoisonnement pour orienter un algorithme d’apprentissage automatique vers un résultat souhaité. Ils introduisent des échantillons malveillants dans l’ensemble des données d’apprentissage, ce qui conduit l’algorithme à se comporter de manière imprévisible. Un exemple connu est celui du chatbot de Microsoft, TAY, qui a été dévoilé sur Twitter en 2016. Conçu pour imiter les adolescents américains et converser avec eux, il s’est rapidement mis à agir comme un activiste d’extrême droite[7]. Cela souligne le fait que, dans leurs premières phases d’apprentissage, les systèmes d’IA sont sensibles aux données qu’ils rencontrent. Les utilisateurs de 4Chan ont intentionnellement empoisonné les données de TAY avec leur humour et leurs conversations controversées.

Toutefois, l’empoisonnement des données peut également être involontaire et résulter de préjugés inhérents aux sources de données ou de préjugés inconscients de ceux qui organisent les ensembles de données. Cela s’est manifesté lorsque les premières technologies de reconnaissance faciale ont eu des difficultés à identifier les teints de peau plus foncés. Il est donc nécessaire de disposer de données d’entraînement diversifiées et non-biaisées pour se prémunir contre les distorsions délibérées ou involontaires des données.

Enfin, la prolifération en ligne d’algorithmes d’IA en open source, tels que ceux présents sur des plateformes comme Hugging Face, présente un autre risque. Les acteurs malveillants pourraient modifier et empoisonner ces algorithmes pour favoriser des biais spécifiques, conduisant des développeurs peu méfiants à intégrer par inadvertance des algorithmes corrompus dans leurs projets, perpétuant ainsi les biais ou les intentions malveillantes.

Attaque oracle

Ce type d’attaque consiste à tester/sonder un modèle avec une série d’entrées soigneusement conçues, tout en analysant les sorties. Grâce à l’application de diverses stratégies d’optimisation et à des requêtes répétées, les attaquants peuvent déduire des informations confidentielles, mettant ainsi en péril la vie privée des utilisateurs, la sécurité globale du système où les règles de fonctionnement internes.

Un exemple pertinent est celui du chatbot Bing de Microsoft, alimenté par l’IA. Peu après son lancement, un étudiant de Stanford, Kevin Liu, a exploité le chatbot à l’aide d’une attaque par injection d’invite, l’amenant à révéler ses directives internes et son nom de code « Sidney », alors que l’une des règles fondamentales du système était de ne jamais révéler ce type d’informations[8].

Un précédent article de RiskInsight présentait un exemple d’attaque oracle et par évasion, ainsi que d’autres types d’attaques qui, bien que non spécifiques à l’IA, représentent néanmoins un risque important pour ces technologies.

Question 5 : Quel est l’état de la réglementation ? Comment l’IA générative est-elle réglementée ?

Depuis notre article de 2022, il y a eu des développements significatifs dans la réglementation de l’IA à travers le monde.

L’Union Européenne (UE)

L’objectif de la stratégie numérique de l’UE est de réguler l’IA, en garantissant son développement innovant et son utilisation, tout en assurant la sécurité et les droits fondamentaux des individus et des entreprises vis-à-vis de l’IA. Le 14 juin 2023, le Parlement européen a adopté et amendé la proposition de règlement sur l’Intelligence Artificielle, qui catégorise les risques liés à l’IA en quatre niveaux distincts : inacceptable, élevé, limité et minimal[9].

États-Unis

Le Bureau de la politique scientifique et technologique de la Maison Blanche, guidé par les perspectives de diverses parties prenantes, a présenté le « Blueprint for an AI Bill of Rights »[10]. Bien que non contraignant, ce document souligne l’engagement en faveur des droits civiques et des valeurs démocratiques dans la gouvernance et le déploiement de l’IA.

Chine

Compte tenu des préoccupations croissantes en matière d’IA, l’administration chinoise du cyberespace a proposé des mesures administratives pour les services d’intelligence artificielle générative. Visant à protéger les intérêts nationaux et à préserver les droits des utilisateurs, ces mesures offrent une approche holistique de la gouvernance de l’IA. Elles ont pour but d’atténuer les risques potentiels associés aux services d’intelligence artificielle générative, tels que la diffusion de fausses informations, les violations de la vie privée, les atteintes à la propriété intellectuelle et la discrimination. Toutefois, la portée territoriale de ces mesures pourrait poser problème aux fournisseurs étrangers de services d’IA en Chine[11].

Royaume-Uni

Le Royaume-Uni emprunte une voie distincte, en mettant l’accent sur une approche pro-innovation dans sa stratégie nationale en matière d’IA. Le Département pour la Science, l’Innovation et la Technologie a publié un livre blanc intitulé « AI Regulation: A Pro-Innovation Approach », axé sur le développement par le biais de réglementations minimales et d’investissements accrus dans l’IA. Le cadre britannique ne prescrit pas de règles ou de niveaux de risque à des secteurs ou technologies spécifiques. Il se focalise plutôt sur la réglementation des résultats générés par l’IA dans des applications précises. Cette approche est guidée par cinq principes fondamentaux : la sûreté & la sécurité, la transparence, l’équité, la responsabilité & la gouvernance, et la contestabilité & la réparation[12].

Cadres de référence

Au-delà des règlementations formelles, plusieurs documents d’orientation existent, tels que le cadre de gestion des risques associés à l’IA du NIST et la norme ISO/IEC 23894. Ces textes fournissent des recommandations pour la gestion des risques liés à l’IA, se concentrant sur des critères destinés à instaurer la confiance dans les algorithmes. En fin de compte, l’enjeu ne se limite pas à la cybersécurité, il s’agit aussi et surtout de confiance.

Avec un paysage réglementaire aussi vaste, les organisations peuvent se sentir dépassées. Pour les aider, nous suggérons de se concentrer sur des considérations clés lors de l’intégration de l’IA dans leurs opérations, afin d’établir une feuille de route pour atteindre la conformité.

• Identifier tous les systèmes d’IA existants au sein de l’organisation et établir une procédure ou un protocole pour identifier les nouvelles initiatives en matière d’IA.
• Évaluer les systèmes en utilisant des critères dérivés de cadres de référence, tels que le NIST.
• Classer les systèmes d’IA selon la classification du règlement sur l’IA de l’UE (inacceptable, élevé, limité, minimal).
• Déterminer l’approche de gestion des risques adaptée à chaque catégorie.

Question bonus : Cela étant dit, que puis-je faire maintenant ?

À mesure que le paysage numérique évolue, Wavestone met l’accent sur une approche globale de l’intégration de l’IA générative. Nous préconisons qu’un déploiement d’IA fasse l’objet d’une analyse de sensibilité rigoureuse, allant de l’interdiction pure et simple à une mise en œuvre guidée et une conformité stricte. Pour les systèmes classés à haut risque, il est primordial d’appliquer une analyse de risque détaillée basée sur les normes établies par l’ENISA et le NIST. Bien que l’IA introduise une couche sophistiquée, les principes fondamentaux de l’hygiène informatique ne doivent jamais être négligés. Nous recommandons l’approche suivante :

• Piloter & Valider : commencez par évaluer le potentiel de transformation de l’IA générative dans votre contexte organisationnel. De plus, il est essentiel de comprendre les outils à votre disposition, de s’orienter parmi les diverses options disponibles et de prendre des décisions éclairées en fonction des besoins spécifiques et des cas d’utilisation.
• Perspective Stratégique : Selon notre enquête auprès des CISO de nos clients, déterminez le niveau idéal d’adoption de l’IA pour votre entreprise. Vos aspirations correspondent-elles aux repères d’adoption de 10%, 65% ou 25% ?
• Atténuation des Risques : Ancrez votre stratégie dans une évaluation des risques approfondie, en adéquation avec le niveau d’adoption de l’IA que vous envisagez.
• Élaboration de Politiques : Basez-vous sur votre analyse avantages-risques pour élaborer des politiques d’IA solides et agiles.
• Apprentissage Continu & Vigilance Réglementaire : Maintenez un engagement constant pour rester au fait de l’évolution du paysage réglementaire, et tenez-vous informé des derniers outils, méthodes d’attaque et stratégies de défense.

[1] Des données sensibles de Samsung divulgués sur ChatGPT par des employés (rfi.fr)

[2] https://www.phonandroid.com/chatgpt-100-000-comptes-pirates-se-retrouvent-en-vente-sur-le-dark-web.html

[3] Bouygues Telecom mise sur l’IA générative pour transformer sa relation client (cio-online.com)

[4] Quelles données Chat GPT collecte à votre sujet et pourquoi est-ce important pour votre vie privée en ligne ? (bitdefender.fr)

[5] OpenAI lance un ChatGPT plus sécurisé pour les entreprises – Le Monde Informatique

[6] Selective Audio Adversarial Example in Evasion Attack on Speech Recognition System | IEEE Journals & Magazine | IEEE Xplore

[7] Not just Tay: A recent history of the Internet’s racist bots – The Washington Post

[8] Microsoft : comment un étudiant a obligé l’IA de Bing à révéler ses secrets (phonandroid.com)

[9] Artificial intelligence act (europa.eu)

[10] https://www.whitehouse.gov/wp-content/uploads/2022/10/Blueprint-for-an-AI-Bill-of-Rights.pdf

[11] https://www.china-briefing.com/news/china-to-regulate-deep-synthesis-deep-fake-technology-starting-january-2023/

[12] A pro-innovation approach to AI regulation – GOV.UK (www.gov.uk)

Cet article IA : Découvrez les 5 questions les plus fréquemment posées par nos clients !  est apparu en premier sur RiskInsight.

Retour en 2021. Une vidéo de Tom Cruise faisant disparaître une pièce de monnaie devient virale. C’est l’un des premiers buzz des vidéos deepfake ; des vidéos qui amusent et apeurent (à raison) les internautes. Avec les années, les intelligences artificielles sous toutes ses formes se sont perfectionnées, si bien qu’il est possible aujourd’hui par exemple de faire de la traduction en temps réel ou de générer des vidéos et audio de personnalités publiques plus vrais que nature. 

Le crime progressant avec les techniques et les technologies, l’intégration de l’IA au sein de l’arsenal du cybercriminel était somme toute assez naturelle et prévisible. Initialement utilisée pour des opérations simples comme le décryptage des captchas ou la création des premiers deep fakes, l’IA est désormais utilisée pour un éventail beaucoup plus large d’activités malveillantes. 

Dans la continuité de notre série sur la cybersécurité et l’IA (Attaquer une IA : un exemple concret, Quand les mots deviennent des armes : prompt Injection et Intelligence artificielle et ChatGPT & DevSecOps – Quels sont les nouveaux risques cybersécurité induits par l’utilisation de l’IA par les développeurs), nous explorons ici l’instrumentalisation de l’IA par les cybercriminels. Si l’IA permet une progression de la qualité des attaques cyber et de leur quantité, son utilisation par les cybercriminels ne remet pas fondamentalement en question le modèle de défense pour les organisations. 

L’utilisation malveillante de l’IA par les cybercriminels : détournement, marché noir, et DeepFake 

Le détournement des Chatbots grand public 

En 2023, impossible de passer à côté de ChatGPT, l’IA générative développée par OpenAI. Avec plus de 1,5 milliards de requêtes par jour, c’est un merveilleux outil, et les cas d’usages sont nombreux. Cette capacité et la valeur ajouté de ce type d’outil est largement exploitable par des attaquants. 

Si des mesures de sécurité ont été mises en place afin d’éviter une utilisation détournée à des fins malveillantes (les fameux points de modération), certaines techniques, comme le prompt injection permettent de passer entre les mailles. Certains attaquants n’hésitent d’ailleurs pas à partager leurs trouvailles sur les forums criminels. Ces techniques portent en général sur les bots les plus utilisés par le grand public : ChatGPT, Google Bard… 

Capture d’écran tirée de l’article de Slahnext

Mais d’autres outils, plus puissants, pourraient faire encore plus de dégâts. On peut citer ici DarkBert, la création de S2W Inc. Il se présente comme étant la première IA générative entrainée sur des données du dark web. La société assure poursuivre un objectif défensif, en permettant notamment une surveillance du dark web afin de détecter l’apparition de sites malveillants ou de nouvelles menaces.  

Dans leur vidéo de démonstration, ils comparent la qualité des réponses de plusieurs Chatbots (GPT, Bard, DarkBert) à la question suivante : « quelles sont les dernières attaques en Europe ? ». Dans ce cas précis, Google Bard donne le nom des victimes et une réponse assez détaillée du type d’attaques (en plus de quelques conseils basiques de sécurité), ChatGPT répond qu’il n’a pas la capacité de répondre, tandis que DarkBert est capable de répondre avec les noms, la date exacte et même les jeux de données volées en question ! Même si dans la réponse qui est faite, les données ne sont pas accessibles, il est tout à fait imaginable, à travers l’utilisation de technique d’attaque oracle (ces attaques qui combinent un ensemble de techniques pour « tirer les vers du nez de l’IA » et contourner son cadre de modération), de faire en sorte que le modèle révèle et communique les jeux de données en question. 

Le risque majeur est que les attaquants réussissent à exploiter la puissance de ces outils à des fins malicieuses, par exemple pour obtenir du code malveillant, faire rédiger des documents de fraude particulièrement réalistes, ou obtenir des données sensibles. 

Cependant, l’utilisation des techniques de prompt injection et Oracle restent (jusqu’à l’apparition d’outils qui permettront de les automatiser) assez chronophage pour les attaquants. En parallèle, les Chatbots renforcent aussi sans cesse leurs mécanismes de protection et la solidité de leur capacité de modération. 

Le marché noir des IA criminelles  

Des choses légèrement plus inquiétantes voient le jour : la publication de Chatbot d’IA générative purement criminels. Dans ce cas, les attaquants récupèrent des technologies IA en open source, en retire les mesures de sécurité, et publient un modèle « débridé ».  

On a vu notamment apparaître sur les forums des outils tels que FraudGPT et WormGPT. Ces nouveaux bots permettent donc d’aller plus loin : trouver des vulnérabilités, apprendre à pirater un site, créer des courriels de phishing, coder des malwares, les automatiser etc. Les cybercriminels vont jusqu’à commercialiser ces modèles, créant ainsi un nouveau marché noir des moteurs d’IA générative. 

Capture d’écran tirée de l’article Netenrich blog montrant les différents usages de Fraud Bot. 

Exploiter la vulnérabilité humaine : les DeepFake ultraréalistes 

L’inquiétude majeure réside dans l’utilisation accrus de DeepFake ultra réaliste. Vous avez probablement été témoin des photos désormais célèbre du pape en Balenciaga ou encore de la vidéo du débat présidentiel de 88 entre Chirac et Mitterrand, parfaitement doublée en anglais et d’un réalisme bluffant.  

Dans le dernier rapport Cybersecurity Information Sheet (CSI), Contextualizing Deepfake Threats to Organizations (Septembre 2023) publié par la NSA, le FBI, CISA relate quelques exemples d’attaques basée sur l’utilisation de DeepFake. Parmi eux, un cas survenu en 2019 au sein d’une filiale britannique du secteur de l’énergie ayant versé $243,000 à cause d’un audio généré par une IA ; les attaquants s’étaient fait passer pour le CEO du groupe, pressant le CEO de la filiale de lui verser cette somme avec la promesse d’un remboursement. En 2023, des cas d’usurpation d’identité par vidéo de CEO ont déjà été signalés.  

Ce genre d’attaque offre une nouvelle dimension au cybercrime, posant des défis en matière de vérification d’identité et soulevant des questions éthiques et légales, notamment sur la diffusion de fausses informations et d’usurpation d’identité. Elles fragilisent encore plus la vulnérabilité la plus importante en matière de cybersécurité informatique : la faille humaine. Il ne fait aucun doute que les cas de fraude au président et de phishing utilisant des DeepFake se multiplieront ces prochains mois et années. 

L’IA comme outil pour les attaquants, pas une révolution pour les défenseurs 

Il est indéniable que l’utilisation des Chatbot d’IA, qu’ils soient grand public ou criminels, vont permettre de réaliser plus d’attaques, et qui plus est, de meilleure qualité ! Montée en compétences techniques, identification de vulnérabilités, ressources clés en main ou partielle : toutes ces capacités permettent à des profils moins expérimentés de réaliser des attaques avancées, plus qualitatives et plus impactantes.  

Néanmoins, l’instrumentalisation de l’IA par les criminels ne révolutionnent pas la manière dont les entreprises vont se défendre. L’impact d’une attaque générée ou soutenue par une IA sera limité pour les organisations déjà matures, au même titre que les autres attaques. Quand vos murs sont blindés, peu importe qu’on tire au 9mm ou avec un fusil d’assaut dessus.  

Les messages, les processus, les outils seront à adapter mais les concepts sont les mêmes. Le malware le plus perfectionné et le plus automatisé aura lui aussi du mal à progresser face à une entreprise qui a bien implémenté les mécanismes de défense en profondeur et de segmentation (droits, réseau…). Au fond, même si une attaque est boostée à l’IA, il s’agira toujours de se protéger contre le phishing, la fraude, les ransomwares, le vol de données…  

En ce qui concerne les DeepFakes, la sensibilisation des collaborateurs demeurera essentielle. Il faudra ainsi adapter les formations contre le phishing pour y inclure des techniques de détection et de réaction contre cette nouvelle menace. La prévention passe enfin par de la sensibilisation aux techniques de désinformation et par l’adoptions des bons gestes (signalement, enregistrement de preuves, vérification des sources, vérification des métadonnées…). 

Evidemment, ceux ayant adopté des outils d’analyse comportementale, ou qui ont automatisé une partie de leur réponse à incident ont un peu d’avance vis-à-vis d’une potentielle compromission. Pour aller plus loin, n’hésitez pas à tester les fonctionnalités IA bêtas de vos solutions existantes (c’est une bonne manière d’intégrer progressivement l’IA dans votre stratégie de sécurité). Bien que toutes les promesses des éditeurs ne soient pas encore remplies, nous sommes convaincus que des progrès significatifs verront le jour. Pour les plus matures, profitez de votre nouveau cycle stratégie pour explorer de nouveaux outils boostés à l’IA, par exemple pour la détection des deep fakes en temps réel, capables d’analyser des flux audio et vidéo. Ils apporteront une couche de sécurité supplémentaire aux outils de détection en place. 

Pour conclure, gardons la tête froide ! 

L’adoption de l’IA par les cybercriminels est une menace sérieuse qui nécessite une réflexion et une action immédiate. Il s’agit pourtant moins de révolutionner la manière de faire de la sécurité que de l’améliorer, la tenir à jour et l’adapter.  

Les équipes sécurité devront surtout maintenir une attitude pro-active face aux défis que soulèvent l’intelligence artificielle. C’est en adaptant vos processus et en restant alerte sur l’évolution de ces technologies, que vous saurez appréhender la vague sereinement, notamment par l’amélioration de vos capacités de détection des menaces de nouvelles générations. Les techniques de défense déjà en place devraient être suffisamment adaptées pour couvrir la majorité des risques. 

Il s’agit également et surtout de ne pas négliger la sécurité votre usage de l’IA : que ce soit le risque de perte de donnée et de propriété intellectuelle avec l’usage des Chatbots grand public par vos collaborateurs, ou les risques d’attaques (empoisonnement, oracle, évasion) de vos algorithmes d’IA internes. Il est primordial d’intégrer la sécurité sur l’ensemble du cycle de développement, en adoptant notamment une approche basée sur les risques spécifiques à l’utilisation de l’IA.  

La présidente de la CNIL, madame Marie-Laure DENIS appelait de ses vœux le 11 septembre 2023 à « la nécessité de créer les conditions d’une utilisation qui soit éthique, responsable et respectueuse de nos valeurs » devant la Commission des lois de l’Assemblée nationale. Les enjeux de ces nouveaux horizons technologiques impliquent de comprendre, d’évaluer les risques et d’encadrer les usages de l’IA (notamment en les liant au RGPD). C’est déjà le bon moment pour se poser ces questions et mettre en place les processus adaptés. 

Cet article L’industrialisation de l’IA par les cybercriminels : faut-il vraiment s’inquiéter ? est apparu en premier sur RiskInsight.

A l’heure où les utilisateurs ont adopté ce produit en masse, cela pose aujourd’hui plusieurs questions fondamentales de cybersécurité.  

Les entreprises doivent-elles laisser leurs employés – spécifiquement les équipes de développement – continuer à utiliser cet outil sans aucune restriction ? Doivent-elles suspendre son usage le temps que les équipes de sécurité se saisissent de la question ? Ou alors faut-il simplement le bannir ? 

Entre autres, certaines entreprises comme J.P. Morgan ou Verizon ont fait le choix d’en interdire l’usage. La société Apple avait initialement décidé d’autoriser l’outil pour ses employés avant de revenir sur sa décision et l’interdire. Amazon et Microsoft ont simplement demandé à leurs employés de faire attention aux informations partagées avec OpenAI. 

L’approche la plus restrictive qui consiste à bloquer la plateforme permet d’éviter toutes questions de cybersécurité mais posent d’autres interrogations, notamment sur la performance et la productivité des équipes, et plus largement de la compétitivité des entreprises sur des marchés changeant rapidement. 

Aujourd’hui, la question du blocage IT de l’intelligence artificielle reste d’actualité. Nous proposons de donner quelques éléments de réponses à cette question pour une catégorie de population particulièrement concernée par la question : les équipes de développement. 

ChatGPT, collecte d’informations personnelles et RGPD 

Le produit d’OpenAI est libre d’accès et d’utilisation sous condition de créer un compte utilisateur. C’est une tendance connue : si un outil en ligne est gratuit, c’est que la source de revenu n’est pas issue de l’accès à l’outil. Pour le cas particulier de ChatGPT, les informations provenant de l’historique des millions d’utilisateurs permettent d’améliorer la plateforme et la qualité du modèle de langage. ChatGPT est un service en preview : toute données entrée par l’utilisateur est susceptible d’être lue par un humain de façon à améliorer les services. 

Actuellement ChatGPT ne semble pas conforme au RGPD et à la loi informatique et liberté mais aucune décision de justice n’a été rendue. Les conditions générales ne font actuellement pas mention du droit à la limitation du traitement, droit à la portabilité des données ou encore du droit d’opposition. La société OpenAI basée aux Etats-Unis ne fait pas mention du RGPD mais rappelle que ChatGPT est conforme aux « CALIFORNIA PRIVACY RIGHTS ». En revanche, cette régulation ne s’applique que pour les résidents Californiens et ne s’applique donc pas au-delà des Etats-Unis d’Amérique. OpenAI ne propose pas non plus de solution pour permettre aux individus de vérifier si l’éditeur stocke leurs données personnelles, ni d’en réclamer leur suppression. 

Enfin, lorsque nous nous attardons sur les mentions légales de ChatGPT, nous pouvons comprendre que :  

1. OpenAI collecte les adresses IP de l’utilisateur, son type de navigateur Web, ainsi que les données et ses interactions avec le site web. Par exemple, cela inclut le type de contenu généré avec l’IA, les cas d’usages et les fonctions utilisées. 
2. OpenAI collecte aussi des informations sur l’activité de navigation des utilisateurs sur le web. Elle se réserve d’ailleurs le droit de partager ces informations personnelles avec des tiers, mais sans préciser lesquelles.  

Tout ceci étant fait dans le but entre autres d’améliorer les services existants ou de développer de nouvelles fonctionnalités.  

Pour revenir aux populations de développeurs, on observe aujourd’hui que la majorité du code s’écrit de manière collaborative en utilisant des outils Git. Ainsi, il n’est pas rare pour un développeur de devoir comprendre un morceau de code qu’il n’a pas écrit lui-même. Plutôt que de demander au rédacteur en question ce qui peut prendre plusieurs minutes (au mieux), un développeur peut être tenté de se tourner vers ChatGPT afin d’obtenir une réponse de manière instantanée. La réponse peut parfois même être plus détaillée que celle que l’auteur du code pourrait fournir. 

Les attaques classiques sur l’IA restent valables 

Plus de la moitié des entreprises se disent aujourd’hui prêtes et décidées à investir et à s’équiper d’outils fonctionnant grâce à l’intelligence artificielle. Par conséquent, il va être de plus en plus intéressant pour les attaquants d’exploiter ce type de technologie. D’autant que la notion cybersécurité est trop souvent ignorée lorsqu’on parle d’intelligence artificielle. 

L’IA d’OpenAI n’est pas immunisée contre les attaques par empoisonnement. Même si l’IA est entraînée sur une base de connaissance conséquente, il est peu probable que l’ensemble de cette connaissance ait fait l’objet d’une revue manuelle. Si nous revenons au sujet de la génération de code, il est probable que selon certains entrants spécifiques l’IA propose du code contenant une porte dérobée (backdoor). Même si ce cas de figure n’a pas été constaté, il n’est pas possible de prouver que celui-ci ne se produira pas selon un entrant particulier de l’utilisateur. 

Nous pouvons également supposer que l’outil n’a été entrainé qu’à partir de sources web relativement sûres. Le LLM (Large Language Model) sur lequel repose ChatGPT : GPT3 pourrait être susceptible à « l’auto-empoisonnement ». En effet, à mesure que GPT3 est utilisée par des millions d’utilisateurs, il est très probable que du texte généré par GPT3 se retrouve au sein de contenus internet de confiance. L’entraînement de GPT4 pourrait donc théoriquement contenir du texte généré par GPT3. Ainsi, l’IA pourrait réaliser son apprentissage à partir de connaissances qui aurait été générées par des versions antérieures du même modèle LLM. Il sera intéressant de voir comment OpenAI contourne le problème d’empoisonnement à mesure que les évolutions sont apportées au modèle. 

L’empoisonnement est une des techniques permettant d’ajouter des backdoors dans le code généré par l’IA, mais ceci n’est pas l’unique vecteur d’attaque. Il est également possible qu’une compromission des systèmes OpenAI permettant de modifier la configuration de ChatGPT afin de suggérer du code contenant des portes dérobées sous certaines conditions. Un attaquant sournois pourrait aller jusqu’à filtrer sur l’identité du compte utilisateur de ChatGPT (par exemple un compte finissant par @grandclientduCAC40.com) pour décider ou non de générer du code contenant des backdoors et autres vulnérabilités. Il est donc nécessaire de rester vigilant du niveau de sécurité d’OpenAI de façon à éviter toute compromission par rebond. 

Chat GPT et la génération de code 

La génération de code via ChatGPT est une des fonctionnalités qui peuvent faire gagner le plus de temps à un développeur au quotidien. Un développeur peut par exemple demander de rédiger un squelette de code pour une fonction puis compléter / corriger les erreurs de l’IA au besoin. Le risque principal induit par cette pratique est ici l’insertion de code malveillant au sein d’une application. 

Cependant, le risque existait bien avant ChatGPT. Un développeur malveillant pourrait très bien obfusquer son code et insérer une backdoor au sein d’une application de manière volontaire. En revanche l’introduction de l’IA apporte une nouvelle dimension au risque dès lors qu’un utilisateur bien intentionné pourrait introduire une backdoor malgré lui. Ceci est à mettre en perspective de la maturité de l’entreprise vis-à-vis de sa chaine CI/CD. La réalisation de scans SAST, DAST et d’audits divers avant la mise en production permet entre-autres de réduire le risque.  

Nous avons constaté que la génération de code via ChatGPT ne suit pas par défaut les meilleures pratiques de sécurité. L’outil peut générer du code utilisant des fonctions non sécurisées comme scanf en langage C. Nous avons proposé à l’outil la requête suivante : « Est-ce que tu peux écrire une fonction en langage C qui permet de créer une liste de nombres entiers grâce à des inputs d’un utilisateur ? ». 

Code généré par ChatGPT suite à l’entrée utilisateur décrite ci-dessus

En analysant le code généré par ChatGPT on remarque – entre autres – trois vulnérabilités importantes :  

(1) Pour débuter, l’utilisation de la fonction scanf permet à l’utilisateur de rentrer n’importe quelle longueur d’input (int overflow…). Il n’y a pas de validation de l’input de l’utilisateur, ce qui reste aujourd’hui un type de vulnérabilité phare remonté par l’OWASP TOP10.  

(2) Additionnellement, la fonction est sensible au buffer overflow : au-delà du 100ème input, la liste list ne contient plus de place pour stocker des données additionnelles ce qui peut soit terminer l’exécution par une erreur ou alors permettre à un utilisateur malveillant d’écrire des données dans une zone de la mémoire qui ne serait pas autorisée afin de prendre le contrôle de l’exécution du programme.  

(3) Pour finir, ChatGPT alloue de la mémoire à la liste via la fonction malloc mais oublie de libérer la mémoire une fois que la liste n’est plus utilisée ce qui pourrait entrainer des soucis de fuite de mémoire (memory leak). 

Chat GPT ne génère donc pas de code de manière sécurisée par défaut contrairement à un développeur expérimenté. L’outil propose du code contenant des vulnérabilités critiques. Si l’utilisateur se révèle assez sensibilisé à la cybersécurité, il est possible de demander à ChatGPT d’identifier les vulnérabilités contenues dans son propre code :  

ChatGPT est capable de détecter les vulnérabilités sur le code ayant été généré par ses soins.

Pour résumer, la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Les recommandations peuvent varier en fonction de la maturité et de la confiance qu’a l’entreprise dans la sécurisation du code livré en production. Une chaine CI/CD et des processus robustes avec des scans de sécurité automatiques (SAST, DAST, FOSS…) a de grande chance de détecter les vulnérabilités les plus critiques.  

Ainsi, ChatGPT n’est pas la seule ressource accessible en ligne par les utilisateurs pouvant permettre l’exfiltration de données (Google Drive, WeTransfer…). Le risque de fuite de données plane déjà sur toute organisation n’ayant pas implémenté une allow-list sur le proxy internet de ses utilisateurs. Le facteur différenciant dans le cas de ChatGPT est que l’utilisateur ne se rend pas nécessairement compte du caractère public des données postées sur la plateforme. Les bénéfices et le gain de temps apportés par l’outil sont bien souvent trop tentant pour l’utilisateur lui faisant oublier les bonnes pratiques. En ce sens ChatGPT n’apporte pas de nouveaux risques mais accentue les probabilités de fuite de données. 

Une organisation dispose donc de deux options afin d’empêcher la fuite de donnée via ChatGPT : (1) former et sensibiliser ses utilisateurs puis leur faire confiance, ou (2) bloquer l’outil.  

Pour les population de développeurs, ici encore la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Il revient à l’entreprise d’évaluer les capacités de sa chaine CI/CD et ses processus de mise en production afin d’évaluer les risques résiduels notamment concernant les faux-négatifs des outils de sécurité intégrés (SAST, DAST…).   

Afin de prendre une décision éclairée, une analyse de risques reste un bon outil pour prendre une décision quant au blocage éventuel de l’accès à ChatGPT. Les aspects suivants doivent être considérés : niveau de sensibilisation des utilisateurs, sensibilité de la donnée manipulée, paradigme de filtrage internet, maturité de la chaine CI/CD… Ces analyses sont bien sûr à mettre en perspective avec les potentiels gains en productivité des équipes. 

Cet article ChatGPT & DevSecOps – Quels sont les nouveaux risques cybersécurité induits par l’utilisation de l’IA par les développeurs ?  est apparu en premier sur RiskInsight.

Pour plus d’informations, retrouvez la vidéo de présentation du concours.

Pour la quatrième édition du concours, la data et l’IA viennent s’ajouter à la cybersécurité !

Alors que les précédentes éditions du concours récompensaient uniquement des startups spécialisées dans le domaine de la cybersécurité, l’édition 2020 a élargi son spectre pour accueillir de nouveaux sujets, que sont l’intelligence artificielle et la data, qui demeurent des composantes clés au sein de l’écosystème cyber.

L’ensemble des sociétés participantes, d’origine française ou européenne, ont su partager toute la richesse de leurs diverses expertises. On peut ainsi dresser le top 5 des sujets traités par les participants cette année :

• Lutte contre la fraude
• Protection de l’identité numérique
• Développement de l’intelligence artificielle pour les affaires
• Protection de l’intégrité des données
• Détection des incidents et vulnérabilités

Un jury d’envergure, des analyses et des messages forts !

Cette cérémonie avait bien évidemment pour but de récompenser les grands gagnants de l’édition 2020, mais pas seulement. C’était également l’opportunité, pour l’ensemble des membres du jury et des personnalités présentes, de partager leurs analyses quant à l’écosystème startups actuel.

Cette année, le jury était composé de Claire Calmejane (Directrice de l’Innovation du Groupe – Société Générale), Christophe Leblanc (Directeur des Ressources et de la Transformation Numérique du Groupe – Société Générale), Pascal Imbert (Président Directeur Général – Wavestone), Reza Maghsoudnia (Directeur Développement Stratégique – Wavestone), Guillaume Poupard (Directeur Général – ANSSI), Jamal Attif (Professeur à Dauphine-PSL, responsable de l’équipe MILES) et d’un collège d’experts (Thierry Olivier, Christina Poirson, Julien Molez, Gérôme Billois, Ghislain de Pierrefeu et Severine Hassler).

Enseignements et perspectives de la crise

Bien que cette crise sanitaire ne soit pas encore terminée, elle paraît en tout cas un peu mieux maîtrisée qu’en mars, quand cette maladie nous était encore inconnue. À ce sujet, Pascal Imbert et Christophe Leblanc ont apporté leur analyse de cette crise et de ses impacts.

Selon eux, cette crise a été à la fois révélatrice des fragilités propres à chaque entreprise et des modèles économiques actuels, mais aussi accélératrice de tendance, avec une place plus importante encore prise par le numérique ces derniers mois. Ces éléments rendent les transformations plus profondes et plus rapides. Cela n’est pas sans conséquence pour les entreprises, qui voient leurs transformations s’accélérer, avec la nécessité d’intégrer de nouveaux facteurs, tel qu’un meilleur équilibre entre efficacité et résilience. Tout cela, avec une place majeure de la technologie, qui représente un défi économique, technologique et de souveraineté. L’environnement startups, mis à l’honneur avec ce concours, est, selon Pascal Imbert, un des élément clé devant nous permettre de reprendre la main sur la technologie et ses usages.

Cette crise est donc à la fois un facteur de transformation digitale et stratégique, dont la data et la cybersécurité font partie intégrante, un facteur d’agilité, avec l’accélération du télétravail et l’adaptation des règles de sécurité informatique qui a été nécessaire et un facteur de « stress-test », pour nos modèles économiques et technologiques.

L’intelligence artificielle et la data au service de la crise

Jamal Attif nous l’a tous rappelé d’emblée : « la valeur est dans la donnée ». Cependant, selon lui, l’IA telle qu’on la connait aujourd’hui, n’est pas en mesure de résoudre cette crise. Elle peut aider à la combattre, en utilisant par exemple des algorithmes de fouille de données bibliographiques permettant de comprendre les effets de certains médicaments. Elle peut aussi accélérer et améliorer les diagnostics dans le milieu médical, via la reconnaissance d’images, mais elle ne peut pas prédire ce qui n’a jamais été observé auparavant, telle que cette épidémie, qui s’est développée très rapidement.

L’écosystème des startups a aujourd’hui un vrai impact dans nos modèles économique, mais il paraît important selon lui, pour faire de l’innovation de rupture permettant de répondre à des problématiques d’une telle envergure, de combiner toutes les forces en présence, que ce soient celles du monde de la recherche, des grands groupes ou des startups.

Cybersécurité : évolution de la menace et innovations

Guillaume Poupard constate deux points majeurs concernant le numérique et la cybersécurité aujourd’hui.

Tout d’abord, il soulève le côté positif de la transformation numérique, qui a permis de surmonter le défaut d’activité pendant cette période particulière. Cependant, il faut selon lui rester prudent, notamment face à la croissance particulièrement inquiétante de la cybercriminalité qui cible désormais de grandes entreprises, avec des cas très graves qui se multiplient (50 ransomwares en 2019, contre déjà 130 en 2020, et ce n’est pas terminé). La question de la lutte contre la cybercriminalité est donc un sujet d’importance majeure, d’où l’utilité de refaire des analyses de risques et des audits des systèmes d’information, afin de déceler les éventuels manquements à la cybersécurité durant ces quelques mois. Tout comme Jamal Attif, il rappelle l’importance que des acteurs publics et privés de toutes tailles, avec des motivations différentes, puissent travailler ensemble, afin de renforcer nos défenses en matière de cybersécurité. Il faut selon lui mettre en avant ceux qui innovent, et c’est d’ailleurs l’un des objectifs du campus cyber, qui devrait voir le jour dans les prochaines années, en région parisienne.

L’autre point, c’est de continuer à élever ces sujets au niveau de l’Union Européenne, et même au-delà, en mettant en place des réseaux pour que l’ensemble des parties prenantes puissent travailler ensemble. C’est notamment l’objectif du lancement, par les états membres de l’Union Européenne, du Cyber Crisis Liaison Organisation Network (CyCLONe).

Zoom sur l’écosystème innovation et startups

Reza Maghsoudnia partage l’essence même de l’écosystème startups, qui est de savoir sortir des sentiers battus, de challenger les acteurs établis, et d’innover pour donner plus de valeur aux diverses transformations que nous vivons. La crise augmente encore le besoin d’innovation, d’où l’importance pour Wavestone, de continuer à identifier ces gisements d’innovation, de les soutenir et de les accompagner.

À ce sujet, Wavestone a créé en 2015 un accélérateur de startups (Shake’Up), permettant d’être en permanence en interaction avec plusieurs centaines d’acteurs innovants sur le marché et d’identifier des pépites, afin de les accompagner. À ce jour, plus de 40 startups ont été accompagnées, dont de véritables success stories telles qu’Alsid et Citalid, dans le domaine de la cybersécurité. En ce qui concerne l’écosystème startups Cybersécurité françaises, nous vous proposons d’ailleurs de lire l’analyse de nos experts, suite au radar des startups réalisé par Wavestone.

61 startups participantes, 8 startups retenues et 4 startups récompensées

Isahit, Prix Spécial – Data for good & Ethics

Fondée en 2016, la « Tech for Good » française Isahit propose aux entreprises une plateforme digitale d’impact sourcing, pour le traitement de tâches digitales ne pouvant être prise en charge par une intelligence artificielle.

Retrouvez la vidéo de présentation de la startup Isahit.

CryptoNext, Prix Spécial – Cybersécurité Made in France

Fondée en 2019, CryptoNext a développé une technologie de chiffrement permettant de rendre les données résistantes à la puissance de l’informatique quantique. Son logiciel a vocation à être implémenté dans les offres des grands acteurs de la sécurité informatique.

Retrouvez la vidéo de présentation de la startup CryptoNext.

Inqom, Grand Prix Data & IA

Fondée en 2015, Inqom a construit un logiciel SaaS d’automatisation la production comptable, permettant de générer le bilan en temps réel. Grâce à l’intelligence artificielle, la solution traite et enrichit les données comptables afin de créer une comptabilité centralisée, uniformisée et intelligente.

Retrouvez la vidéo de présentation de la startup Inqom.

Hackuity, Grand Prix Cybersécurité

Fondée en 2018, Hackuity propose une plateforme repensant la manière dont les vulnérabilités informatiques sont gérées dans les entreprises en collectant, normalisant et orchestrant toutes les pratiques d’évaluation de la sécurité, automatisées ou manuelles.

Retrouvez la vidéo de présentation de la startup Hackuity.

Cet article Banking Innovation Awards : ils construisent ensemble la banque du futur !  est apparu en premier sur RiskInsight.

Des méthodes de détection statiques à de l’analyse comportementale

Les attaques évoluant de plus en plus rapidement et de manière toujours plus élaborée, le SOC (Security Operations Center) est forcé de revoir son approche concernant les outils en place car les mécanismes de détection statiques deviennent trop rapidement obsolètes :

• L’approche historique repose sur la reconnaissance de comportements et d’empreintes connues (ex : signatures de malwares). Cette méthode, appelée misuse-based, remonte des alertes explicites et simples à analyser pour les opérationnels, mais seules les attaques déjà subies et détectées pourront être reconnues.
• La nouvelle approche vise à analyser les actions déviant du comportement normalement observé sans avoir à définir explicitement et exhaustivement un acte malveillant (ex : comportement d’un individu s’éloignant de celui de ses collègues). Cette approche anomaly-based permet de détecter des attaques non renseignées directement dans les outils mais nécessite d’exploiter de plus larges volumes de données.

L’approche anomaly-based exploite les capacités de corrélation des algorithmes d’apprentissage non supervisé mettant en avant des liens dans des données non labellisées (non catégorisées comme normales ou anormales).

Recette de l’été : détection d’anomalies sur lit de Machine Learning

Pour savoir si le Machine Learning convient à son contexte, la meilleure solution reste de réaliser un PoC (Proof of Concept). Comment l’implémenter ? Quels sont les points d’attention ? Voici les étapes clés de notre développement.

Entrée, plat ou dessert : définir le cas d’usage

Faire du Machine Learning, c’est bien. Savoir pourquoi, c’est mieux. Définir un cas d’usage revient à répondre à la question « Que voulez-vous observer ? » et déterminer les moyens disponibles pour y répondre.

Dans notre contexte, un cas d’usage est un scénario de menace portant sur un ou des groupes de comptes (administrateurs malveillants, exfiltration de données sensibles…). Pour les évaluer, plusieurs critères sont à prendre en considération :

• Utilité: quel serait l’impact si le scénario se réalisait ?
• Disponibilité des données: quelles sont les sources de données utiles disponibles ?
• Complexité des données: les données disponibles sont-elles structurées (nombres, tableaux) ou non structurées (images, texte) ?

Nous avons choisi de travailler sur la compromission de comptes de services : certains peuvent avoir des droits importants, et leurs actions automatisées génèrent des données relativement structurées. Dans le cadre d’un PoC, un périmètre restreint et des sources de données homogènes et facilement accessibles sont à privilégier pour obtenir des résultats concrets et exploitables, avant d’envisager des cas d’usages plus ambitieux.

Pesée des ingrédients : déterminer le modèle de données

Afin d’exploiter au mieux les données, il est nécessaire de définir une représentation permettant de modéliser un comportement à partir des informations disponibles. Ici intervient notamment l’expertise métier : une action isolée peut-elle être signe de compromission ou faut-il plutôt prendre en compte une série d’actions pour détecter un comportement malveillant ?

Dans un premier temps, nous avons défini un modèle basé sur l’analyse de logs unitaires et de même famille (ex : connexions, accès aux ressources…) pour évaluer le fonctionnement global. Cependant, un modèle trop simple ignorera des signaux faibles cachés dans des corrélations d’actions, tandis qu’une représentation trop complexe ajoutera du temps de traitement et sera plus sensible aux biais de modélisation.

Sélection des ustensiles : choisir l’algorithme

Plusieurs types d’algorithmes peuvent être employés pour la détection d’anomalies :

• Certains tentent d’isoler chaque point : si un point est facile à isoler, il est éloigné des autres et donc plus anormal.
• Les algorithmes de clustering créent des groupes de points qui se ressemblent et calculent le barycentre de chacun correspondant au comportement moyen : si un point est trop éloigné du barycentre, il est considéré comme anormal.
• Moins fréquents, les auto-encodeurs sont des réseaux de neurones artificiels qui apprennent à recréer le comportement normal avec moins de paramètres : les erreurs de reproduction du comportement pourront être considérées comme un score d’anomalie.

D’autres approches existent encore, jusqu’aux plus exotiques systèmes immunitaires artificiels qui imitent les mécanismes biologiques pour créer un outil de détection évolutif. Il faut cependant ne pas oublier qu’un outil simple et bien optimisé est souvent plus efficace qu’un outil trop complexe.

L’algorithme de clustering des k-moyennes a été sélectionné dans notre cas : utilisé notamment dans la détection de fraude bancaire, il simplifie le réentrainement qui permet à l’outil de rester adapté malgré les évolutions des comportements.

Tous ces algorithmes peuvent également être enrichis, selon le modèle de comportements choisi, pour prendre en compte une suite d’actions. Ainsi, des réseaux de neurones convolutifs ou récurrents peuvent être ajoutés en amont pour prendre en compte des séries temporelles.

Préparation des ingrédients : transformer les données

Une fois que l’algorithme a été sélectionné, il faut traiter les données brutes afin de les rendre exploitables. Ce traitement s’effectue en plusieurs étapes :

• Le nettoyage: correction des erreurs de parsing, suppression des informations inutiles et ajout des informations manquantes
• L’enrichissement: ajout des données venant d’autres sources et retraitement des champs pour mettre en avant une information (ex : indiquer si une date est un jour férié…)
• La transformation: création de colonnes binaires pour les données qualitatives (ex : nom de compte, type d’événement…) ne pouvant pas être directement transformées en nombres (une colonne pour chaque valeur unique, indiquant si la valeur est présente ou non)
• La normalisation : retraitement des valeurs afin qu’elles soient toutes comprises entre 0 et 1 (pour éviter qu’un champ ne prenne l’ascendant sur un autre)

En raison de la variété d’événements possibles et de la complexité des logs, nous avons fait le choix d’automatiser ce processus : pour chaque champ, l’algorithme détecte le type de données et sélectionne la transformation adaptée dans une bibliothèque prédéfinie. L’opérateur peut ensuite interagir avec l’outil pour modifier ce choix avant de continuer le processus.

Assaisonnement : tester et optimiser l’outil

Une fois le modèle défini, l’algorithme choisi et les données transformées, l’outil développé devrait être en capacité de lever des alertes sur des anomalies. Ces alertes ont-elles du sens ou sont-elles des faux positifs ?

Afin d’évaluer la performance de l’outil, nous avons effectué deux types de tests :

• La simulation d’intrusion en effectuant des actions malveillantes pour vérifier si elles sont bien détectées comme anormales (cette approche peut être également traitée en ajoutant directement de « faux » logs dans les sets de données)
• L’analyse des anomalies en vérifiant si les alertes levées correspondent effectivement à des comportements malveillants

De nombreux paramètres peuvent être ajustés dans les algorithmes permettant d’affiner la détection. L’optimisation des performances se fait par itérations, en modifiant les paramètres et en observant l’effet sur un set de données de validation. Chronophage manuellement, elle peut être améliorée par l’approche AutoML qui cherche à automatiser certaines étapes par l’utilisation d’algorithmes d’optimisation.

Cependant, l’optimisation des paramètres ne suffit pas : les résultats de notre PoC nous ont permis de constater que la qualité d’une détection basée sur de l’analyse comportementale repose en grande partie sur la pertinence des comportements définis en amont du développement de l’algorithme.

ML or not ML: that may not be the question

Malgré ses atouts indéniables, le Machine Learning est un outil à utiliser de manière raisonnée : les frameworks deviennent de plus en plus accessibles et simples d’utilisation, mais les étapes cruciales restent la définition du use-case et du modèle de comportement. Ces choix, où l’expertise métier est indispensable, influenceront de manière irréversible le choix des données, la sélection de l’algorithme de détection et les tests à effectuer.

La question n’est donc plus « Où puis-je mettre du Machine Learning dans mon SOC ? », mais « Parmi toutes les approches disponibles, quelle est la plus efficace pour répondre à mon problème ? ».

Pour le savoir, une seule solution : allumez les fourneaux !

Cet article Détecter des incidents cyber par Machine Learning : notre maquette en 5 étapes clefs ! est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Juliette Delanoë évoque l’importance de la transformation digitale des grands groupes : « de plus en plus de biens et services peuvent être souscrits ou consommés en ligne. En particulier, la vérification des identités en ligne est un enjeu fondamental pour que la révolution digitale soit vecteur de progrès durable pour la société ». La combinaison des expériences des fondateurs a permis de développer un produit permettant via le flux vidéo, d’identifier « et de protéger les individus dans le monde digital, en permettant d’y utiliser les documents d’identité physique régaliens de façon fiable, pratique, et respectueuse de la vie privée ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Juliette Delanoë met en parallèle l’importance d’avoir des parcours digitaux agréables et rapides pour leurs utilisateurs et la nécessité d’en assurer la sécurité : « l’entrée en relation, étape très critique de l’expérience utilisateur, avait lieu il y a quelques années exclusivement en boutique, mais avec l’arrivée des néo-banques, et de la génération des millenials, cette étape se digitalise et s’automatise rapidement ». Il convient donc de conserver cette opportunité mais de faire attention aux enjeux sécuritaires qui se dessinent et notamment aux « nouveaux types de fraudes propre au digital qui se développent – comme l’utilisation de faux documents d’identité pour ouvrir un compte bancaire en ligne ».

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

Ubble propose aux RSSIs de tester la solution en partageant sa conviction profonde que « le mouvement (donc la vidéo) est indispensable à la vérification des visages comme des documents (hologrammes, reflets), et nous développons des technologies qui vérifient les identités non pas sur la base de simples images, mais sur un flux de vidéo en streaming ». En effet, les streams vidéo, la computer vision et le deep learning permettent d’éviter la fraude. Ainsi il n’est pas possible de « présenter un document d’identité qui soit une simple photocopie [ou …] d’utiliser le document de quelqu’un d’autre ». L’atout de la solution réside également dans une expérience utilisateur aisée et agréable pour un client de bonne foi.

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

Ubble explique : « nos technologies répondent à une faille sécuritaire nouvellement créée, que les solutions existantes n’adressent pas, ou seulement partiellement. Nos technologies sont en parfaite synergie avec les systèmes mis en place par les banques, et viennent s’ajouter pour combler la faille sécuritaire créée lors de la digitalisation et de l’automatisation de l’entrée en relation ».

Comment voyez-vous la banque de demain en 3 tendances ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

Selon ubble, le futur verra l’apparition d’un nouveau rôle pour la banque : la banque de demain « sera un des services les plus sécurisé dans le monde digital ». La start-up prévoit ainsi que « la banque de demain [sera amenée à jouer] un rôle sécuritaire fort dans le monde digital en général. En tant qu’acteur de confiance qui connaît ses clients, elle pourra attester de leur identité auprès d’autres fournisseurs de services ».

Pour en savoir plus : http://www.ubble.ai

Cet article L’INTERVIEW D’UBBLE – VERIFICATION D’IDENTITE VIA LA VIDEO est apparu en premier sur RiskInsight.