Les solutions d’IA sont le nouveau Shadow IT

Des employés ambitieux vantent les nouveaux outils d’IA et ignorent les graves risques de sécurité SaaS

Comme le Informatique fantôme SaaS du passé, l’IA place les RSSI et les équipes de cybersécurité dans une situation difficile mais familière.

Les employés utilisent secrètement l’IA avec peu de respect pour les procédures établies d’examen des technologies de l’information et de la cybersécurité. Considérant L’ascension fulgurante de ChatGPT jusqu’à 100 millions d’utilisateurs dans les 60 jours suivant son lancementsurtout avec peu de fanfare commerciale et marketing, la demande d’outils d’IA de la part des employés ne fera qu’augmenter.

Comme le montrent de nouvelles études certains travailleurs augmentent leur productivité de 40 % grâce à l’IA générativela pression exercée sur les RSSI et leurs équipes pour accélérer l’adoption de l’IA – et fermer les yeux sur l’utilisation non autorisée des outils d’IA – s’intensifie.

Mais succomber à ces pressions peut introduire de graves risques de fuite et de violation de données SaaS, en particulier lorsque les employés affluent vers les outils d’IA développés par les petites entreprises, les entrepreneurs individuels et les développeurs indépendants.

Les startups indépendantes d’IA n’ont généralement pas la rigueur de sécurité de l’IA d’entreprise

Les applications d’IA indépendantes se comptent désormais par dizaines de milliers, et elles réussissent à attirer les employés avec leurs modèles freemium et stratégie de marketing de croissance axée sur les produits. Selon un ingénieur en sécurité offensive et chercheur en IA de premier plan Joseph Thackerles développeurs d’applications d’IA indépendants emploient moins de personnel de sécurité et se concentrent moins sur la sécurité, moins de surveillance juridique et moins de conformité.

Thacker répartit les risques liés aux outils d’IA indépendants dans les catégories suivantes :

• Fuite de données : Les outils d’IA, notamment l’IA générative utilisant de grands modèles de langage (LLM), ont un large accès aux invites saisies par les employés. Même les historiques de discussion ChatGPT ont été divulgués, et la plupart des outils d’IA indépendants ne fonctionnent pas avec les normes de sécurité appliquées par OpenAI (la société mère de ChatGPT). Presque tous les outils d’IA indépendants conservent des invites à des fins de « données de formation ou de débogage », laissant ces données vulnérables à l’exposition.
• Problèmes de qualité du contenu : Les LLM sont suspects d’hallucinations, qu’IBM définit comme le phénomène dans lequel LLMS « perçoit des modèles ou des objets qui sont inexistants ou imperceptibles pour les observateurs humains, créant des résultats absurdes ou totalement inexacts ». Si votre organisation espère s’appuyer sur un LLM pour la génération ou l’optimisation de contenu sans examens humains ni protocoles de vérification des faits, les risques de publication d’informations inexactes sont élevés. Au-delà des pièges liés à la précision de la création de contenu, un nombre croissant de groupes tels que des universitaires et des éditeurs de revues scientifiques ont exprimé préoccupations éthiques concernant la divulgation de la paternité de l’IA.
• Vulnérabilités du produit : En général, plus l’organisation qui construit l’outil d’IA est petite, plus les développeurs risquent de ne pas réussir à remédier aux vulnérabilités courantes des produits. Par exemple, les outils d’IA indépendants peuvent être plus sensibles à l’injection rapide et aux vulnérabilités traditionnelles telles que SSRF, IDOR et XSS.
• Le risque de conformité: L’absence de politiques de confidentialité et de réglementations internes matures chez Indie AI peut entraîner de lourdes amendes et pénalités en cas de problèmes de non-conformité. Employeurs dans des secteurs ou des zones géographiques où les réglementations en matière de données SaaS sont plus strictes, telles que SOX, ISO 27001, NIST CSF, NIST 800-53 et APRA CPS234 pourraient se retrouver en infraction lorsque les employés utilisent des outils qui ne respectent pas ces normes. De plus, de nombreux fournisseurs indépendants d’IA ne sont pas conformes à la norme SOC 2.

En bref, les fournisseurs indépendants d’IA n’adhèrent généralement pas aux cadres et aux protocoles qui assurent la sécurité des données et des systèmes SaaS critiques. Ces risques sont amplifiés lorsque Les outils d’IA sont connectés aux systèmes SaaS d’entreprise.

Connecter l’IA indépendante aux applications SaaS d’entreprise augmente la productivité et la probabilité d’attaques par porte dérobée

