Évaluation des risques liés à l'IA pour les ingénieurs ML

Malgré les raisons convaincantes de sécuriser les systèmes de Machine Learning, une enquête Microsoft couvrant 28 entreprises a constaté que la plupart des praticiens de l’industrie n’ont pas encore pris la mesure du Machine Learning (ML) contradictoire. 25 des 28 entreprises ont indiqué qu’elles n’ont pas les bons outils en place pour sécuriser leurs systèmes de ML. De plus, elles cherchent ouvertement de l’aide. Nous avons constaté que l’absence de préparation n’est pas limitée aux petites organisations, elle concerne les entreprises du Fortune 500, les gouvernements et les organisations à but non lucratif. Les clients reconnaissent la nécessité de sécuriser les systèmes d’IA, mais ils ne savent pas comment procéder.

Ce document est une première étape pour les organisations afin d’évaluer la posture de sécurité de leurs systèmes d’IA. Mais au lieu d’ajouter une autre infrastructure à suivre pour les organisations, nous avons tenté de fournir le contenu d’une manière qui peut être alignée sur des infrastructures d’évaluation des risques de sécurité existants.

Les trois objectifs de ce document sont les suivants :

• Fournir une perspective complète de la sécurité du système d’intelligence artificielle. Nous avons examiné chaque élément du cycle de vie du système d’IA dans un paramètre de production : de la collecte de données au modèle de déploiement en passant par le traitement des données. Nous avons également pris en compte la chaîne d’approvisionnement de l’IA ainsi que les contrôles et les stratégies en matière de sauvegarde, de récupération et de planification d’urgence liés aux systèmes d’IA.
• Décrire les menaces pesant sur les ressources d’IA critiques et fournir de l’aide pour les sécuriser. Pour aider directement les ingénieurs et les professionnels de la sécurité, nous avons énuméré la déclaration de menace à chaque étape du processus de création du système d’IA. Ensuite, nous fournissons un ensemble de directives qui superposent et renforcent les pratiques existantes dans le contexte des systèmes d’IA.
• Permettre aux organisations d’effectuer des évaluations des risques en matière de sécurité de l’IA. L’infrastructure permet de collecter des informations sur l’état actuel de la sécurité des systèmes d’IA dans une organisation, d’effectuer une analyse des écarts et de suivre la progression de la posture de sécurité.

Nous l’avons formulé conjointement avec les parties prenantes de Microsoft, avec des représentants d’Azure Security, de la stratégie d’IA responsable dans l’ingénierie, du Centre de réponse aux problèmes de sécurité Microsoft, d’Azure Security, ainsi que de l'IA, de l'éthique et des effets dans l'ingénierie et la recherche (Aether).

Introduction

Nous vous suggérons d’utiliser ce document pour commencer à discuter de la sécurisation des systèmes d’IA alignés sur les efforts de sécurité des informations en cours et les objectifs métier. Le document se concentre sur les systèmes d’IA et l’inclusion de contrôles traditionnels, car les systèmes d’IA sont basés sur l’infrastructure informatique traditionnelle.

Nous abordons les domaines suivants liés aux systèmes d’IA.

Contrôles d’administration	Description
Stratégies de sécurité du Machine Learning	Contrôles et stratégies relatifs aux stratégies documentées qui régissent le Machine Learning, l’intelligence artificielle et la sécurité des informations.

Contrôles techniques	Description
Collecte de données	Contrôles et stratégies liés à la collecte, au stockage et à la classification des données utilisées pour le Machine Learning et l’intelligence artificielle.
Traitement des données	Contrôles et stratégies relatifs au traitement et à l’ingénierie des données utilisées pour le Machine Learning et l’intelligence artificielle.
Apprentissage du modèle	Contrôles et stratégies relatifs à la conception, à l’apprentissage et à la validation des modèles.
Déploiement de modèle	Contrôles et stratégies relatifs au déploiement de modèles et à l’infrastructure de prise en charge.
Surveillance du système	Contrôles et stratégies relatifs à la surveillance continue des systèmes de Machine Learning.
Gestion des incidents	Contrôles et stratégies relatifs à la façon dont les incidents liés au système d’IA sont gérés.
Continuité d’activité et reprise d’activité	Contrôles et stratégies relatifs à la perte de propriété intellectuelle par le biais du vol de modèle, de la dégradation du service ou d’autres vulnérabilités spécifiques à l’IA.

