Les équipes de ML renforcent leurs défenses contre l'empoisonnement des données

InfoQ a publié une analyse du 22 juin sur l'empoisonnement des modèles ML, en mettant l'accent sur les attaques par données d'entraînement, les limites de la détection et les contrôles des pipelines pour les équipes qui déploient des modèles en production.

Igor Maljkovic, chercheur-doctorant en sécurité de l'IA, présente l'empoisonnement comme un problème d'intégrité des données. Les attaques ajoutent ou modifient des échantillons d'entraînement pour qu'un modèle apprenne le mauvais comportement. Elles peuvent dégrader la précision générale, cibler une classe ou implanter un déclencheur qui modifie les prédictions au moment de l'inférence.

L'avertissement principal vise les équipes qui utilisent des ensembles de données publics, l'étiquetage collaboratif, des flux de contribution ouverts ou des magasins de données internes partagés. On peut construire une boucle d'entraînement propre et malgré tout s'entraîner sur des données hostiles si l'on manque de traçabilité, de contrôle d'accès et de portes de vérification.

Nouveau risque dans l'ensemble d'entraînement

Les attaques par empoisonnement ciblent les données qui façonnent le modèle. Un attaquant peut inverser les étiquettes, ajouter des valeurs aberrantes, fabriquer des échantillons de porte dérobée ou soumettre des exemples à étiquette correcte qui semblent valides à un examinateur.

L'inversion des étiquettes donne au modèle de mauvaises associations. Une image de chat reçoit une étiquette de chien, ou un échantillon de malware reçoit une étiquette bénigne. Les grands ensembles de données rendent la revue manuelle difficile, de sorte que de petits sous-ensemble empoisonnés peuvent survivre aux contrôles routiniers.

Les attaques par porte dérobée utilisent un déclencheur. Un attaquant ajoute des exemples d'entraînement contenant un petit motif, un filigrane, un sticker, un token ou un artefact, puis assigne la classe cible de l'attaquant. Le modèle apprend le déclencheur et conserve une précision normale sur les entrées propres. Au moment de l'inférence, l'attaquant ajoute le déclencheur et guide la prédiction.

L'empoisonnement à étiquette correcte augmente le niveau de difficulté pour les défenseurs. L'attaquant conserve la bonne étiquette mais altère les caractéristiques de sorte que l'exemple modifie la représentation interne du modèle. Un examinateur humain voit un échantillon valide. Le modèle voit un point d'entraînement qui pousse un exemple cible vers la mauvaise classe.

Les attaques par collision de caractéristiques utilisent ce schéma. L'attaquant fabrique un exemple de sorte que l'extracteur de caractéristiques d'un modèle le place près d'une cible dans l'espace de représentation. Pendant l'entraînement, le classifieur apprend une frontière qui classera ensuite incorrectement la cible.

L'empoisonnement par déni de service (DoS) cible la fiabilité plutôt qu'une seule prédiction. Un attaquant contribue un grand volume d'échantillons bruités, corrompus ou non informatifs. Le modèle s'entraîne plus lentement, converge vers de moins bons poids, ou échoue aux portes de qualité de base.

Impact sur les pipelines

Les équipes ML en production devraient traiter l'empoisonnement comme un problème de chaîne d'approvisionnement. Le modèle hérite du niveau de confiance de ses données d'entraînement.

Le chatbot Tay de Microsoft a donné au public un exemple clair en 2016. Les utilisateurs ont nourri le système avec des entrées hostiles, et le robot a produit des messages racistes et offensants. L'incident concernait l'apprentissage en ligne plutôt qu'un corpus d'entraînement statique, mais la leçon s'applique au MLOps : les systèmes qui apprennent à partir d'entrées non fiables nécessitent des limites, une révision et des chemins de restauration.

Les systèmes de recherche, anti-spam, de malware et médicaux ML font face à la même catégorie de risque. Un filtre anti-spam peut apprendre à accepter des messages malveillants si les attaquent soumettent assez d'exemples comme courrier légitime. Un classifieur de malware peut manquer des charges utiles si des attaquants empoisonnent la classe bénigne. Un modèle médical peut nuire aux patients si des initiés ou des flux de données compromis ajoutent des scans mal étiquetés.

Les dommages apparaissent souvent tardivement. Un modèle empoisonné peut passer des tests de précision agrégée et n'échouer que sur la cible de l'attaquant. Cette lacune rend l'empoisonnement de modèle plus difficile à détecter que des tâches d'ingestion brisées ou une dérive de schéma.

Plan de détection

Les équipes ont besoin de contrôles en couches. Une hygiène de base aide toujours : dédoublonner les enregistrements, valider les schémas, vérifier la distribution des étiquettes, scanner les valeurs aberrantes et comparer les nouvelles données à des bases de référence fiables.

Ces contrôles attrapent les attaques grossières. Des attaquants plus sophistiqués conçoivent des échantillons qui s'ajustent à la distribution d'entraînement, de sorte que les défenseurs ont besoin d'une révision sensible au modèle.

