Kieran Norton, responsable Cyber ​​IA et automatisation chez Deloitte aux États-Unis – Série d'entretiens

Kieran Norton Associé principal chez Deloitte & Touche LLP, Kieran est responsable de la cyberintelligence artificielle et de l'automatisation aux États-Unis pour Deloitte. Fort de plus de 25 ans d'expérience et d'une solide expérience technologique, il excelle dans la gestion des risques émergents et fournit à ses clients des analyses stratégiques et pragmatiques en matière de cybersécurité et de gestion des risques technologiques.

Dans DeloitteKieran dirige les efforts de transformation de l'IA pour le département Cyber ​​des États-Unis. Il supervise la conception, le développement et le déploiement commercial de solutions d'IA et d'automatisation, aidant ainsi les clients à améliorer leurs capacités cybernétiques et à adopter les technologies d'IA/Gen IA tout en gérant efficacement les risques associés.

En externe, Kieran aide les clients à faire évoluer leurs stratégies de sécurité traditionnelles pour soutenir la transformation numérique, moderniser les chaînes d'approvisionnement, accélérer la mise sur le marché, réduire les coûts et atteindre d'autres objectifs commerciaux critiques.

Alors que les agents d’IA deviennent de plus en plus autonomes, quelles nouvelles catégories de menaces de cybersécurité émergent que les entreprises ne comprennent peut-être pas encore pleinement ?

Les risques associés à l’utilisation de nouvelles technologies liées à l’IA pour concevoir, construire, déployer et gérer des agents peuvent être compris ; leur mise en œuvre est une autre affaire.

L'agence et l'autonomie des agents IA – la capacité des agents à percevoir, décider, agir et fonctionner indépendamment des humains – peuvent engendrer des difficultés pour maintenir la visibilité et le contrôle des relations et des interactions des modèles/agents avec les utilisateurs, les données et les autres agents. À mesure que les agents se multiplient au sein de l'entreprise, connectant de multiples plateformes et services avec une autonomie et des droits de décision croissants, cette tâche deviendra de plus en plus complexe. Les menaces associées à une agence/autonomie IA mal protégée, excessive ou fantôme sont nombreuses. Elles peuvent inclure la fuite de données, la manipulation des agents (via l'injection rapide, etc.) et les chaînes d'attaques agent-agent. Ces menaces ne sont pas toutes immédiates, mais les entreprises doivent réfléchir à la manière dont elles les géreront à mesure qu'elles adoptent et développent des fonctionnalités basées sur l'IA.

La gestion des identités IA est un autre risque à prendre en compte avec attention. L'identification, la définition et la gestion des identités machine des agents IA deviendront plus complexes à mesure que davantage d'agents seront déployés et utilisés dans les entreprises. La nature éphémère des modèles et composants IA, dont le développement et le démantèlement sont répétés dans des circonstances variables, compliquera la gestion de ces identifiants. Les identités des modèles sont nécessaires pour surveiller l'activité et le comportement des agents, tant du point de vue de la sécurité que de la confiance. Sans une mise en œuvre et une surveillance adéquates, la détection des problèmes potentiels (performances, sécurité, etc.) sera très complexe.

Dans quelle mesure devrions-nous nous préoccuper des attaques par empoisonnement des données dans les pipelines de formation de l’IA et quelles sont les meilleures stratégies de prévention ?

L'empoisonnement des données est l'une des nombreuses façons d'influencer/manipuler les modèles d'IA au cours de leur cycle de développement. Il survient généralement lorsqu'un acteur malveillant injecte des données nuisibles dans l'ensemble d'entraînement. Cependant, il est important de noter qu'au-delà des acteurs adverses explicites, l'empoisonnement des données peut également survenir en raison d'erreurs ou de problèmes systémiques lors de la génération des données. À mesure que les organisations deviennent de plus en plus gourmandes en données et recherchent des données exploitables à des sources plus variées (par exemple, annotation manuelle externalisée, ensembles de données synthétiques achetés ou générés, etc.), le risque d'empoisonnement involontaire des données d'entraînement augmente et n'est pas toujours facile à diagnostiquer.

Le ciblage des pipelines d'entraînement est un vecteur d'attaque majeur utilisé par les adversaires pour exercer une influence subtile ou manifeste. La manipulation des modèles d'IA peut entraîner des résultats tels que des faux positifs, des faux négatifs et d'autres influences plus subtiles et dissimulées susceptibles de fausser les prédictions de l'IA.

Les stratégies de prévention vont de la mise en œuvre de solutions techniques, procédurales et architecturales. Les stratégies procédurales incluent la validation/nettoyage des données et les évaluations de confiance ; les stratégies techniques incluent l'utilisation d'améliorations de sécurité grâce à des techniques d'IA comme l'apprentissage fédéré ; les stratégies architecturales incluent la mise en œuvre de pipelines Zero Trust et la mise en place d'une surveillance/alerte robuste facilitant la détection des anomalies. La qualité de ces modèles dépend de celle de leurs données, même si une organisation utilise les outils les plus récents et les plus performants. L'empoisonnement des données peut donc devenir un talon d'Achille pour les personnes non préparées.