Nous avons adapté l’infrastructure existante des contrôles et des stratégies de la norme populaire ISO27001 :2013 et l’avons mappée dans le processus de construction des systèmes d’IA, de la phase de collecte de données à la réponse aux menaces pour les systèmes d'IA. Les organisations peuvent avoir des contrôles existants mis en œuvre à partir de la norme ISO27001 :2013 ou déjà en conformité avec plusieurs infrastructures de risque (NIST 800-53, PCI-DSS, FedRamp, etc.) dans le cadre des efforts de sécurité des informations existants.

L’échec de la sécurisation adéquate des systèmes d’IA augmente le risque non seulement pour les systèmes d’IA traités dans cette évaluation, mais plus généralement dans l’ensemble de la technologie de l’information et de l’environnement de conformité.

L’objectif de ce document n’est pas de remplacer l’un de ces efforts existants, mais de décrire la sécurisation des systèmes d’IA du point de vue des outils et des infrastructures existants, et de l’étendre à toutes les parties du processus de création d’IA.

Les conseils répertoriés ici ne sont pas prescriptifs, car cela nécessiterait davantage de contexte, comme la plateforme sous-jacente, le type de données sous-jacent et le choix de l’algorithme. Si vous êtes un client Azure Machine Learning, reportez-vous à l’article Sécurité et gouvernance en entreprise.

Gravité suggérée, probabilité, impact

Tous les contrôles ne sont pas importants pour la sécurité d’un système d’IA. Par conséquent, pour hiérarchiser correctement le travail, chaque contrôle doit être évalué par l’organisation avec une évaluation de gravité qui est pertinente pour l’impact commercial de ne pas mettre en œuvre un contrôle donné. Une organisation peut choisir d’accepter le risque d’un contrôle critique et de mettre en œuvre plutôt un contrôle de compensation pour réduire le risque. En fin de compte, ces évaluations permettent de guider la prise de décision basée sur les risques plutôt que de prescrire des activités.

Niveau de gravité

La gravité d’une compromission dépendra du cas d’usage du modèle d’IA. Heureusement, si les données ou les systèmes utilisés étaient d'une importance critique avant l'intégration du Machine Learning, cela devrait rester identique. De même, si le modèle utilisé est « prêt à l’emploi » sans autre entrée, selon le contexte dans lequel le modèle est utilisé, la gravité d’une compromission est probablement inférieure. Les techniques telles que la confidentialité différentielle peuvent réduire l’impact potentiel d’une compromission. Toutefois, ce contexte ne réduirait pas le caractère critique du système, les données ou le modèle. Nous recommandons que les modèles soient protégés à l’aide d’une stratégie de défense en profondeur plutôt que de s’appuyer sur une mise en œuvre défensive.

Niveau de gravité suggéré

Suggéré comme critique

• Si le modèle d’IA est formé ou ingère des données personnelles sensibles, des données classifiées ou des données régies par des exigences de conformité telles que PCI, HIPAA, GLBA, etc.
• Si le modèle d’IA est utilisé dans une application ou un système critique pour l’entreprise, de sorte que la compromission aurait un impact négatif important sur les opérations commerciales
• Si le modèle d’IA est utilisé dans des applications où des dommages physiques ou la mort sont des résultats possibles
• Si le modèle d’IA est utilisé dans un système qui prend en charge l’infrastructure critique (par exemple, l’eau, l’alimentation, l’intégrité)

Suggéré comme élevé

• Si le modèle d’IA est entraîné sur ou ingère des données personnelles sensibles, des informations confidentielles ou des données qui sont autrement considérées comme critiques par l’organisation
• Si la compromission de ce modèle d’IA avait un impact important, mais étendu sur les opérations commerciales
• Si le modèle d’IA est utilisé dans des applications ou des systèmes critiques pour l’entreprise

Suggéré comme moyen

• Si le modèle d’IA est entraîné sur un sous-ensemble de données d’apprentissage contenant des types de données sensibles
• Si la compromission de ce modèle d’IA aurait des implications pour les modèles déployés en production
• Si le modèle d’IA est utilisé dans des applications orientées commerce, mais non critiques
• Si le modèle d’IA n’est pas utilisé en production, mais contient des informations sur les modèles de production

Suggéré comme bas

