Partager via

Évaluation des risques d’IA pour les ingénieurs ML

Malgré les raisons impérieuses de sécuriser les systèmes ML, l'enquête de Microsoft couvrant 28 entreprises a constaté que la plupart des praticiens de l'industrie n'ont pas encore accepté l'apprentissage automatique contradictoire (ML). Vingt-cinq 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, ils cherchent explicitement des conseils. Nous avons constaté que le manque de préparation n’est pas limité aux petites organisations : elles vont des entreprises fortune 500, des gouvernements aux organisations à but non lucratif. Les clients reconnaissent la nécessité de sécuriser les systèmes d’INTELLIGENCE artificielle, 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 IA. Mais au lieu d’ajouter un autre framework pour les organisations à suivre, nous avons tenté de fournir le contenu d’une manière qui peut être alignée sur des frameworks d’évaluation des risques de sécurité existants.

Il existe trois objectifs pour ce document :

  • 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 IA dans un paramètre de production : de la collecte de données, du traitement des données au déploiement du modèle. Nous avons également pris en compte la chaîne d’approvisionnement ia et 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 IA.
  • Décrire les menaces aux ressources IA critiques et des conseils pour les sécuriser. Pour aider directement les ingénieurs et les professionnels de la sécurité, nous avons énuméré l’instruction de menace à chaque étape du processus de création du système IA. Ensuite, nous fournissons un ensemble de directives qui superposent et renforcent les pratiques existantes dans le contexte des systèmes IA.
  • Permettre aux organisations d’effectuer des évaluations des risques de sécurité IA. Le framework permet de collecter des informations sur l’état actuel de la sécurité des systèmes 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, d’une stratégie d’IA responsable en ingénierie, de Microsoft Security Response Center, d’Azure Security et d’IA, d’éthique et d’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 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 IA et l’inclusion de contrôles traditionnels, car les systèmes IA sont basés sur l’infrastructure informatique traditionnelle.

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

Contrôles administratifs Description
politiques de sécurité d'apprentissage automatique 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.
Formation du modèle Contrôles et stratégies relatifs à la conception, à l’entraînement et à la validation des modèles.
modèle de déploiement 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 Machine Learning.
Gestion des incidents Contrôles et stratégies relatifs à la façon dont les incidents liés au système IA sont gérés.
continuité d’activité et reprise après sinistre Contrôles et politiques 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é le framework existant de contrôles et de stratégies de la norme populaire ISO27001:2013 et l'avons mappé sur l'ensemble du processus de construction du système d'IA - de la phase de collecte des données à la réponse aux menaces qui pèsent sur les systèmes d'IA. Les organisations peuvent avoir des contrôles existants implémentés à partir de ISO27001:2013 ou déjà en conformité avec plusieurs frameworks 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’INTELLIGENCE artificielle augmente le risque non seulement pour les systèmes d’INTELLIGENCE artificielle 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 IA du point de vue des outils et infrastructures existants, et 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 d’entreprise.

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

Tous les contrôles ne sont pas importants pour la sécurité d’un système 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 de l’entreprise de ne pas implémenter un contrôle donné. Une organisation peut choisir d’accepter le risque d’un contrôle critique et d’implémenter 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.

Sévérité

La gravité d’une compromission va dépendre du cas d’usage du modèle IA. Heureusement, si les données ou les systèmes utilisés étaient d'une importance capitale avant l'intégration de l'apprentissage automatique, ils devraient le rester. De même, si le modèle utilisé est « off-the-shelf » 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 la criticité 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 implémentation défensive.

Niveau de gravité suggéré

Suggéré comme critique

  • Si le modèle 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 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 IA est utilisé dans des applications où un dommage physique, des préjudices ou la mort sont des résultats possibles
  • Si le modèle d'intelligence artificielle est utilisé dans un système qui soutient une infrastructure critique (par exemple, l'eau, l'énergie, la santé)

suggéré comme élevé

  • Si le modèle 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 IA aurait un impact important mais étendu sur les opérations commerciales
  • Si le modèle IA est utilisé dans les applications ou systèmes critiques pour l’entreprise