De quelles manières les acteurs malveillants peuvent-ils manipuler les modèles d’IA après le déploiement et comment les entreprises peuvent-elles détecter les falsifications à un stade précoce ?

L'accès aux modèles d'IA après le déploiement s'effectue généralement via une interface de programmation d'application (API), une application via un système embarqué et/ou un protocole de port vers un périphérique. Une détection précoce nécessite une intervention précoce dans le cycle de vie du développement logiciel (SDLC), la compréhension des techniques de manipulation des modèles pertinentes ainsi que la priorisation des vecteurs de menaces afin de concevoir des méthodes de détection et de protection. Certaines manipulations de modèles impliquent le détournement d'API, la manipulation d'espaces mémoire (exécution) et l'empoisonnement lent/progressif par dérive de modèle. Compte tenu de ces méthodes de manipulation, certaines stratégies de détection précoce peuvent inclure l'utilisation de la télémétrie/surveillance des points d'extrémité (via la détection et la réponse aux points d'extrémité et la détection et la réponse étendues), la mise en œuvre de pipelines d'inférence sécurisés (par exemple, l'informatique confidentielle et les principes Zero Trust) et l'activation du tatouage/de la signature des modèles.

L'injection rapide est une famille d'attaques de modèle qui se produisent après le déploiement et peuvent être utilisées à diverses fins, notamment pour extraire des données de manière non intentionnelle, révéler des invites système non destinées aux utilisateurs normaux et induire des réponses de modèle susceptibles de donner une image négative d'une organisation. Il existe sur le marché divers outils de protection permettant de réduire le risque d'injection rapide, mais comme dans le reste du cyberespace, il s'agit d'une course aux armements où les techniques d'attaque et les contre-mesures défensives sont constamment mises à jour.

Comment les cadres de cybersécurité traditionnels ne parviennent-ils pas à répondre aux risques uniques des systèmes d’IA ?

Nous associons généralement le « cadre de cybersécurité » aux directives et aux normes, par exemple NIST, ISO, MITRE, etc. Certaines des organisations à l’origine de ces normes ont publié des directives mises à jour spécifiques à la protection des systèmes d’IA, qui peuvent être très utiles.

L'IA ne rend pas ces cadres inefficaces : vous devez toujours prendre en compte tous les aspects traditionnels de la cybersécurité. Il vous faudra peut-être mettre à jour vos processus et programmes (par exemple, votre cycle de vie du développement logiciel) pour prendre en compte les spécificités des charges de travail de l'IA. L'intégration et l'automatisation (lorsque cela est possible) de contrôles de protection contre les menaces subtiles décrites ci-dessus constituent la solution la plus efficace.

Au niveau tactique, il convient de mentionner que la gamme complète d'entrées et de sorties possibles est souvent beaucoup plus large que celle des applications non IA, ce qui crée un problème d'échelle pour les tests de pénétration traditionnels et les détections basées sur des règles, d'où l'accent mis sur l'automatisation.

Quels éléments clés devraient être inclus dans une stratégie de cybersécurité spécifiquement conçue pour les organisations déployant une IA générative ou de grands modèles linguistiques ?

Lors de l'élaboration d'une stratégie de cybersécurité pour le déploiement de GenAI ou de grands modèles de langage (LLM), il n'existe pas d'approche universelle. Cela dépend en grande partie des objectifs commerciaux globaux de l'organisation, de sa stratégie informatique, de son secteur d'activité, de son empreinte réglementaire, de sa tolérance au risque, etc., ainsi que des cas d'utilisation spécifiques de l'IA envisagés. Un chatbot à usage interne présente un profil de risque très différent de celui d'un agent susceptible d'avoir un impact sur la santé des patients, par exemple.

Cela dit, il existe des fondamentaux que chaque organisation devrait aborder :

• Effectuer une évaluation de l'état de préparation— Cela permet d'établir une base de référence des capacités actuelles et d'identifier les lacunes potentielles en fonction des cas d'utilisation prioritaires de l'IA. Les organisations doivent identifier les contrôles existants qui peuvent être étendus pour répondre aux risques nuancés associés à GenAI et à la nécessité de mettre en œuvre de nouvelles technologies ou d'améliorer les processus actuels.
• Établir un processus de gouvernance de l'IA— il peut s'agir d'une nouveauté au sein d'une organisation ou d'une modification des programmes de gestion des risques existants. Cela devrait inclure la définition de fonctions d'activation de l'IA à l'échelle de l'entreprise et l'intégration des parties prenantes de l'ensemble de l'entreprise (informatique, produits, risques, cybersécurité, etc.) dans la structure de gouvernance. De plus, il convient d'inclure la définition et la mise à jour des politiques pertinentes (politiques d'utilisation acceptable, politiques de sécurité cloud, gestion des risques liés aux technologies tierces, etc.) ainsi que l'établissement d'exigences en matière de formation et de développement pour soutenir la maîtrise et la sécurité de l'IA dans toute l'organisation.
• Établir une architecture d'IA fiable—avec la mise en place de plateformes d'IA/GenAI et de bacs à sable d'expérimentation, les technologies existantes ainsi que les nouvelles solutions (par exemple, les pare-feu/sécurité d'exécution d'IA, les garde-fous, la gestion du cycle de vie des modèles, les capacités IAM améliorées, etc.) devront être intégrées dans les environnements de développement et de déploiement de manière reproductible et évolutive.
• Améliorer le SDLC—Les organisations devraient établir une intégration étroite entre les développeurs d'IA et les équipes de gestion des risques chargées de protéger, de sécuriser et d'instaurer la confiance dans les solutions d'IA. Cela implique d'établir un ensemble uniforme et standard de pratiques de développement logiciel sécurisé et d'exigences de contrôle, en partenariat avec les équipes de développement et d'adoption de l'IA.