Les employés obtiennent (ou perçoivent) une amélioration significative des processus et des résultats grâce aux outils d’IA. Mais bientôt, ils voudront augmenter leurs gains de productivité en connectant l’IA aux systèmes SaaS qu’ils utilisent quotidiennement, tels que Google Workspace, Salesforce ou M365.

Étant donné que les outils d’IA indépendants dépendent davantage de la croissance par le bouche à oreille que par les tactiques de marketing et de vente traditionnelles, les fournisseurs d’IA indépendants encouragent ces connexions au sein des produits et rendent le processus relativement transparent. Un article de Hacker News sur les risques de sécurité de l’IA générative illustre ce point avec l’exemple d’un employé qui trouve un assistant de planification IA pour l’aider à mieux gérer son temps en surveillant et en analysant la gestion des tâches et les réunions de l’employé. Mais l’assistant de planification IA doit se connecter à des outils tels que Slack, Gmail d’entreprise et Google Drive pour obtenir les données qu’il est conçu pour analyser.

Puisque les outils d’IA reposent en grande partie sur Jetons d’accès OAuth pour établir une connexion IA-SaaSl’assistant de planification AI bénéficie d’une communication continue basée sur l’API avec Slack, Gmail et Google Drive.

Les employés établissent chaque jour de telles connexions entre l’IA et le SaaS, sans aucune inquiétude. Ils voient les avantages possibles, et non les risques inhérents. Mais les employés bien intentionnés ne réalisent pas qu’ils ont peut-être connecté une application d’IA de second ordre aux données hautement sensibles de votre organisation.

Figure 1 : Comment un outil d’IA indépendant établit une connexion de jeton OAuth avec une plate-forme SaaS majeure. Crédit : AppOmni

Les connexions IA vers SaaS, comme toutes les connexions SaaS vers SaaS, hériteront des paramètres d’autorisation de l’utilisateur. Cela se traduit par un risque de sécurité sérieux, car la plupart des outils d’IA indépendants suivent des normes de sécurité laxistes. Les acteurs malveillants ciblent les outils d’IA indépendants comme moyen d’accéder aux systèmes SaaS connectés qui contiennent les joyaux de l’entreprise.

Une fois que l’acteur malveillant a exploité cette porte dérobée vers le parc SaaS de votre organisation, il peut accéder aux données et les exfiltrer jusqu’à ce que leur activité soit remarquée. Malheureusement, de telles activités suspectes passent souvent inaperçues pendant des semaines, voire des années. Par exemple, environ deux semaines se sont écoulées entre l’exfiltration des données et l’annonce publique de la Violation de données CircleCI en janvier 2023.

Sans le bon Outils de gestion de la posture de sécurité SaaS (SSPM) Pour surveiller les connexions IA-SaaS non autorisées et détecter les menaces telles qu’un grand nombre de téléchargements de fichiers, votre organisation est exposée à un risque accru de violations de données SaaS. SSPM atténue considérablement ce risque et constitue un élément essentiel de votre Programme de sécurité SaaS. Mais il n’est pas destiné à remplacer les procédures et protocoles d’examen.

Comment réduire pratiquement les risques de sécurité des outils d’IA indépendants

Après avoir exploré les risques de l’IA indépendante, Thacker recommande aux RSSI et aux équipes de cybersécurité de se concentrer sur les principes fondamentaux pour préparer leur organisation aux outils d’IA :

1. Ne négligez pas la diligence raisonnable standard

Nous commençons par les bases pour une raison. Assurez-vous qu’un membre de votre équipe, ou un membre du service juridique, lit les conditions de service de tous les outils d’IA demandés par les employés. Bien sûr, cela ne constitue pas nécessairement une protection contre les violations ou les fuites de données, et les fournisseurs indépendants peuvent étirer la vérité dans l’espoir d’apaiser les entreprises clientes. Mais une compréhension approfondie des conditions éclairera votre stratégie juridique si les fournisseurs d’IA ne respectent pas les conditions de service.

2. Envisagez de mettre en œuvre (ou de réviser) les politiques relatives aux applications et aux données

Une politique de candidature fournit des directives claires et de la transparence à votre organisation. Une simple « liste autorisée » peut couvrir les outils d’IA créés par les fournisseurs SaaS d’entreprise, et tout ce qui n’est pas inclus tombe dans le camp « non autorisé ». Vous pouvez également établir une politique de données qui dicte les types de données que les employés peuvent alimenter dans les outils d’IA. Par exemple, vous pouvez interdire l’entrée de toute forme de propriété intellectuelle dans les programmes d’IA ou le partage de données entre vos systèmes SaaS et vos applications d’IA.