suggéré comme moyen

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

suggéré comme faible

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

proposé à titre informatif

  • Si les données sont déclassifiées à partir d’une source vérifiée
  • Si le modèle 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 implémenter des contrôles qui :

  1. Supprimez la surface d’attaque ou compliquez l’énumération de la surface d’attaque.
  2. Assurez-vous que la journalisation et les alertes fonctionnent comme prévu pour garantir la résolution rapide des problèmes.
  3. Assurez-vous que tous les systèmes de prise en charge sont à jour avec les exigences de sécurité.

Les contrôles peuvent inclure des points de terminaison de gestion, une segmentation du réseau ou une limitation de 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 qui compromet un point de terminaison externe et progresse en sens inverse à 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 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 dans 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 que les organisations commencent. Nous vous suggérons de remplir une catégorisation similaire en organisant des architectes de sécurité, des ingénieurs machine learning 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 IA chez BCG. À mesure que la nécessité sociale de sécuriser nos systèmes d’IA devient de plus en plus évidente, les ressources telles que le Framework de gestion des risques de sécurité de l’IA de Microsoft peuvent être des contributions fondamentales. Nous implémentons déjà les meilleures pratiques trouvées dans ce framework dans les systèmes IA que nous développons pour nos clients et sommes heureux que Microsoft a développé et open source ce framework pour bénéficier de l’ensemble du secteur. — Jack Molloy, ingénieur de sécurité senior, Boston Consulting Group

Utilisation de base

Le reste du document suit cette structure :

  • Un contrôle de risque contient une description de la zone que le contrôle couvre.
  • L’objectif du contrôle et ce qu’il est censé accomplir.
  • Une instruction sur les menaces qui donne une description du risque à atténuer.
  • Lignes directrices pour la mise en œuvre d’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 des conseils qui ne peuvent pas être implémentés.

Le tableau suivant est un contrôle extrait de l’évaluation des risques des systèmes d’INTELLIGENCE artificielle, 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 le Machine Learning et l’intelligence artificielle.

Décrit de manière générale ce que couvrent les contrôles de cette catégorie.

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 qui est atténué avec les contrôles.

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

Instruction qui décrit le résultat de la non-implémentation du contrôle.

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

Verbiage 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 peuvent être approuvées avant d’entraîner un modèle. Les données non approuvées ou inconnues peuvent introduire des vulnérabilités de sécurité ultérieurement dans le pipeline.
  2. Les données qui contiennent des données 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, aux points de terminaison non sécurisés qui fuitent accidentellement des données.

Les orientations sont des recommandations pour répondre aux critères ci-dessus. Nous les fournissons de manière indépendante du produit et du fournisseur pour laisser aux organisations la possibilité de résoudre le problème d'une manière qui a du sens pour elles.

Évaluation de la sécurité du Machine Learning

Avant de commencer

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

  1. Rassemblez des informations sur l’état actuel de la sécurité de l’IA au sein de l’organisation.
  2. Effectuez une analyse des écarts et créez une feuille de route pour implémenter des recommandations.
  3. Suivez la progression de la sécurité en effectuant cette évaluation annuellement ou bi-annuellement.

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 d’implémenter des recommandations dans cette évaluation. Pour plus d’informations, consultez l’article conseils de sécurité Azure dans le 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 le Machine Learning et l’intelligence artificielle.

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

Sources de données

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

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

Conseils :

  1. Les données d’entrée doivent être validées et approuvées par le biais de l’approbation de gestion avant d’être utilisées dans un système IA.
  2. Les données collectées pour un système IA doivent être examinées avant l’utilisation ou le stockage.
  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 approuvées 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. Les données collectées doivent avoir un propriétaire responsable de son adhésion aux stratégies documentées.

Types de données sensibles

Control: pour garantir que les données stockées pour les systèmes 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 les étiquettes de classification des données, les stratégies d’accès, les informations de licence, les statistiques descriptives, la source d’origine et la date de collecte.

