Appliquer EBIOS RM à un système IA

Catégorie : Commun Statut : ⧼cc-com-0⧽ 1 : Idée - 2 : Prototype - 3 : Validation - 4 : Production

1. SYNTHESE EXECUTIVE

1.1. OBJECTIFS ET PERIMETRE

Ce document résulte de travaux du groupe de travail intelligence artificielle & cyber sécurité (GT IA & Cyber) porté par le Campus Cyber. Il a pour principal objectif de fournir une vision pragmatique de l’application du guide « méthodologie EBIOS RM » publié par l’ANSSI pour évaluer un système à base d’intelligence artificielle. Il identifie un certain nombre de mesures de sécurité, certaines ayant été implémentées avec efficacité au sein d’entreprises contributrices.

Les méthodes, métriques et conclusions présentées ici sont basées sur des retours d’expérience de mise en application de la méthode EBIOS Risk Manager, en incluant les questions relatives à la cybersécurité que se sont posées régulièrement les experts en cybersécurité de différents secteurs.

1.2. STRUCTURE DU DOCUMENT

La suite de ce document est organisée comme suit :

• la section 2 définit un système d’intelligence artificielle vu par un expert en cybersécurité, en s’attachant à détailler les composants fondamentaux des systèmes intelligence artificielle, les acteurs et les principaux points d’attention concernant les bibliothèques logicielles et les modèles utilisés ;
• la section 3 présente les conclusions générales du groupe de travail, en incluant, dans la mesure du possible, des exemples qui sont ensuite détaillés dans la section 4 (annexe 1) ;
• la section 4 présente une analyse de risques EBIOS Risk Manager complète réalisée sur un système réel, anonymisé de son contexte, incluant l’ensemble des 5 étapes de la méthodologie.

2. UN SYSTEME IA VU PAR LES EXPERTS CYBERSECURITE

Cette section présente la vision d’un système d’intelligence artificielle (IA) vu par les experts de cybersécurité, il a vocation à présenter les principales briques et les principaux acteurs nécessaires à la mise en œuvre d’une application IA.

Dans le cadre de ce travail, le groupe a décidé de focaliser son analyse d'un système d'IA en prenant les hypothèses suivantes :

1. L'intelligence artificielle s'appuie sur un modèle de machine learning appris de manière supervisée ;
2. L'apprentissage du modèle se fait "en batch", c'est-à-dire que toutes les données sont disponibles au moment de l'entraînement du modèle ;
3. Lorsque le modèle est mis en production, il n'y a pas d'évolution dynamique du modèle. Ainsi aucune mise à jour ou réapprentissage du modèle n'est considéré.

Bien que ce cadre puisse paraître restrictif, il constitue aujourd'hui la majorité des cas d'usage des intelligences artificielles.

2.1. SCHEMA D'UN SYSTEME D'INFORMATION D'INTELLIGENCE ARTIFICIELLE

Un système d’intelligence artificielle est fréquemment illustré par deux systèmes plus ou moins isolés et composés de trois composants. Ces deux sous-systèmes ont des fonctions définies dans les paragraphes 2.3, 2.4 et 2.5. :

• Le premier, le système d’information de production, met à disposition le traitement par machine learning des données.
• Le second, le système d’entraînement, composé de quatre sous-systèmes, permet l’acquisition de données, le traitement des données, l’ingénierie du modèle et le déploiement du modèle de machine learning.

Figure 1 - Schéma de principe d'un SI d'intelligence artificielle

2.2. LES PARTIES PRENANTES D'UN SYSTEME D'INTELLIGENCE ARTIFICIELLE

Le développement, la mise en production et le suivi d’une application IA fait appel à de nombreux acteurs, dont certains sont spécialistes de data science/IA et d’autres ne le sont pas. Comme le montre la figure 2, il y a quatre grandes familles d’acteurs (voir le panorama des métiers de la cybersécurité ) :

• Les profils "métier",
• Les spécialistes de data science,
• Les profils IT,
• Les profils "risque".

Figure 2 – les familles d’acteurs

Notons que chaque entreprise peut avoir des noms un peu différents pour ces profils, voire découper différemment les rôles sur différents acteurs. Les descriptions suivantes sont donc à adapter à chaque cas.

Profils "métier"

• Sponsor métier : l’entité ou la personne qui émet une expression de besoin pour un nouveau projet et qui est responsable de l’évaluation métier du projet en production.
• Citizen data scientist : il peut exécuter des process de production de modèles avec des outils simples (no-code) pour démontrer/ explorer la valeur métier
• Analyste métier : il analyse les besoins métier et identifie les indicateurs de performance métier (KPI)
• Chef de projet IA : Il accompagne le projet dans l’expression fonctionnelle des besoins et pilote leur traduction en réalisation technique et leur exécution. Il encadre l’équipe projet.