3. S’engager à assurer régulièrement la formation et l’éducation des employés

Peu d’employés recherchent des outils d’IA indépendants dans un but malveillant. La grande majorité ignore tout simplement le danger auquel elle expose votre entreprise lorsqu’elle utilise une IA non autorisée.

Proposez des formations fréquentes afin qu’ils comprennent la réalité des fuites de données, des violations des outils d’IA et ce qu’impliquent les connexions IA-SaaS. Les formations constituent également des moments opportuns pour expliquer et renforcer vos politiques et votre processus de révision des logiciels.

4. Posez les questions critiques dans vos évaluations de fournisseurs

Pendant que votre équipe mène évaluations des fournisseurs des outils d’IA indépendants, insistez sur la même rigueur que celle que vous appliquez aux entreprises examinées. Ce processus doit inclure leur posture de sécurité et leur conformité aux lois sur la confidentialité des données. Entre l’équipe qui demande l’outil et le fournisseur lui-même, abordez des questions telles que :

• Qui aura accès à l’outil d’IA ? Est-ce limité à certains individus ou équipes ? Les sous-traitants, partenaires et/ou clients y auront-ils accès ?
• Quelles personnes et quelles entreprises ont accès aux invites soumises à l’outil ? La fonctionnalité IA repose-t-elle sur un tiers, un fournisseur de modèles ou un modèle local ?
• L’outil d’IA consomme-t-il ou utilise-t-il de quelque manière que ce soit des entrées externes ? Que se passerait-il si des charges utiles à injection rapide y étaient insérées ? Quel impact cela pourrait-il avoir ?
• L’outil peut-il prendre des mesures conséquentes, telles que des modifications de fichiers, d’utilisateurs ou d’autres objets ?
• L’outil d’IA possède-t-il des fonctionnalités susceptibles de générer des vulnérabilités traditionnelles (telles que SSRF, IDOR et XSS mentionnés ci-dessus) ? Par exemple, l’invite ou la sortie est-elle rendue là où XSS pourrait être possible ? La fonctionnalité de récupération Web permet-elle d’accéder aux hôtes internes ou à l’adresse IP des métadonnées du cloud ?

AppOmni, un fournisseur de sécurité SaaS, a publié un série de guides RSSI sur la sécurité de l’IA qui fournissent des questions d’évaluation plus détaillées des fournisseurs ainsi que des informations sur les opportunités et les menaces présentes par les outils d’IA.

5. Établissez des relations et rendez votre équipe (et vos politiques) accessibles

Les RSSI, les équipes de sécurité et autres gardiens de la sécurité de l’IA et du SaaS doivent se présenter comme des partenaires dans la navigation dans l’IA auprès des dirigeants d’entreprise et de leurs équipes. Les principes de comment les RSSI font de la sécurité une priorité commerciale se décomposer en relations solides, en communication et en lignes directrices accessibles.

Montrer l’impact des fuites et des violations de données liées à l’IA en termes de dollars et d’opportunités perdues fait que les cyber-risques trouvent un écho auprès des équipes commerciales. Cette amélioration de la communication est essentielle, mais ce n’est qu’une étape. Vous devrez peut-être également ajuster la façon dont votre équipe travaille avec l’entreprise.

Que vous optiez pour des listes d’applications ou de données autorisées – ou une combinaison des deux – assurez-vous que ces directives sont clairement rédigées et facilement disponibles (et promues). Lorsque les employés savent quelles données sont autorisées dans un LLM ou quels fournisseurs approuvés ils peuvent choisir pour les outils d’IA, votre équipe est beaucoup plus susceptible d’être considérée comme un moteur de progrès, et non comme un obstacle. Si les dirigeants ou les employés demandent des outils d’IA qui dépassent les limites, démarrez la conversation avec ce qu’ils essaient d’accomplir et leurs objectifs. Lorsqu’ils voient que vous êtes intéressé par leur point de vue et leurs besoins, ils sont plus disposés à s’associer avec vous sur l’outil d’IA approprié que de se lancer dans une aventure avec un fournisseur d’IA indépendant.

La meilleure chance de protéger votre pile SaaS des outils d’IA sur le long terme est de créer un environnement dans lequel l’entreprise considère votre équipe comme une ressource et non comme un obstacle.