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.

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 MODELES PRE-ENTRAINES

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. HYPOTHESES

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. METHODES ET METRIQUES A UTILISER POUR EVALUER LA SECURITE D'UN SYSTEME 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.).