Apprentissage Machine Learning Partie 3 : Attaquer les modèles Black Box

Accueil » Cybersécurité » Analytics & Intelligence » Apprentissage Machine Learning Partie 3 : Attaquer les modèles Black Box

Dans le premier article de cette série, nous avons couvert un bref aperçu de l'apprentissage automatique, de l'approche Revoke-Obfuscation pour détecter les scripts PowerShell obscurcis et de mes efforts pour améliorer l'ensemble de données et les modèles de détection de PowerShell obscurcis. Nous nous sommes retrouvés avec trois modèles : une régression logistique régularisée L2 (Ridge), un classificateur LightGBM et une architecture de réseau de neurones.

Le deuxième article couvrait l'attaque de ces modèles à partir d'unboîte blanche perspective, c'est-à-dire où nous avons l'intégralité du modèle formé lui-même, y compris les caractéristiques d'entrée, l'architecture du modèle, les paramètres/poids du modèle et les données de formation. Je recommande fortement de parcourir au moins ces deux premiers messages avant de continuer pour vous assurer que tout cela a le plus de sens possible.

Dans cet article, nous allons couvrir les problèmes les plus courants et les plus difficiles,boîte noire perspective. Ici, nous ne savons que quelles fonctionnalités sont extraites de chaque échantillon - même l'architecture restera opaque pour nous.

Après avoir lu ce qui était certainement des centaines de pages de recherche universitaire sur l'apprentissage automatique contradictoire, je peux dire en toute sécurité qu'une bonne partie de la recherche a été menée dans une perspective de boîte blanche. Rappelez-vous notre définition des attaques de boîte blanche et de boîte noire du deuxième article de cette série :

En outre, la plupart des recherches semblent avoir porté sur la reconnaissance d'images. Bien que ce soit intéressant, c'est certainement un espace problématique différent de celui auquel nous avons affaire. Plus précisément, les images peuvent avoir plusieurs pixels perturbés par une petite quantité sans que l'image contradictoire résultante n'apparaisse modifiée à l'œil humain. Pour de nombreux problèmes de sécurité auxquels nous sommes confrontés, par exemple notre espace de problèmes d'obfuscation PowerShell, nous sommes plus limités dans a) le nombre de fonctionnalités que nous pouvons modifier et b) dans quelle mesure nous pouvons modifier lesdites fonctionnalités. Autrement dit, nous avons un sous-espace fonctionnel plus petit de modifications que nous pouvons apporter aux scripts PowerShell par opposition aux images.

Un certain nombre d'attaques par boîte noire impliquentextraction de modèle (voir la section suivante) pour créer un modèle local, parfois appelé modèle de substitution ou de substitution. Les attaques existantes sont ensuite exécutées contre le modèle local pour générer des échantillons contradictoires dans l'espoir que ces échantillons échappent également au modèle cible. Cela fonctionne souvent à cause du phénomène detransférabilité des attaques, dont nous parlerons bientôt.

Les attaques par boîte noire peuvent également ignorer l'extraction du modèle et interroger directement les entrées sur le modèle cible. Ces attaques, où la configuration interne du modèle n'est pas du tout nécessaire, sont ce que l'on appelle en fait des attaques de type boîte noire dans la littérature académique. Cependant, en utilisant l'extraction de modèle, nous pouvons potentiellement appliquer des attaques de boîte blanche contre des clones locaux de modèles de boîte noire où nous n'avons qu'un oracle pour soumettre des entrées et obtenir des étiquettes.

L'extraction de modèles, selon Will Pearce et d'autres, est l'une des primitives les plus fondamentales du ML contradictoire. Bien que cette idée ait probablement existé pendant un certain temps, je pense que les premières formalisations de l'extraction de modèles (ou du moins une qui a popularisé la méthode) ont été l'article de 2016 "Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples" et l'article de 2017 "Practical black box Attacks against Machine Learning", tous deux de Papernot et al. Le résumé général de leur approche à partir de l'article de 2017 est :

Notre stratégie d'attaque consiste à former un modèle local pour se substituer au DNN cible [Deep Neural Network], en utilisant des entrées générées synthétiquement par un adversaire et étiquetées par le DNN cible. Nous utilisons le substitut local pour élaborer des exemples contradictoires et constatons qu'ils sont mal classés par le DNN ciblé.