• Si le modèle d’IA est entraîné sur des données qui ne sont pas utilisées en production
• Si le modèle d’IA n’est pas utilisé en production et n’a pas d’informations sur les modèles de production

Suggéré comme informationnel

• Si les données ne sont pas classifiées à partir d’une source approuvée
• Si le modèle d’IA n’est pas utilisé en production

Vraisemblance

La probabilité comporte deux composants majeurs : la disponibilité du modèle et la disponibilité des techniques. Pour réduire la probabilité d’une attaque, une organisation doit mettre en œuvre des contrôles qui :

1. réduisent la surface d'attaque ou la rendent plus difficile à énumérer ;
2. garantissent que la journalisation et les alertes fonctionnent comme prévu afin d'assurer une résolution rapide des problèmes ;
3. garantissent que tous les systèmes de support sont mis à jour avec les exigences de sécurité.

Les contrôles peuvent inclure la mise en place de points de terminaison, la segmentation du réseau ou la limitation du débit. Une attention particulière doit être accordée aux flux de trafic et aux diagrammes de réseau ou de pipeline, par exemple, un attaquant compromettant et un point de terminaison externe et remontant à travers un pipeline.

Impact

L’impact est lié aux effets sur l’organisation. Nous vous suggérons de commencer par vous familiariser avec différentes façons dont les systèmes de ML peuvent être attaqués et prendre en compte les façons dont les modèles de production peuvent affecter l’organisation. Pour plus d’informations, consultez l’article Modes d’échec en Machine Learning. Une fois cette familiarisation effectuée, elle peut être mappée à une matrice de gravité.

Matrice de gravité

Le tableau suivant est une matrice de gravité des risques et des vulnérabilités de base pour aider les organisations à démarrer. Nous vous suggérons de remplir une catégorisation similaire en réunissant des architectes de sécurité, des ingénieurs en apprentissage automatique et des membres de l’équipe rouge IA.

Type d’attaque	Vraisemblance	Impact	Exploitabilité
Extraction	Élevé	Faible	Élevé
Évasion	Élevé	Moyenne	Élevé
Inférence	Moyenne	Moyenne	Moyenne
Inversion	Moyenne	Élevé	Moyenne
Empoisonnement	Faible	Élevé	Faible

« La conception et le développement de l’IA sécurisée constituent une pierre angulaire du développement de produits d’IA chez BCG. À mesure que le besoin sociétal de sécuriser nos systèmes d'IA devient de plus en plus évident, les ressources telles que l’infrastructure de gestion des risques de sécurité de l’IA de Microsoft peuvent constituer des contributions fondamentales. Nous mettons en œuvre déjà les meilleures pratiques trouvées dans cette infrastructure dans les systèmes d’IA que nous développons pour nos clients et sommes heureux que Microsoft ait développé et mis en open source cette infrastructure pour le bénéfice de l’ensemble du secteur. » – Jack Molloy, ingénieur sécurité senior, Boston Consulting Group

Usage de base

Le reste du document suit cette structure :

• Un contrôle des risques contient une description de la zone que le contrôle couvre.
• L’objectif du contrôle et ce qu’il est censé accomplir.
• Une déclaration de menace qui donne une description du risque en cours d’atténuation.
• Une aide pour mettre en œuvre un contrôle. Nous comprenons que tous les conseils ne peuvent pas être mis en œuvre pour des raisons commerciales légitimes. Nous vous suggérons de documenter les conseils qui ne peuvent pas être mis en œuvre.

Le tableau suivant est un contrôle extrait de l’évaluation des risques des systèmes d’IA, des notes sont ajoutées pour décrire chaque partie d’une structure de catégories de risques.

Exemple de contrôle

Comment le lire

1. Collecte de données

Catégorie principale

Contrôles et stratégies relatifs à la collecte et au stockage de données provenant de toutes les sources utilisées pour l’apprentissage automatique et l’intelligence artificielle.

Décrit ce que les contrôles de cette catégorie couvrent à un niveau élevé.

2. Sources de données

Catégorie de contrôle

Objectif : pour garantir l’intégrité des données collectées qui sont utilisées pour les modèles entraînés.

Doit décrire le risque en cours d’atténuation avec les contrôles.

Déclaration de menace : les données sont collectées à partir de sources non fiables pouvant contenir des données personnelles sensibles, d’autres données indésirables susceptibles d’affecter la sécurité d’un modèle ou présenter des risques de conformité à l’organisation.

