Ce que les leaders doivent savoir sur l'IA générative

Bienvenue dans le podcast de FS-ISAC, FinCyber Today. Je suis Elizabeth Heathfield, Directrice des affaires de l'entreprise chez FS-ISAC. À l'heure où l'IA générative cesse d'être une nouveauté cool et devient indispensable, il faut apprendre à penser non seulement à l'IA, mais comme l'IA. Patrick Sullivan, VP et CTO d'Akamai, et moi avons discuté avec enthousiasme de comment tirer parti de la nature non déterministe des outils d'IA.

Merci beaucoup d'être ici. Je vous en suis très reconnaissante. Je suis ravie de discuter avec vous, car nous sommes emballés par l'IA. Parlons donc de la gestion des risques non déterministes. Définissons les règles de base et établissons les fondamentaux ici. Qu'est-ce que le non-déterminisme des modèles GenAI ? Parfait. Oui, il est important de poser les bases. Si l'on examine les modèles d'IA générative qui nous passionnent tous, leur fonctionnement consiste en de nombreuses multiplications de matrice complexe, puis à essayer de compléter le mot suivant avec les résultats les plus probables. Selon la configuration, ce sera le résultat le plus probable ou vous pourriez essayer une alternative moins probable. Ce que cela signifie, et ce pourquoi nous parlons de non-déterminisme, c'est qu'une exécution sur un ensemble d'entrées, même si ce modèle est entièrement statique, sans changement au niveau du système, donnera un résultat différent la fois suivante. Si vous l'exécutez à nouveau, les résultats seront encore différents. Par certains aspects, c'est très différent des systèmes conventionnels. Il y a donc un changement de mentalité que les gens doivent accepter. Dans des domaines comme les tests de sécurité, si une charge utile latente d'injection pompée n'explose pas une fois, vous n'avez pas pour autant l'assurance d'être invulnérable. La prochaine fois que vous exécuterez la même charge utile pour la même application, elle explosera peut-être, avec des conséquences négatives. C'est important de le comprendre. Et une compréhension théorique ne suffit pas. Vous devez le voir en action. Vous devez avoir les mains sur le clavier, les yeux sur l'écran et observer ce phénomène où vous avez une charge utile latente et à l'exécution identique suivante, elle a un impact. C'est là que vous comprendrez quelles sont les ramifications pour la sécurité.

Comment l'envisager et se faire à l'idée ? En particulier au niveau de l'entreprise ? Il est important de clarifier : il ne s'agit pas des chatbots. Nous parlons de flux de travail plus complexes, agentiques, par exemple. Absolument. Il y a une bonne nouvelle. Toutes les équipes de sécurité, dans toutes les organisations membres, ont des pionniers qui sont prêts à suivre toutes les formations qui existent. Ils ont une longueur d'avance. C'est donc sur la base que les responsables doivent se concentrer. Comment développer la base et s'assurer que chacun dans l'organisation de conformité de sécurité a les informations. Et cela inclut tout, de l'audit à l'équipe rouge et aux équipes AppSec. La formation élémentaire sera sans doute ennuyeuse pour certains, mais je pense qu'il est important de poser les bases. Cela peut être un atelier, un atelier sur l'IA ou un hackathon sur l'IA où vous pouvez facilement mettre les gens à contribution et observer ce phénomène. Ce principe de voir pour le croire est important. Et puis, quelqu'un effectue un audit et vous vous dites « Que signifie avoir de l'assurance ? » Quand un test est concluant, qu'est-ce que cela veut dire au sens large ? Au prochain test sur un système statique, l'échec est-il possible ? - Oui. - Tout le monde doit être impliqué. D'accord. Nous avons posé les enjeux de base.

Très bien, commençons par parler de certaines des opportunités que vous voyez le secteur financier exploiter. En particulier, quelles opportunités offre l'IA générative ? Parfait. L'adoption de l'IA se fait à différents rythmes dans différentes organisations, n'est-ce pas ? Certains dirigeants ont dit : « Nous sommes une organisation mature, mais nous ne laisserons pas l'opportunité de l'IA à la première startup ou Fintech venue. Nous allons saisir ces opportunités. » Cette appétence pour le risque est formidable, mais en prenant ces risques, les entreprises vont souvent commencer à déployer ces outils d'IA dans des co-pilotes de développement, par exemple. On commence à voir un rendement avec une productivité accrue des développeurs. J'ai lu, la semaine dernière, une étude de l'un de nos partenaires, Apiiro. Le développement de copilotes d'IA générative multiplie par 4 les mises à jour logicielles selon les PR effectuées. Cela peut aller jusqu'à un facteur 10 en moyenne sur tous les outils AST utilisés. Il y a beaucoup de doublons, mais en général, vous allez plus vite, ce qui est excellent pour l'entreprise. Mais si l'équipe de sécurité, AppSec en particulier, ne parvient pas à automatiser, vous allez être dépassé. C'est donc une opportunité. La couverture en est une autre. Nos outils nous envoient beaucoup d'alertes. Les rapports de violation font souvent état d'incidents sérieux. Non qu'aucun outil n'ait envoyé d'alerte, il y avait souvent une alerte ici, une autre là, mais pas assez pour dépasser le seuil d'un analyste humain. Donc, avec une couverture plus étendue, peut-être via une IA capable d'agir sur certains éléments et d'abaisser ce seuil - pour un examen plus approfondi… - Oui. C'est également une opportunité pour nous.

