Sécurité des assistants vocaux : comment les entreprises peuvent-elles protéger leurs assistants vocaux contre les attaques ?

Les assistants vocaux répondent désormais aux demandes des clients, accèdent aux données de l'entreprise et, dans certains cas, mènent même à bien des processus métier de manière autonome. Cela en fait également une cible de plus en plus attractive pour les pirates. Toute organisation déployant des assistants vocaux dans son service client doit donc bien comprendre les risques associés – et savoir comment les atténuer.

Ce défi est aggravé par une autre évolution : de nombreux employés utilisent déjà leurs propres outils d’IA dans leur travail quotidien, souvent à l’insu du service informatique et sans son accord. Ce phénomène est désormais connu sous le nom d’« IA fantôme ».

Parallèlement, les clients et les entreprises font de plus en plus confiance aux réponses générées par l'IA, à mesure que la qualité de ces systèmes ne cesse de s'améliorer. Ironiquement, cette confiance grandissante fait des assistants vocaux une cible encore plus attrayante pour les cyberattaques.

Quelles attaques contre les assistants vocaux constituent réellement une menace ?

Les risques de sécurité liés à l’IA peuvent désormais être classés assez rapidement. L’un des cadres de référence les plus connus est proposé par la communauté OWASP (Open Web Application Security Project). L’OWASP est une organisation à but non lucratif qui promeut depuis de nombreuses années les meilleures pratiques en matière de cybersécurité. Elle publie régulièrement ses célèbres classements « Top 10 » des risques de sécurité, accompagnés de conseils pratiques sur la manière d’y remédier. Plus récemment, elle a également lancé le GenAI Security Project, qui se concentre spécifiquement sur les risques liés à l'IA générative.

L'un des risques les plus importants identifiés par l'OWASP est l'« injection de messages ». Ce phénomène se produit lorsqu'un appelant utilise des messages soigneusement élaborés pour manipuler l'IA afin qu'elle effectue des actions pour lesquelles elle n'a jamais été conçue, telles que la divulgation d'informations confidentielles ou l'octroi de remises non autorisées. Ce phénomène s'apparente à une escroquerie par téléphone, à la différence près que l'attaquant manipule un système d'IA plutôt qu'un être humain. De plus en plus, ces attaques sont menées de manière automatisée.

L'injection de prompts n'est qu'un vecteur d'attaque parmi d'autres. Les modèles d'IA peuvent également être submergés de requêtes, ce qui donne lieu à une forme d'attaque par déni de service. Soumis à une charge excessive, un modèle peut présenter des défaillances imprévisibles, ignorer les mesures de sécurité prévues ou produire des réponses qu'il ne générerait pas en temps normal. Les modèles linguistiques peuvent également exposer des informations internes, révéler des détails d'implémentation ou traiter des contenus qu'ils devraient rejeter purement et simplement. Regardez notre vidéo

Un autre risque important découle de l’intégration de l’IA aux systèmes de gestion des connaissances et à la « Retrieval-Augmented Generation » (RAG). De nombreux assistants vocaux s’appuient sur de vastes bases de connaissances d’entreprise pour répondre aux demandes spécifiques des clients. Si ces intégrations ne sont pas correctement sécurisées, des pirates pourraient être en mesure de manipuler les données sous-jacentes, d’influencer les réponses du modèle ou d’accéder à des informations qui ne devraient jamais être accessibles.

Il en va de même pour les intégrations avec les systèmes CRM et ERP, ainsi qu’avec les API et autres interfaces logicielles. Ces intégrations constituent depuis longtemps une source courante de vulnérabilités dans les environnements logiciels traditionnels, et les systèmes d’IA ne font que renforcer leur importance. Des informations sensibles peuvent fuir par des interfaces mal sécurisées, tandis que les outils connectés permettant aux agents d’IA d’interagir avec des applications externes sont de plus en plus souvent la cible d’attaques. Ces derniers mois, des chercheurs ont mis en évidence des attaques au cours desquelles du code non autorisé a été exécuté ou des identifiants ont été extraits via des intégrations vulnérables.

L'éventail des attaques potentielles est donc vaste. La protection des systèmes d'IA nécessite plusieurs niveaux de défense plutôt qu'une seule mesure de sécurité.

Une bonne approche consiste à définir clairement, dès le départ, le rôle de l’agent d’IA et à fixer des limites strictes. Celui-ci ne doit pas traiter certaines catégories d’informations, accorder des remises non autorisées ni prendre d’engagements juridiquement contraignants. Les décisions de cette nature doivent toujours rester sous contrôle humain.