Spécialistes de data science :

• Data analyst : Il réalise des études autour des données, et en restitue les conclusions
• Data engineer : il analyse les besoins en données, il définit les processus de collecte et monitoring selon les modes d’interaction (batch, fil de l’eau)
• Data scientist : c’est l’expert en data science, il conçoit le pipeline de construction du modèle et produit / sélectionne le modèle
• Data visualizer : il élabore des visualisations des données et des résultats à destination des data scientists et des spécialistes métier
• Validateur de modèle : il s’assure de la validité du modèle et évalue ses conséquences non désirées éventuelles. Il assure une revue du modèle indépendante du développeur (data scientist)

Profils IT

• Architecte solution : il propose une architecture de solution, comprenant les contraintes de cybersécurité
• Administrateur plateforme de production : il est responsable de la plateforme informatique où s’exécutent les modèles. Il assure le traitement des alertes et les reprises sur incidents lors des phases d’apprentissage et d’inférence
• Machine learning engineer : il intègre les pipelines machine learning dans des processus Machine Learning Operations(MLOps)
• Architecte de données : il conçoit les infrastructures et les solutions Data, il identifie les différentes sources de données
• Data manager : Il assure l’organisation et la gestion des données sur son domaine de responsabilité. Il agit comme un référent pour les données.

Profils risque

• Coordinateur Sécurité / Security Champion : il apporte la déclinaison des politiques de sécurité pour le système IA
• Délégué à la Protection des Données (DPD) : il veille au respect de la réglementation sur la protection des données personnelle
• Responsable de la Sécurité des Systèmes d'Information (RSSI) : il décline les enjeux et besoins de sécurité pour le système IA. Il valide les niveaux de risques associés au système

Certains de ces profils sont transverses et interviennent sur de nombreux projets (sponsor métier, administrateur de plateforme de production, architecte données et profils risque) alors que d’autres sont dédiés à un projet et constituent une équipe projet. Les profils risque doivent donc intervenir aux côtés de profils IA dans des équipes projet mixtes.

2.3. LE PIPELINE IA

Cycle de vie

Nous présentons ci-dessous un schéma apportant une vue simplifiée du cycle de vie d'un modèle de machine learning et montrant les étapes au cours desquelles les différents types d’attaque peuvent avoir lieu. En haut de la figure, nous retrouvons donc les trois grandes familles d'attaque ; en bas de cette figure, les données du monde réel qui servent à alimenter l’entraînement ou les requêtes en phase d’inférence (c-à-d en production, appelée aussi phase de « run »). Enfin, entre les deux, nous montrons les 3 principales étapes par lesquelles passe le modèle : entraînement, évaluation et inférence (sachant que la construction sera itérative avec des allers-retours entre ces étapes).

Surface d'attaque

Les attaques se déroulent dans les diverses phases du cycle de vie du système Machine Learning. En outre, elles nécessitent plus ou moins de connaissances de la part de l’attaquant, tant en ce qui concerne les données (d’apprentissage notamment) que le modèle. Les données utilisées peuvent être attaquées plus ou moins facilement selon leur provenance : une entreprise pourra utiliser des données internes, des données achetées à un fournisseur extérieur ou bien des données disponibles en open source ; les niveaux de protection de ces sources sont alors évidemment très différents. De même, selon que le modèle est réalisé en interne ou sous-traité à une partie prenante externe, les attaques seront plus ou moins faciles.

Les briques du pipeline IA

Le pipeline de réalisation d’un processus IA comprend différentes étapes exécutées par l’intermédiaire de briques techniques communes aux différents projets, comme le montre la figure suivante qui décrit :

