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 périmètre

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. Schéma d'un système 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 système 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.

2.6. Focus sur les librairies machine-learning

Les librairies de machine learning (LibML) sont des composantes essentielles à la mise en œuvre de projet IA. Celles-ci proposent des algorithmes standards et des fonctions d’entraînement nécessaires à tout modèle de machine learning. Les librairies machine learning sont très fréquemment open-source et utilisées telles quelles au sein des environnements data. De fait, ces librairies sont sensibles aux attaques de type supply chain liées à leur nature open-source.

Afin d’illustrer la structure de dépendance complexe engendrée par les pratiques actuelles en IA, nous fournissons ci-dessous la structure de dépendance engendrée par un projet (minimaliste) visant à utiliser des données textuelles pour réaliser une tâche de classification supervisée. Nous avons utilisé la méthodologie suivante : nous avons extrait les imports python d’un code exemple lors d’une compétition kaggle datant de 2017 (https://www.kaggle.com/anokas/data-analysis-xgboost-starter-0-35460-lb) en supprimant les librairies utilisées uniquement pour l’affichage de résultats. Le fichier requirement.txt résultant est alors le suivant :

• numpy
• pandas
• seaborn
• scikit-learn
• nltk
• xgboost

On utilise ensuite pipgrip afin d’en déduire la structure de dépendances associée :

Faisons à présent le même exercice pour un projet traitant des images (https://www.kaggle.com/rajmehra03/flower-recognition-cnn-keras) :

• numpy
• pandas
• scikit-learn
• keras
• tensorflow
• tqdm

Comme étudié dans les travaux récents par Ohm et al. (2020), plusieurs approches sont possibles pour concevoir une attaque « supply chain » en exploitant les éléments les moins sécurisé de cette chaîne de dépendances. En particulier, l’analyse de 174 packages spécifiques issus des environnements node.js, python, et ruby ont montré d’ores et déjà une exploitation active. Les approches employées sont illustrées dans la figure suivante (provenant du même article).

De plus, certaines librairies machine learning fournissent des modèles pré-entraînés qui décalent les enjeux et mesures de sécurité liées à l’entraînement auprès des tiers ayant réalisé le pré-entraînement.

2.7. Focus sur les modèles pré-entrainés

Au-delà des pratiques classiques consistant à apprendre un modèle à partir d’un jeu de données acquis par une entreprise, une approche récente consiste à utiliser des modèles pré-entrainés . Cette technique repose sur le principe suivant : dans les domaines tels que le traitement du langage naturel et la vision par ordinateur, les approches actuelles les plus performantes reposent sur des réseaux de neurones profonds, comprenant de très nombreuses couches, donc des millions de paramètres. Pour les entraîner, il faut donc des jeux de données (datasets) extrêmement volumineux (des centaines de millions d’exemples), qui ne sont, en général, disponibles que pour quelques entreprises (GAFA).

Pour ces modèles, il a été observé que les caractéristiques construites par les couches successives des réseaux de neurones constituent un puissant espace de représentation pour de nombreuses tâches connexes à celles pour lesquelles le réseau de neurones a été initialement développé: la couche de représentation (embedding) résume en quelque sorte la connaissance de ce qu’est un texte (ou une image) ; entraîné sur une certaine collection de textes, cette représentation pourra également être signifiante pour une autre collection de textes (on parle de transfert d’une collection à une autre). Par conséquent de nombreux modèles pré-entrainés sont aujourd’hui disponibles dans ces domaines d’application, permettant aux développeurs d’intelligence artificielle de s’appuyer sur des réseaux existants, sans avoir à disposer d’énormes datasets : on charge le modèle pré-entraîné, puis on refait quelques itérations d’apprentissage avec son propre dataset.

Pour des exemples précis de modèles pré-entrainés, ainsi que les tâches précises associées, le lecteur intéressé pourra explorer la bibliothèque mise à disposition par HuggingFace , qui contient plus de 30 000 modèles pré-entrainés.

3. APPLIQUER EBIOS RISK MANAGER A UN PROJET D'INTELLIGENCE ARTIFICIELLE, LES ELEMENTS CLES

3.1. Hypothèses

Lors de la rédaction de ce document, de nombreuses questions ont été posées et des hypothèses structurantes apportées. De par la complexité liée au continuous learning (ou reinforcement), ces aspects ont été exclus de l’analyse des risques réalisée. En complément, il a été unanimement convenu que l’approche « Keep Human In The Loop  » devait être respectée pour les systèmes d’intelligence artificielle dans l’ensemble des usages d’entreprises.

3.2. LES BONNES QUESTIONS A SE POSER POUR COMMENCER L'EVALUATION D'UN SYSTEME

D’un point de vue de la cybersécurité, nous avons vu dans les parties précédentes qu’un système intégrant une intelligence artificielle a de nombreuses spécificités. Lors des échanges conduits dans le groupe de travail, nous avons identifié trois grandes catégories de questions qui apparaissent lorsqu’on intègre une intelligence artificielle :

1. La finalité. L’évaluation d’un système utilisant une intelligence artificielle nécessite de définir avec précision la finalité des sorties fournies par l’intelligence artificielle. Un critère clé pour segmenter cette analyse est de s’interroger sur le degré d’autonomie de l’intelligence artificielle. Celui-ci dépend de la fréquence ainsi que de la latence de la prise de décisions. Si l’humain peut superviser ou contrôler les prises de décisions relativement lentes, par exemple dans le cas de l’identification des employés les plus susceptibles de quitter une entreprise, certains secteurs d’activités ne pourront pas intégrer l’humain de manière régulière, par exemple dans le cas de transactions financières ou encore réponses automatisées à des attaques DDoS. Ainsi l’évaluation d’un système intégrant une intelligence artificielle doit s’interroger sur l’implication humaine dans l’utilisation des résultats fournis par l’intelligence artificielle :
   1. assistance à la décision humaine, ie augmentation de l’humain,
   2. simple monitoring humain de bon fonctionnement, ie automatisation monitorée,
   3. autonomie complète de l’intelligence artificielle dans ses prises de décision.

1. Les données. Une intelligence artificielle est, d’un point de vue informatique, une succession d’instructions élémentaires (exécution d’un algorithme) qui ont été construites à partir de données, et non pas écrites par un humain comme c’est le cas pour les programmes informatiques conventionnels. A partir de cette observation, il découle que la place des données dans l’évaluation d’un système intégrant une intelligence artificielle est primordiale. Pendant la phase d’entraînement de l’intelligence artificielle, une analyse approfondie doit donc être menée pour comprendre et cartographier la provenance et les caractéristiques des données utilisées. On s’interrogera donc sur la fiabilité, la disponibilité, ou encore la licence des données utilisées. Cette dépendance aux données doit également conduire l’évaluateur d’un système à base d’intelligence artificielle à comprendre finement la chaîne d’approvisionnement de la donnée, lors de la phase d’entraînement pour en contrôler la provenance, mais surtout ensuite lors de la phase de test pour assurer des résultats fiables.

1. Le modèle. Enfin, une intelligence artificielle implémente, d’un point de vue mathématique, un modèle, fonctionnant souvent sur des principes statistiques. Si le modèle est effectivement une succession d’instructions élémentaires capables de fournir une sortie (prévision, recommandation, ...) à partir de données d’entrée, celui-ci s’appuie souvent sur de nombreuses bibliothèques externes, dans des écosystèmes variés (python, R, java). Il constitue ainsi un élément fondamental de l’intelligence artificielle, et l’évaluation d’un système intégrant une intelligence artificielle doit donc s’interroger sur de nombreuses caractéristiques des modèles :
   1. Qui accède au modèle pendant les différentes phases du cycle de vie des IA ?
   2. Qui peut modifier le modèle ?
   3. Quelle est la chaîne de dépendance du modèle envers des bibliothèques externes ? Un cas particulier de dépendance doit par ailleurs être pris en compte dans le cas où un modèle pré-entraîné est utilisé. En effet, cette possibilité simplifie dans de nombreux cas le développement de nouvelles intelligences artificielles, en limitant la nécessité de bases de données conséquentes, mais elle crée de nombreuses failles sur la maîtrise du modèle mis en production. Ces failles peuvent être de nature informatique (backdoors) ou statistique (modèle peu fiable).

Le schéma suivant regroupe les éléments les plus prépondérants

3.3. Méthodes et métriques a utiliser pour évaluer la sécurité d'un système IA

L’évaluation des risques, et en particulier du niveau de menace requiert une prise en compte des spécificités liées aux systèmes d’intelligence artificielle. En conséquence, l’échelle de pénétration a été revue en incluant deux critères complémentaires :

• le premier est l’accès aux données, identifiant la capacité d’une partie prenante à accéder et interférer avec les données des systèmes. Cette échelle permet de déterminer si les acteurs peuvent altérer les données ;
• le second est l’accès au modèle de machine learning utilisé pour permettre au système intelligence artificielle de fonctionner. Cette échelle permet ainsi de déterminer si les acteurs peuvent altérer le modèle.

3.4. Analyse EBIOS RM

Atelier 1 - Définir le cadre de l'étude

3.4.1.1. Identifier les valeurs métiers

Contrairement aux projets traditionnels, les projets incluant des traitements à base d’intelligence artificielle ne sont pas conçus ou identifiés a priori, c’est-à-dire que ceux-ci n’ont pas forcément de spécifications claires. En conséquence, la phase de cadrage doit servir à définir et formaliser les attendus de sécurité et de conformité. Ceux-ci seront ensuite complétés au fur et à mesure de la conception des traitements utilisant de l’intelligence artificielle.

Dans cette phase, il est essentiel d’identifier les 'traitements' et 'valeurs métiers éligibles' à l’utilisation d’intelligence artificielle, c’est-à-dire identifier les traitements du système 'pouvant être ou étant réalisés' en intégrant un composant d’intelligence artificielle.

Pour cela, il est nécessaire :

• de cartographier les traitements du système ;
• d’identifier les composants et actifs du système ;
• d’identifier les traitements du système dans lesquels l’intelligence artificielle est utilisée ou utilisable.

Une fois identifiées, les valeurs métiers faisant l’objet de traitement à base d’intelligence artificielle font l’objet d’analyses complémentaires présentés dans les ateliers suivants.

3.4.1.2. Identifier les biens supports

Lors de l’identification des biens supports, les valeurs métiers doivent prendre en compte les différents systèmes utilisés dans un traitement intelligence artificielle (i.e. de la phase d’entraînement à la phase d’exécution en production) afin de n’omettre aucun risque induit sur le système visé par l’étude.

D’une manière générale, un système d’intelligence artificielle est composé de deux environnements distincts :

• le système de production, porteur du traitement réalisé pour le métier ;
• le système d’entraînement, validation et ré-entraînement, permettant aux équipes IT de construire les composants du traitement d’intelligence artificielle.

3.4.1.3 Identifier les évènements redoutés

La caractérisation des 'événements redoutés' (ER) permet d’identifier les enjeux et les objectifs de sécurité attendus. Afin de spécifier les enjeux et objectifs associés à un traitement d’intelligence artificielle, une échelle temporaire peut être utilisée pour affiner les attentes et déterminer les événements redoutés.

3.4.1.4 Déterminer le socle de sécurité

Lors de la définition du socle de sécurité, les éléments suivants doivent être pris en compte pour évaluer le niveau de sécurité attendu par le système :

• Transparent et interprétable : consiste à être clair, transparent et compréhensible sur la façon et la raison pour laquelle les données sont utilisées. Un traitement transparent et interprétable doit être compréhensible par les utilisateurs du système, c’est-à-dire dans un langage technico-fonctionnel adapté au contexte (ex : dans le cas d’une demande de crédit, le traitement réalisé par intelligence artificielle doit présenter étapes de décision, permettant à un conseiller de présenter les conclusions au demandeur dudit crédit. Une réponse binaire ‘Approuvé’ ou ‘Rejeté’ n’est ni transparent, ni interprétable par les utilisateurs du système). Il est par essence exclut d’inclure le langage propre à l’IT pour rendre interprétable un traitement d’intelligence artificielle ;

• Imputabilité des actions : attribut de démonstration que les traitements réalisés avec, ou assistés par, intelligence artificielle sont les même que ceux réalisés sans intelligence artificielle. L’imputabilité des actions est un concept fondamental dans la sécurité de l’information. Ainsi, une application d’intelligence artificielle ne doit être que le prolongement ou l’automatisation d’un traitement réalisable par une intelligence humaine.

Atelier 2 - Identifier les couples Sources de risques / Objectifs visés (SR/OV)

La phase d’identification des sources de risques et des couples SR/OV peut être réalisée lors de la phase d’initialisation et de conception d’un projet. Pour une application utilisant de l’intelligence artificielle, cette règle reste vraie. Lors de l’identification des objectifs visés par les sources de risques, il est nécessaire de prendre en considération les éléments suivants, pouvant intervenir dans l’évaluation de la pertinence des couples SR/OV :

• 'Vol ou divulgation de propriété intellectuelle ou de secret industriel' : évaluer si le savoir-faire transmis et intégré dans le traitement réalisé par machine learning peut être source de convoitise ou de divulgation pour des cybercriminels ;
• 'Biais d’un traitement' : évaluer si le biais d’un traitement peut impacter les traitements réalisés par machine learning et bénéficier à un cybercriminel ;
• 'Atteinte à l’intégrité d’un processus autonome' : porter atteinte aux missions de l’entreprise en modifiant le comportement d’un processus autonome afin de le rendre inopérant ou non efficace.

Dans le cadre de l’étude des sources de risques et objectifs visés du projet anonymisé, les sources de risques sélectionnées permettent d’obtenir un panorama usuel des menaces liées au système étudié. En conséquence, trois couples SR/OV ont été retenus :

Tableau 10 - Liste des couples Sources de Risque / Objectifs Visés

L’identification des scénarios stratégiques fait intervenir l’évaluation des scénarios liés aux parties tierces et aux partenaires. Dans le cas d’une application utilisant des traitements à base d’intelligence artificielle, les composants liés au système d’entraînement doivent être considérés comme vecteur de la menace numérique.

Atelier 3 - Elaboration des scénarios stratégiques

3.4.1.5. Cartographie de la menace numérique et des parties prenantes

Lors de la conception d’une application utilisant l’intelligence artificielle, de nombreux modes opératoires peuvent être envisagés, parmi cet ensemble, deux catégories se distinguent :

• L’entraînement de modèle « in-house » ou au sein de l’entreprise, il s’agit de l’utilisation de compétences et de développement réalisés par et au sein de l’entreprise, celle-ci fait donc intervenir des équipes internes de 'Data Scientists' et de Data Engineers, pouvant être assimilés aux parties prenantes critiques (PPC) ;
• L’utilisation de modèles commercialisés ou pré-entrainés, incluant l’utilisation de parties tierces, développant et maintenant le modèle d’intelligence artificielle en condition opérationnelle. Dans ce cas, les parties prenantes critiques (PPC) inclus le fournisseur de modèle utilisé par le système.

3.4.1.6 Constitution des scénarios stratégiques intelligence artificielle

Lors de l’élaboration des scénarios stratégiques, les éléments suivants doivent être pris en compte :

• L’attaque par l’intermédiaire des environnements des data scientists et data engineers. Les environnements de travail des data scientists sont généralement contrôlés (plus faiblement que pour les administrateurs des systèmes d’information), mais peuvent être de forts vecteurs de la menace numérique, en particulier lorsque ceux-ci proviennent de tiers ;
• L’attaque par l’intermédiaire des partenaires de diffusion des librairies de data science utilisées. Les librairies proviennent de répertoires publics, multi-contributeurs et leur sécurité peut ne pas être évaluée. Ces librairies peuvent ainsi inclure du code malveillant, et compromettre le système dans les phases d’entraînement et de production ;
• L’attaque par l’intermédiaire du système d’entraînement. Les systèmes de production et d’entraînement étant liés, la propagation d’attaque, bien que limitée, reste probable par le biais d’un modèle entraîné ou d’un moyen de distribution corrompu.

Les scénarios stratégiques sélectionnées dans le cadre de l’analyse réalisée permettent d’identifier les cas usages dans lesquels les risques sont fortement liés à l’utilisation d’un système d’intelligence artificielle, en conséquence, les risques forts mais ne faisant pas intervenir d’attaque liées à l’intelligence artificielle ont été exclus. En particulier, les scénarios ont été contextualisés en fonction des connaissances de l’attaquant définies par les catégories suivantes :

• Boite noire : l’attaquant n’a pas d’information sur le modèle ;
• Boite grise : l’attaquant a quelques informations, sur le type d’algorithme utilisé, ou bien les paramètres en entrée, ou encore une partie des données d’entraînement ;
• Boite blanche : l’attaquant a pleine connaissance du modèle (type, entrées, paramètres, etc.).

Tableau 13 - Récapitulatif des chemins d’attaque des scénarios stratégiques (à mettre)

Atelier 4 - Elaborer les scénarios opérationnels

L’identification des scénarios opérationnels dépend de fortement des technologies et des méthodes d’analyses utilisées. Parmi les références utilisables, l’Open Source INTelligence (OSINT), l’Open Web Application Security Project (OWASP) ML et eXplainable AI DARPA peuvent être utilisées pour identifier les principales méthodes d’attaques sur les modèles d’intelligence artificielle.

3.4.1.7. Identification des biens supports du scénario

Parmi les scénarios opérationnels fréquemment envisagés, les biens supports suivants doivent être considérés au sein du chemin d’attaque (ou mode opératoire) du scénario :

• Les sources de données provenant de systèmes tiers, pouvant être compromis par d’autres vecteurs de menace ;
• Les pipelines de data science, identifiés par les composants d’acquisition et de traitement des données, d’ingénierie et d’entraînement des modèles ;
• Les méthodes et actifs de livraison des modèles, identifiés pas les phases de packaging, de livraison et de déploiement des modèles entraînés.

3.4.1.8. Formalisation des scénarios opérationnels

Afin de déterminer les scénarios opérationnels liés aux systèmes intelligence artificielle, les références du MITRE ATT&CK et MITRE ATLAS . De plus, afin d’aiguiller les référents sécurité, l’ensemble des actions élémentaires évaluées inclus des éléments concernant la maturité de l’attaque, ainsi que l’environnement impacté :

Maturité des actions élémentaires :

• Papier : l’action élémentaire est documentée dans des papiers de recherche mais n’a pas été recensée par les membres du Groupe de Travail ;
• POC (Proof of concept) : l’action élémentaire est documentée et des exploits sont disponibles pour exécution en environnement maîtrisé ;
• INDUS (Industrialisation) : l’action élémentaire est activement utilisée pour réaliser des attaques sur le système intelligence artificielle.

Environnement impacté :

• TRAIN (Training, Formation) : référence l’environnement utilisé pour réaliser l’entraînement des modèles de machine learning ;
• DEV (Développement) : référence le système d’information utilisé pour réaliser le développement du système intelligence artificielle sans la partie entraînement du modèle de machine learning ;
• PROD (Production) : référence le système d’information utilisé pour la production et la mise à disposition des modèles de machine learning.

Les hypothèses suivantes ont également été prises pour l’enchaînement des actions élémentaires entre les environnements :

• TRAIN —> DEV : possible via la mise à disposition du modèle lors des phases d’évaluation et de mise en production ;
• TRAIN —> PROD : possible via la mise à disposition du modèle lors de la phase de mise en production ;
• DEV —> TRAIN : non évalué dans le cadre de l’étude réalisée ;
• DEV —> PROD : possible via l’intégration de code utilisé en production ;
• PROD —> TRAIN : possible par l’accès d’acteurs de la production aux environnements d’entraînement ;
• PROD —> DEV : non évalué dans le cadre de l’étude réalisée.

En synthèse, l’évaluation d’une action élémentaire, suivant la méthode EBIOS RM peut se formaliser de la façon suivante :

Fichier:Image2.13.png

Figure 2 - Action élémentaire évaluée

3.5 Principales attaques sur les modèles et le pipeline de données

Nous présentons succinctement une typologie des cibles d’attaques contre la confidentialité, contre l’intégrité et contre la disponibilité. On peut noter qu’une attaque à l’intégrité peut aussi impacter la disponibilité (voir section empoisonnement). Cette section s’appuie largement sur le travail présenté dans le draft du NIST relatif aux attaques contre les systèmes machine learning, référencé en [10], que nous avons tenté de croiser avec la vision classique de la sécurité (protection/détection en lien avec confidentialité, intégrité et disponibilité).

Les attaques contre le machine learning peuvent être regroupées en 3 grands famille (empoisonnement, oracle et évasion) :

Empoisonnement Un attaquant modifie le corpus de données utilisé pour entraîner les modèles afin d'altérer ou d’influencer le comportement de ces systèmes lorsqu'ils seront déployés en production. Oracle (inférence, extraction) Un attaquant crée des entrées et reçoit des sorties du modèle attaqué, dans le but d'obtenir des informations sur ce modèle - et même parfois sur les données d'entraînement. Evasion Un attaquant modifie de manière malveillante une requête sur le modèle attaqué afin que celui-ci produise un résultat erroné.

Ces attaques couvrent l’ensemble du cycle de vie d’un système à base de machine learning, de la phase de collecte des données, à l’inférence (en test, phase UAT – User Acceptance Test – ou en « run » – production), en passant par les phases de préparation des données puis d’apprentissage. L’attaque peut toutefois être plus difficile à mettre en œuvre dans certaines phases. Ainsi, en phase de run, des mécanismes de sécurité spécifiques seront certainement mis en œuvre (exemple : limitation du nombre d’interrogations via une API). La figure ci-dessous résume cette couverture de l’ensemble du cycle de vie d’un système à base de machine learning :

Certaines attaques peuvent nécessiter de connaître le modèle (on parle alors d’attaque en boîte blanche). Dans d’autre cas cela n’est pas nécessaire, l’attaque peut avoir lieu en boîte noire. La connaissance dont peut disposer l’attaquant définit un « modèle d’attaque » : ce modèle est important à considérer lorsqu’on fait une analyse de risque pour un système machine learning concret. Il permet de définir les attaques qui sont possibles et donc contre lesquelles on va lutter.

Dans certains cas, on peut considérer que l’attaquant dispose d’informations partielles seulement (architecture du modèle, par exemple) ; on parle alors d’attaque en boîte grise. Un grand nombre d’attaque (empoisonnement et évasion notamment) sont transférables entre modèles similaires. Autrement dit, si un attaquant a accès aux données d’apprentissage du modèle qu’il souhaite attaquer et qu’il apprend lui-même un modèle à partir de ces données, alors il pourra concevoir des attaques sur son système (en boîte blanche) et ces attaques auront de grandes chances de fonctionner sur le modèle qu’il souhaite attaquer (en boîte noire). Cela est possible même si les deux modèles (celui attaqué et celui entraîné par l’attaquant, appelé en anglais surrogate model) n’ont pas la même architecture. Voir par exemple https://arxiv.org/abs/1610.08401 (perturbations « universelles » qui, appliquées à de nombreuses images, permettent une évasion de plusieurs modèle) ou https://www.usenix.org/system/files/sec19-demontis.pdf (expériences avec de nombreux modèles différents). Ces articles établissent en particulier des propositions permettant de rendre les modèles plus robustes aux attaques « transférable » d’une architecture de modèle à une autre, notamment via une simplification du modèle qui se fera probablement au prix de la performance : un tel choix pourra être fait en mesurant cet impact.

Le tableau ci-dessous résume les différents types d’attaque identifiés du point de vue cycle (en colonne) et impact (en ligne). Il faut noter, d’une part que nous n’avons pas cherché l’exhaustivité, d’autre part que certaines attaques (en italique dans le tableau) sont des attaques n’exploitant pas les spécificités du machine learning, tandis que d’autres (en gras dans le tableau) exploitent au contraire ces spécificités.

Attaques contre la phase de collecte

En agissant sur le canal de collecte (écoute, perturbation), l’attaquant peut naturellement, sans exploiter de spécificité machine learning, attenter à la confidentialité (écoute) ou à la disponibilité (perturbation) des données. En agissant sur les capteurs (modification illégitime de leur logiciel, par exemple), l’attaquant peut générer des données qui vont empoisonner la base d’apprentissage.

Attaques contre la phase de préparation des données et apprentissage

Les attaques contre la phase d'apprentissage ont pour but de voler (attaque à la confidentialité) ou d’altérer (attaque contre l’intégrité ou la disponibilité) les données ou le modèle produit en lui-même.

Atteinte à la confidentialité 

Le vol (tant des données d’apprentissage que d’un modèle entraîné) passe par des attaques informatiques classiques (au sens où elles ne sont pas spécifiques à un vol de données destinées à faire de l’apprentissage). On pourra donc ici considérer toutes les techniques classiques d’atteinte à la confidentialité : pénétration de système par usurpation d’identité (par exemple via un vol préalable de mot de passe), exploitation d’une vulnérabilité pour obtenir un accès au système sur lequel sont stockées les données, exfiltration par un virus, etc. Les techniques d’attaques étant classiques, on se protégera par des techniques de sécurité classiques également (par exemple : contrôle d’accès, chiffrement des données, détection d’intrusions).

On peut noter ici que le vol de données d’apprentissage pourra permettre à l'attaquant de créer son propre modèle, qui pourra être exploitée en tant que tel pour inférence, voire, plus subtilement, pour tester des entrées potentielles à soumettre en tant qu'attaques dans la phase d'inférence (voir ci-après).

Atteinte à l’intégrité

L’intégrité du modèle peut être attaquée par une modification du modèle appris de manière à faciliter les attaques lors de la phase d’inférence sans affecter le comportement du système sur des données légitimes.

Pour ce faire, l’empoisonnement des données est réalisé en modifiant la base d’apprentissage par injection de données supplémentaires (modifiant ainsi la distribution des données sous-jacentes sans changer les caractéristiques ou les étiquettes des données d'entraînement originales) ou modification des données en elles-mêmes (modification des labels ou des valeurs de données).

La modification du modèle peut être indirecte ou directe. La modification indirecte passe par la modification de l’exécutable implantant l’algorithme d’apprentissage, lorsque cet exécutable est stocké sur disque ou après son chargement en mémoire pour exécution. Il s’agit donc d’attaques classiques, mais qui modifie la logique du machine learning. Modifiant l’apprentissage, on modifie bien sûr le modèle produit. La modification directe du modèle peut aussi se faire sur disque ou en mémoire.

Remarque : parfois, pour protéger des informations personnelles, les données d’apprentissage sont distribuées sur un ensemble de machines afin d’assurer qu’aucune entité centrale ne les possède entièrement. Dans ce cas, l’apprentissage est « fédéré » : un modèle « central » voit ses poids ajustés à partir de modèles calculés localement par les participants. Ces modèles locaux peuvent eux-mêmes être potentiellement compromis par un attaquant. En outre, les communications entre machines nécessaires dans cette forme d’apprentissage peuvent être classiquement attaquées.

Atteinte à la disponibilité 

Ici, il s’agit en phase de préparation des données et d’apprentissage, d’empoisonner les données afin de préparer une future indisponibilité en phase d’inférence (avec un trigger particulier qui par exemple va causer une charge de calcul importante pour le modèle). La plupart des modèles sont supposés être robustes à ce type d’attaque (cas des réseaux de neurones pour lesquels le temps de calcul est généralement quasi indépendant des données) mais certains peuvent être particulièrement vulnérables surtout à des entrées très spécifiques (cas d’algorithmes K-NN dont le temps de calcul peut exploser dans des zones à fortes densités).

Attaques contre la phase d’inférence (test ou run)

En phase de test, des attaques classiques visent à voler des données (de test) ou le modèle. Par ailleurs, en phase finale des tests (modèle quasi-près), il est possible de faire des attaques similaires à celles qui seraient réalisées en phase de run, qui visent :

• à générer des exemples d’entrées permettant de déduire des informations sur le modèle ou sur les données qui ont été utilisées pour l’apprentissage (on parle alors d’attaques par oracle). Il s’agit donc ici d’attaque à la confidentialité (on note ici qu’une attaque au niveau de l’inférence peut entraîner la violation de la confidentialité des données d’apprentissage) ;
• ou à générer des exemples d’entrées (on parle d’exemples adverses) capables d'échapper à une classification correcte (on parle alors d’attaques d’évasion). Ces attaques violent l’intégrité du résultat attendu. Ces données peuvent être forgées directement, ou engendrée à partir d’une perturbation du domaine physique (par exemple port de lunette spéciale pour empêcher la reconnaissance faciale).

Atteinte à la confidentialité

En test, des attaques classiques visent à voler des données (de test) ou le modèle.

En run, les attaques consistent à observer des valeurs de sortie et/ou des valeurs de confiance pour en déduire certaines caractéristiques du modèle (on parle alors parfois d’attaque par extraction) ou des données d’apprentissage (on parle alors d’attaque par inversion). Une autre forme d’attaque consiste pour l’attaquant à observer les réponses du modèle à certaines requêtes pour déterminer si des valeurs spécifiques étaient présentes dans les données d'apprentissage (attaque d’appartenance) : l’attaquant exploite ici les différences de confiance du modèle entre des valeurs vues pendant l'apprentissage et des valeurs non vues.

Atteinte à l’intégrité

En test, l’attaquant cherche par des attaques classiques à modifier le modèle stocké sur disque. En run, l’attaquant cherche une perturbation d'entrée (si possible non évidente à déceler par un opérateur humain) qui entraîne une mauvaise classification en sortie.

Atteinte à la disponibilité

En test, des attaques seraient possible, mais n’apporteraient rien à l’attaquant, sauf cas exceptionnel. En run, en revanche, il s’agit d’empêcher le modèle de produire une inférence, en présentant l’entrée (trigger particulier) qui va causer par exemple une charge de calcul importante pour le modèle.

Comme nous l’avons mentionné précédemment dans ce document, les attaques contre le machine learning peuvent être, soit similaires à celles qui sont classiquement lancées contre tout système d’information (vol de données, l’usurpation d’identité, le déni de services, etc.) soit de nouvelles formes d’attaques dirigées spécifiquement contre les mécanismes de machine learning. Ces dernières peuvent être regroupées en 3 grandes familles (empoisonnement, oracle et évasion) d’attaque sur les modèles ainsi que deux familles attaques sur la supply chain (data supply et library supply) sur lesquelles nous nous focalisons ici.

LES RECHERCHES DU GROUPE DE TRAVAIL ONT ESSENTIELLEMENT IDENTIFIE LE MITRE ATLAS  COMME REFERENCE LITTERAIRE AINSI QUE DES SCHEMAS D’ATTAQUES RENCONTRES

Attaque par empoisonnement des données d’entraînement

Un attaquant modifie le corpus de données utilisé pour entraîner les modèles afin d'altérer ou d’influencer le comportement de ces systèmes lorsqu'ils seront déployés en production.

Figure 3 - Attaque par empoisonnement des données

Figure 4 - Attaque ciblée sur l'empoisonnement des données

Ce type d’attaque est particulièrement problématique car persistant si non détecté. En outre, en cas de détection, un réentraînement complet du modèle est nécessaire.

Deux scénarios sont possibles pour ces attaques, illustrés par les figures 2 et 3 ci-dessus :

• Dans le cas des modèles dont les bases d’entraînement sont non publiques (Fig. 2), l’attaquant doit au préalable gagner l’accès aux données internes de la cible afin de pouvoir les modifier. Il s’agit donc d’actes malveillants internes (compte valide) ou de compromission plus générale de l’environnement de la cible (usurpation de compte). Une fois le droit d’accès acquis, l’attaquant peut modifier les données elles-mêmes ou les méta-données associées (étiquettes).

• Dans le cas de modèles apprenant sur des données publiques (Fig. 3) de façon continue (par exemple des systèmes de recommandations ou les algorithmes de classement de recherches Google), l’attaque par empoisonnement sera réalisée, soit en empoisonnant les données collectées par le pipeline de génération de données d’entraînement (ce qui ramène au cas précédent), soit en générant de fausses données (faux avis ou recherches ciblées dans nos exemples) en grande quantité afin d’avoir un impact significatif sur les données d’apprentissage disponibles.

Voir en annexe (section 4, Fig. 18, 19 et 20) pour une vision plus complète de l’intégration de ces attaques dans une kill chain.

Ce type d’attaque est très utilisé par des spammeurs sur les recherches Google afin de faire remonter des services frauduleux en premiers résultats. Des attaques visant l’outil de détection de spam de Gmail ou Virus Total ont également été recensées.

Ces attaques sont relativement aisées à mettre en œuvre pourvu que l’on dispose de moyens permettant la génération et la diffusion de données en grande quantité, d’autant plus que les comportements des modèles ciblés peuvent être approximés.

Attaque sur la chaîne d’approvisionnement des données – data supply 

Un attaquant altère la chaîne d’approvisionnement de la donnée afin d’induire un entraînement ou un ré entraînement biaisé pour atteindre les objectifs qu’il a fixé.

Figure 5 - Attaque sur la supply chain data

Ce type d’attaque peut être réalisé de façon persistante ou ponctuelle en fonction de la porte d’accès aux données. Par exemple, la compromission d’une solution éditeur permet d’obtenir un accès persistant dans le système et ainsi perturbé de façon pérenne les activités du système ciblé. A contrario, une intervention ponctuelle via la modification d’un flux de données (MITM-attack) ou d’une attaque physique (Side Channel Attack ) peut altérer les prédictions pendant une durée déterminée afin d’atteindre un objectif précis.

Deux types d’altérations ont pu être constatées au travers de la chaîne d’approvisionnement :

• Dans le cas où les modifications altèrent les données d’entraînement, celui-ci est perturbé ce qui permet de « cacher » (Class-Oriented Poinsoining attack ) les classes de données et ainsi induire un comportement au modèle entraîné. Une fois cette altération mise en œuvre, il est complexe de la détecter sans expertise forte concernant les données ;

• Dans le cas où les modifications altèrent les données utilisées lors des phases de validation, ceci permet de perturber le processus d’évaluation des performances des modèles, et ainsi perturber la capacité de l’entreprise à mettre en production le modèle. Cette altération peut aisément être détectée a posteriori mais est terriblement efficace pour des attaques ciblées dans le temps (cas d’une élection par exemple).

• Ces attaques sont fortement dépendantes du niveau de sécurité des données d’entrées du modèle et du niveau de sécurité des solutions logicielles utilisées pour mettre à disposition les données. Il est par ailleurs aisé de mettre en place ces attaques de façon non ciblée en packageant celles-ci dans des logiciels légitimes. Plus les données sont complexes, plus une attaque de ce type est efficace et complexe à détecter.

Attaque sur la chaîne d’approvisionnement des bibliothèques – library supply

Un attaquant altère la chaîne d’approvisionnement des bibliothèques machine learning utilisées afin d’introduire une redirection de trafic en utilisation ou une altération des résultats basée sur des triggers.

Figure 6 - Attaque sur la supply chain du modèle

Ce type d’attaque peut être réalisée de différentes façons, il est par exemple possible de modifier la bibliothèque au sein de son répertoire de code (npm repository package compromised ) ou lors de son intégration dans les environnements de production.

Ces attaques sont fortement dépendantes du niveau de sécurité des bibliothèques et des processus de distribution de celles-ci au sein de l’entreprise. Les mesures de qualification et de validation de la mise à disposition des logiciels (ou bibliothèques) sont très efficaces contre ce type d’attaque.

Attaque par oracle sur le modèle en production

Un attaquant crée des entrées et reçoit des sorties du modèle attaqué, dans le but d'obtenir des informations sur ce modèle - et même parfois sur les données d'entraînement.

Les façons d’accéder à un modèle peuvent être très variées et n’ont comme limite que l’imagination des hackers ou vengeurs. Quelques-unes d’entre elles sont décrites en annexe dans les modes opératoires des chemins d’attaque (scénarios d’attaque du cas d’étude). Le cas le plus simple est une API accessible librement, ou dont un compte d’accès a été piraté, sur notre modèle.

Nous partons donc du postulat que l’attaquant peut faire suffisamment de requêtes sur le modèle et récupérer les sorties/résultats de celui-ci. Cette condition est un prérequis pour ce type d’attaque !

Il existe de nombreuses boites à outils permettant l’extraction du modèle (sur github, en open source), voire des données ayant servies à l’entraînement. Nous arrivons ainsi à dupliquer de façon plus ou moins fidèle le modèle original, en fonction de l’algo ayant servi à l’attaque et du type de modèle.

Il est à noter que ce modèle de substitution pourra servir aussi à générer des exemples adverses (des inputs permettant de faire de l’évasion, autrement dit tromper une intelligence artificielle) qui serviront le moment opportun en production.

Parmi les familles d’attaques recensées, il y a les :

• Attaques d'extraction
• Attaques d'inversion
• Attaques par inférence d'appartenance

Une attaque grand public reconnue à ce jour a été celle faite contre GPT2 d’Open AI. Sources

• https://www.wired.com/story/dangerous-ai-open-source/
• https://blog.usejournal.com/opengpt-2-we-replicated-gpt-2-because-you-can-too-45e34e6d36dc

Parmi les techniques de défense, nous trouvons actuellement 2 grande familles :

• la robustesse du modèle
• la confidentialité différentielle

Pour plus d’information sur ces boites à outil, vous pouvez consulter :

• https://github.com/EthicalML/awesome-production-machine-learning#adversarial-robustness-libraries

Attaque par évasion sur le modèle en production

Une attaque par évasion se produit lorsque le modèle reçoit un « exemple contradictoire » - une entrée soigneusement perturbée qui ressemble et est perçue exactement comme sa copie non falsifiée pour un humain - mais qui perturbe complètement le modèle. De fait, il est possible pour des acteurs malveillants de créer (craft) ou d’essayer (draft) de produire des données d’entrées qui seront interprétées de façon erronée. L’acteur malveillant peut ainsi déjouer des mécanismes de sécurité en place .

Figure 8 - Attaque par oracle sur les données RH

3.6. Les principales mesures de sécurité à adopter

Les quatre premières bonnes pratiques organisationnelles à mettre en place afin de limiter les risques liés aux systèmes d’intelligence artificielle sont :

1. Mettre en œuvre un comité éthique et risques pour sélectionner les cas d’usages intelligence artificielle pertinents pour l’entreprise et les données autorisées

La mise en place d’un comité éthique et risques doit permettre d’évaluer la pertinence des cas d’usages par rapport à la stratégie et aux risques encourus par l’entreprise. Similaires aux comités d’architecture et sécurité, les comités éthique et risques sont à inclure dans le cycle de vie du projet.

1. Informer les équipes intelligence artificielle et Data de leurs droits et devoirs pour manipuler les données et les risques associés

La formation des équipes intelligence artificielle et Data est fondamentale pour assurer la sécurité des données et des applications développées. A l’instar des populations de développeurs et d’administrateurs, des thématiques spécifiques doivent être abordées. Par exemple, l’utilisation de librairies certifiées, l’utilisation d’enclave ou encore les pratiques d’hygiène cybersécurité sont à inculquer à cette nouvelle population d’acteurs IT.

1. Former les équipes intelligence artificielle et Data aux bonnes pratiques de manipulation sécurisée de la donnée (anonymisation, chiffrement…), aux techniques d’apprentissage distribué et au développement sécurisé

En complément des bonnes pratiques de cybersécurité, les techniques de manipulation sécurisée des données (anonymisation, chiffrement des données, signature, etc.) doivent être connues et utilisées. De plus, dans des contextes où les équipes intelligence artificielle produisent du code à destination d’application, il est strictement nécessaire de mettre en place des pratiques de développement sécurisé. Enfin, l’utilisation de techniques d’entraînement spécifiques, telles que le « federated learning » par exemple, doivent être connues et appliquées lorsque nécessaire.

1. Définir sur chaque projet : les données ne pouvant pas être transmises au système, les limites de déviation/pertinence du système acceptables et les signaux de vol de donnée (volume de requête, interrogation ciblée sur une donnée critique…)

Les données utilisables par les systèmes intelligence artificielle étant souvent variées (structurée / non structurée) et changeantes, des règles de sûreté (appelés GuardRail) doivent être définies dès la conception afin d’assurer la sécurité en production. Par exemple, des rate-limiting peuvent être utilisés pour limiter les accès aux modèles, des trackers de déviation peuvent être également appliqués pour détecter les déviations et en limiter les impacts. En complément, le système peut avertir les consommateurs des résultats du niveau de pertinence du modèle avec des métriques organisationnelles (temps de ré entraînement, volume de données utilisées, format des données, etc.) ou technique.

Des mesures spécifiques aux environnements de développement, d’entraînement, de validation et de production :

1. Standardiser l’anonymisation de la collecte des données, le chiffrement de leur stockage et de leur transmission

Lors des phases de recensement et d’identification des données qui seront utilisées pour réaliser les entraînements, définir, pour chaque attribut, s’il doit être anonymisé, tokenisé ou chiffré. De plus, lors de la transmission de données, un mécanisme de chiffrement des données doit être mis en œuvre afin de garantir la confidentialité et l’intégrité des données transmises.

1. Mettre en œuvre des scénarios de détection des fuites d’information pour l’ensemble du pipeline data

Le pipeline intelligence artificielle incluant de nombreuses manipulations (et donc accès aux données), il est nécessaire d’identifier les scénarios techniques de fuite sur l’ensemble des composants. Les scénarios associés doivent être mis en place pour identifier toute manipulation de données hors du cadre défini des manipulations de données au sein de l’Entreprise.

1. Prévoir un environnement d’entraînement spécifique et isolé avec un accès restreint aux librairies pour ceux qui manipulent les jeux de données

Les environnements d’entraînements devant être flexibles et à la main des datascientists, il est essentiel de contrôler leur hébergement ainsi que leur accès. Il est recommandé de mettre en place une zone réseau dédiée à l’entraînement dans laquelle les accès et le filtrage sont maintenus indépendamment des activités de data science. De plus, et afin de limiter l’introduction de code malveillant, ces environnements doivent être accessibles au moyen d’un bastion et faire l’objet d’un contrôle de code pour toute librairie introduite dans le système d’information d’entraînement.

1. Valider régulièrement le niveau de sécurité des librairies et composants open-sources utilisés dans les environnements d’entraînement et de validation

Les librairies de machine learning étant un composant essentiel des phases d’entraînements, il est nécessaire de valider l’intégrité de celles-ci dès qu’une nouvelle version est publiée avant d’être utilisée pour entraîner les modèles. Un outillage de type Static Application Security Testing (SAST) permet d’analyser le code de la librairie pour vérifier la non présence de code malveillant ou de vulnérabilités pouvant être exécutés lors de l’utilisation en production.

1. Construire des datasets adverses avec les scénarios de risques identifiés pour valider les changements sur les modèles

Basé sur l’analyse des risques réalisée, créer des dataset synthétiques permettant d’évaluer la robustesse du modèle créé par rapport aux scénarios identifiés. De plus, ceux-ci peuvent être utilisés lors des phases d’évaluation pour valider les cas adverses pouvant provoquer les incidents de sécurité identifiés.

1. Lancer les modèles en production dans des enclaves sécurisées ayant des droits d’exécution limités

Afin de limiter la propagation d’une attaque par exploitation d’une vulnérabilité liée à l’API du modèle, l’utilisation d’enclave durcie de sécurité limitant l’exécution sur un compte de service est fortement recommandé. Cela permet également de pouvoir tester plusieurs modèles en parallèle ou mettre en œuvre des approches de validation par consensus.

1. Surveiller les systèmes pour détecter les déviations

La déviation d’un système intelligence artificielle est inévitable dans le temps. Il est donc nécessaire de mettre en place une surveillance des résultats et des indicateurs clés de performance permettant d’identifier les variations. Ces déviations doivent être quantifiées par rapport aux risques cyber afin d’évaluer l’impact de l’erreur résiduelle.

Les cibles et les types d’attaque étant précisées, regardons à présent les contre-mesures possibles, à nouveau sans chercher l’exhaustivité.

Le tableau ci-dessous résume ces contre-mesures qui, comme les attaques, peuvent être classiques (en italique) ou tenir compte des spécificités du machine learning (en gras) :

(tableau pas complet)

Protection en phase de collecte

Les attaques classiques contre les données en transit sur le canal de collecte peuvent être contrées par de réponses de sécurité elles aussi classiques : chiffrement et signature des données, redondance (même si cela peut engendrer un problème de coût) et évasion de fréquence.

Pour empêcher l’attaquant d’agir sur les capteurs eux-mêmes (modification illégitime de leur logiciel, par exemple), on peut aussi mettre en place des techniques classiques, comme la signature de code.

Protection en phase de préparation des données et apprentissage

Atteinte à la confidentialité 

Pour contrer les attaques classiques, les contre-mesures le sont également. L’accès aux données donnera lieu à authentification fiable et à contrôle d’accès. La confidentialité des données peut aussi être assurée préventivement par l'utilisation de mécanismes cryptographiques classiques (chiffrement). Enfin, on pourra chercher à détecter les fuites d’information. Une alternative possible à ces mesures préventives réside dans la détection de vols de modèle ou de données grâce au tatouage de ce modèle ou de ces données.

Des techniques moins courantes de la sécurité, plutôt utiliser habituellement pour la protection des données personnelles, peuvent être utilisées également. La sécurité différentielle (differential privacy) consiste à « randomiser » les données d’apprentissage ou les sorties de modèles, pour éviter une inférence trop précise. Il s’agit d’une technique typique de protection des données personnelles. Par exemple, on localisera un individu dans un cercle de 500m autour de sa position réelle. Une valeur aléatoire correspondant à une variation de 0 à 500m est alors ajoutée aux coordonnées GPS de cet utilisateur. Bien évidemment, ce mécanisme engendre une diminution de précision et donc une dégradation des performances globales d’inférence (un équilibre est à trouver entre valeur d’usage des données et protection des dites données). Un mécanisme alternatif, le chiffrement homomorphe, permet d’éviter ce problème. Ce type de chiffrement produit une donnée chiffrée sur laquelle on peut faire directement des calculs (pour l’apprentissage, donc) sans avoir à passer par une phase de déchiffrement. En revanche, ce type de chiffrement introduit une surcharge de calcul (et de taille des données) et donc ralentit l’apprentissage.

Atteinte à l’intégrité

Ici encore, contre les attaques classiques, on peut utiliser des approches classiques de la cyber sécurité : contrôle d’accès(en l’occurrence contrôle des accès en écriture), passant sûrement par une authentification fiable des utilisateurs ou, plus généralement, des entités actives du système ; et utilisation des mécanismes de signature numérique(type HMAC).

Ces attaques peuvent aussi trouver des réponses qui ne sont pas habituellement utilisées par les spécialistes en cyber sécurité. Ainsi, il est possible de lutter contre l’empoissonnement en « désinfectant » les données (les exemples qui provoquent des taux d'erreur élevés sont retirés de la base d’apprentissage ; on espère que les valeurs injectées ou modifiées comptent parmi ceux-ci). Une autre approche, consiste à renoncer à détecter les données injectées ou modifiées, mais à utiliser des techniques de régularisation pour réduire les distorsions potentielles du modèle d'apprentissage causées par les données empoisonnées (on parle de statistiques robustes). Dans l'apprentissage contradictoire, des exemples adverses correctement labélisés sont injectées dans les données d'apprentissage afin de minimiser les erreurs de classification causées par ces exemples. Le masquage par gradient réduit la sensibilité du modèle aux petites perturbations des entrées en calculant les dérivées de premier ordre du modèle par rapport à ses entrées et en minimisant ces dérivées pendant la phase d'apprentissage. Les méthodes d'ensemble, consiste à entrainer plusieurs modèles qui sont combinés pour améliorer la robustesse globale. Le « feature Squeezing » consiste à « lisser » les données d'entrée (suppression des petites perturbations) pour tenter d'annuler d’inhiber les perturbations adverses. Enfin, pour contrer les perturbations adverses, les « reformers » permettent de calculer, pour chaque donnée d’entrée, la plus proche donnée dans l'ensemble d'apprentissage (généralement à l’aide d’un auto-endodeur).

Atteinte à la disponibilité

Pour lutter contre l’empoisonnement des données préparatoire à une attaque à la disponibilité en phase d’inférence, on peut là encore recourir à des solutions classiques de sécurité (authentification, contrôle d’accès, signature). Puisque cette atteinte à la disponibilité passe par une modification des données (donc atteinte à l’intégrité), il est aussi possible de recourir aux mêmes techniques que celles évoquées ci-dessus : désinfection des données et statistiques robustes.

Protection en phase d’inférence (test ou run)

Atteinte à la confidentialité 

Dans le cas de la lutte contre les attaques ciblant la confidentialité en phase d’inférence, des techniques classiques de la cyber sécurité et de la protection des données personnelles : authentification et contrôle d’accès, chiffrement, détection des fuites d’information.

La differential pricacy ou la cryptographie homomorphe peuvent aussi être utilisées ici.

Enfin, si l’inférence passe par l’accès à une API, on peut tout simplement limiter en test ou en run le nombre de requêtes possibles via cette API, ce qui limitera l’attaquant dans ses essais.

Atteinte à l’intégrité  

Pour lutter contre les attaques à l’intégrité en phase d’inférence, des techniques classiques de la cyber sécurité peuvent être utilisées : authentification, contrôle d’accès, signature numérique.

Par ailleurs, en phase de run, une solution (mais qui impacte une fonctionnalité du système machine learning) est de bannir l’apprentissage continu, afin de se protéger de toute modification illégitime de modèle qu’entrainerait un empoisonnement des données.

Atteinte à la disponibilité

Si on ne considère pas d’attaque contre la disponibilité à cette étape du test (voir ci-dessus), il est bien entendu inutile de déployer des contre-mesures.

En phase de run, on pourra chercher à détecter a posteriori la présentation du trigger, par monitoring et explicabilité. D’une manière générale, monitorer le système (par exemple ses temps de réponses) peut être une solution.

Coût des contre-mesures

Bien sûr, rien n’est gratuit ! Comme nous l’avons mentionné, les contre-mesures peuvent entraîner des surcharges de traitement (chiffrement homomorphe) ou avoir un effet négatif sur la précision du modèle (differential privacy). Selon le contexte d’usage, en fonction du ratio risque/bénéfice, ces baisses de performances peuvent être rédhibitoires et rejetées par les clients métiers.