Nous avons donc vu certaines des opportunités. Parlons de certains risques. Quels sont les risques pour les entreprises qui les amènent à repenser légèrement leur gestion à mesure qu'elles implémentent l'IA générative ? Quels sont les risques associés ? Bien sûr. Par exemple, dans le domaine AppSec… Personnellement, j'ai passé environ vingt ans à gérer des risques AppSec. L'un des principaux anti-modèles constatés en cas d'échec de l'AppSec est le mélange de code ou d'instructions avec les données. Les données doivent être ici, les instructions, là, les instructions SQL dans la base de données. C'est un ensemble de problèmes. Les instructions du SE, si elles sont interprétées, posent différents risques. Avec ces applications GenAI, les utilisateurs prennent des instructions, des données et les mixent. - Exact. - On a un cocktail. C'est un problème. On parle ici d'un modèle de triangle toxique. Si vous avez des données externes, par exemple une requête qui arrive ou les données d'entraînement saisies dans votre système, des données internes avec un RAG ou tout autre type de système qui accède à des données confidentielles régi par de nombreuses règles en matière de confidentialité et d'autorisation d'accès. Le troisième côté, c'est le canal de communication. Les API… Direct est la pire option. Mais aussi l'accès aux e-mails ou aux modules de contrôle logiciel, un référentiel public, Slack, ou tout autre outil de ce type. Lorsque les trois côtés de ce triangle toxique sont réunis, un risque existe. Et vous aurez besoin de mesures correctives très solides pour le gérer. Si vous pouvez vous limiter à deux aspects sur trois, vous limitez déjà grandement les risques.

En parlant spécifiquement des outils que les entreprises appliquent, qui sont bâtis sur des modèles de pointe. C'est là qu'on a l'effet mixeur. C'est possible. Les modèles de pointe offrent ces données externes. Dès le départ, vous avez - toutes sortes de données externes. - Oui. Les adversaires peuvent en profiter. S'ils connaissent une vulnérabilité, ils peuvent l'exploiter avec une entrée qu'ils génèrent. Cela se combine avec les autres facteurs et donne une situation compliquée. Cela fait partie des risques auxquels nous sommes maintenant exposés. Comment gérer le risque lorsque tout semble aller bien, mais que ce n'est pas le cas ? Comment gérer ces risques ? Nous avons toujours vécu dans un monde polarisé, où tout était noir ou blanc. Désormais… Le modèle renvoie un résultat qui semble tout à fait correct. Faut-il utiliser plusieurs modèles ? Comment savoir comment vérifier les résultats ? C'est difficile, car les modèles ont parfois raison, parfois tort, mais sont toujours confiants. Il y a différentes techniques. On pourrait envisager un modèle qui supervise le modèle pour examiner les variantes des demandes précédentes. Pour d'autres systèmes, selon leur importance, les entreprises disent : « Nous ne pouvons pas encore nous passer de l'humain. Nous aurons un garde-fou humain. » À vrai dire, en matière de sécurité, l'humain est souvent le maillon faible. C'est assez ironique d'en revenir à ça. Mais ce sont des contrôles compensatoires. Nous devons absolument garder à l'esprit que nous verrons des réponses très confiantes et très, très fausses à ce stade de maturité.