Il est tout aussi important de procéder à une vérification fiable de l'identité des appelants, par exemple au moyen d'identifiants client, de la vérification de l'IBAN ou, de préférence, d'une authentification multifactorielle (MFA), qui nécessite un facteur d'authentification supplémentaire, tel qu'un code envoyé sur un téléphone portable enregistré. Cela réduit considérablement le risque de réussite des attaques automatisées.

Aucune mesure de sécurité n'est suffisante à elle seule. Une protection efficace repose sur la combinaison de plusieurs contrôles de sécurité au sein d'un système de défense en plusieurs couches – une approche communément appelée « défense en profondeur ». Les sections suivantes présentent les trois piliers fondamentaux d'une telle stratégie de sécurité.

Trois façons de protéger efficacement les assistants vocaux

Pour faire face à ces risques, trois approches se sont imposées dans la pratique :

• Des mécanismes de contrôle intégrés directement à la plateforme de bot vocal,
• Des outils de protection adaptatifs pouvant être mis en œuvre à titre de mesure complémentaire,
• les tests d'intrusion, qui permettent de simuler des attaques afin de détecter les vulnérabilités avant qu'un véritable pirate ne le fasse.

Mécanismes de sécurité intégrés aux plateformes de voicebots

Les mesures de sécurité intégrées constituent un bon point de départ, car elles sont directement intégrées à la plateforme de bot vocal que vous utilisez déjà, sans nécessiter de logiciel supplémentaire ni de licence distincte. La plupart des principales plateformes intègrent désormais leurs propres contrôles de sécurité en standard.

NiCE Cognigy

NiCE Cognigy propose des paramètres de sécurité configurables pour les agents IA. Ces paramètres permettent aux organisations de définir différentes catégories de contrôles de sécurité. Bien que la documentation explique l'objectif de chaque catégorie, elle ne fournit pas toujours d'informations détaillées sur le fonctionnement concret de chaque paramètre. Pour les déploiements en production, il est donc conseillé de travailler en étroite collaboration avec le partenaire de mise en œuvre ou le fournisseur afin de comprendre exactement comment chaque contrôle fonctionne et comment il doit être configuré.

Le principal avantage des garde-fous intégrés réside dans le fait qu’ils sont directement intégrés à la plateforme. Cela n’entraîne généralement qu’une latence minime. Cependant, certains mécanismes de sécurité s’appuient sur des invites supplémentaires ou des instructions système, ce qui peut augmenter la consommation de jetons.

Parloa

Parloa offre un contrôle plus précis sur la configuration des garde-fous. Pour de nombreuses catégories de garde-fous, les organisations peuvent choisir différents niveaux de protection, tels que « Faible », « Moyen » ou « Élevé ». Il prend également en charge les filtres personnalisés, ce qui permet de définir des termes, des sujets ou des scénarios spécifiques dans lesquels le bot doit soit répondre différemment, soit mettre fin à l'interaction.

À mesure que les capacités des mécanismes de contrôle continuent d’évoluer, les plateformes s’éloignent de plus en plus des simples filtres de contenu isolés pour s’orienter vers une analyse au niveau de la conversation, évaluant le contexte d’une interaction dans son ensemble plutôt que des invites et des réponses prises isolément. Comme pour tout mécanisme de contrôle intégré, ces contrôles constituent un premier niveau de protection efficace, même s’ils peuvent également augmenter la consommation de jetons, car des instructions supplémentaires sont traitées parallèlement à la conversation. Une requête est la saisie fournie par un utilisateur, un système ou un agent IA qui demande à un modèle linguistique de générer une réponse ou d’effectuer une tâche spécifique.

Outils de protection adaptative : Cisco AI Defense

Ces types d'outils s'avèrent particulièrement utiles lorsque les mesures de protection intégrées ne suffisent plus à elles seules – par exemple, lorsqu'il faut surveiller de manière centralisée plusieurs bots et plateformes, ou lorsque les équipes de sécurité ont besoin d'une supervision indépendante des fournisseurs dans différents environnements d'IA.

On peut citer, par exemple, Cisco AI Defence. Cisco, qui s'est imposé depuis longtemps dans les domaines des réseaux et de la cybersécurité, a élargi son portefeuille ces dernières années afin de répondre aux défis croissants en matière de sécurité liés à l'IA.

L'une de ses principales fonctionnalités est l'inspection sémantique. Celle-ci ajoute une couche de sécurité entre l'application d'IA – par exemple, un assistant vocal – et le grand modèle linguistique (LLM). Le système analyse le flux d'informations et est capable d'identifier les requêtes, les réponses ou les schémas de comportement suspects avant qu'ils n'atteignent le modèle ou l'utilisateur.