Une déclaration qui décrit ce qui se produit lorsque l’on ne met pas en œuvre le contrôle.

Contrôle : les données doivent être collectées à partir de sources fiables. Une liste de sources fiables doit être conservée et mise à jour. Les approbations pour la collecte de données non fiables doivent être considérées au cas par cas.

Une formulation spécifique qui décrit la meilleure pratique pour le contrôle.

Conseils :

1. Tous les efforts raisonnables doivent être faits pour s’assurer que les données sont fiables avant d’entraîner un modèle. Les données non fiables ou inconnues peuvent introduire des vulnérabilités de sécurité ultérieurement dans le pipeline.
2. Les données qui contiennent des informations personnelles sensibles, qu’elles soient utilisées à des fins de science des données ou autrement, doivent être nettoyées ou stockées et accessibles de manière appropriée.
3. La collecte de données sans considération pour son contexte peut entraîner des jeux de données qui contiennent des données illégales. Les efforts de collecte de données doivent être attentifs aux documents protégés par le droit d’auteur, aux violations de données et aux points de terminaison non sécurisés qui divulguent accidentellement des données.

L’aide est constituée de recommandations pour répondre aux critères ci-dessus. Nous les fournissons de manière neutre par rapport au produit et au fournisseur afin de laisser aux organisations la liberté de résoudre le problème de la manière qui leur semble la plus appropriée.

Évaluation de la sécurité de l’apprentissage automatique

Avant de commencer

L’objectif de cette évaluation est d’aider les organisations à articuler, suivre et corriger les risques pour les opérations commerciales introduits par les systèmes d’IA. Cette évaluation doit être utilisée pour :

1. rassembler des informations sur l’état actuel de la sécurité de l’IA au sein de l’organisation ;
2. effectuer une analyse des écarts et créer une feuille de route pour mettre en œuvre des recommandations ;
3. suivre la progression de la sécurité en effectuant cette évaluation annuellement ou semestriellement.

Si une organisation n’a pas de programme de sécurité, cette évaluation n’est pas le point de départ. Une organisation doit disposer d’un programme de sécurité des informations fonctionnel avant de mettre en œuvre des recommandations dans cette évaluation. Pour plus d’informations, consultez l’article Recommandations en matière de sécurité Azure dans Cloud Adoption Framework.

Collecte de données

Contrôles et stratégies relatifs à la collecte et au stockage de données provenant de toutes les sources utilisées pour l’apprentissage automatique et l’intelligence artificielle.

Objectif : pour garantir l’intégrité des données collectées dans les systèmes d’IA.

Sources de données

Contrôle : les données doivent être collectées à partir de sources fiables. Une liste de sources fiables doit être conservée et mise à jour. Les approbations de la direction pour la collecte de données non fiables doivent être envisagées au cas par cas. Si une source non fiable est approuvée, elle doit être documentée.

Déclaration de menace : les données sont collectées à partir de sources non fiables pouvant contenir des données personnelles sensibles, d’autres données indésirables susceptibles d’affecter les performances d’un modèle ou présenter des risques de conformité à l’organisation.

Conseils :

1. Les données d’entrée doivent être validées et considérées comme fiables par le biais de l’approbation de gestion avant d’être utilisées dans un système d’IA.
2. Les données collectées pour un système d’IA doivent être examinées avant d’être utilisées ou stockées.
3. Si nécessaire, les données collectées doivent être nettoyées des entrées indésirables.
4. La source de données doit être documentée et conservée avec les données.
5. Les données d’inférence utilisées pour entraîner un modèle ne doivent pas être implicitement considérées comme fiables et doivent être traitées comme de nouvelles données.
6. Les efforts de collecte de données doivent être documentés et audités. Le propriétaire des données collectées doit être responsable de leur conformité aux stratégies documentées.

Types de données sensibles

Control : pour garantir que les données stockées pour les systèmes d’IA sont correctement sécurisées, suivies et classées en fonction de leur sensibilité et de leur cas d’usage. Ce contrôle inclut des étiquettes de classification des données, des stratégies d’accès, des informations de licence, des statistiques descriptives, la source d’origine et la date de collecte.

Déclaration de menace : les données utilisées dans les systèmes d’IA sont utilisées, stockées ou accessibles de manière inappropriée en raison d’un manque d’attributs, de métadonnées ou de documentation requis.