Déclaration de menace: les données utilisées par les systèmes d'IA sont utilisées, stockées ou accessibles de manière inappropriée lorsqu'il manque des attributs, des métadonnées ou de la documentation nécessaires.

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 la stratégie à tous les membres du personnel impliqués dans l’utilisation ou la création de systèmes IA.
  2. Implémentez 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 IA.

Stockage de 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 sans sécurité 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.

Conseils :

  1. Assurez-vous que les systèmes ou comptes de recherche d’IA ou de développement n’ont pas accès aux bases de données de production et vice versa.
  2. Les données utilisées dans les systèmes IA doivent être classifiées et protégées en fonction d’une stratégie de classification documentée.
  3. Les données utilisées dans les systèmes IA sont suivies sous une stratégie de gestion des ressources 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 géré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 gestion.
  6. Les données utilisées dans les processus Machine Learning ne doivent pas être exposées à Internet.
  7. Les données extraites d’Internet (ou d’autres sources non approuvées) doivent passer par un processus de filtrage qui inclut l’approbation de gestion.
  8. Les jeux de données doivent être versionnés avec des processus de contrôle de modification formels en place.

Accès aux données

Contrôle: Les jeux de données doivent être correctement suivis et vérifiés via le hachage cryptographique avant d’être utilisés.

Déclaration de menace: des ensembles de données sont modifiés sans autorisation.

Conseils :

  1. Le contrôle d’accès en fonction du rôle pour les jeux de données doit être appliqué.
  2. Effectuez des audits d’accès réguliers pour garantir que les comptes ayant accès aux jeux de données doivent avoir accès aux jeux de données. 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 leur utilité. 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 approuvés et doivent le rester 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 gestion mises à jour avant d’être soumises au service de suivi central.

Traitement des données

Contrôles et stratégies relatifs au traitement des données utilisées pour le Machine Learning et l’intelligence artificielle.

Objectif: pour garantir le traitement sécurisé des données de sa forme brute vers un formulaire intermédiaire prêt pour l’entraînement.

Pipelines de traitement

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

Déclaration de menace: un acteur de menace 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 passent par un système de production ne sont pas pertinentes pour les efforts de 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 paramètre de production sécurisé dans un paramètre de développement sont correctement suivies. 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 avoir besoin d’être effectuée dans un environnement intermédiaire sécurisé.
  2. L’audit approprié de l’accès aux données tout au long du cycle de vie du traitement des données est important. Sans comptes distincts, il n’existe aucun audit suffisant de l’accès. En outre, la possibilité de répondre à un incident ne peut pas se produire sans affecter potentiellement 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 son cycle de vie ; ce suivi inclut des sous-ensembles de jeux de données plus volumineux. Il doit être nécessaire qu’un modèle puisse être retracé vers les données sur laquelle il a été formé. En outre, une copie de ces données doit exister dans son intégralité.

Ouverture de l'ensemble de données

Contrôle : Garantir les sous-ensembles (par exemple, tranches temporelles, catégorielles) de données incluses pour la construction de modèles et comment cela peut entraîner des risques pour la sécurité (fuite de la vie privée, empoisonnement/intégrité via une trop grande importance accordée aux commentaires, etc.)