L'idée est d'approximer la limite de décision du modèle cible avec moins de données (et généralement différentes) que celles sur lesquelles le modèle a été formé à l'origine. Fondamentalement, l'extraction de modèle implique d'abord de soumettre un certain nombre d'échantillons étiquetés connus au modèle, qui fonctionne comme un oracle d'étiquetage. Imaginez que vous soumettiez un tas de fichiers binaires à une sorte de site Web qui vous permette de savoir si les fichiers binaires sont malveillants ou non. Ou imaginez avoir nos modèles Revoke-Obfuscation adaptés comme une sorte d'API interne, où nous pouvons soumettre nos mesures de fonctionnalités et obtenir un résultat d'étiquette normal ou obscurci, ou un score de probabilité d'obscurcissement. Avec suffisamment d'entrées, nous pouvons former un modèle de substitution local qui fonctionne de manière similaire au modèle cible.

Figure 1 de "Active Deep Learning Attacks under Strict Rate Limitations for Online API Calls" par Shi et al. résume bien le processus :

Une hypothèse raisonnable est que plus nous pouvons nous rapprocher de l'architecture du modèle d'origine, mieux notre modèle local fonctionnera. C'est quelque chose que nous allons explorer dans ce post.

Une approche légèrement différente consiste à former un modèle initialement médiocre avec peu d'échantillons et à utiliser certaines des techniques d'attaque en boîte blanche décrites dans le deuxième article pour générer des échantillons contradictoires. Ces échantillons sont exécutés via le classificateur, et comme décrit par ce post :

… les exemples contradictoires sont un pas dans la direction du gradient du modèle pour déterminer si le modèle de boîte noire classifiera les nouveaux points de données de la même manière que le modèle de substitution. Les données augmentées sont étiquetées par le modèle de boîte noire et utilisées pour former un meilleur modèle de substitution. Tout comme l'enfant, le modèle de substitution obtient une compréhension plus précise de la limite de décision du modèle de la boîte noire.

Résultat final dans tous les cas ? Nous avons un modèle entraîné localement qui se rapproche de la limite de décision du modèle cible. Avec cela, nous pouvons exécuter divers algorithmes d'attaque basés sur la boîte blanche qui exploitent les gradients de modèles internes, en plus de toutes les attaques de boîte noire également.

Sidenote : Entrées et architectures de modèles

Si les entrées du modèle que vous attaquez sont des images ou du texte, à certains égards, vous avez de la chance car vous pouvez probablement deviner l'architecture de base du modèle cible. Il existe des directives établies pour ces types d'entrées, c'est-à-dire les réseaux de neurones convolutifs pour les images et les LSTM/Transformers (ou Naive Bayes dans des cas spécifiques) pour le texte. Dans ces exemples, nous allons travailler avec des données tabulaires, c'est-à-dire des données affichées dans des colonnes ou des tableaux. Nous espérons revoir les modèles textuels attaquants une autre fois !

Vous vous demandez peut-être : « Vraiment ? Les attaques contre des modèles de merde clonés localement peuvent fonctionner contre de vrais modèles de production ? La réponse est OUI, en raison d'un phénomène appelé transférabilité des attaques. L'article de 2019 "Pourquoi les attaques contradictoires sont-elles transférées ? Explication de la transférabilité des attaques d'évasion et d'empoisonnement" par Demontis et al. explore cela d'un point de vue académique, mais je ferai de mon mieux pour expliquer le concept. De plus, étant donné que ce document n'a que quelques années et qu'il n'y a pas de consensus général sur la raison pour laquelle les attaques contradictoires sont transférées, rappelez-vous que c'est encore une question ouverte.

Le travail fondateur qui a introduit ce concept est l'article de 2016 mentionné précédemment "Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples" par Papernot, McDaniel et Goodfellow. Les premières phrases du résumé donnent un bon aperçu du concept (c'est moi qui souligne):

De nombreux modèles d'apprentissage automatique sont vulnérables aux exemples contradictoires : des entrées spécialement conçues pour amener un modèle d'apprentissage automatique à produire une sortie incorrecte.Les exemples contradictoires qui affectent un modèle affectent souvent un autre modèle, même si les deux modèles ont des architectures différentes ou ont été formés sur des ensembles de formation différents, tant que les deux modèles ont été formés pour effectuer la même tâche.Un attaquant peut donc former son propre modèle de substitut, créer des exemples contradictoires contre le substitut et les transférer vers un modèle de victime, avec très peu d'informations sur la victime.

