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.

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.

L’IAM est un concept ayant des impacts multiples. Cela doit être pris en compte lors de l’exécution d’un tel programme, afin d’éviter de tomber rapidement dans les problématiques courantes. Voyons cela de plus près.

Les défis d’un programme IAM : quelques exemples typiques

Les trois principaux facteurs qui imposent des exigences en matière d’IAM sont l’évolution des activités métier, la cybersécurité et l’expérience des utilisateurs. Cependant, les organisations entreprennent souvent des programmes IAM motivés, exclusivement ou principalement, par le désir de migrer vers une nouvelle solution. Avec la dette technique ou l’outillage comme seule véritable préoccupation, les programmes IAM peuvent être très rapidement confrontés à des problèmes.

1/ Impacts de la migration vers une nouvelle solution

Souvent, le désir est de simplement migrer vers un nouvel outil ou d’effectuer une mise à niveau majeure de la solution technique existante, tout en laissant tous les autres éléments du service IAM inchangés. Cela peut avoir des effets indésirables sur ces autres aspects. Par exemple, un nouvel outil entraînera probablement de nouveaux processus d’approbation, qui nécessiteront la formation du personnel à une nouvelle interface utilisateur. Il pourrait même nécessiter des processus de départ et d’arrivée entièrement nouveaux pour les RH. Ce point sensible se résume finalement à un manque d’évaluation de l’impact du changement technologique, dans le contexte d’un écosystème IAM plus large.

2/ Une liste d’exigences toujours plus longue

Lorsqu’une organisation réalise que le changement IAM ne se limite pas à l’outillage, cela peut souvent ouvrir les vannes à un nombre irréaliste de nouveaux objectifs. Les parties prenantes finissent par exiger davantage du programme (comme une meilleure expérience utilisateur et une intégration ITSM accrue), alors que ces nouveaux objectifs n’avaient pas été identifiés et pris en compte à l’origine. Le programme peut devenir un moyen d’exprimer le mécontentement à l’égard du service IAM existant, ce qui entraîne un glissement de périmètre. Cette dynamique peut rapidement mettre à mal le programme au niveau de la gestion du changement, du budget et de l’architecture de la solution.

3/ Forcer une mise en œuvre similaire

Une fois que les interactions entre la nouvelle solution IAM et ses services périmétriques sont pleinement opérationnelles, vous devez encore tenir compte des différences de philosophie de conception entre le nouvel outil et l’ancien. Les principales différences de conception des produits doivent être prises en compte. Si ce n’est pas le cas, les organisations peuvent finir par exiger un code personnalisé et des configurations complexes sur la nouvelle solution, simplement pour correspondre à l’ancienne configuration. Cela peut avoir un impact sur l’assistance du fournisseur, la maintenance, les performances globales – sans parler de la nécessité de conserver un énorme corpus de connaissances sur la personnalisation complexe. En empruntant cette voie, vous risquez de causer plus de problèmes que ceux que vous essayez de résoudre. Un véritable effet papillon peut donc se produire lorsqu’on essaie de forcer l’utilisation d’outils différents à des fins similaires.

La clé pour éviter ces problèmes courants est de reconnaître que l’IAM doit être considérée comme un sujet transversal, qui a un impact sur la technologie, les personnes et les processus.

Quelle est donc l’approche recommandée ?

La clé du succès est la reconnaissance du fait que l’amélioration de l’IAM est un programme de grande envergure. La mise en œuvre de nouvelles solutions n’est que la partie émergée de l’iceberg, et les impacts clés ne doivent pas être sous-estimés. Les points clés à considérer lors de la transformation sont :

• Le renouvellement de la solution IAM : le déploiement (ou la mise à niveau) de la nouvelle solution IAM. Cela comprend l’architecture de la solution, l’ingénierie et la migration technique.
• La modélisation des droits : les droits d’accès existants doivent être traduits dans le nouvel écosystème IAM, tels que les rôles métier et les profils d’application.
• Le nettoyage des données IAM : l’examination, le nettoyage et la validation de la fiabilité et de l’exactitude des données utilisateurs existants. Par exemple, la recertification du rôle d’un utilisateur et la validation de son supérieur hiérarchique pour s’assurer que la bonne personne approuve les demandes d’accès.
• Les nouveaux processus et la gestion du changement : cela inclut de nouvelles façons de demander et d’examiner l’accès aux applications, de nouveaux processus pour gérer les départs et les arrivées, et la formation du personnel.
• L’interopérabilité avec les autres services et actifs du SI : par exemple, l’intégration du nouvel outillage IAM avec le SOC peut nécessiter une réingénierie de l’ingestion des journaux dans le SIEM et des appels API. Un autre travail typique consiste à coordonner la migration avec celles liées à l’AD.