Conseils :

1. Développez une stratégie de données qui englobe la confidentialité et la protection des types de données sensibles et communiquez cette stratégie à tous les membres du personnel impliqués dans l’utilisation ou la création de systèmes d’IA.
2. Mettez en œuvre des pipelines de formation et de déploiement qui protègent la confidentialité et l’intégrité des données utilisées dans les systèmes d’IA.

Stockage des données

Contrôle : les données doivent être stockées de manière appropriée en fonction d’un processus de classification documenté. Les jeux de données doivent être indexés et considérés comme une ressource soumise à la gestion des ressources et aux stratégies de contrôle d’accès.

Déclaration de menace : les données sont stockées de manière non sécurisée et peuvent être falsifiées ou modifiées par des parties ou systèmes non autorisés. Les données ne sont pas correctement classifiées, ce qui entraîne la divulgation d’informations confidentielles ou de données personnelles sensibles.

Assistance

1. Veillez à ce que les systèmes de développement ou de recherche en IA, ou les comptes associés n'aient pas accès aux bases de données de production et vice versa.
2. Les données utilisées dans les systèmes d’IA doivent être classifiées et protégées conformément à une stratégie de classification documentée.
3. Les données utilisées dans les systèmes d’IA sont suivies conformément à une politique de gestion des actifs documentée.
4. Les données utilisées pour les cas d’usage d’IA sensibles sont stockées sur des systèmes approuvés et managés.
5. L’accès aux données doit être audité et les utilisateurs demandant l’accès doivent passer par un processus de contrôle d’accès formel qui inclut l’approbation de la direction.
6. Les données utilisées dans les processus d’apprentissage automatique ne doivent pas être exposées à Internet.
7. Les données extraites d’Internet (ou d’autres sources non fiables) doivent passer par un processus de filtrage qui inclut l’approbation de la direction.
8. Les jeux de données doivent être versionnés avec des processus formels de contrôle de modification en place.

Accès aux données

Contrôle : les jeux de données doivent être suivis et vérifiés de manière appropriée via un hachage de chiffrement avant d’être utilisés.

Déclaration de menace : les jeux de données sont modifiés sans autorisation.

Conseils :

1. Le contrôle d'accès basé sur les rôles pour les jeux de données doit être appliqué.
2. Effectuez régulièrement des audits d'accès pour vérifier que les comptes ayant accès aux jeux de données doivent réellement y avoir accès. Vérifiez que chaque compte fonctionne dans des limites normales.
3. Si une plateforme de suivi centralisée n’est pas utilisée, l’accès aux données via les journaux d’accès bruts doit être examiné pour vérifier son objectif. Vérifiez que chaque compte fonctionne dans des limites normales.
4. Les fournisseurs de ressources tiers, les sous-traitants ou d’autres parties externes ne doivent pas avoir un accès excessif ou inapproprié aux ressources de données d’apprentissage/test d’une entreprise sans contrats en place.

Intégrité des données

Control : les jeux de données doivent être fiables et rester approuvés tout au long du cycle de vie du système d’IA.

Déclaration de menace : les jeux de données sont modifiés pendant le cycle de vie de l’IA sans pouvoir auditer ou suivre les modifications.

Conseils :

1. Les jeux de données doivent être identifiés de manière unique afin que les modifications non autorisées apportées à un jeu de données approuvé entraînent une révision du jeu de données.
2. Les jeux de données et leurs descriptions de chiffrement doivent être suivis dans un emplacement central. L’accès au jeu de données doit être audité.
3. Les modifications apportées au jeu de données doivent inclure une description de chiffrement et une approbation de la direction mises à jour avant d’être soumises au service de suivi central.

Traitement des données

Contrôles et stratégies relatifs au traitement et à l’ingénierie des données utilisées pour l’apprentissage automatique et l’intelligence artificielle.

Objectif :assurer le traitement sécurisé des données de leur forme brute à une forme intermédiaire prête pour l'apprentissage.

Pipelines de traitement

Contrôle : les pipelines de traitement doivent être correctement sécurisés.

Déclaration de menace : un acteur malveillant peut apporter des modifications non autorisées au système en modifiant les pipelines de traitement des données.

Conseils :