Leur article vise à prouver deux hypothèses, à savoir que "les transférabilités d'échantillons contradictoires intra-techniques et inter-techniques sont des phénomènes constamment forts dans l'espace des techniques d'apprentissage automatique" et que "les attaques par boîte noire sont possibles dans des contextes pratiques contre tout classificateur d'apprentissage automatique inconnu. " Leur article présente un argument convaincant pour chacun et démontre également la transférabilité des différentes classes de modèles, résumée par la figure 3 à la page 5 de l'article :

Les valeurs dans chaque cellule sont le pourcentage d'échantillons (images MNIST ici, le cas de test de facto pour les attaques contradictoires) conçus pour échapper à une architecture de modèle particulière, qui, lorsqu'ils sont appliqués à une autre architecture de modèle, ont également changé leur étiquette de classification. C'est-à-dire le pourcentage d'échantillons contradictoires réussis fabriqués localement qui trompent également le modèle cible. Notez que ce chiffre n'inclut pas les ensembles Random Forests ou Boosted Decision Tree (la colonne Ens est un ensemble personnalisé des 5 techniques existantes). Le type de modèle de substitution se trouve sur le côté gauche et le type de modèle ciblé se trouve en bas. Nous pouvons voir quelques modèles :

À partir de là, ma théorie est que si vous pouvez largement correspondre à l'architecture du modèle cible, vous avez de meilleures chances que vos attaques contre le substitut soient transférées.

Comment cela résistera-t-il à nos exemples d'ensembles de données ?