Énoncé de la 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 de Machine Learning (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 gestion. Inclus dans l’exception doit être une raison documentée de 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 auditables à tout moment. En outre, les modèles qui ont été formés sur des données non tracées 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.

Entraînement du modèle

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

Conception de modèle

Contrôle : Le modèle de code de formation est examiné par une partie responsable.

Déclaration de menace: code incorrect ou vulnérabilités dans le code du modèle produisent 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 des modèles peuvent avoir un effet important sur l’efficacité d’un modèle. Les environnements de production ne sont pas l’endroit pour la recherche ou pour tester des revendications non modifiables 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.

Entraînement du modèle

Contrôle : Le critère de sélection du modèle (ensembles métriques et d'attente) imite la dérive naturelle et les conditions adverses auxquelles on peut s'attendre 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 un contexte antagoniste.

Conseils :

  1. Les jeux d’entraînement et de validation doivent respecter les dépendances temporelles naturelles. Par exemple, pour les classifieurs de programmes malveillants, un jeu de validation doit inclure uniquement des versions logicielles ultérieures à celles contenues dans le jeu d’entraînement.
  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. Former explicitement aux conditions les plus défavorables à l'aide d'une formation contradictoire.
  4. Effectuez le suivi des expériences et des métadonnées associées.

Sélection du modèle

La sélection de 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’entraînement et d’hyper-paramètres d’entraînement. 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 : La conception du modèle et l'algorithme de formation incluent une régularisation explicite ou implicite du modèle.

Déclaration de menace: Les modèles sont surajustés à un ensemble de données d’entraînement et/ou de validation unique, ce qui les rend plus vulnérables aux modes d’échec.

Conseils :

  1. Lorsque cela est possible sur le plan calculatoire, il convient d'utiliser la validation croisée K-fold afin d'éviter l'ajustement excessif à un seul ensemble d'attente.
  2. Vérifier que les modèles sélectionnés fonctionnent bien sur des ensembles disparates d'exclusions afin de valider qu'ils n'ont pas été surajouté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 au fur et à mesure que de nouvelles données d'entraînement affluent dans les pipelines d'entraînement.

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

Conseils :

  1. Versionner les modèles de sorte que chaque fois qu'un modèle est formé, une nouvelle version lui est attribuée. 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’infrastructure de prise en charge.

Test de sécurité

Control: Les modèles mis en production sont correctement sécurisés.

Déclaration de menace: les systèmes d'intelligence artificielle 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 implémentés 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 ressembler étroitement à l’environnement de production final.
  5. La fréquence, l’étendue et les méthodes pour les révisions de sécurité indépendantes doivent être documentées.

Révision de la sécurité et de la conformité

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

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

Conseils :

  1. Les appareils de passerelle vers les systèmes 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, implémentées ou examinées.
  4. Le critère de séparation des réseaux ML en domaines doit être cohérent avec la stratégie de contrôle d’accès 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 ML doivent être implémentés suffisamment pour permettre un ensemble de contrôles diplômés.
  6. Les utilisateurs et les ingénieurs 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.

Surveillance du système

Contrôles et stratégies relatifs à la surveillance continue des systèmes Machine Learning et à l’infrastructure de prise en charge.

Journaux de bord et analyse des journaux de bord

Contrôle : La journalisation et le contrôle sont essentiels pour les systèmes de ML pour des raisons de sécurité.

Instruction sur la menace : Lors d'une enquête, les journaux des systèmes ML sont introuvables.

Conseils :

  1. La journalisation et la surveillance doivent se produire de manière cohérente sur tous les systèmes 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 rassemblés dans un lieu central.

Déclaration de Menace: Pendant une enquête, les analystes de sécurité n’ont pas de manuel formalisé.

Conseils :

  1. Les organisations pour devront suivre un processus formel pour signaler les incidents de 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 d’un événement de sécurité des informations.
  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é d’activité

Planification, examen et résultats

Contrôle: Assurez-vous que les systèmes ML peuvent être corrigés et récupérés après un incident.

Déclaration de menace: Les incidents provoquent des problèmes persistants de confidentialité, d’intégrité ou de disponibilité pour les systèmes critiques d'apprentissage automatique.

Conseils :

  1. Les ressources IA critiques doivent être identifiées et inventoriés.
  2. L’organisation doit développer un plan de continuité d’activité (BCP) ou un processus de récupération d’urgence (DR) face à des attaques sur les systèmes IA.
  3. L'organisation doit identifier et prioriser les risques associés à l'impact de la perte de systèmes IA critiques en raison d'attaques.
  4. Les organisations doivent disposer d’un test de continuité d’activité exécuté selon une planification répétée pour les systèmes IA critiques.

Références

Si vous avez des questions, des commentaires ou des retours d'expérience, contactez atml@microsoft.com.

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