Je veux donc parler de notre manière de reconnaître l'échec. Bien sûr, il y a des évaluations. Il y a une foule de projets qui consistent, en gros, à vérifier l'IA par l'IA. Il y a aussi l'idée d'avoir un humain dans la boucle. Mais cela pourrait finalement prendre plus de temps aux humains de vérifier qu'il n'en aurait fallu s'ils l'avaient fait dès le début, - sans… - Clairement. un nouveau système coûteux. Il existe plusieurs façons d'essayer d'évaluer, de vérifier si c'est automatisé, humain, etc. Mais il faut composer avec les exigences réglementaires. Comment envisager de respecter les exigences générales en matière de GRC, etc. pendant que nous réfléchissons à cela ? Ce changement va prendre du temps. Bien sûr. Il y a un énorme décalage de vitesse entre l'innovation dans ce domaine, la plus rapide que j'ai vue dans ma carrière, et l'évolution du cadre réglementaire. Nous devons penser à nos amis de la GRC qui gèrent cette disparité. Mais en même temps, la réglementation très stricte repose surtout sur les premiers principes. Nous en retrouverons une grande partie dans ce nouveau paysage. Vous savez, les bases : Disposez-vous d'un bon inventaire des actifs de l'endroit où ces technologies sont déployées ? Nous avons parlé de déterminisme et de non-déterminisme. Il convient de souligner que si vous connaissez le modèle et disposez d'un contrôle administratif sur ce système, vous pouvez le manipuler. Et vous pouvez configurer ces systèmes, régler la température sur zéro, les forcer à être déterministes. Et il peut s'agir d'un domaine où la sécurité et la conformité, et la tension qu'elles appliquent à l'entreprise pourraient aider.

Certains systèmes n'ont peut-être pas besoin de non-déterminisme. Si c'est une application « ennuyeuse » dans un domaine juridique ou comptable, par exemple, vous n'avez pas besoin d'une créativité débordante. Peut-être voulez-vous favoriser la prévisibilité pour un agent. D'autres domaines peuvent nécessiter un échantillonnage plus vaste de résultats moins probables pour générer ce qui est perçu - comme la créativité des systèmes. - Oui. Mais il faut poser les questions difficiles : avez-vous besoin d'un tel niveau de non-déterminisme ? Il faut argumenter dans les deux sens. Admettons, vous souhaitez un système le plus déterministe possible. J'entends également parler de décomposer les tâches… Ceci fait partie du flux de travail agentique et du sous-agent… Ce sous-agent ne fait que cette tâche, pour savoir exactement où est le problème. Alors qu'avec un seul flux de travail, où tout le monde effectue x étapes, il est très difficile de voir où le problème est survenu. Si vous pouvez scinder le flux au plus près du niveau du composant, vous le rendez plus déterministe même si l'automatisation n'est pas terminée. C'est un autre excellent exemple. Dans ce domaine également, l'examen de la sécurité et de la conformité contribue à fournir de meilleurs résultats. C'est presque comme la séparation des tâches, - Oui, exactement. - où vous pouvez intégrer certaines de ces choses. Nous pouvons nous reposer sur les principes fondamentaux solides qui sous-tendent nos opérations. Ainsi, dans certains cas, traiter ces systèmes comme les autres et leur imposer une partie de la surveillance traditionnelle nous aide.

D'un autre côté, les acteurs malveillants tirent parti de cette nature non déterministe pour faire preuve d'opportunisme… Ils peuvent agir et espérer un résultat créatif auquel nous n'avions pas pensé. Nous voulons donc éviter de devenir déterministes au point de limiter la puissance et de donner un avantage aux acteurs malveillants. Êtes-vous d'accord avec cela ? Oui, je pense… si nous regardons vers l'avenir… Reprenons l'exemple AppSec. Traditionnellement, nous construisions des API et des applications - pour que les humains les utilisent. - Oui. Guidés par une fonction de recherche. Aujourd'hui, on s'aperçoit qu'on crée des API et des applications Web pour alimenter un agent ou un chatbot. Pas vrai ? Si des gens cherchent à choisir l'institution financière la plus appropriée pour eux compte tenu d'un ensemble de conditions, ils utilisent peut-être un agent ou un chatbot. La façon dont nous entretenons ces bots pour l'entraînement et dont nous répondons à ces agents, qui peuvent nécessiter un traitement différent selon chaque cas d'utilisation, n'est pas notre méthode actuelle pour un visiteur web lambda. C'est le scénario optimiste, où il existe un client valide derrière certaines de ces technologies. Bien sûr, il y a aussi les usurpateurs et les personnes qui exploitent ces mêmes outils à des fins néfastes. Nous allons devoir gérer plus d'automatisation, plus de bots sur notre site aux prises avec l'identité déléguée. Si je suis le propriétaire légitime de mon identité, mais je veux qu'un agent fasse des choses en mon nom. C'est quelque chose que nous observons déjà, mais c'est vraiment le début. Cela va poser des défis du côté de l'IAM, des autorisations. Il y a fort à faire.