Notre objectif ici est de recréer un modèle de substitution local en n'ayant accès au modèle qu'en tant qu'oracle d'étiquetage (c'est-à-dire les modèles cibles formés à partir du premier message). Ensuite, nous exécuterons les attaques de la boîte blanche du deuxième poteau contre notre remplaçant, en espérant une transférabilité d'attaque suffisante. Bien que cela soit très similaire aux processus des deux premiers articles, nous avons quelques étapes supplémentaires.

Tout d'abord, nous avons besoin d'un nouveau jeu de données à utiliser pour l'extraction du modèle. J'ai sélectionné 1500 fichiers aléatoires dans PowerShellCorpus et j'ai parcouru chacun un ensemble aléatoire d'obfuscations d'Invoke-Obfuscation, ce qui m'a donné 3000 échantillons au total. J'ai ensuite exécuté le code d'extraction de fonctionnalités sur chaque script et généré le fichier BlackBox.ast.csv qui est maintenant mis à jour dans ./datasets/ dans le référentiel Invoke-Evasion.

La prochaine étape estextraction de modèle , où nous formons un modèle local de substitution sur l'ensemble de données étiqueté par le modèle cible. Pour ce faire, j'ai utilisé chaque modèle cible pour générer un ensemble respectif d'étiquettes pour le nouvel ensemble de données. Bien que ces étiquettes ne soient pas la vérité exacte, car aucun de nos modèles n'était parfait, les étiquettes reflètent la limite de décision du modèle cible lui-même. J'ai divisé l'ensemble de données en un train/test standard avec un ratio de 80/20, comme nous l'avons fait dans le premier article.

Dans la section précédente, j'ai mentionné que plus vous adaptez votre modèle local à l'architecture du modèle cible, plus il est probable que votre attaque conçue trompera la cible. Je voulais voir quelles étapes de "reconnaissance du modèle" pourraient aider à éclairer l'architecture du modèle cible. La grande question dans mon esprit est de déterminer si la cible est linéaire, arborescente, un réseau de neurones ou une troisième option. Les algorithmes basés sur des arbres fonctionnent souvent extrêmement bien avec à peu près n'importe quel ensemble de données, donc mon hypothèse est que les forêts aléatoires et les arbres boostés par gradient correspondront bien à chaque ensemble de données de modèle cible. Pour cette raison, nous voulons idéalement déterminer si le modèle est probablement un réseau de neurones ou linéaire d'abord, avec un arbre basé sur le résultat du processus d'élimination.

C'est définitivement une question ouverte et quelque chose, je ne pense pas, a été fortement pris en compte dans le milieu universitaire. Cependant, je tiens à répéter que je ne suis pas un expert ici - s'il existe des travaux dans ce domaine (ou si quelqu'un a des idées supplémentaires), veuillez me le faire savoir !

Mes deux idées principales que je détaillerai sous peu sont :

J'ai commencé par ajuster les modèles suivants sur chaque ensemble de données cible, en effectuant une recherche aléatoire de base à validation croisée (à l'aide de RandomizedSearchCV) pour les hyperparamètres communs pour les algorithmes superficiels (c'est-à-dire tout sauf le réseau de neurones) :

J'ai ensuite utilisé HopSkipJump pour générer des échantillons contradictoires pour chaque modèle. Pour une raison quelconque, je n'ai pas réussi à faire en sorte que le réseau de neurones génère correctement suffisamment d'échantillons à l'aide de HopSkipJump, j'ai donc utilisé l'attaque Fast Gradient Method (FGM) à la place. Pourquoi choisir ces architectures spécifiques comme modèles locaux ? Je voulais sélectionner une gamme de choses réellement utilisées dans la production et je voulais une couverture linéaire (régression logistique), des ensembles d'arbres (forêts aléatoires/arbres boostés) et des réseaux de neurones.

Ces échantillons contradictoires ont été exécutés sur chaque modèle local et le modèle cible pour obtenir des précisions comparables. Cependant, plus important encore, j'ai extrait les échantillons spécifiques mal classés par chaque modèle local. Ces échantillons ont été exécutés par rapport au modèle cible, donnant le pourcentage d'échantillons contradictoires conçus contre le modèle local qui ont également trompé le modèle cible. C'est letransférabilité idée dont nous avons parlé plus tôt. Bien que l'efficacité générale de l'ensemble des échantillons contradictoires locaux par rapport à la cible soit un point de données intéressant, ce qui nous importe vraiment, c'est l'efficacité du modèle de substitution local pour créer des échantillons contradictoires qui trompent le modèle cible.

Ensuite, j'ai pris le modèle de régression logistique le plus performant, qui est linéaire, et j'ai fortement modifié un seul coefficient pour un échantillon pour voir si cela affectait la sortie du modèle. Le but ici était de voir si le modèle était potentiellement linéaire pour un autre point de référence.

Voici le résultat de notre processus de recherche d'évasion-transférabilité par rapport au premier modèle :

Ces résultats sont intéressants. Le modèle qui correspondait le plus aux données étiquetées du modèle cible était la forêt aléatoire, le substitut de régression logistique (qui correspondait le plus à l'architecture du modèle cible) avait le plus grand nombre d'échantillons contradictoires transférés vers le modèle cible, mais XGBoost avait le pourcentage le plus élevé d'échantillons contradictoires transférés vers la cible de régression logistique.

Voici le résultat de notre processus de recherche d'évasion-transférabilité par rapport au deuxième modèle :

Ces résultats sont également intéressants. Les modèles qui correspondaient le plus aux données étiquetées du modèle cible étaient la forêt aléatoire et XGBoost, tandis que le réseau de neurones avait à la fois le plus grand nombre d'attaques adverses transférées ainsi que le meilleur pourcentage de transférabilité des attaques vers la cible LightGBM. Comparé aux deux autres modèles cibles, le modèle 2 semble également être le plus résistant aux échantillons contradictoires.

Voici le résultat de notre processus de recherche d'évasion-transférabilité par rapport au premier modèle :

Ces résultats sont tout aussi intéressants que les deux précédents. La plupart des modèles avaient une précision extrêmement proche sur les données étiquetées du modèle cible, tandis que la régression logistique et XGBoost avaient le plus grand nombre d'échantillons contradictoires transférés vers le réseau de neurones cible. Le réseau de neurones avait le meilleur pourcentage de transférabilité des attaques, mais le deuxième pire nombre d'attaques transférées.

Sur la base des résultats, ma stratégie pour déterminer l'architecture du modèle en mesurant la transférabilité de l'attaque du modèle de substitution ne semble pas très bien fonctionner dans ce cas. En guise de confirmation, pour chaque modèle, j'ai pris le substitut le plus prometteur pour chaque cible et effectué les mêmes attaques que nous avons faites contre les modèles de boîte blanche dans le deuxième message. Cela n'a pas été aussi efficace, et j'ai fini avec une grande quantité de modifications pour chaque script. Plus précisément, les scripts modifiés obtiendraient une très faible probabilité d'obscurcissement par rapport au substitut local, mais seraient toujours classés comme obscurcis par la cible.

Je me suis creusé la tête pour trouver une explication à cela, et Will a pu m'aider à faire la lumière sur plusieurs choses. Cela a entraîné deux changements majeurs dans mon approche : des étiquettes souples et un renversement de ma perspective de l'ensemble du problème.

Will détaille l'effet des étiquettes dures et souples sur l'extraction du modèle sur la diapositive 21 de sa présentation BlackHat EU 2021 :

Intuitivement, cela a du sens. Une étiquette dure comme normal ou obfuscated fournit moins d'informations qu'un ensemble de probabilités comme obfuscated=0.73. Plus nous avons d'informations, mieux nous pouvons faire correspondre les éléments internes du modèle - il y a beaucoup d'espace entre les étiquettes binaires dures comme 0 et 1 !

Considérons la situation où nos API magiques Invoke-Obfuscation donnent une probabilité d'obfuscation comme 0,73 au lieu d'une simple étiquette binaire 0/1. Comment pouvons-nous profiter de ces informations supplémentaires ? Souvenez-vous du premier article où nous parlions de classification versus régression : la classification nous donne des étiquettes, tandis que la régression nous donne un nombre !

Voyons ce qui se passe si nous étiquetons notre jeu de données contradictoire avec la probabilité que le script soit obscurci, au lieu de simplement l'étiquette dure normale/obscurcie. Nous garderons un seuil de 0,5 ou plus pour signifier que l'échantillon est obscurci, mais cela peut être ajusté (et c'est souvent pour changer l'équilibre des faux positifs et des faux négatifs).

Puisque nous faisons de la régression au lieu de la classification, nous avons besoin d'un ensemble d'algorithmes légèrement différent. Les réseaux de neurones, les forêts aléatoires, les arbres boostés par gradient et les machines à vecteurs de support ont tous des équivalents de régression. Cependant, au lieu de la régression logistique (nom déroutant pour un classificateur ici, je sais), nous allons utiliser la régression linéaire classique, la régression Lasso (L1), la régression Ridge (L2) et la régression BayesianRidge au lieu de Bayesian Naive Bayes. Ensuite, pour chacun, nous vérifierons l'erreur quadratique moyenne moyenne (RMSE) sur l'ensemble de test, une métrique de régression commune qui élève au carré la différence entre chaque prédiction et sa valeur réelle, additionne tous les carrés et prend la racine carrée du total :

Nous prendrons également chaque modèle de régression, ferons une prédiction pour chaque échantillon et les transformerons à nouveau en étiquettes dures en voyant celles qui sont égales à 0,5 ou plus. Cela nous permettra d'obtenir une mesure de précision. Tout cela est une sorte d'approche de type classificateur-approximation-régresseurs. Les détails sont dans leBlackBox.ipynbnotebook dans le référentiel Invoke-Evasion.

Un problème que j'ai rencontré est que puisque nous construisons des modèles de régression au lieu de modèles de classification, nous ne pouvons pas les utiliser tels quels avec HopSkipJump ou d'autres algorithmes d'attaque. J'ai fait quelques tentatives pour lancer un modèle de classification personnalisé qui enveloppait le mode scikit-learn de régression, mais ART ne fonctionnait toujours pas correctement avec eux. Je suis sûr qu'il existe un moyen de le faire, mais il reste un problème majeur que nous n'avons pas encore pris en compte…

Un grand défi que j'ai rencontré en essayant de comprendre la situation d'apprentissage automatique contradictoire ici est de savoir comment transformer l'ensemble de données numériques contradictoires modifié en un script de travail. Comme je l'ai mentionné au cours de cette série d'articles, la plupart des recherches universitaires sur l'apprentissage automatique contradictoire ont porté sur les données d'image. La perturbation des caractéristiques contradictoires pour les images est assez facile, ou plutôt sans contrainte - nous modifions simplement les bits pour les pixels, puis soumettons l'image à notre classificateur cible. Presque tous les algorithmes d'évasion d'apprentissage automatique contradictoires sont utilisés de cette façon. Vous fournissez un tableau d'échantillons de données et un algorithme d'attaque et des échantillons perturbés / contradictoires sont produits, c'est-à-dire des tableaux de nombres qui trompent le modèle cible lors du traitement.

Nous avons exploré la possibilité de masquer divers algorithmes d'attaque dans le deuxième article sur l'attaque des modèles de boîte blanche. Même si nous avons limité les modifications à un sous-ensemble plus petit de fonctionnalités plus facilement modifiables, ce n'est toujours pas idéal. Si nous avons un tableau de fonctionnalités modifiées à partir d'un échantillon d'origine, comment pouvons-nous a) le transformer en un script qui b) s'exécute du tout et c) exécute toujours la fonctionnalité prévue du script ?

Comme nous en avons parlé dans le deuxième post, quel est le ??? processus dans la figure suivante :

J'avais du mal à comprendre cela jusqu'à ce que je lise une partie de la source de la branche mlsecevasion de Counterfit et que j'aie eu une autre conversation avec Will qui a complètement changé ma perspective. Il a relayé une idée clé de Hyrum Anderson :tout cela n'est vraiment qu'un problème d'optimisation !

Les algorithmes d'attaque de boîte noire ML optimisent les caractéristiques d'entrée mesurées pour le problème d'adversaire max-min dont nous avons parlé dans le deuxième article, où nous voulons maximiser la fonction d'erreur/perte du modèle pour un échantillon mais minimiser le nombre de changements pour le faire. Au lieu d'optimiser directement la modification des éléments vectorisés, pourquoi ne pas optimiser un certain nombre d'actions séquentielles qui affectent ces éléments ?

Fondamentalement, nous voulons d'abord énumérer un certain nombre d'actions de modification que nous pouvons exécuter sur un échantillon spécifique qui modifient les fonctionnalités extraites pour ledit échantillon. Par exemple, Counterfit a un ensemble d'ajouts/superpositions de section PE, d'importations à ajouter et d'horodatages à essayer pour les PE. Pour notre situation, nous voudrions quelque chose qui ajoute des fonctionnalités "normales", et nous pouvons utiliser les approches d'explicabilité du deuxième article pour guider ce processus. Ensuite, nous pouvons utiliser un algorithme comme HopSkipJump pour trouver une combinaison de ces fonctionnalités qui produit le résultat souhaité.

Notre approche ressemblera plutôt à ceci :

Dans le cas de Counterfit, ils prennent un vecteur qui représente les modifications à effectuer et l'alimentent en quelque chose comme HopSkipJump. Pour certains travaux futurs, j'espère construire un module Counterfit pour cette obfuscation PowerShell, mais nous garderons les choses un peu plus manuelles pour l'instant.

Il existe une autre alternative à l'utilisation d'algorithmes d'attaque, l'optimisation bayésienne, "une stratégie de conception séquentielle pour l'optimisation globale des fonctions de boîte noire". Rappelez-vous dans le premier article lorsque nous avons brièvement parlé d'Optuna, un cadre conçu pour régler les hyperparamètres pour les algorithmes d'apprentissage automatique. Optuna implémente diverses méthodes d'optimisation bayésienne et est extrêmement flexible, avec une approche générale de :

L'autre idée clé ici est quenous n'avons pas besoin d'utiliser Optuna uniquement pour le réglage des hyperparamètres ! La fonction objectif représente une boîte noire, et nous pouvons l'utiliser pour exécuter un certain nombre d'actions de modification à effectuer sur notre script cible et renvoyer le score de probabilité d'obscurcissement de notre modèle cible. C'est une approche que Counterfit a également mise en œuvre, en utilisant le framework Hyperopt au lieu d'Optuna.

Si cela ressemble à un apprentissage par renforcement, vous n'êtes pas complètement à côté de la plaque. N'étant pas aussi alphabétisé dans les mathématiques pertinentes que je le voudrais, je dirai que je crois que cette approche est similaire à l'apprentissage par renforcement en principe mais différente dans la pratique. Mon sentiment instinctif est que cette approche fonctionnera probablement pour de plus petits ensembles de changements atomiques qui ne dépendent pas autant de l'ordre - un plus grand nombre d'actions séquentielles très dépendantes du contexte fonctionnera probablement mieux avec une approche d'apprentissage par renforcement appropriée. Cependant, comme nous avons une courte boucle de rétroaction consistant à sélectionner des transformations-obscurcir le script-mesurer l'obscurcissement, nous n'avons probablement pas besoin de la surcharge supplémentaire d'une approche complète d'apprentissage par renforcement.

Nous allons tout rassembler ici, en combinant l'approche classificateur-approximation-régresseurs avec l'optimisation bayésienne des modifications de script.

Notre objectif global : prenez le script d'entrée DBOdemo1.ps1 obfusqué et renvoyez un script modifié qui préserve la fonctionnalité du script d'origine tout en étant signalé comme normal par notre modèle de réseau de neurones réglé. Nous souhaitons également ajouter le moins de caractères possible au script.

Notre approche complète du début à la fin sera :

L'idée principale ici est que nous extrayons le modèle cible aussi efficacement que possible et utilisons les informations de la boîte blanche de ce modèle de substitution local pour guider la construction de fonctions qui modifient le script cible obscurci. Ensuite, nous optimisons l'utilisation de ces fonctions de modification par rapport au modèle de boîte noire cible. Cette approche nous permet de minimiser le temps et le nombre de requêtes sur l'API de la boîte noire.

Voici les résultats de notre étude d'optimisation qui a duré 30 minutes :

Et le script optimisé final ressemble à ceci :

En 30 minutes, nous nous sommes retrouvés avec un script optimisé qui n'a augmenté la taille du script d'origine que de 23,06 %, mais qui avait un score d'obscurcissement du modèle cible de 35,24, bien en dessous du seuil de 50 pour Normal.

La dernière question qui me vient à l'esprit est "Cet échantillon contradictoire est-il transféré aux deux autres modèles cibles ?" Voyons:

Cet échantillon optimisé a réussi contre le modèle cible 3, le réseau de neurones, ainsi que le modèle 1, la régression logistique. Cependant, il n'a pas été transféré à l'ensemble arborescent boosté par LightGBM (modèle 2). C'est probablement parce que nous :

Éviter les modèles linéaires, comme la régression logistique, est facile. Éviter les ensembles d'arbres, comme les forêts aléatoires ou les arbres de décision boostés par gradient, ou les réseaux de neurones, est un peu plus difficile. Éviter les versions boîte noire de ces modèles est encore plus difficile, ou du moins prend plus de temps et d'efforts.

La plupart des attaques dans la littérature impliquent de générer plusieurs échantillons contradictoires et de tester leur efficacité contre un modèle cible, comme nous l'avons fait pour nos trois modèles cibles. Il n'y a pas autant de travail que je connaisse (j'ai promis d'avoir essayé de regarder !) qui implique des données tabulaires pratiques d'attaques de boîtes noires dans le monde réel comme des exemples ici. Selon l'architecture du modèle cible et si le modèle est une boîte blanche ou une boîte noire, l'évasion pour un seul échantillon peut avoir différents niveaux de difficulté.

Le domaine de l'apprentissage automatique contradictoire a moins de dix ans, les premières attaques formalisées ayant été lancées vers 2014. La plupart des travaux jusqu'à présent ont été académiques et se sont fortement concentrés sur les attaques en boîte blanche contre les classificateurs d'images. Bien que des cadres pratiques tels que la boîte à outils Adversarial Robustness existent, la plupart des algorithmes d'attaque ont des restrictions qui les rendent non applicables ou non souhaitables pour nos scénarios d'attaque de sécurité. Plus précisément, tous les algorithmes d'attaque ne peuvent pas être utilisés sur des données tabulaires/non-images, et la plupart ne vous permettent pas de limiter les fonctionnalités modifiées (appelées masquage de fonctionnalités).

Du côté de l'algorithme d'attaque contradictoire, la grande idée que Will m'a transmise est quetout ceci n'est qu'un problème d'optimisation ! La sécurité de l'information, comme de nombreuses industries, ignore souvent les avancées d'autres domaines qui pourraient énormément nous aider. Mon exemple personnel de cela était quand Andy et moi travaillions sur le problème/outil qui est finalement devenu l'approche graphique originale de BloodHound - nous avons continué à trébucher autour du problème jusqu'à ce qu'Andy discute de nos défis avec son ami Sam, qui s'est lamenté : "Mec, comment n'avez-vous pas entendu parler de la théorie des graphes ?"

Le problème de "comment prendre ces nombres contradictoires et les transformer en une attaque utilisable" est un véritable problème dans l'exécution pratique de ces attaques. Cependant, si nous changeons notre façon de penser au problème, nous pouvons utiliser des approches influencées par le cadre Counterfit, ou le cadre lui-même, pour optimiser les actions contradictoires.

J'espère que la communauté universitaire d'apprentissage automatique contradictoire continue de faire plus de progrès sur la recherche contradictoire pratique au-delà des attaques contradictoires en boîte blanche sur les classificateurs d'images (comme celui-ci !). Les problèmes du monde réel sont plus difficiles que de jouer uniquement avec MNIST, et il y a beaucoup de chances d'une grande collaboration avec des professionnels de l'industrie de la sécurité pour aborder certains de ces scénarios pratiques. Il existe une tonne de modèles d'arbres boostés par gradient non centrés sur l'image déployés dans le monde réel sous forme de boîtes noires : comment pouvons-nous les attaquer efficacement tout en minimisant notre nombre de requêtes ?

N'oubliez pas non plus que pour avoir à peu près l'espoir d'une attaque adverse contre un modèle de boîte noire, vous devez connaître les fonctionnalités d'entrée ! Avec les images, c'est évident, mais pour les systèmes du monde réel, cela peut devenir plus compliqué et peut nécessiter une ingénierie inverse pour comprendre les mécanismes d'extraction de caractéristiques.

Et enfin, rappelez-vous que les modèles ML sont une "solution vivante" - comme l'a déclaré Lee Holmes, "La seule chose à garder à l'esprit avec les modèles ou signatures ML est qu'ils ne sont jamais" terminés ". Si vous ne vous recyclez pas sur la base de faux positifs et de faux négatifs, vous avez perdu. " Par souci de brièveté, j'ai ignoré de nombreuses préoccupations du monde réel concernant le déploiement et la maintenance des modèles. Le sous-domaine émergent des MLOps traite un grand nombre de ces problèmes, et je prévois de revoir l'aspect pratique de la mise en œuvre des modèles dont nous avons discuté tout au long de cette série à mesure que j'en apprendrai davantage sur cette discipline émergente.

Mais qu'en est-il des défenses ??!!?

Oui, je sais, je sais, s'il vous plaît, ne me dites pas que je suis un membre irresponsable de l'équipe rouge. Je vais rédiger un article de suivi qui reflète certaines des défenses autour de cet espace problématique, mais j'essaie toujours de prendre pied pour des choses comme la distillation et l'entraînement contradictoire. Mais je vais vous laisser avec un aperçu que le parrain du ML contradictoire Ian Goodfellow a déclaré il y a environ quatre ans :

Il est également important de souligner que toutes les défenses jusqu'à présent sont basées sur des modèles de menace irréalistes où l'attaquant est très limité... en tant que problème de recherche, il a été très difficile de résoudre même la version limitée et cela reste un domaine de recherche très actif avec beaucoup de défis importants à résoudre.

Pour les travaux futurs dans ce domaine spécifique, voici quelques objectifs généraux que j'espère poursuivre :

Maintenant que nous sommes à la fin de cette mine d'informations réparties sur trois articles, j'espère que vous avez apprécié la lecture de ce matériel autant que j'ai aimé le rechercher et l'écrire. Ce fut un voyage long mais enrichissant pour moi, et si cela a suscité votre intérêt pour ce domaine, je vous dis de vous lancer ! Vous pouvez nous rejoindre sur le DEF CON AI Village Discord, la chaîne #DeepThought sur le BloodHound Slack, ou n'hésitez pas à m'envoyer un e-mail à volonté [at] harmj0y.net.

Learning Machine Learning Part 3: Attacking Black Box Models a été initialement publié dans Posts By SpecterOps Team Members on Medium, où les gens poursuivent la conversation en mettant en évidence et en répondant à cette histoire.

*** Il s'agit d'un blog syndiqué du réseau des blogueurs de sécurité de Posts By SpecterOps Team Members - Medium rédigé par Will Schroeder. Lisez le message original sur : https://posts.specterops.io/learning-machine-learning-part-3-attacking-black-box-models-3efffc256909?source=rss----f05f8696e3cc---4