Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Par Andrew Marshall, Jugal Parikh, Emre Kiciman et Ram Shankar Siva Kumar
Merci spécial à Raul Rojas et au travail d’ingénierie de sécurité AETHER
Novembre 2019
Ce document est un livrable du groupe de travail AETHER Engineering Practices for AI et complète les pratiques existantes de modélisation des menaces SDL en fournissant de nouvelles instructions sur l’énumération des menaces et l’atténuation spécifiques à l’espace IA et Machine Learning. Il est destiné à être utilisé comme référence pendant les révisions de conception de sécurité des éléments suivants :
Produits/services interagissant avec ou prenant des dépendances sur les services basés sur l’IA/ML
Produits/services créés avec l’IA/ML à leur cœur
L’atténuation traditionnelle des menaces de sécurité est plus importante que jamais. Les exigences établies par le cycle de vie du développement de la sécurité sont essentielles pour établir une base de sécurité des produits sur laquelle repose cette aide. Ne pas traiter les menaces de sécurité traditionnelles rend possibles les attaques spécifiques à l’IA/ML décrites dans ce document, tant dans les domaines logiciels que physiques, et facilite la compromission au niveau inférieur de la pile logicielle. Pour une présentation des nouvelles menaces de sécurité nettes dans cet espace, consultez La sécurisation de l’avenir de l’IA et du ML chez Microsoft.
Les compétences des ingénieurs de sécurité et des scientifiques des données ne se chevauchent généralement pas. Cette orientation propose une manière pour les deux disciplines d'avoir des conversations structurées sur ces nouvelles menaces/atténuations, sans nécessiter que les ingénieurs en sécurité deviennent des scientifiques de données ou vice versa.
Ce document est divisé en deux sections :
- « Principales considérations relatives à la modélisation des menaces » se concentre sur de nouvelles façons de penser et de nouvelles questions à poser lors de la modélisation des menaces des systèmes IA/ML. Les scientifiques des données et les ingénieurs de sécurité doivent examiner cette situation, car il s’agira de leur playbook pour les discussions sur la modélisation des menaces et la hiérarchisation des atténuations.
- « Menaces spécifiques à l’IA/ML et à leurs atténuations » fournit des détails sur des attaques spécifiques ainsi que des étapes d’atténuation spécifiques à utiliser aujourd’hui pour protéger les produits et services Microsoft contre ces menaces. Cette section s’adresse principalement aux scientifiques des données qui peuvent avoir besoin d’implémenter des atténuations spécifiques des menaces en tant que sortie du processus de modélisation des menaces/examen de sécurité.
Ce guide est organisé autour d'une taxonomie des menaces en apprentissage automatique adversaire créée par Ram Shankar Siva Kumar, David O’Brien, Kendra Albert, Salome Viljoen et Jeffrey Snover, intitulée « Failure Modes in Machine Learning ». Pour obtenir des conseils de gestion des incidents sur le tri des menaces de sécurité détaillées dans ce document, reportez-vous à la barre de bogues SDL pour les menaces IA/ML. Tous ces documents sont des documents vivants qui évolueront au fil du temps avec le paysage des menaces.
Éléments clés à prendre en compte dans la modélisation des menaces : modifier la manière dont vous percevez les limites de confiance
Supposez la compromission/empoisonnement des données à partir desquelles vous vous entraînez et le fournisseur de données. Apprenez à détecter les entrées de données anormales et malveillantes, ainsi qu’à faire la distinction entre et récupérer à partir de celles-ci
Résumé
Les magasins de données d’apprentissage et les systèmes qui les hébergent font partie de votre étendue de modélisation des menaces. La plus grande menace de sécurité dans le Machine Learning aujourd’hui est l’empoisonnement des données en raison de l’absence de détections et d’atténuations standard dans cet espace, combinée à la dépendance vis-à-vis des jeux de données publics non approuvés/non approuvés en tant que sources de données d’apprentissage. Le suivi de la provenance et de la traçabilité de vos données est essentiel pour garantir sa fiabilité et éviter un cycle d’entraînement « garbage in, garbage out ».
Questions à poser dans une révision de sécurité
Si vos données sont empoisonnées ou falsifiées, comment savez-vous ?
-Quelles données de télémétrie avez-vous pour détecter un décalage dans la qualité de vos données d’apprentissage ?
Êtes-vous en formation à partir d’entrées fournies par l’utilisateur ?
-Quel type de validation/assainissement d’entrée faites-vous sur ce contenu ?
-La structure de ces données est-elle similaire aux feuilles de données pour les jeux de données ?
Si vous effectuez l’apprentissage sur des magasins de données en ligne, quelles étapes suivez-vous pour garantir la sécurité de la connexion entre votre modèle et les données ?
-Ont-ils un moyen de signaler des compromissions aux consommateurs de leurs aliments ?
-Sont-ils même capables de cela ?
Quelle est la sensibilité des données depuis lesquelles vous effectuez l’apprentissage ?
-Le cataloguez-vous ou contrôlez l’ajout/mise à jour/suppression des entrées de données ?
Votre modèle peut-il générer des données sensibles ?
-Ces données ont-elles été obtenues avec l’autorisation de la source ?
Le modèle génère-t-il uniquement les résultats nécessaires pour atteindre son objectif ?
Votre modèle retourne-t-il des scores de confiance bruts ou toute autre sortie directe qui peut être enregistrée et dupliquée ?
Quel est l’impact de vos données d’apprentissage récupérées en attaquant/invertissant votre modèle ?
Si les niveaux de confiance de votre modèle tombent soudainement, pouvez-vous découvrir comment/pourquoi, ainsi que les données qui l’ont provoqué ?
Avez-vous défini une entrée bien formée pour votre modèle ? Que faites-vous pour vous assurer que les entrées répondent à ce format et que faites-vous si ce n’est pas le cas ?
Si vos sorties sont incorrectes, mais ne provoquent pas de signalement d’erreurs, comment savez-vous ?
Savez-vous si vos algorithmes d’entraînement sont résilients aux entrées contradictoires au niveau mathématique ?
Comment remédier à une contamination adversariale de vos données d’entraînement ?
-Pouvez-vous isoler/mettre en quarantaine du contenu contradictoire et réentreîner des modèles impactés ?
-Pouvez-vous revenir à un modèle d'une version précédente pour le réentraînement ?
Utilisez-vous l’apprentissage par renforcement sur du contenu public non évalué ?
Commencez à réfléchir à la traçabilité de vos données : avez-vous trouvé un problème, pourriez-vous le suivre à son introduction dans le jeu de données ? Si ce n’est pas le cas, est-ce un problème ?
Savoir d'où proviennent vos données d'apprentissage et identifier les normes statistiques afin de commencer à comprendre à quoi ressemblent les anomalies.
-Quels éléments de vos données d’apprentissage sont vulnérables à l’influence extérieure ?
-Qui peut contribuer aux jeux de données à partir duquel vous effectuez une formation ?
- Comment attaquer vos sources de données d’entraînement pour nuire à un concurrent ?
Menaces et atténuations connexes dans ce document
Perturbation adversaire (toutes les variantes)
Empoisonnement des données (toutes les variantes)
Exemples d’attaques
Forcer la classification des e-mails bénins en tant que spam ou permettre à un e-mail malveillant de passer inaperçu.
Entrées conçues par des attaquants qui réduisent le niveau de confiance de la classification correcte, en particulier dans les scénarios à conséquence élevée
L’attaquant injecte du bruit de façon aléatoire dans les données sources classifiées afin de réduire la probabilité que la classification correcte soit utilisée à l’avenir, réduisant efficacement le modèle
Contamination des données d’entraînement pour forcer la classification incorrecte des points de données sélectionnés, ce qui entraîne l’exécution ou l’omission d’une action spécifique par un système
Identifier les actions que votre ou vos modèles ou produits/services peuvent entreprendre, ce qui peut entraîner des dommages au client en ligne ou dans le domaine physique
Résumé
Les attaques sur les systèmes d'IA/AM laissés sans atténuation peuvent atteindre le monde physique. Tout scénario pouvant être manipulé pour nuire psychologiquement ou physiquement aux utilisateurs constitue un risque catastrophique pour votre produit/service. Cela s'étend à toute donnée sensible concernant vos clients utilisée pour l'apprentissage et les choix de conception qui pourraient divulguer ces données sensibles.
Questions à poser dans une révision de sécurité
Vous entraînez-vous avec des exemples contradictoires ? Quel impact ont-ils sur la sortie de votre modèle dans le domaine physique ?
À quoi ressemble le trolling pour votre produit/service ? Comment pouvez-vous détecter et y répondre ?
Qu’est-ce qu’il faudrait pour que votre modèle retourne un résultat qui permet à votre service de refuser l’accès aux utilisateurs légitimes ?
Quel est l’impact de votre modèle copié/volé ?
Votre modèle peut-il être utilisé pour déduire l’appartenance d’une personne individuelle dans un groupe particulier ou simplement dans les données d’entraînement ?
Un attaquant peut-il causer des dommages réputationnels ou un retour de bâton médiatique à votre produit en le forçant à effectuer des actions spécifiques ?
Comment gérez-vous des données correctement mises en forme mais trop biaisées, telles que des trolls ?
Pour chaque façon d’interagir avec ou d’interroger votre modèle est exposée, cette méthode peut-elle être interrogée pour divulguer des données d’apprentissage ou des fonctionnalités de modèle ?
Menaces et atténuations connexes dans ce document
Inférence d’appartenance
Inversion de modèle
Vol de modèle
Exemples d’attaques
Reconstruction et extraction des données d’apprentissage en interrogeant à plusieurs reprises le modèle pour obtenir des résultats de confiance maximale
Duplication du modèle lui-même par correspondance de requête/réponse exhaustive
Requête au modèle de manière à révéler qu'un élément spécifique de données privées a été inclus dans le jeu d'entraînement
Voiture autonome trompée pour ignorer les panneaux d’arrêt et les feux de circulation
Les bots conversationnels manipulés pour troller des utilisateurs bénins
Identifier toutes les sources de dépendances IA/ML ainsi que les couches de présentation frontale dans votre chaîne d’approvisionnement de données/modèle
Résumé
De nombreuses attaques dans l’IA et l'apprentissage automatique commencent par un accès légitime aux API qui sont exposées pour permettre des requêtes à un modèle. En raison des sources riches en données et en expériences utilisateur riches impliquées ici, un accès tiers authentifié mais « inapproprié » (il existe ici une zone grise) à vos modèles présente un risque en raison de la capacité d’agir en tant que couche d'interface au-dessus d’un service fourni par Microsoft.
Questions à poser dans une révision de sécurité
Quels clients/partenaires sont authentifiés pour accéder à votre modèle ou API de service ?
-Peuvent-ils agir en tant que couche de présentation sur votre service ?
-Pouvez-vous révoquer rapidement leur accès en cas de compromission ?
-Quelle est votre stratégie de récupération en cas d’utilisation malveillante de votre service ou dépendances ?
Untiers peut-il construire une façade autour de votre modèle pour le réutiliser et nuire à Microsoft ou à ses clients ?
Les clients fournissent-ils directement des données d’apprentissage ?
-Comment sécuriser ces données ?
-Que se passe-t-il si elle est malveillante et que votre service est la cible ?
À quoi ressemble un faux positif ici ? Quel est l’impact d’un faux négatif ?
Pouvez-vous suivre et mesurer l’écart entre les taux vrais positifs et faux positifs sur plusieurs modèles ?
De quel type de télémétrie avez-vous besoin pour prouver la fiabilité des résultats de votre modèle à vos clients ?
Identifiez toutes lesdépendances tierces de votre chaîne d’approvisionnement de données ML/Training , pas seulement les logiciels open source, mais aussi les fournisseurs de données.
-Pourquoi les utilisez-vous et comment vérifier leur fiabilité ?
Est-ce que vous utilisez des modèles prédéfinis de tiers ou envoyez-vous des données d'entraînement à des fournisseurs MLaaS tiers ?
Répertoriez les actualités concernant les attaques sur des produits/services similaires. Comprendre que de nombreuses menaces IA/ML sont transférées entre les types de modèles, quel impact ces attaques auraient-elles sur vos propres produits ?
Menaces et atténuations connexes dans ce document
Reprogrammation de réseau neuronal
Exemples contradictoires dans le domaine physique
Fournisseurs malveillants d'apprentissage automatique récupérant des données de formation
Attaque de la chaîne d’approvisionnement ML
Modèle avec une porte dérobée
Dépendances spécifiques à l'apprentissage automatique compromises
Exemples d’attaques
Un fournisseur MLaaS malveillant infecte votre modèle avec un bypass spécifique.
Un client malveillant découvre une vulnérabilité dans une dépendance commune de votre OSS, télécharge une charge utile de données d'entraînement manipulées pour compromettre votre service.
Un partenaire sans scrupule utilise des API de reconnaissance faciale et crée une couche de présentation sur votre service pour produire Deep Fakes.
Menaces spécifiques à l’IA/ML et à leurs atténuations
#1 : Perturbation contradictoire
Descriptif
Dans les attaques de type perturbation, l’attaquant modifie furtivement la requête pour obtenir une réponse souhaitée à partir d’un modèle déployé en production[1]. Il s’agit d’une violation de l’intégrité de l’entrée du modèle qui conduit à des attaques de style flou où le résultat final n’est pas nécessairement une violation d’accès ou EOP, mais compromet plutôt les performances de classification du modèle. Cela peut également être manifeste par des trolls utilisant certains mots cibles d’une manière que l’IA les interdit, refusant efficacement le service aux utilisateurs légitimes avec un nom correspondant à un mot « interdit ».
[24]
Variante #1a : classification incorrecte ciblée
Dans ce cas, les attaquants génèrent un exemple qui n’est pas dans la classe d’entrée du classifieur cible, mais qui est classé par le modèle comme classe d’entrée particulière. L’exemple contradictoire peut apparaître comme un bruit aléatoire aux yeux humains, mais les attaquants ont une connaissance du système d’apprentissage automatique cible pour générer un bruit blanc qui n’est pas aléatoire, mais exploite certains aspects spécifiques du modèle cible. L’adversaire fournit un échantillon d'entrée qui n’est pas légitime, mais le système cible le classifie comme une catégorie légitime.
Exemples
[6]
Atténuation
Renforcement de la robustesse face aux attaques adverses à l’aide de la confiance du modèle induite par l’entraînement contradictoire [19] : les auteurs proposent le cadre HCNN (Highly Confident Near Neighbor), qui combine les informations de confiance et la recherche du voisin le plus proche, afin de renforcer la robustesse du modèle initial. Cela peut aider à distinguer les prédictions de modèle correctes et incorrectes dans un voisinage d’un point échantillonné de la distribution d’entraînement sous-jacente.
Analyse causale pilotée par l’attribution [20] : les auteurs étudient la connexion entre la résilience aux perturbations contradictoires et l’explication basée sur l’attribution des décisions individuelles générées par les modèles Machine Learning. Ils signalent que les entrées contradictoires ne sont pas robustes dans l’espace d’attribution, c’est-à-dire que le masquage de quelques fonctionnalités avec une attribution élevée conduit à changer l’indécision du modèle Machine Learning sur les exemples contradictoires. En revanche, les entrées naturelles sont robustes dans l’espace d’attribution.
[20]
Ces approches peuvent rendre les modèles d'apprentissage automatique plus résilients aux attaques adversaires, car déjouer ce système cognitif à deux couches nécessite non seulement d'attaquer le modèle d'origine, mais également de s'assurer que l'attribution générée pour l'exemple adversaire est similaire aux exemples originaux. Les deux systèmes doivent être compromis simultanément pour une attaque contradictoire réussie.
Parallèles traditionnels
Élévation de privilège à distance car l'attaquant a pris le contrôle de votre modèle
Sévérité
Essentiel
Variante #1b : classification incorrecte source/cible
Il s’agit d’une tentative par un attaquant de faire en sorte qu’un modèle retourne l’étiquette souhaitée pour une entrée donnée. Cela force généralement un modèle à retourner un faux positif ou un faux négatif. Le résultat final est une prise de contrôle subtile de la précision de classification du modèle, par laquelle un attaquant peut provoquer des contournements spécifiques à volonté.
Bien que cette attaque ait un impact significatif sur l’exactitude de la classification, il peut également être plus fastidieux de s’exécuter, étant donné qu’un adversaire ne doit pas seulement manipuler les données sources afin qu’elles ne soient plus étiquetées correctement, mais également étiquetées spécifiquement avec l’étiquette frauduleuse souhaitée. Ces attaques impliquent souvent plusieurs étapes/tentatives de forcer la classification incorrecte [3]. Si le modèle est susceptible aux attaques d'apprentissage par transfert qui provoquent une erreur de classification ciblée, il peut n’y avoir aucune empreinte de trafic d’attaquant discernable, car les attaques de sondage peuvent être effectuées hors connexion.
Exemples
Forcer la classification des e-mails bénins en tant que courrier indésirable ou laisser passer un exemple malveillant inaperçu. Ces attaques sont également connues sous le nom d’évasion de modèle ou d’attaques par mimétisme.
Atténuation
Actions de détection réactives/défensives
- Implémentez un seuil de temps minimal entre les appels à l’API fournissant des résultats de classification. Cela ralentit les tests d’attaque en plusieurs étapes en augmentant le temps global nécessaire pour trouver une perturbation du succès.
Actions proactives/de protection
Dénoisage des caractéristiques pour améliorer la robustesse contradictoire [22] : les auteurs développent une nouvelle architecture réseau qui augmente la robustesse contradictoire en effectuant un dénoisage des fonctionnalités. Plus précisément, les réseaux contiennent des blocs qui dénoisent les fonctionnalités à l’aide de moyens non locaux ou d’autres filtres ; les réseaux entiers sont formés de bout en bout. Lorsqu’ils sont combinés avec l’entraînement contradictoire, les réseaux de dénoisage des caractéristiques améliorent considérablement l’état de l’art dans la robustesse contradictoire dans les paramètres d’attaque de boîte blanche et de boîte noire.
Formation et régularisation contradictoires : entraîner avec des exemples contradictoires connus pour renforcer la résilience et la robustesse contre les entrées malveillantes. Cela peut également être considéré comme une forme de régularisation, qui pénalise la norme des dégradés d’entrée et rend la fonction de prédiction du classifieur plus lisse (augmentant la marge d’entrée). Cela inclut des classifications correctes avec des taux de confiance inférieurs.
Investissez dans le développement d’une classification monotonique avec la sélection de caractéristiques monotoniques. Cela garantit que l’adversaire ne sera pas en mesure d’échapper au classifieur en remplissant simplement les caractéristiques de la classe négative [13].
La mise en file d’attente des fonctionnalités [18] peut être utilisée pour renforcer les modèles DNN en détectant des exemples contradictoires. Il réduit l’espace de recherche disponible pour un adversaire en fusionnant des échantillons qui correspondent à de nombreux vecteurs de caractéristiques différents dans l’espace d’origine en un seul échantillon. En comparant la prédiction d’un modèle DNN sur l’entrée d’origine avec celle sur l’entrée compressée, la compression des caractéristiques peut aider à détecter des exemples adversaires. Si les exemples originaux et pressés produisent des sorties sensiblement différentes du modèle, l’entrée est susceptible d’être contradictoire. En mesurant le désaccord entre les prédictions et en sélectionnant une valeur de seuil, le système peut générer la prédiction correcte pour les exemples légitimes et rejeter les entrées contradictoires.
[18]Défenses certifiées contre les exemples contradictoires [22] : les auteurs proposent une méthode basée sur une relaxation semi-définitive qui génère un certificat qui pour un réseau donné et teste une entrée, aucune attaque ne peut forcer l’erreur à dépasser une certaine valeur. Deuxièmement, étant donné que ce certificat est différentiable, les auteurs l’optimisent conjointement avec les paramètres réseau, fournissant un normaliseur adaptatif qui encourage la robustesse contre toutes les attaques.
Actions de réponse
- Émettre des alertes sur les résultats de classification avec une variance élevée entre les classifieurs, en particulier si un seul utilisateur ou un petit groupe d’utilisateurs.
Parallèles traditionnels
Élévation de privilèges à distance
Sévérité
Essentiel
Variante #1c : classification incorrecte aléatoire
Il s’agit d’une variante spéciale où la classification cible de l’attaquant peut être autre que la classification source légitime. L’attaque implique généralement l’injection de bruit de manière aléatoire dans les données sources classifiées afin de réduire la probabilité que la classification correcte soit utilisée à l’avenir [3].
Exemples
Atténuation
Identique à variant 1a.
Parallèles traditionnels
Déni de service non persistant
Sévérité
Important
Variante #1d : Réduction de la confiance
Un attaquant peut créer des entrées pour réduire le niveau de confiance de la classification correcte, en particulier dans les scénarios à conséquence élevée. Cela peut également prendre la forme d’un grand nombre de faux positifs destinés à surcharger les administrateurs ou les systèmes de surveillance avec des alertes frauduleuses indistinguishables à partir d’alertes légitimes [3].
Exemples
Atténuation
- Outre les actions couvertes dans variant #1a, la limitation des événements peut être utilisée pour réduire le volume d’alertes d’une seule source.
Parallèles traditionnels
Déni de service non persistant
Sévérité
Important
#2a empoisonnement ciblé des données
Descriptif
L’objectif de l’attaquant est de contaminer le modèle d’ordinateur généré dans la phase d’entraînement, afin que les prédictions sur les nouvelles données soient modifiées dans la phase de test[1]. Dans les attaques ciblées contre l’empoisonnement, l’attaquant souhaite classer de manière incorrecte des exemples spécifiques afin de provoquer des actions spécifiques ou omises.
Exemples
Soumettre un logiciel AV en tant que logiciel malveillant pour forcer sa mauvaise classification comme malveillante et éliminer l’utilisation de logiciels AV ciblés sur les systèmes clients.
Atténuation
Définir des capteurs d’anomalies pour examiner la distribution des données au jour le jour et l’alerte sur les variations
-Mesurer la variation quotidienne des données d’entraînement, télémétrie pour le biais/la dérive
Validation des entrées, comprenant à la fois l'assainissement et la vérification de l'intégrité
L’empoisonnement injecte des échantillons d’entraînement sortants. Deux stratégies principales pour contrer cette menace :
-Nettoyage des données/ validation : éliminez les échantillons malveillants des données d’entraînement -Bagging pour lutter contre les attaques d’empoisonnement [14]
-Reject-on-Negative-Impact (RONI) défense [15]
- Apprentissage robuste : choisissez des algorithmes d’apprentissage robustes en présence d’échantillons d’empoisonnement.
-Une telle approche est décrite dans [21] où les auteurs résolvent le problème de l’empoisonnement des données en deux étapes : 1) l’introduction d’une nouvelle méthode de factorisation de matrice robuste pour récupérer la véritable sous-espace et 2) nouvelle régression de composant principal robuste pour découper les instances contradictoires en fonction de la base récupérée à l’étape (1). Ils caractérisent les conditions nécessaires et suffisantes pour récupérer correctement le sous-espace réel et présenter une limite à la perte de prédiction attendue par rapport à la vérité terrestre.
Parallèles traditionnels
Hôte Troie dans lequel l’attaquant persiste sur le réseau. Les données d’entraînement ou de configuration sont compromises et ingérées et approuvées dans le but de la création d'un modèle.
Sévérité
Essentiel
#2b Empoisonnement indiscriminé des données
Descriptif
L’objectif est de ruiner la qualité/l’intégrité du jeu de données attaqué. De nombreux jeux de données sont publics/non fiables/non curés, ce qui suscite des préoccupations accrues concernant la possibilité d'identifier de telles violations de l'intégrité des données en premier lieu. La formation sur les données compromises à l'insu est une situation de garbage-in/garbage-out. Une fois détecté, le triage doit déterminer l’étendue des données qui ont été violées et mises en quarantaine/réentraînées.
Exemples
Une société extrait les données sur les contrats à terme sur le pétrole d'un site web bien connu et approuvé pour former ses modèles. Le site web du fournisseur de données est ensuite compromis par le biais d’une attaque par injection SQL. L’attaquant peut empoisonner le jeu de données à la volonté et le modèle entraîné n’a aucune notion que les données sont teintes.
Atténuation
Identique à la variante 2a.
Parallèles traditionnels
Déni de service authentifié sur une ressource à valeur élevée
Sévérité
Important
#3 Attaques d’inversion de modèle
Descriptif
Les fonctionnalités privées utilisées dans les modèles Machine Learning peuvent être récupérées [1]. Cela inclut la reconstruction des données d’entraînement privées auxquelles l’attaquant n’a pas accès. Également connues sous le nom d'attaques par escalade dans la communauté biométrique [16, 17], ceci est réalisé en recherchant l'entrée qui maximise le niveau de confiance retourné, sous condition que la classification corresponde à la cible [4].
Exemples
[4]
Atténuation
Les interfaces pour les modèles entraînés à partir de données sensibles nécessitent un contrôle d’accès fort.
Requêtes de limite de débit autorisées par modèle
Implémentez des portes entre les utilisateurs/appelants et le modèle réel en effectuant une validation d’entrée sur toutes les requêtes proposées, en rejetant tout ce qui ne répond pas à la définition de l’entrée et en retournant uniquement la quantité minimale d’informations nécessaires pour être utiles.
Parallèles traditionnels
Divulgation d’informations ciblées et secrètes
Sévérité
Cette valeur par défaut est importante conformément à la barre de bogues SDL standard, mais l'extraction de données sensibles ou identifiables personnellement ferait passer cela à un niveau critique.
#4 Attaque d’inférence d’appartenance
Descriptif
L’attaquant peut déterminer si un enregistrement de données donné faisait partie du jeu de données d’entraînement du modèle ou non[1]. Les chercheurs ont pu prédire la procédure principale chez un patient (par exemple, la chirurgie que le patient a subie) en fonction des attributs (par exemple : âge, sexe, hôpital) [1].
[12]
Atténuation
Les documents de recherche illustrant la viabilité de cette attaque indiquent que la confidentialité différentielle [4, 9] serait une atténuation efficace. Il s’agit toujours d’un domaine naissant chez Microsoft et AETHER Security Engineering recommande de développer une expertise en matière d’investissements de recherche dans cet espace. Cette recherche aurait besoin d’énumérer les fonctionnalités de confidentialité différentielles et d’évaluer leur efficacité pratique en tant qu’atténuations, puis concevoir des méthodes pour que ces défenses soient héritées de manière transparente sur nos plateformes de services en ligne, comme la compilation de code dans Visual Studio vous donne on-by-protections de sécurité par défaut qui sont transparentes pour les développeurs et les utilisateurs.
L’utilisation du dropout neuronal et de l’empilement de modèles peuvent être des mesures d'atténuation efficaces dans une certaine mesure. L’utilisation du abandon neuronal augmente non seulement la résilience d’un réseau neuronal à cette attaque, mais augmente également les performances du modèle [4].
Parallèles traditionnels
Confidentialité des données. Les inférences sont faites sur l’inclusion d’un point de données dans le jeu d’entraînement, mais les données d’apprentissage proprement dites ne sont pas divulguées
Sévérité
Il s’agit d’un problème de confidentialité, et non d’un problème de sécurité. Elle est traitée dans les conseils de modélisation des menaces, car les domaines se chevauchent, mais toute réponse ici serait pilotée par la confidentialité, et non par la sécurité.
#5 Vol de modèle
Descriptif
Les attaquants recréent le modèle sous-jacent en interrogeant légitimement le modèle. La fonctionnalité du nouveau modèle est identique à celle du modèle sous-jacent[1]. Une fois le modèle recréé, il peut être inversé pour récupérer des informations sur les fonctionnalités ou effectuer des inférences sur les données d’apprentissage.
Résolution d’équations : pour un modèle qui retourne des probabilités de classe via la sortie de l’API, un attaquant peut créer des requêtes pour déterminer des variables inconnues dans un modèle.
Recherche de chemin d’accès : attaque qui exploite les particularités de l’API pour extraire les « décisions » prises par une arborescence lors de la classification d’une entrée [7].
Attaque de transfert - Un adversaire peut entraîner un modèle local( éventuellement en émettant des requêtes de prédiction au modèle ciblé) et l’utiliser pour créer des exemples contradictoires qui transfèrent vers le modèle cible [8]. Si votre modèle est extrait et découvert vulnérable à un type d’entrée contradictoire, de nouvelles attaques contre votre modèle déployé en production peuvent être développées entièrement hors connexion par l’attaquant qui a extrait une copie de votre modèle.
Exemples
Dans les paramètres où un modèle ML sert à détecter le comportement contradictoire, comme l’identification du courrier indésirable, la classification des programmes malveillants et la détection des anomalies réseau, l’extraction de modèle peut faciliter les attaques d’évasion [7].
Atténuation
Actions proactives/de protection
Réduisez ou obfusez les détails retournés dans les API de prédiction tout en conservant leur utilité pour les applications « honnêtes » [7].
Définissez une requête bien formée pour vos entrées de modèle et retournez uniquement des résultats en réponse aux entrées terminées et bien formées correspondant à ce format.
Retourne les valeurs de confiance arrondies. La plupart des appelants légitimes n’ont pas besoin de précision à plusieurs décimales.
Parallèles traditionnels
Falsification non authentifiée et en lecture seule des données système, divulgation d’informations à valeur élevée ciblée ?
Sévérité
Important dans les modèles sensibles à la sécurité, Modéré sinon
#6 Reprogrammation de réseau neuronal
Descriptif
Par le biais d’une requête spécialement conçue d’un adversaire, les systèmes Machine Learning peuvent être convertis en une tâche qui s’écarte de l’intention originale du créateur [1].
Exemples
Contrôles d’accès faibles sur une API de reconnaissance faciale permettant aux tiers d'intégrer dans des applications conçues pour nuire aux clients Microsoft, comme un générateur de deepfakes.
Atténuation
Authentification mutuelle client-serveur<> forte et contrôle d’accès aux interfaces de modèle
Suppression des comptes incriminés.
Identifiez et appliquez un contrat de niveau de service pour vos API. Déterminez le délai de résolution acceptable d’un problème une fois signalé et assurez-vous que le problème ne se reproduise plus une fois que le SLA a expiré.
Parallèles traditionnels
Il s’agit d’un scénario d’abus. Vous êtes moins susceptible d'ouvrir un incident de sécurité qu'à simplement désactiver le compte de l'utilisateur fautif.
Sévérité
De l'important au critique
#7 Exemple contradictoire dans le domaine physique (bits-atoms>)
Descriptif
Un exemple contradictoire est une entrée/requête d’une entité malveillante envoyée dans le seul but de tromper le système Machine Learning [1]
Exemples
Ces exemples peuvent se manifester dans le domaine physique, comme une voiture auto-conduite qui est trompée dans l’exécution d’un signe d’arrêt en raison d’une certaine couleur de lumière (l’entrée contradictoire) qui s’est déclenchée sur le signe d’arrêt, forçant le système de reconnaissance d’image à ne plus voir le signe d’arrêt comme un signe d’arrêt.
Parallèles traditionnels
Élévation de privilèges, exécution de code distant
Atténuation
Ces attaques se manifestent parce que les problèmes de la couche Machine Learning (la couche de données et d’algorithme sous la prise de décision pilotée par l’IA) n’ont pas été atténués. Comme avec tout autre système physique *ou* logiciel, la couche située en dessous de la cible peut toujours être attaquée par le biais de vecteurs traditionnels. En raison de cela, les pratiques de sécurité traditionnelles sont plus importantes que jamais, en particulier avec la couche de vulnérabilités nonmitigées (couche de données/algo) utilisée entre l’IA et les logiciels traditionnels.
Sévérité
Essentiel
#8 Fournisseurs ML malveillants qui peuvent récupérer des données d’apprentissage
Descriptif
Un fournisseur malveillant présente un algorithme dérobé, où les données d’entraînement privées sont récupérées. Ils ont pu reconstruire des visages et des textes uniquement avec le modèle.
Parallèles traditionnels
Divulgation d’informations ciblées
Atténuation
Les documents de recherche illustrant la viabilité de cette attaque indiquent que le chiffrement homomorphe serait une atténuation efficace. Il s’agit d’un domaine avec peu d’investissements actuels chez Microsoft et AETHER Security Engineering recommande de développer une expertise avec les investissements de recherche dans cet espace. Cette recherche aurait besoin d’énumérer les principes de chiffrement homomorphique et d’évaluer leur efficacité pratique en tant qu’atténuations face aux fournisseurs de ML-as-a-Service malveillants.
Sévérité
Important si les données sont des informations d’identification personnelle, Modérée dans le cas contraire
#9 Attaque de la chaîne d’approvisionnement ML
Descriptif
En raison de ressources volumineuses (données + calcul) requises pour entraîner des algorithmes, la pratique actuelle consiste à réutiliser les modèles entraînés par les grandes entreprises et à les modifier légèrement pour les tâches à la main (par exemple, ResNet est un modèle de reconnaissance d’image populaire de Microsoft). Ces modèles sont organisés dans un zoo de modèles (Caffe héberge des modèles de reconnaissance d’images populaires). Dans cette attaque, l’adversaire s'en prend aux modèles hébergés sur Caffe, compromettant ainsi le système pour les autres utilisateurs. [1]
Parallèles traditionnels
Compromission de dépendances tierces non liées à la sécurité
App Store sans connaissance hébergeant des programmes malveillants
Atténuation
Réduisez les dépendances tierces pour les modèles et les données, le cas échéant.
Incorporez ces dépendances dans votre processus de modélisation des menaces.
Tirez parti de l’authentification forte, du contrôle d’accès et du chiffrement entre les systèmes de la 1re/3e partie.
Sévérité
Essentiel
#10 Apprentissage Automatique avec Porte Dérobée
Descriptif
Le processus d’entraînement est externalisé à un tiers malveillant qui falsifie les données d’entraînement et a fourni un modèle troie qui force les classifications incorrectes ciblées, telles que la classification d’un certain virus comme non malveillant[1]. Il s’agit d’un risque dans les scénarios de génération de modèle ML-as-a-Service.
[12]
Parallèles traditionnels
Compromission de la dépendance de sécurité de tierce partie
Mécanisme de mise à jour logicielle compromise
Compromission de l’autorité de certification
Atténuation
Actions de détection réactives/défensives
- Les dommages sont déjà faits une fois que cette menace a été découverte, de sorte que le modèle et toutes les données d'apprentissage fournies par le fournisseur malveillant ne peuvent pas être considérées comme fiables.
Actions proactives/de protection
Entraîner tous les modèles sensibles en interne
Cataloguer les données d’apprentissage ou s’assurer qu’elles proviennent d’un tiers approuvé avec des pratiques de sécurité fortes
Évaluez les menaces de l'interaction entre le fournisseur de MLaaS et vos propres systèmes.
Actions de réponse
- Identique à la compromission de la dépendance externe
Sévérité
Essentiel
#11 Exploiter les dépendances logicielles du système ML
Descriptif
Dans cette attaque, l’attaquant ne manipule pas les algorithmes. Au lieu de cela, exploite les vulnérabilités logicielles telles que les dépassements de mémoire tampon ou les scripts intersites[1]. Il est toujours plus facile de compromettre les couches logicielles sous IA/ML que d’attaquer directement la couche d’apprentissage, de sorte que les pratiques traditionnelles d’atténuation des menaces de sécurité détaillées dans le cycle de vie du développement de la sécurité sont essentielles.
Parallèles traditionnels
Dépendance de logiciel open source compromise
Vulnérabilité du serveur web (XSS, CSRF, échec de validation d’entrée d’API)
Atténuation
Collaborez avec votre équipe de sécurité pour suivre les bonnes pratiques applicables en matière de cycle de vie de développement de sécurité/assurance de sécurité opérationnelle.
Sévérité
Variable; Jusqu’à Critique en fonction du type de vulnérabilité logicielle traditionnelle.
Bibliographie
[1] Modes d’échec dans le Machine Learning, Ram Shankar Siva Kumar, David O’Brien, Kendra Albert, Salome Viljoen et Jeffrey Snover, https://learn.microsoft.com/security/failure-modes-in-machine-learning
[2] AETHER Security Engineering Workstream, Data Provenance/Lineage v-team
[3] Exemples contradictoires dans Deep Learning : caractérisation et divergence, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf
[4] ML-Leaks : Attaques et défenses d'inférence d'appartenance indépendantes des modèles de Machine Learning, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf
M. Fredrikson, S. Jha et T. Ristenpart, « Attaques d’inversion de modèle qui exploitent les informations de confiance et les contre-mesures de base », dans les actes de la Conférence ACM SIGSAC 2015 sur la sécurité informatique et des communications (CCS).
[6] Nicolas Papernot & Patrick McDaniel - Exemples contradictoires dans Machine Learning AIWTB 2017
[7] Vol de modèles Machine Learning via des API de prédiction, Florian Tramèr, l’École Polytechnique Fédérale de Lausanne (EPFL) ; Fan Zhang, Université Cornell ; Ari Juels, Cornell Tech ; Michael K. Reiter, l’Université de Caroline du Nord à Chapel Hill ; Thomas Ristenpart, Cornell Tech
[8] L’espace des exemples contradictoires transférables, Florian Tramèr , Nicolas Papernot , Ian Goodfellow , Dan Boneh et Patrick McDaniel
[9] Compréhension des inférences d’appartenance sur Well-Generalized Modèles d'apprentissage Yunhui Long1 , Vincent Bindschaedler1 , Lei Wang2 , Diyue Bu2 , Xiaofeng Wang2 , Haixu Tang2 , Carl A. Gunter1 et Kai Chen3,4
[10] Simon-Gabriel et al., la vulnérabilité adversariale des réseaux neuronaux augmente avec la dimension des entrées, ArXiv 2018.
[11] Lyu et al., une famille unifiée de régularisation par gradient pour des exemples adversariaux, ICDM 2015
[12] Modèles sauvages : Dix ans après la montée de l'apprentissage automatique adversarial - NeCS 2019 Battista Biggioa, Fabio Roli
[13] Détection robuste face aux attaques adverses de programmes malveillants à l'aide de la classification monotone Inigo Incer et al.
[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto et Fabio Roli. Classificateurs utilisant le bagging pour lutter contre les attaques d’empoisonnement dans les tâches de classification adversaire
[15] Un rejet amélioré de la défense contre l'impact négatif Hongjiang Li et Patrick P.K. Chan
[16] Adler. Vulnérabilités dans les systèmes de chiffrement biométrique. 5e Conf. int’l AVBPA, 2005
Galbally, McCool, Fierrez, Marcel, Ortega-Garcia[17]. Sur la vulnérabilité des systèmes de vérification des visages aux attaques par montée progressive. Patt. Rec., 2010
[18] Weilin Xu, David Evans, Yanjun Qi. Compression des caractéristiques : détection des exemples adversariaux dans les réseaux neuronaux profonds. Symposium sur la sécurité du réseau et du système distribué en 2018. 18-21 février.
[19] Renforcement de la robustesse adversariale à l’aide de la confiance du modèle induite par l’entraînement adversarial - Xi Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen, Somesh Jha
[20] Analyse causale pilotée par l’attribution pour la détection d’exemples contradictoires, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami
[21] Régression linéaire robuste contre l’empoisonnement des données d’entraînement – Chang Liu et al.
[22] Réduction du Bruit de Caractéristiques pour Améliorer la Robustesse Adversariale, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He
[23] Défenses certifiées contre les exemples contradictoires - Aditi Raghunathan, Jacob Steinhardt, Percy Liang