Comme pour toute couche de sécurité intermédiaire, il faut tenir compte de la latence. Selon l’architecture, l’inspection sémantique peut entraîner des délais de traitement supplémentaires. La compatibilité est un autre facteur important. Tous les voicebots ou toutes les plateformes d’IA de type « Agentic » ne sont pas suffisamment ouverts pour permettre à une solution de sécurité tierce de s’intercaler directement entre l’application et le LLM. Dans certains cas, l’intégration n’est possible que via des API, tandis que dans d’autres, il n’y a absolument aucun accès au modèle ou au flux de texte sous-jacent.

La surveillance des API connectées constitue un autre niveau de protection important. Cela inclut les intégrations avec les bases de connaissances, les systèmes CRM et ERP, les bases de données clients et d’autres applications à partir desquelles l’IA lit des données ou vers lesquelles elle en écrit.

La solution Runtime Protection de Cisco contribue à sécuriser ces intégrations en surveillant l'activité des API, en détectant les tentatives d'accès suspectes et en bloquant les actions malveillantes si nécessaire. L'objectif est de réduire à la fois le risque et l'impact potentiel d'une application d'IA compromise.

Des fonctionnalités supplémentaires – notamment Secure Access, les intégrations dans l’espace de travail, l’assistant IA et AgenticOps – peuvent renforcer encore davantage la posture de sécurité d’une organisation. Malgré tout, le principe de l’intervention humaine reste essentiel. En fin de compte, c’est à un administrateur humain qu’il revient de prendre les décisions critiques, telles que la désactivation temporaire d’un bot ou la validation d’une action recommandée.

Service géré Damovo : tests d'intrusion sur les assistants vocaux

La troisième approche consiste en un service de tests d'intrusion développé par Damovo. Alors que les tests d'intrusion existent depuis un certain temps déjà pour les chatbots, les tests équivalents destinés aux voicebots sont restés relativement limités.

La raison est simple. Même si un assistant vocal peut être testé manuellement, le nombre considérable de vecteurs d’attaque potentiels – estimé à environ 500 – rend les tests exhaustifs à la fois chronophages et gourmands en ressources. De plus, les scénarios d’attaque doivent être adaptés au secteur d’activité concerné, qu’il s’agisse de la banque, de l’assurance, de la santé ou d’un autre secteur.

Damovo suit donc une méthodologie structurée. Le processus commence par la création de consignes de test adaptées au secteur d’activité du client. Ces consignes sont ensuite associées aux catégories de risques OWASP GenAI correspondantes.

Un bot de test automatisé passe ensuite des appels vers le bot vocal cible. Après le message d'accueil initial et, le cas échéant, le processus d'authentification, les dialogues de test prédéfinis sont exécutés. Les deux parties de la conversation sont enregistrées séparément, ce qui permet d'analyser indépendamment les invites et les réponses du bot vocal.

Chaque dialogue de test est transcrit et enrichi de métadonnées, ce qui permet de constituer une piste d'audit complète et vérifiable. Une analyse assistée par l'IA détermine ensuite si l'attaque simulée a abouti, si le robot vocal a correctement bloqué la requête ou s'il a divulgué des informations qui auraient dû rester protégées.

Le client reçoit un rapport détaillé qui met en correspondance les résultats avec les catégories de risques OWASP GenAI pertinentes et qui inclut les éléments de preuve à l'appui de chaque vulnérabilité identifiée.

Combien cela coûte-t-il au total et quelle est la charge de travail que cela implique ?

Coûts

Pour les assistants vocaux actuellement utilisés, les mécanismes de sécurité intégrés n’entraînent généralement aucun coût supplémentaire direct. Ils peuvent toutefois générer des coûts indirects liés à une augmentation de la consommation de jetons. À l’heure actuelle, il est difficile de quantifier avec précision cette consommation supplémentaire, car il existe peu de données publiées à ce sujet. À mesure que les capacités de ces mécanismes de contrôle continuent d’évoluer, il est toutefois probable que des fonctionnalités plus avancées nécessiteront des licences supplémentaires – par exemple, lorsqu’un grand modèle linguistique (LLM) distinct analyse en arrière-plan le contexte d’une conversation dans son intégralité.

Les outils de protection adaptative sont des solutions destinées aux entreprises et entraînent généralement des coûts de mise en œuvre, de maintenance et de licence. Selon le fournisseur et l'ampleur du déploiement, ces coûts peuvent être nettement supérieurs à ceux liés aux fonctionnalités intégrées à la plateforme.