Le clustering par activation regroupe les échantillons d'entraînement par leurs activations internes issues d'un modèle entraîné. Si une classe contient un petit cluster avec des motifs d'activation inhabituels, l'équipe peut inspecter ces exemples pour des déclencheurs de porte dérobée.

L'analyse de signature spectrale recherche des directions inhabituelles dans l'espace des caractéristiques. Les échantillons empoisonnés créent souvent des artefacts géométriques que les contrôles d'étiquettes standard ne détectent pas.

L'analyse d'influence classe les exemples d'entraînement par leur effet sur des prédictions sélectionnées. Une équipe peut remonter une prédiction suspecte aux échantillons qui l'ont façonnée, puis inspecter la traçabilité, les étiquettes et les transformations.

La Boîte à outils pour la robustesse adversariale d'IBM donne aux équipes un banc d'essai pratique pour ces méthodes. ART supporte TensorFlow, Keras, PyTorch, scikit-learn, XGBoost, LightGBM, CatBoost et GPy. Ses défenses contre l'empoisonnement incluent le clustering par activation et les approches par signature spectrale.

Un flux de travail ART typique entraîne ou charge un classifieur, extrait les activations pour des données d'entraînement étiquetées, regroupe ces activations, puis signale les échantillons suspects pour révision. Les équipes peuvent exécuter cette vérification comme un audit hors ligne avant la promotion vers un registre de modèles.

Contrôles adaptés au MLOps

Les équipes de sécurité devraient commencer par l'accès. Utiliser un contrôle d'accès basé sur les rôles pour les magasins de données, les outils d'étiquetage, les magasins de caractéristiques et les tâches d'entraînement. Limiter l'accès en écriture aux ensembles de données d'entraînement. Exiger une révision pour les nouvelles sources et les grands changements d'étiquettes.

La traçabilité des données donne aux intervenants un chemin d'un modèle défaillant vers les enregistrements sources. Les équipes peuvent utiliser DVC ou lakeFS pour versionner les ensembles de données, enregistrer la lignée et reproduire les exécutions d'entraînement. Les sommes de contrôle et les signatures aident les équipes à détecter les altérations entre l'ingestion et l'entraînement.

Les portes de validation devraient s'exécuter avant que les données n'entrent dans l'ensemble d'entraînement. TensorFlow Data Validation peut vérifier les changements de schéma et de distribution. Great Expectations peut appliquer des règles de qualité des données à travers les pipelines par lots.

Les échantillons canaris et les ensembles de données dorées donnent aux équipes des sondes stables. Un échantillon canari a un résultat attendu et connu. Un ensemble de données doré contient des exemples fiables que les examinateurs contrôlent. Si un modèle réentraîné change de comportement sur ces sondes, l'équipe devrait arrêter la promotion et inspecter les récentes modifications de données.

Le code d'entraînement peut réduire l'influence des échantillons empoisonnés. Les équipes peuvent utiliser une régularisation plus forte, des fonctions de perte robustes, un rééchantillonnage pondéré ou des exemples d'entraînement adversarial. Ces mesures ne remplacent pas les contrôles de données, mais elles peuvent limiter le rayon de déflagration lorsque des échantillons hostiles passent à travers la révision.

La surveillance en production ferme la boucle. Suivre les métriques au niveau des classes, les changements de confiance, les motifs d'activation et les échecs par rapport aux ensembles de données dorés après le déploiement. Associer ces signaux à un support de restauration dans le registre de modèles et le magasin de caractéristiques.

Chemin de migration pour les équipes

Une petite équipe peut commencer par quatre changements.

Premièrement, enregistrer la lignée de l'ensemble de données pour chaque exécution d'entraînement. Stocker la source, l'horodatage, la version de la transformation, la source des étiquettes et l'identité de l'examinateur là où la politique le permet.

Deuxièmement, ajouter des contrôles de validation à l'ingestion. Faire échouer la tâche en cas de rupture de schéma, de pics de distribution d'étiquettes et de dérive de source qui dépasse votre seuil.

Troisièmement, exécuter un audit d'empoisonnement hors ligne sur les ensembles de candidats à l'entraînement. ART donne aux chercheurs et aux équipes plateforme un point de départ utile pour le clustering par activation et les vérifications spectrales.

Quatrièmement, conditionner la promotion du modèle à des sondes fiables. Exécuter chaque modèle candidat contre les ensembles de données dorés et les échantillons canaris avant la publication.

Les grandes équipes devraient ajouter une séparation des tâches. Les contributeurs de données, les réviseurs d'étiquettes, les entraîneurs de modèles et les propriétaires de publication ne devraient pas partager un large accès en écriture. Le personnel de sécurité devrait auditer les exceptions, les sources à fort impact et les événements d'entraînement d'urgence.

L'empoisonnement ML ne nécessite pas d'accès exotique. Les attaquants ont besoin d'un chemin vers les données d'entraînement ou la rétroaction d'apprentissage en ligne. Votre défense commence lorsque vous traitez les modifications de données avec la même discipline que celle appliquée aux modifications de code.