1. Toutes les données qui circulent dans un système de production ne sont pas pertinentes pour les efforts en science des données. Il est important d’analyser uniquement les données requises et de s’assurer que toutes les données déplacées d'un environnement de production sécurisé vers un environnement de développement sont suivies de manière appropriée. Considérez que certains types de données peuvent ne pas être déplacés dans un environnement de développement. La science des données peut devoir être réalisée dans un environnement intermédiaire sécurisé.
2. Il est important d'effectuer un audit approprié de l'accès aux données tout au long du cycle de traitement des données. Sans comptes distincts, il n’existe aucun audit suffisant de l’accès. En outre,la capacité à répondre à un incident ne peut pas se faire sans potentiellement affecter les processus métier. La compromission d’un seul compte entraînerait une compromission de toutes les données quittant l’environnement de production sécurisé.
3. Les processus de science des données peuvent nécessiter des ressources qui se trouvent en dehors d’une limite de conformité stricte.
4. Les processus de science des données doivent toujours être conformes aux exigences existantes. Ce processus peut inclure le déplacement de ressources et de processus de science des données dans un environnement conforme.
5. Les données doivent être suivies tout au long de leur cycle de vie ; ce suivi inclut les sous-ensembles des jeux de données plus volumineux. Il doit être nécessaire de pouvoir retracer un modèle jusqu'aux données sur lesquelles il a été entraîné. En outre, une copie de ces données doit exister dans son intégralité.

Ouverture du jeu de données

Contrôle : pour garantir que les sous-ensembles (par exemple, des tranches temporelles, catégorielles) de données incluses pour la création de modèles et la façon dont cela peut entraîner des risques de sécurité (fuites de confidentialité, empoisonnement/intégrité via une suraccentuation sur les commentaires, etc.).

Déclaration de menace : l’acteur malveillant peut récupérer des parties des données en reconstruisant/récupérant des sous-ensembles de données.

Conseils :

1. Les sous-ensembles de données sont eux-mêmes des jeux de données. Ces sous-ensembles doivent avoir les mêmes métadonnées attachées au jeu de données parent et doivent être examinées de la même façon pour les types de données sensibles.
2. En fonction des stratégies relatives aux pratiques d’apprentissage automatique (SLA, métriques de biais, etc.), tout jeu de données donné (y compris les sous-ensembles) doit respecter une norme documentée minimale entourant ces métriques si elles doivent être utilisées dans la génération de modèles. Les métadonnées doivent toujours être attachées au jeu de données.
3. Tous les jeux de données qui violent les stratégies existantes doivent avoir une exception documentée approuvée par la direction. L'exception doit inclure une raison documentée pour l'exception en plus des métadonnées requises.
4. Toutes les données utilisées pour la génération de modèles doivent être suivies dans un emplacement central. Les données doivent être pouvoir être auditées à tout moment. En outre, les modèles qui ont été entraînés sur des données non suivies doivent être extraits de la production jusqu’à ce qu’ils soient mis en correspondance avec un jeu de données connu avec les métadonnées requises.
5. Les jeux de données doivent être correctement versionnés afin que toutes les métadonnées soient mises à jour et que les utilisateurs des données comprennent le contenu et les propriétés statistiques. Si nécessaire, l’approbation de la gestion pour les cas d’usage sensibles doit être requise.

Apprentissage du modèle

Contrôles et stratégies liés à l’apprentissage des modèles et algorithmes.

Conception de modèle

Contrôle : le code d’apprentissage du modèle est examiné par une partie responsable.

Déclaration de menace : un code incorrect ou des vulnérabilités dans le code du modèle entraînent des risques de disponibilité, d'intégrité ou de confidentialité.

Conseils :

1. La conception et la recherche de modèles doivent se produire dans l’environnement approprié. La conception et l’architecture du modèle peuvent avoir un effet important sur l’efficacité d’un modèle. Les environnements de production ne sont pas le lieu pour la recherche ou pour tester des affirmations non démontrables sur l'efficacité d'une conception.
2. La sélection du modèle pour un système de production doit être examinée et approuvée par la direction. Ce processus doit se produire au début de la phase de développement et doit être suivi via n’importe quel mécanisme disponible (Excel, DevOps, Git, etc.). Les exceptions doivent être documentées.
3. Les modèles sont souvent spécifiques à un domaine et il doit y avoir une documentation adéquate qui accompagne le modèle tout au long de son utilisation dans une organisation.
4. Vérifiez que les métadonnées du modèle sont accessibles aux utilisateurs et que les utilisations non approuvées des modèles sont documentées et appliquées. Il est acceptable pour un utilisateur d’affiner un modèle existant tant que de nouvelles métadonnées sont attachées et suivies de manière appropriée.