Le service de tests d'intrusion gérés est principalement destiné à des évaluations ponctuelles et s'avère généralement bien plus rentable que le déploiement permanent d'un logiciel de sécurité d'entreprise. Cependant, l'élaboration de scénarios de test réalistes nécessite de les adapter à la fois au secteur d'activité concerné et aux cas d'utilisation spécifiques de l'organisation, ce qui augmente le coût initial du projet.

Le fait que ces tests soient effectués de manière ponctuelle, après la mise en place d'une nouvelle fonctionnalité, ou de manière régulière dépend des exigences de sécurité et du profil de risque de l'organisation.

Effort de maintenance

Ces trois approches diffèrent également en termes d'effort d'entretien continu. Les « garde-fous » intégrés ne nécessitent que très peu d'entretien, car ils sont déjà intégrés à la plateforme. Les outils de protection adaptatifs impliquent un niveau d'effort moyen à élevé, en particulier pendant la phase initiale de mise en œuvre. Les tests d'intrusion nécessitent un niveau d'effort modéré, principalement en raison de la nécessité d'une personnalisation spécifique au secteur d'activité.

Latence

Ces trois approches diffèrent également en termes de latence. Les mécanismes de protection intégrés sont généralement intégrés à la plateforme elle-même et n’entraînent donc que des retards minimes. Les outils de protection adaptatifs peuvent ajouter une latence supplémentaire, en fonction de l’architecture sous-jacente et de l’approche d’intégration. Les tests d’intrusion doivent généralement être effectués en dehors des heures de travail habituelles afin de ne pas perturber les activités quotidiennes des utilisateurs.

Pourquoi ce sujet prend-il de l'importance en ce moment ?

L'un des principaux moteurs de cette évolution est la demande croissante en matière de traçabilité. Des exigences telles que la directive NIS 2 et la directive DORA sont déjà devenues des axes prioritaires, auxquelles s'ajoute désormais la nécessité d'évaluer les systèmes de gestion de l'IA conformément à la norme ISO 42001. En conséquence, un nombre croissant d'organisations doivent démontrer que leurs chatbots et voicebots font l'objet d'évaluations et d'audits de sécurité réguliers.

C'est là que les différences entre les trois approches apparaissent particulièrement clairement. Les garde-fous intégrés sont relativement limités dans ce domaine, car ils ne fournissent souvent qu'une documentation restreinte et une visibilité limitée sur la manière dont les décisions sont prises. Les outils adaptatifs offrent nettement plus de rapports et d’informations, bien que leurs capacités restent tributaires des fonctionnalités et des limites spécifiques de la solution utilisée. Le service de tests d’intrusion gérés, en revanche, peut être adapté de manière beaucoup plus flexible – par exemple, selon qu’un client souhaite tester 10, 100 ou 500 vecteurs d’attaque – et fournit donc les preuves les plus complètes et les plus transparentes.

Ces trois approches diffèrent également en termes de risque résiduel. Selon leur configuration, les mesures de protection intégrées sont généralement associées, à elles seules, à un niveau de risque résiduel moyen à élevé. Les outils adaptatifs peuvent réduire considérablement ce risque en appliquant en arrière-plan des contrôles de sécurité éprouvés de niveau entreprise. Les tests d’intrusion gérés offrent l’évaluation la plus réaliste, car ils sont effectués sur des systèmes en production à l’aide de scénarios d’attaque et d’interactions réalistes, ce qui se traduit par le risque résiduel le plus faible.

Conclusion : une défense en profondeur plutôt qu’une solution unique

En fin de compte, on peut en conclure qu’il ne s’agit pas d’un choix entre l’un ou l’autre. Les assistants vocaux doivent être protégés à plusieurs niveaux : les mesures de sécurité constituent la première ligne de défense, les outils adaptatifs apportent une protection supplémentaire, et les tests d’intrusion en temps réel permettent d’évaluer la résilience réelle de ces mesures de sécurité.

Cette approche par couches garantit que, si un dispositif de contrôle venait à faillir, soit l'attaque serait empêchée de se poursuivre, soit son impact potentiel serait considérablement réduit.

Les organisations qui souhaitent réduire au maximum le risque résiduel devraient donc prendre en compte ces trois niveaux dans leur ensemble, plutôt que de mettre en œuvre des mesures individuelles de manière isolée. Les entreprises qui souhaitent évaluer le niveau de sécurité réel de leur propre assistant vocal peuvent le faire grâce à un test d'intrusion géré proposé par Damovo.