1. les objectifs métier : recueil des besoins et définition des KPI ;
2. la gouvernance des données : il s’agit de collecter les données (soit dans des sources internes -un data lake par exemple-, soit des sources externes ou open source), puis de les pré-traiter (data wrangling) ;
3. la modélisation : le modèle est produit par apprentissage sur les données d’apprentissage, et évalué sur les données d’évaluation. Un modèle est finalement choisi quand ses performances sont jugées satisfaisantes ;
4. le déploiement : le modèle choisi est mis en production et utilisé en mode « inférence »
5. La maintenance du modèle : les performances du modèle sont régulièrement contrôlées et des alertes sont levées quand les performances se dégradent (ce qui finira toujours par se produire, les conditions environnantes changeant au cours du temps. Il faut alors examiner les alertes et décider de la nécessité de ré-entraîner le modèle
6. Le transfert métier : le modèle, son mode d’exploitation et ses performances sont expliqués aux profils métier pour qu’ils puissent se l’approprier et l’intégrer dans leurs processus.

Ces briques sont supportées par différentes briques techniques organisées en plusieurs environnements :

• 2 et 3 : environnement d’entraînement & validation.
• 4 : environnement de production
• 5 : environnement de ré-entraînement (qui est le même que les SI d’entraînement / validation) si l’analyse des alertes montre la nécessité du ré-entraînement.

Les différents environnements ont pour fonctions de :

• Collecter les données
• Stocker les données
• Traiter les données
• Diffuser les résultats

La figure ci-dessous, représentant l’architecture de la plateforme ALEIA, montre les différentes briques techniques nécessaires, que nous ne décrirons pas toutes.

2.3.1.1. Ingestion de données / ETL

La collecte des données se fait, en général, en utilisant un outil spécialisé dit ETL (extract, transform, load) : on extrait les données de différentes sources (internes ou externes, voire open source), on les transforme (restructuration, analyses de qualité, enrichissements), puis on les charge, soit dans un data lake pour utilisation extérieure, soit dans une base de données propre à un projet.

2.3.1.2. Data Lake

Le data lake est une structure de stockage des données brutes dans leur format natif. Il comprend des données structurées, par exemple provenant de bases relationnelles, et des données non structurées (texte, vidéos par exemple). Un data lake permet le stockage de très gros volumes de données (big data), souvent sur une architecture en cluster. Il n'est pas optimisé pour les requêtes SQL comme les bases de données relationnelles classiques.

2.3.1.3 Répertoire de modèle / code / librairies

La réalisation des modèles nécessite différents composants :

• On définit un workflow pour spécifier les différents éléments du projet, les sources de données, les algorithmes d’apprentissage, les moteurs d’optimisation et les mesures de performance choisis.
• Des librairies d’algorithmes d’apprentissage sont utilisées (en général open source )

L’exécution de l’algorithme d’apprentissage sur les données choisies produit un modèle, souvent sous la forme d’un Jupyter notebook, une application web permettant de partager le code.

2.4. ENVIRONNEMENT D'ENTRAINEMENT, RE-ENTRAINEMENT, ET VALIDATION

L’environnement d’entraînement / validation / ré-entraînement (souvent appelé le « studio ») s’appuie sur les couches basses de collecte, stockage et préparation des données. Les profils data science sont les principaux utilisateurs de ces environnements.

Comme indiqué précédemment, ces environnements supportent les phases 2 et 3 (voire 5 s’il y a lieu de ré-entraîner le modèle) du pipeline IA. Concrètement, les tâches à exécuter, pour un projet IA donné et spécifié par les utilisateurs métier sont les suivantes :

1. Collecter les données choisies et les transformer : effectuer les pré-traitements, on devra ici s’assurer de la qualité des données, et notamment des données manquantes, des valeurs aberrantes (outliers) et des biais existants
2. Charger l’algorithme d’apprentissage retenu (depuis une librairie)
3. Exécuter l’algorithme d’apprentissage sur l’architecture technique choisie (serveur central, GPU, cloud)
4. Évaluer les performances obtenues sur les données d’apprentissage et de validation, après chaque itération (ou quelques itérations)
5. Quand l’apprentissage est terminé, stocker le modèle

Les principaux enjeux de sécurité sont la protection des accès aux données, la protection des calculs (pré-traitements et apprentissage) et la protection des résultats finaux (modèle et performances).

2.5. ENVIRONNEMENT DE PRODUCTION

L’environnement de production s’appuie sur les architectures standards des systèmes d’informations usuels (architecture n-tiers) et fournit les services de mise à disposition des modèles de machine learning (souvent appelé « serving ») ainsi que les capacités de monitoring nécessaires au suivi des déviations. Comme indiqué précédemment, cet environnement supporte les activités de passage en production et de maintien en condition de sécurité des machine learning. Une des approches du groupe de travail est l’exécution des modèles de machine learning au sein d’enclaves sécurisées exécutant uniquement les modèles.

2.5.1.1. Mise à disposition "Serving"

La mise à disposition de modèle est un environnement de calcul pouvant être fourni sous diverses formes tels que des API, des Web Services, des librairies ou des agents qui sont « embarqués » au sein du SI de production.

2.5.1.2. Enclave de sécurité

L’enclave de sécurité est un environnement durci limitant l’exécution de modèle avec des privilèges élevés et ainsi réduisant la surface d’attaque. Une enclave de sécurité permet également de faciliter la maintenance du système.