Apprentissage du modèle

Contrôle : le critère de sélection de modèle (jeux de métriques et de blocage) imite la dérive naturelle et toutes les conditions contradictoires qui peuvent être attendues au moment du déploiement.

Déclaration de menace : un modèle entraîné dans des conditions idéales est susceptible d’être fragile lorsqu’il est déployé dans des environnements adverses.

Assistance

1. Les jeux d’apprentissage et de validation doivent respecter les dépendances temporelles naturelles. Par exemple, pour les classificateurs de programmes malveillants, un jeu de validation doit inclure uniquement des versions logicielles ultérieures à celles contenues dans le jeu d’apprentissage.
2. Ajoutez explicitement la robustesse du modèle en augmentant les jeux de données avec des altérations courantes qui pourraient raisonnablement être découvertes dans la nature.
3. Entraînez explicitement contre les conditions les plus défavorables en utilisant un réapprentissage adverse.
4. Effectuez le suivi des expériences et des métadonnées associées.

La sélection des modèles

La sélection du modèle consiste à choisir un modèle à partir d’un ensemble de candidats, où chaque candidat a un ensemble unique de paramètres de modèle, d’algorithme d’apprentissage et d’hyper-paramètres d’apprentissage. Le critère de sélection pour le modèle gagnant est souvent basé sur une seule métrique mesurable (par exemple, perte minimale, taux de détection maximal) mesurée sur un jeu de données de blocage commun ou moyenne sur un jeu de validation k-fold.

Contrôle : l’algorithme de conception et d’apprentissage de modèle inclut la normalisation explicite ou implicite du modèle.

Déclaration de menace : les modèles sont surajustés à un jeu de données d’apprentissage et/ou de validation unique et sont plus vulnérables aux modes d’échec.

Conseils :

1. Lorsque le calcul est possible, la validation croisée k-fold doit être utilisée pour empêcher le surajustement d’un jeu de blocage unique.
2. Vérifiez que les modèles sélectionnés fonctionnent correctement sur des ensembles de blocage disparates pour vérifier qu’ils ne sont pas surajustés.
3. Vérifiez que les processus existent.

Gestion des versions des modèles

Contrôle : les modèles sont continuellement réentraînés en tant que nouveaux flux de données d’apprentissage dans des pipelines d’apprentissage.

Déclaration de menace : un incident se produit, mais le modèle impliqué ne peut pas être trouvé pour investigation.

Conseils :

1. Modèles de version de sorte que chaque fois qu’un modèle est entraîné, il reçoit une nouvelle version. Les qualificateurs tels que my_model_dev_1.1 ou my_model_prod_1.1 doivent être utilisés pour délimiter la production à partir de modèles de préproduction. Ce contrôle de version permet d’isoler les problèmes liés à un problème de production ou de préproduction. Référencez les processus ou stratégies SDL sécurisés existants.

Déploiement de modèle

Contrôles et stratégies relatifs au déploiement de modèles, d'algorithmes et d'infrastructures de prise en charge.

Tests de sécurité

Contrôle : les modèles mis en production sont correctement sécurisés.

Déclaration de menace : les systèmes d’IA ne sont pas correctement testés pour les vulnérabilités avant le déploiement.

Conseils :

1. Les critères formels de test d’acceptation n’ont pas été définis et documentés pour les nouveaux systèmes d’IA, les mises à niveau et les nouvelles versions.
2. Les nouveaux systèmes d’IA, les mises à niveau ou les nouvelles versions doivent être mis en œuvre avec des tests formels.
3. Les outils automatisés doivent être utilisés pour tester les systèmes d’information, les mises à niveau ou les nouvelles versions.
4. L'environnement de test doit correspondre le plus possible à votre environnement de production.
5. La fréquence, l’étendue et les méthodes pour les révisions de sécurité indépendantes doivent être documentées.

Examen de la sécurité et de la conformité

Contrôle : une gestion robuste du réseau sous-jacent est essentielle pour sécuriser le système de ML et l’infrastructure.