Oui. Nous en avons parlé un peu plus tôt. Sans oublier le nouveau risque lié aux tiers et à la chaîne logistique. Car si ce sont des agents qui parlent à des agents… Nos fournisseurs ont des agents qui discutent avec d'autres agents, sans aucune visibilité à ce niveau. C'est comme des boîtes noires empilées sur des boîtes noires. Alors, comment envisager cette situation ? La gestion des risques logistiques est déjà un défi. S'y ajoute à présent une autre couche avec encore moins de visibilité. Vous voyez ? Comment devrions-nous envisager cette situation ? Je pense que le premier défi à relever est que, du côté client, si quelqu'un utilise un agent, l'identifier de manière appropriée et le traiter comme il faut, et vérifier qu'il s'agit de l'identité déléguée à autoriser, c'est la première étape. Puis, peut-être sur notre back-end, nous faisons appel à des tiers. Qui font eux-mêmes appel à d'autres. C'est ainsi que nous gérons les risques logistiques. L'une de nos entreprises membres y est parvenue en début d'année avec la lettre ouverte de Pat Opet aux fournisseurs SaaS. Elle a souligné des lacunes dans l'écosystème actuel. Une partie de la solution viendra de fournisseurs SaaS plus transparents sur ce qui se passe en aval. Des adversaires tentent le coup de force. C'était prophétique.

Nous avons beaucoup parlé des LLM. C'est un peu le point de vue par défaut sur l'IA générative, mais on entend aussi beaucoup parler de la puissance potentielle des petits modèles de langage. Surtout avec des cas d'utilisation très spécifiques, il n'y a peut-être pas besoin d'un océan quand un lac suffit. Est-ce une piste pour la gestion de ces risques non déterministes ? Je pense que c'est le cas. Je pense que c'est un autre domaine où la sécurité exerce une pression sur l'entreprise en posant des questions comme : « Avez-vous vraiment besoin d'un LLM complet et des risques associés ? » La modélisation des menaces contre un LLM est absolument folle, n'est-ce pas ? Vous devez maintenant réfléchir : « Puis-je demander à une appli financière comment créer un WMD ? » Selon sur quoi vous vous entraînez, cela peut faire partie du modèle de menace. - Oui. - Les équipes de sécurité mettent l'entreprise au défi… Voilà ce que nous avons abordé : « Avez-vous vraiment besoin d'un modèle non déterministe, ou un modèle déterministe ferai-il l'affaire dans ce scénario ? » C'est inclus dans le contrôle de configuration. De même, il faut y réfléchir : « Avez-vous vraiment besoin d'un LLM, ou un SLM suffit-il dans ce cas d'utilisation ? » Voici un autre exemple où la sécurité peut guider l'entreprise vers un meilleur résultat pour tout le monde. C'est une question que je vois de plus en plus d'entreprises se poser. Cette évolution est positive.

Il y a le modèle, la température que nous avons abordée, mais également le contrôle du contexte. On ne laisse pas le contexte s'étendre indéfiniment, car cela dégrade évidemment la qualité qui en découle. En outre, plus vous obtenez de résultats, plus vous avez d'entrées, et plus les coûts sont élevés. Il faut essayer de les limiter. Sans oublier les prompts. Il doit exister des façons de les rendre plus prévisibles. N'est-ce pas ? Nous avons des modèles de prompt, des bibliothèques de prompts. En les rendant plus prévisibles, les entrées seront mieux régulées. Vous pouvez donc gérer une partie du non-déterminisme sur toutes ces dimensions, n'est-ce pas ? Je pense que nous devons former nos équipes à toutes ces dimensions différentes pour qu'elles sachent quels sont les outils, sans dimension monolithique. Qu'en pensez-vous ? Tout à fait d'accord. Historiquement, l'adoption de nouvelles tendances a posé des problèmes en matière de sécurité. Lorsque nous nous sommes lancés dans l'e-commerce, il y a eu une vague d'injections SQL… Des bases de données entières inondaient les applications web. Nous en avons tiré des leçons et amélioré l'inspection des entrées dans l'application. Puis, quand nous sommes passés au cloud, des schémas similaires se sont produits.

Alors que nous nous lançons dans cette nouvelle tendance, y a-t-il des leçons à tirer de l'introduction de certaines de ces applications Web reliées à des données sensibles dans le back-end ? Pouvons-nous appliquer des leçons tirées du cloud ? Pouvons-nous apprendre de nos expériences passées sans que des entreprises souffrent pour que les autres en tirent des leçons ? Espérons que ce soit le cas ici et que nous réduirons une partie de ce risque avant que des violations graves surviennent.

Nous avons fait un bon tour d'horizon. Si nos auditeurs ne devaient retenir qu'un point de cette conversation, lequel serait-ce ? Nous avons vu beaucoup de points intéressants. Je dirais que la clé est de s'assurer que l'équipe de sécurité de l'information comprend les bases. À ce stade, établissons un niveau de base de formation à l'IA, Si possible pratique, où les participants peuvent expérimenter dans un atelier ou un hackathon. Nous connaissons beaucoup de principes fondamentaux. Et lorsque nous les comprenons, nous savons où les appliquer. Je dirais donc que c'est probablement ça.