Nous recommandons donc de structurer le programme IAM de telle sorte que chacun de ces sujets soit couvert par un projet individuel. Le département en charge de la rédaction des politiques IAM doit opérer au niveau du programme, afin de fournir des inputs clairs permettant de guider les différents projets.

Un sponsorship fort et une vision publiquement partagée des objectifs sont également essentiels à la réussite. Les programmes IAM touchant de nombreux domaines organisationnels, il est essentiel que le gestionnaire de programme et la fonction PMO soient soutenus au niveau de la direction.

Enfin, la flexibilité est essentielle pour gérer l’évolution des circonstances et des contraintes. Voici d’autres conseils pour que le programme puisse rester sur la bonne voie et atteindre les objectifs prévus :

• Trouver un bon compromis entre les actifs hérités, la cible idéale et les capacités de la nouvelle solution : la cible doit être basée sur ce qui aide le mieux à fournir le service IAM de bout en bout à l’entreprise.
• Évaluez la possibilité d’intégrer des nouvelles solutions aux services existants, même s’ils ne sont pas envisagés à l’origine dans l’état cible idéal. Simplifiez et rationalisez dans la mesure du possible. Cela sera utile à la fois à court et à long terme.
• N’excluez pas la possibilité de conserver des outils existants qui devaient initialement être déclassés, si cela soutient les objectifs de l’IAM : il est parfois préférable de conserver certains actifs existants, plutôt que de déclasser et de migrer au nom de la modernisation technique.

Dans cet article, nous avons vu comment la définition des objectifs clés est essentielle pour la réussite du programme. Il est important de comprendre l’ampleur du changement IAM, à la fois pour structurer le programme et pour respecter les délais et le budget. Cette approche permettra également aux responsables du programme et à chaque responsable de stream de mettre en œuvre des mesures flexibles pour migrer d’un écosystème et d’applications legacy vers la nouvelle solution. Le tout sans perdre de vue les principes directeurs de la gestion des identités et des accès.

Cet article Gestion des identités et des accès : les clés d’un programme de transformation réussi est apparu en premier sur RiskInsight.

Transformation de l’IAM : quels sont les principaux moteurs ?

Les entreprises évoluent à un rythme effréné et la rapidité de mise sur le marché dépend fortement de systèmes informatiques reposant sur des services d’identité robustes et évolutifs. Qu’il s’agisse d’un nouveau service web disponible pour les clients, d’une expansion importante ou d’une fusion de back-office, la nécessité de faire évoluer les services IAM rapidement et efficacement est omniprésente.

Chez Wavestone, nous observons trois facteurs, souvent combinés, qui exigent davantage de la gestion des identités et des accès :

1. Les risques de cybersécurité
2. L’évolution des besoins métiers
3. L’expérience de l’utilisateur final

Examinons chacun de ces points plus en détail.

1/ Évolution des modèles de cybersécurité et de systèmes d’information

Les systèmes d’information sont de plus en plus ouverts et fragmentés. L’adoption du cloud et les architectures distribuées contribuent à ce changement fondamental. La sécurité adapte ses principes et la notion de zero trust est désormais bien établie. La gestion des identités et des accès est un élément clé du zero trust.

Les systèmes d’information sont consommés par des tiers, des clients et des employés. L’identité est essentielle pour l’échange de données critiques et la confidentialité entre diverses entités. Il est donc nécessaire de disposer d’une identité unique pour chaque entité dans l’ensemble du système d’information. Si les architectures évoluent, l’objectif ultime de l’IAM ne change pas : la bonne personne ou entité, avec le niveau de droits approprié, pour accéder à la bonne ressource, dans le bon contexte. Il est essentiel que ce principe soit respecté en permanence.

L’identité unique de chaque machine et de chaque utilisateur est également essentielle pour la traçabilité. Une organisation doit être en mesure d’identifier, d’authentifier et d’autoriser tout utilisateur, de toute autre entité, lorsqu’il accède à une ressource. Il est essentiel de pouvoir centraliser l’enregistrement, l’audit et le suivi de ces événements à travers le système d’information.

2/ L’identité au service de l’entreprise