Déclaration de menace : compromission du système de ML en accédant au réseau non sécurisé.

Conseils :

1. Les appareils de passerelle vers les systèmes de ML doivent être configurés pour filtrer le trafic entre les domaines et bloquer l’accès non autorisé.
2. Les exigences légales, réglementaires et contractuelles pertinentes doivent être explicitement définies et documentées, et traitées, en même temps que des contrôles spécifiques et des responsabilités individuelles.
3. Les instructions de configuration sécurisée doivent également être documentées, mises en œuvre ou examinées.
4. Le critère de séparation des réseaux de ML en domaines doit être cohérent avec la stratégie de contrôle d’accès de l’organisation ou les exigences d’accès de l’organisation.
5. Les mécanismes tels que la passerelle sécurisée, le VPN, le routage pour les systèmes de ML doivent être mis en œuvre suffisamment pour permettre un ensemble de contrôles gradué.
6. Les utilisateurs et les ingénieurs en ML doivent utiliser ou respecter les exigences de mise en œuvre des contrôles pour séparer et restreindre correctement l’utilisation des systèmes accessibles publiquement, des réseaux internes et des ressources critiques.

Contrôle du système

Contrôles et stratégies relatifs à la surveillance continue des systèmes d’apprentissage automatique et d’infrastructure de prise en charge.

Journaux et révision des journaux

Contrôle : la journalisation et la supervision sont essentielles pour les systèmes de ML pour des raisons de sécurité.

Déclaration de menace : lors d’une investigation, les journaux des systèmes de ML ne sont pas trouvés.

Conseils :

1. La journalisation et la supervision doivent se produire de manière cohérente sur tous les systèmes d’IA et leurs composants, notamment le stockage, les pipelines, les serveurs de production, etc.
2. Les journaux d’événements et de sécurité doivent être examinés régulièrement pour un comportement anormal.
3. Les rapports consolidés et les alertes sur l’activité système doivent être générés et examinés par la direction ou un représentant de la sécurité.

Gestion des incidents

Rôles et responsabilités

Contrôle : les journaux de sécurité doivent être collectés dans un emplacement central.

Déclaration de menace : lors d’une enquête, les analystes en sécurité n’ont pas de playbook formalisé.

Conseils :

1. Les organisations doivent suivre un processus formel pour signaler les incidents des systèmes d’IA dans le contexte de la perte de service, de la perte d’équipement, de la perte d’installations, des dysfonctionnements du système, des surcharges système, des erreurs humaines, des non-conformités avec des stratégies ou des instructions, des violations de sécurité physique, des modifications du système non contrôlées, des dysfonctionnements logiciels, des dysfonctionnements matériels et des violations d’accès.
2. Les procédures formelles de réponse aux incidents et d’escalade doivent être développées pour documenter les actions effectuées lors de la réception d’un rapport sur un événement de sécurité de l’information.
3. Les procédures de réponse aux incidents doivent être testées périodiquement, en suivant les métriques de réponse.

Planification de la continuité commerciale

Planification, examen et résultats

Contrôle : vérifiez que les systèmes de ML peuvent être corrigés et récupérés après un incident.

Déclaration de menace : les incidents causent des problèmes persistants de confidentialité, d’intégrité ou de disponibilité aux systèmes de ML critiques.

Conseils :

1. Les ressources d’IA critiques doivent être identifiées et inventoriées.
2. L’organisation doit développer un plan de continuité des activités (BCP) ou un processus de récupération d’urgence (DR) face aux attaques sur les systèmes d’IA.
3. L’organisation doit identifier par ordre de priorité les risques liés à l’impact de la perte de systèmes d’IA critiques suite à des attaques.
4. Les organisations doivent effectuer des tests de continuité des activités selon un calendrier répété pour les systèmes d’IA critiques.

Références

• ISO 27001 Annexe A Contrôles : vue d’ensemble (isms.online)
• Site officiel du Conseil des normes de sécurité PCI
• Modes d’échec en Machine Learning
• Modélisation des menaces dans les systèmes d’IA/de ML et leurs dépendances
• Sélecteurs de vues IA/ML de la barre de bogues de Security Development Lifecycle
• Sécurité et gouvernance d’entreprise

Si vous avez des questions, des commentaires ou des commentaires, contactez atml@microsoft.com.

Télécharger un fichier PDF de ce document à partir de notre dépôt GitHub.