Pouvez-vous expliquer le concept de « pare-feu IA » en termes simples ? En quoi diffère-t-il des pare-feu réseau traditionnels ?

Un pare-feu IA est une couche de sécurité conçue pour surveiller et contrôler les entrées et sorties des systèmes d'IA, en particulier des grands modèles linguistiques, afin d'empêcher toute utilisation abusive, de protéger les données sensibles et de garantir un comportement responsable de l'IA. Contrairement aux pare-feu traditionnels qui protègent les réseaux en filtrant le trafic en fonction des adresses IP, des ports et des menaces connues, les pare-feu IA se concentrent sur la compréhension et la gestion des interactions en langage naturel. Ils bloquent des éléments tels que les contenus toxiques, les fuites de données, l'injection d'invites et l'utilisation non éthique de l'IA en appliquant des politiques, des filtres contextuels et des garde-fous spécifiques aux modèles. En résumé, alors qu'un pare-feu traditionnel protège votre réseau, un pare-feu IA protège vos modèles IA et leurs sorties.

Existe-t-il des normes industrielles actuelles ou des protocoles émergents qui régissent l’utilisation de pare-feu ou de garde-fous spécifiques à l’IA ?
Le protocole de communication de modèles (MCP) n'est pas une norme universelle, mais il gagne en popularité dans le secteur pour répondre à la charge de configuration croissante des entreprises qui doivent gérer la diversité des solutions d'IA-GenAI. Le MCP régit la manière dont les modèles d'IA échangent des informations (y compris l'apprentissage), y compris l'intégrité et la vérification. On peut considérer le MCP comme la pile TCP/IP pour les modèles d'IA, particulièrement utile dans les cas d'utilisation centralisés, fédérés ou distribués. Le MCP est actuellement un cadre conceptuel mis en œuvre grâce à divers outils, recherches et projets.

L’espace évolue rapidement et nous pouvons nous attendre à ce qu’il change considérablement au cours des prochaines années.

Comment l’IA transforme-t-elle le domaine de la détection et de la réponse aux menaces aujourd’hui par rapport à il y a seulement cinq ans ?

Nous avons constaté une modernisation à divers degrés des plateformes de centres d'opérations de sécurité (SOC) commerciaux, utilisant des ensembles de données massifs et de haute qualité ainsi que des modèles avancés d'IA/ML pour améliorer la détection et la classification des menaces. De plus, elles exploitent l'automatisation, les flux de travail et les capacités de remédiation automatique pour réduire le délai entre la détection et l'atténuation. Enfin, certaines ont introduit des fonctionnalités de copilotage pour améliorer le triage et la réponse.

De plus, des agents sont en cours de développement pour remplir certains rôles au sein du SOC. À titre d'exemple pratique, nous avons créé un « Analyste numérique » Agent à déployer dans notre propre offre de services gérés. L'agent joue le rôle d'analyste de premier niveau : il trie les alertes entrantes, enrichit le contexte à partir des informations sur les menaces et d'autres sources, et recommande des mesures d'intervention (basées sur un historique complet des cas) à nos analystes humains, qui les examinent, les modifient si nécessaire et prennent les mesures nécessaires.

Comment voyez-vous l’évolution de la relation entre l’IA et la cybersécurité au cours des 3 à 5 prochaines années : l’IA sera-t-elle davantage un risque ou une solution ?
L'évolution de l'IA au cours des 3 à 5 prochaines années pourrait contribuer à la cybersécurité, mais elle pourrait aussi engendrer des risques. L'IA élargira la surface d'attaque et créera de nouveaux défis en matière de défense. De plus, l'IA antagoniste augmentera la viabilité, la rapidité et l'ampleur des attaques, ce qui engendrera de nouveaux défis. En revanche, l'exploitation de l'IA dans le secteur de la cybersécurité offre des opportunités significatives pour améliorer l'efficacité, l'efficience, l'agilité et la rapidité des cyberopérations dans la plupart des domaines, créant ainsi un scénario de « combattre le feu par le feu ».

Merci pour cette excellente interview, les lecteurs voudront peut-être aussi visiter Deloitte.