Les entreprises subissent des transformations fondamentales qui exigent une plus grande agilité et des délais de mise sur le marché plus courts. Par exemple, de nombreux commerçants cherchent de nouvelles voies numériques pour accéder au marché en raison de l’évolution du paysage du commerce électronique et des défis opérationnels posés par la pandémie de COVID-19. Les services d’identité doivent être en mesure de soutenir des initiatives commerciales de grande envergure et d’assurer l’innovation à grande échelle.

L’évolution complexe de l’entreprise ne peut être ralentie par des délais de sécurité ou de livraison d’infrastructure prolongés. L’identité doit être un catalyseur, et non un synonyme de retard. Tout projet doit pouvoir s’appuyer sur des services d’identité qui sont fournis comme un produit de base à l’entreprise, et non pas nouvellement conçus et déployés pour chaque initiative.

La consolidation et la normalisation des solutions et processus IAM sont essentielles à la mise en œuvre de ce modèle. Il s’agit notamment d’une gestion cohérente et solide, qui dépend de méthodes et de protocoles agnostiques sur le plan technologique, basés sur les normes industrielles les plus récentes et les plus sûres (telles que SAML, OIDC et OAuth).

La fourniture de services d’identité doit être intégrée dans le modèle opérationnel de l’organisation et dans des pratiques telles que Agile, DevOps @ scale et innovation @ scale : l’IAM doit être fourni comme un service à l’entreprise.

3/ Les exigences en matière d’expérience utilisateur sont désormais au centre des préoccupations

Le troisième moteur, crucial, de la transformation de l’IAM est l’expérience utilisateur. Il s’agit pour les organisations de fournir aux employés la même qualité de services d’authentification et d’autorisation que celle dont les clients externes ont souvent bénéficié par le passé. L’objectif est de permettre aux utilisateurs finaux de prouver leur identité facilement et sans effort, et d’accéder aux services requis, en tout lieu et à partir de tout appareil. Cela constitue la base d’une véritable expérience continue qui soutient les nouveaux modes de collaboration, également accélérés par le travail à distance.

Des processus d’enregistrement faciles et fluides, ainsi qu’une authentification cohérente dans les différentes applications, doivent être proposés aux clients pour simplifier leur expérience et les fidéliser à la marque. Ce même principe vaut pour les employés et les tiers.

Les technologies sans mot de passe et les identifiants uniques pour les applications sont des exemples de solutions en plein essor ; des approches innovantes fondées sur le risque et le contexte peuvent rationaliser les accès, ce qui peut avoir un impact positif important sur l’expérience des utilisateurs en réduisant les demandes d’authentification.

Quelles sont les étapes de la transformation de l’IAM ?

La compréhension de votre maturité actuelle est une étape clé pour atteindre les objectifs ci-dessus. Au fil des années de soutien aux initiatives IAM de nos clients, nous avons construit notre parcours d’amélioration de la maturité IAM, qui comprend 4 étapes de maturité.

• Fragmenté : l’organisation n’a pas d’approche consolidée de l’IAM à travers les solutions, la gouvernance et les normes.
• Rationalisé : le paysage technologique soutenant l’IAM est simplifié et géré de manière centralisée afin de faciliter l’expérience utilisateur pour toutes les applications et tous les utilisateurs. La consolidation fournit des capacités de supervision satisfaisantes.
• Étendu : les capacités organisationnelles d’IAM sont adaptées à un système d’information en évolution : tout utilisateur, tout appareil, tout service.De nombreuses organisations disposent actuellement d’éléments de ces capacités, mais rarement déployés à l’échelle mondiale.
• Maîtrisé : l’organisation a adopté des solutions de nouvelle génération, qui offrent de solides avantages en matière de sécurité et une expérience utilisateur fluide, tout en réduisant la charge de travail des opérations informatiques grâce à une automatisation intelligente.A ce jour, ces solutions sont adoptées au cas par cas ou servent d’objectif dans les feuilles de route IAM.

Chacune des étapes ci-dessus nécessite une transformation profonde de l’environnement : changement de gouvernance, changement de processus, et déploiement ou migration des technologies de soutien. Pour réussir, nous pensons qu’elles doivent être abordées dans le cadre d’un programme de transformation IAM dédié.

Restez à l’écoute de notre prochaine publication, où nous partagerons avec vous ce qui est bon pour un programme de transformation IAM…

Cet article La gestion des identités et des accès de retour sur le devant de la scène est apparu en premier sur RiskInsight.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot « lieu de travail » utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son « plan d’accès » (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du « plan d’accès » par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la « grammaire » du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en « privilèges » ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (« confiance technique ») des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.