Bedreigingsmodellering in AI/ML-systemen en afhankelijkheden

Door Andrew Marshall, Jugal Parikh, Emre Kiciman en Ram Shankar Siva Kumar

Met speciale dank aan Raul Rojas en de AETHER Security Engineering Workstream

November 2019

Dit document is een product van de AETHER Engineering Practices for AI Working Group en vormt een aanvulling op bestaande procedures voor SDL-bedreigingsmodellering door nieuwe richtlijnen te bieden voor de inventarisatie en risicobeperking van bedreigingen specifiek gericht op de domeinen van AI en Machine Learning. Het is bedoeld om te worden gebruikt als naslag tijdens evaluatie van het beveiligingsontwerp van het volgende:

1. Producten en services die interactie hebben met of afhankelijk zijn van op AI/ML gebaseerde services

2. Producten en services die worden gebouwd met AI/ML als de kern

De traditionele methode van risicobeperking van beveiligingsbedreigingen is belangrijker dan ooit. De vereisten die zijn vastgelegd in de Security Development Lifecycle zijn essentieel voor het samenstellen van een fundament voor productbeveiliging waarop deze richtlijnen zijn gebaseerd. Als wordt nagelaten om maatregelen te nemen tegen traditionele beveiligingsproblemen, vergroot dit de kans dat u te maken krijgt met de in dit document beschreven AI/ML-specifieke aanvallen. Dit geldt voor zowel software als het fysieke domein, waarbij compromissen lager in de software-stack triviaal van aard worden. Zie De toekomst van Artificial Intelligence en Machine Learning bij Microsoft beveiligen voor een inleiding van 'net-new' beveiligingsdreigingen in dit domein.

De skillsets van beveiligingsengineers en gegevenswetenschappers overlappen elkaar doorgaans niet. Deze richtlijnen bieden een manier voor beide disciplines om gestructureerde gesprekken te hebben over deze net-new bedreigingen/oplossingen zonder dat beveiligingsengineers gegevenswetenschappers moeten worden of omgekeerd.

Dit document is onderverdeeld in twee secties:

1. De sectie 'Belangrijke nieuwe aandachtspunten bij bedreigingsmodellering' is gericht op nieuwe manieren van denken en nieuwe vragen om te stellen bij het toepassen van bedreigingsmodellering op AI/ML-systemen. Zowel gegevenswetenschappers als beveiligingsengineers moeten deze sectie doornemen omdat die zal functioneren als hun playbook voor discussies over bedreigingsmodellering en het prioriteren van risicobeperking.
2. De sectie 'AI/ML-specifieke bedreigingen en hun oplossingen' biedt details over specifieke aanvallen, evenals specifieke stappen voor risicobeperking die op dit moment worden gebruikt om producten en services van Microsoft te beschermen tegen deze bedreigingen. Deze sectie is voornamelijk gericht op gegevenswetenschappers die mogelijk specifieke bedreigingsoplossingen moeten implementeren die het resultaat zijn van het proces van bedreigingsmodellering/beveiligingsevaluatie.

Deze richtlijnen zijn georganiseerd rond een Adversarial Machine Learning Threat Taxonomy gemaakt door Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen en Jeffrey Snover getiteld "Failure Modes in Machine Learning." Raadpleeg de SDL-bugbalk voor AI/ML-bedreigingen voor richtlijnen voor incidentbeheer voor het trireren van beveiligingsrisico's die in dit document worden beschreven. Dit zijn allemaal levende documenten die zich in de loop van de tijd zullen ontwikkelen met het bedreigingslandschap.

Belangrijke nieuwe overwegingen bij threat modeling: de manier wijzigen waarop u vertrouwensgrenzen bekijkt

Ga ervan uit dat corruptie/verontreiniging geldt voor zowel de gegevens die u traint als de gegevens die afkomstig zijn van de gegevensprovider. Leer afwijkende en schadelijke gegevensvermeldingen te herkennen, en om er onderscheid tussen te maken en ze te herstellen

Samenvatting

De archieven met trainingsgegevens en de systemen die als host fungeren voor deze archieven, vallen onder het bereik van uw bedreigingsmodel. De grootste beveiligingsbedreiging in machine learning op dit moment is gegevensverontreiniging vanwege het gebrek aan standaarddetecties en -risicobeperking in dit domein, in combinatie met de afhankelijkheid van niet-vertrouwde/niet-gecureerde openbare gegevenssets als bronnen van trainingsgegevens. Het bijhouden van de oorsprong en herkomst van uw gegevens is essentieel om de betrouwbaarheid van de gegevens te garanderen en een 'garbage in, garbage out'-trainingscyclus te voorkomen.

Vragen om te stellen tijdens een beveiligingsevaluatie

• Als uw gegevens zijn verontreinigd of gemanipuleerd, hoe zou u dat kunnen zien?

  -Welke telemetriegegevens zijn nodig om vast te stellen dat er sprake is van scheefheid in de kwaliteit van uw trainingsgegevens?

• Traint u op basis van door de gebruiker geleverde invoer?

  -Wat voor invoervalidatie/-opschoning past u toe op die inhoud?

  -Is de gedocumenteerde structuur van deze gegevens vergelijkbaar met Gegevensbladen voor gegevenssets?

• Als u traint met behulp van online gegevensarchieven, welke stappen neemt u dan om de beveiliging van de verbinding tussen uw model en de gegevens te waarborgen?

  -Hebben de archieven zij een manier om inbreuken te melden aan consumenten van hun feeds?

  -Zijn ze daar überhaupt wel voor geschikt?

• Hoe gevoelig zijn de gegevens die u gebruikt om te trainen?

  -Neemt u ze op in een catalogus of beheert u het toevoegen/bijwerken/verwijderen van gegevensvermeldingen?

• Kan uw model gevoelige gegevens uitvoeren?

  -Zijn deze gegevens verkregen met toestemming van de bron?

• Produceert het model alleen resultaten die nodig zijn om het doel te bereiken?

• Retourneert uw model onbewerkte betrouwbaarheidsscores of andere directe uitvoer die kan worden vastgelegd en gedupliceerd?

• Wat is de impact van het herstellen van uw trainingsgegevens door uw model aan te vallen/om te keren?

• Als de betrouwbaarheidsniveaus van de modeluitvoer plotseling afnemen, kunt u dan nagaan hoe dit komt en waarom en welke gegevens de scoredaling veroorzaken?

• Hebt u een goed gevormde invoer gedefinieerd voor uw model? Wat doet u om ervoor te zorgen dat de invoer overeenkomt met deze indeling en wat kunt u doen als dat niet het geval is?

• Als de uitvoer onjuist is, maar hierdoor geen fouten worden gerapporteerd, hoe komt u hier dan achter?

• Weet u of uw trainingsalgoritmes op wiskundig niveau overweg kunnen met adversarial invoer?

• Hoe herstelt u van adversarial verontreiniging van uw trainingsgegevens?

  -Kunt u adversarial inhoud isoleren/in quarantaine plaatsen en de betrokken modellen opnieuw trainen?

  -Kunt u voor hernieuwde training terugdraaien/herstellen naar een model van een eerdere versie?

• Gebruikt u bekrachtigend leren met niet-gecureerde openbare inhoud?

• Als we kijken naar de herkomst van uw gegevens, kunt u dan bij een probleem herleiden wanneer de gegevens zijn toegevoegd aan de gegevensset? Als dat niet mogelijk is, is dat een probleem?

• Weet waar uw trainingsgegevens vandaan komen en identificeer statistische normen om te leren hoe afwijkingen eruitzien

  -Welke elementen van uw trainingsgegevens zijn kwetsbaar voor invloed van buitenaf?

  -Wie kan een bijdrage leveren aan de gegevenssets waarmee u traint?

  -Hoe zou u uw bronnen van trainingsgegevens aanvallen om een concurrent schade te berokkenen?

Gerelateerde bedreigingen en oplossingen in dit document

• Adversarial verstoring (alle varianten)

• Verontreiniging van gegevens (alle varianten)

Voorbeelden van aanvallen

• Afdwingen dat goedaardige e-mails worden geclassificeerd als spam of ervoor zorgen dat een schadelijk voorbeeld onopgemerkt blijft

• Door aanvaller samengestelde invoer die het betrouwbaarheidsniveau van juiste classificatie verlaagt, met name in cruciale scenario's

• Een aanvaller injecteert willekeurige ruis in de brongegevens die worden geclassificeerd om de kans te verkleinen dat in de toekomst de juiste classificatie wordt gebruikt, waardoor het model minder slim wordt gemaakt

• Verontreiniging van trainingsgegevens om onjuiste classificatie van geselecteerde gegevenspunten af te dwingen, wat tot gevolg heeft dat specifieke acties worden uitgevoerd of worden nagelaten door een systeem

Bepalen welke acties een model of product/service kan nemen waardoor de klant online of in het fysieke domein beschadigd kan raken

Samenvatting

Als er niets wordt gedaan tegen aanvallen op AI/ML-systemen, kunnen deze hun weg vinden naar de fysieke wereld. Elk scenario dat kan worden aangepast om uw gebruikers psychisch of fysiek te beschadigen, is een onherstelbaar risico voor uw product/service. Dit geldt ook voor gevoelige gegevens van uw klanten die worden gebruikt voor training en voor ontwerpkeuzen die weglekken van deze persoonlijke gegevens tot gevolg kunnen hebben.

Vragen om te stellen tijdens een beveiligingsevaluatie

• Traint u met adversarial voorbeelden? Welke impact hebben die op de uitvoer van het model in het fysieke domein?

• Hoe ziet 'trolling' eruit voor uw product/service? Hoe kunt u trolling detecteren en erop reageren?

• Wat zou er nodig zijn om uw model een resultaat te laten retourneren dat uw service ertoe verleidt om legitieme gebruikers geen toegang te geven?

• Wat is de impact als u model wordt gekopieerd/gestolen?

• Kan uw model worden gebruikt om het lidmaatschap van een bepaalde persoon van een bepaalde groep af te leiden, of eenvoudigweg in de trainingsgegevens?

• Kan een aanvaller reputatieschade of PR-schade veroorzaken voor uw product door dit geforceerd bepaalde acties te laten uitvoeren?

• Hoe gaat u om met correct opgemaakte maar overduidelijk bevooroordeelde gegevens, zoals van trollen?

• Voor elke manier waarop interactie mogelijk is met uw model of waarop het model kan worden weergegeven, kan die methode worden bevraagd om trainingsgegevens of modelfunctionaliteit vrij te geven?

Gerelateerde bedreigingen en oplossingen in dit document

• Afleiden van lidmaatschap

• Modelinversie

• Stelen van model

Voorbeelden van aanvallen

• Reconstructie en extractie van trainingsgegevens door herhaaldelijk bevragen van het model voor maximale vertrouwensresultaten

• Duplicatie van het model zelf door uitgebreide matching van query's/responsen

• Bevragen van het model op een manier dat er een specifiek element van persoonlijke gegevens uit de trainingsset wordt vrijgegeven

• Zelfrijdende auto die ertoe wordt verleid stopborden/verkeerslichten te negeren

• Gespreksbots die worden gemanipuleerd om goedaardige gebruikers te trollen

Alle bronnen van AI/ML-afhankelijkheden identificeren evenals presentatielagen in de front-end van de toeleveringsketen van gegevens/het model

Samenvatting

Veel aanvallen in AI and Machine Learning beginnen met legitieme toegang tot API's die worden aangeboden om via query's toegang te krijgen tot een model. Vanwege de rijke bronnen van gegevens en de rijke gebruikerservaringen die hier een rol spelen, is geverifieerde maar 'ongepaste' (er is sprake van een grijs gebied hier) toegang vanderden tot uw modellen een risico vanwege de mogelijkheid om te fungeren als een presentatielaag boven een door Microsoft geleverde service.

Vragen om te stellen tijdens een beveiligingsevaluatie

• Welke klanten/partners zijn geverifieerd voor toegang tot uw model of service-API's?

  -Kunnen ze fungeren als een presentatielaag over uw service?

  -Kunt u hun toegang direct intrekken bij onjuist gebruik?

  -Wat is de herstelstrategie in het geval van kwaadaardig gebruik van uw service of afhankelijkheden?

• Kan eenexterne partij een façade bouwen rond uw model om het doel ervan aan te passen en Microsoft of haar klanten schade te berokkenen?

• Leveren klanten rechtstreeks trainingsgegevens aan u?

  -Hoe beveiligt u die gegevens?

  -Wat als deze kwaadaardig blijken te zijn en uw service het doelwit is?

• Hoe ziet een fout-positief er hier uit? Wat is de impact van een fout-negatief?

• Bent u in staat om de afwijking van terecht-positieven vs fout-positieven te traceren en meten voor verschillende modellen?

• Wat voor soort telemetrie is er nodig om de betrouwbaarheid van uw model te bewijzen aan uw klanten?

• Identificeer alleexterne afhankelijkheden in de toeleveringsketen van uw ML/trainingsgegevens, niet alleen open sourcesoftware, maar ook gegevensproviders

  -Waarom gebruikt u ze en hoe controleert u de betrouwbaarheid ervan?

• Gebruikt u vooraf gemaakte modellen van externe partijen of verzendt u trainingsgegevens naar externe MLaaS-providers?

• Maak een overzicht van nieuws over aanvallen op vergelijkbare producten/services. Als bekend is dat veel AI/ML-bedreigingen worden overgedragen tussen modeltypen, welke impact zouden deze aanvallen dan hebben op uw eigen producten?

Gerelateerde bedreigingen en oplossingen in dit document

• Neural Net herprogrammeren

• Adversarial voorbeelden in het fysieke domein

• Kwaadwillende ML-providers die trainingsgegevens kunnen herstellen

• Aanval van ML-toeleveringsketen

• Model met backdoor

• Gecompromitteerde ML-specifieke afhankelijkheden

Voorbeelden van aanvallen

• Kwaadwillende MLaaS-provider gebruikt Trojaanse paarden om uw model met een specifieke bypass binnen te dringen

• Kwaadwillende klant vindt beveiligingsprobleem in gemeenschappelijke OSS-afhankelijkheid die u gebruikt en uploadt gemanipuleerde payload met trainingsgegevens om uw service schade te berokkenen

• Gewetenloze partner gebruikt API's voor gezichtsherkenning en maakt een presentatielaag die over uw service wordt heengelegd om 'deep fakes' te produceren.

AI/ML-specifieke bedreigingen en hun oplossingen

#1: Adversarial Perturbation

Beschrijving

Bij verstorende aanvallen wijzigt de aanvaller heimelijk de query om een gewenste reactie te krijgen van een model dat in productie is geïmplementeerd[1]. Dit is een schending van de modelinvoerintegriteit die leidt tot verstoringsaanvallen waarbij het eindresultaat niet noodzakelijkerwijs een toegangsschending of EOP is, maar eerder een aantasting van de classificatieprestaties van het model. Dit kan ook worden bewerkstelligd door trollen die bepaalde doelwoorden op een dusdanige manier gebruiken dat ze door AI worden verboden, waardoor legitieme gebruikers met een naam die overeenkomt met een 'verboden' woord, de toegang tot de service wordt ontzegd.

[24]

Variant #1a: Gerichte misclassificatie

In dit geval genereren aanvallers een sample dat niet voldoet aan de invoerklasse van de doelclassificatie maar dat door het model wordt geclassificeerd als die specifieke invoerklasse. Het adversarial sample kan als willekeurige ruis worden geïnterpreteerd door het menselijk oog, maar aanvallers beschikken over voldoende kennis van het doel-ML-systeem om witte ruis te genereren die niet willekeurig is maar die enkele specifieke aspecten van het doelmodel benut. De kwaadwillende partij verstrekt een invoer-sample dat geen legitiem sample is, maar het doelsysteem classificeert het als een legitieme klasse.

Voorbeelden

[6]

Oplossingen

• Versterking van Adversarial Robustness met behulp van Model Confidence Geïnduceerd door Adversarial Training [19]: de auteurs stellen HcNN (Highly Confident Near Neighbor) voor, een framework dat betrouwbaarheidsinformatie en dichtstbijzijnde burenzoekopdrachten combineert om de adversarial robuustheid van een basismodel te versterken. Hierdoor kan beter onderscheid worden gemaakt tussen juiste en verkeerde modelvoorspellingen in de directe omgeving van een punt waarvan een sample wordt genomen vanuit de onderliggende trainingsdistributie.

• Toeschrijvingsgestuurde causale analyse [20]: de auteurs bestuderen de verbinding tussen de tolerantie voor adversarial perturbaties en de uitleg op basis van toeschrijving van afzonderlijke beslissingen die worden gegenereerd door machine learning-modellen. Ze melden dat adversarial invoer niet robuust is in de toeschrijvingsruimte. Door enkele kenmerken te maskeren met hoge toeschrijving, kan het machine learning-model geen beslissing meer nemen over de adversarial voorbeelden. De natuurlijke invoer, daarentegen, is wel robuust in de toeschrijvingsruimte.

  [20]

Deze benaderingen kunnen ervoor zorgen dat machine learning-modellen beter bestand zijn tegen adversarial aanvallen omdat voor het misleiden van dit tweelaagse herkenningssysteem niet alleen het oorspronkelijke model moet worden aangevallen, maar ook de toeschrijving die wordt gegenereerd voor het adversarial voorbeeld, vergelijkbaar moet zijn met de oorspronkelijke voorbeelden. Beide systemen moeten tegelijkertijd worden gecompromitteerd voor een geslaagde adversarial aanval.

Traditionele parallellen

Verhoging van bevoegdheden op afstand aangezien de aanvaller nu de controle heeft over uw model

Ernst

Kritiek

Variant #1b: misclassificatie van bron/doel

Dit kan worden omschreven als een poging door een aanvaller om een model ertoe te verleiden een bepaald label te retourneren voor gegeven invoer. Meestal wordt een model hierbij geforceerd om een fout-positief of een fout-negatief te retourneren. Het eindresultaat is een subtiele overname van de classificatienauwkeurigheid van het model, waarbij een aanvaller specifieke bypasses naar wens kan genereren.

Hoewel deze aanval een sterk nadelige invloed heeft op de classificatienauwkeurigheid, kan dit ook tijdrovender zijn omdat de aanvaller niet alleen de brongegevens moet manipuleren zodat deze niet meer het juiste label hebben, maar bovendien worden gelabeld met het gewenste frauduleuze label. Deze aanvallen vereisen vaak meerdere stappen/pogingen om misclassificatie af te dwingen [3]. Als het model vatbaar is voor het overdragen van leeraanvallen die gerichte misclassificatie afdwingen, is er mogelijk geen waarneembare footprint van de aanvaller omdat de verkennende aanvallen offline kunnen worden uitgevoerd.

Voorbeelden

Afdwingen dat goedaardige e-mails worden geclassificeerd als spam of ervoor zorgen dat een schadelijk voorbeeld onopgemerkt blijft. Deze aanvallen worden ook wel modelontwijkings- of imitatieaanvallen genoemd.

Oplossingen

Acties voor reactieve/defensieve detectie

• Implementeer een minimale tijdsdrempel tussen aanroepen van de API die classificatieresultaten levert. Hierdoor wordt het testen via een meerstaps aanval vertraagd door het verlengen van de algehele tijd die nodig is voor het vinden van een succesvolle verstoring.

Proactieve/beschermende acties

• Functienoising voor het verbeteren van adversarial robustness [22]: de auteurs ontwikkelen een nieuwe netwerkarchitectuur die adversarial robuustheid verhoogt door functienoising uit te voeren. Dit houdt in dat de netwerken blokken bevatten waarmee de kenmerken van ruis worden ontdaan met behulp van niet-lokale middelen of andere filters. De volledige netwerken worden end-to-end getraind. In combinatie met training met adversarial gegevens laten de feature denoising-netwerken een aanzienlijke verbetering zien van de state-of-the-art voor wat betreft de beveiliging tegen adversarial aanvallen, voor instellingen voor zowel whitebox- als blackbox-aanvallen.

• Adversarial Training en Regularization: Train met bekende adversarial samples om tolerantie en robuustheid te bouwen tegen schadelijke invoer. Dit kan ook worden gezien als een vorm van regulering, waarbij de norm van invoergradiënten wordt bestraft en de voorspellingsfunctie van de classificatie gelijkmatiger wordt (door het vergroten van de invoermarge). Dit omvat juiste classificaties met lagere vertrouwensscores.

Investeer in het ontwikkelen van monotone classificatie met een selectie van monotone kenmerken. Dit zorgt ervoor dat de aanvaller de classificatie niet kan omzeilen door kenmerken uit de negatieve klasse toe te voegen [13].

• 'Feature squeezing' [18] kan worden gebruikt om DNN-modellen te versterken door voorbeelden van adversarial gegevens te detecteren. Hiermee wordt de zoekruimte die beschikbaar is voor een aanvaller verkleind door samples die overeenkomen met een groot aantal verschillende kenmerkvectoren in de oorspronkelijke ruimte, samen te voegen in één sample. Door de voorspelling van een DNN-model voor de oorspronkelijke invoer te vergelijken met die voor de beperkte ('squeezed') invoer, kan deze techniek helpen bij het opsporen van adversarial voorbeelden. Als de oorspronkelijke en beperkte voorbeelden uitvoer produceren die aanzienlijk afwijkt van het model, is de invoer waarschijnlijk adversarial van aard. Door het verschil te meten tussen de voorspellingen en een drempelwaarde te selecteren, kan het systeem de juiste voorspelling genereren voor legitieme voorbeelden en adversarial invoer weigeren.

  

  [18]

• Certified Defenses against Adversarial Examples [22]: De auteurs stellen een methode voor op basis van een semi-definitieve ontspanning die een certificaat uitvoert dat voor een bepaald netwerk en testinvoer geen aanval kan afdwingen dat de fout een bepaalde waarde overschrijdt. Daar komt bij, omdat dit certificaat differentieerbaar is, dat auteurs het certificaat optimaliseren met de netwerkparameters, om zo een instelbare regeling te bieden die een betere bescherming biedt tegen alle aanvallen.

Responsacties

• Verstuur waarschuwingen voor classificatieresultaten met een groot verschil tussen classificaties, met name indien afkomstig van een individuele gebruiker of een kleine groep gebruikers.

Traditionele parallellen

Verhoging van bevoegdheden op afstand

Ernst

Kritiek

Variant #1c: Willekeurige misclassificatie

Dit is een speciale variant waarbij de doelclassificatie van de aanvaller alles kan zijn behalve de legitieme bronclassificatie. Met de aanval wordt meestal willekeurige ruis in de brongegevens geïnjecteerd die worden geclassificeerd om de kans te verkleinen dat in de toekomst de juiste classificatie wordt gebruikt [3].

Voorbeelden

Oplossingen

Zelfde als variant 1a.

Traditionele parallellen

Niet-persistente denial of service

Ernst

Belangrijk

Variant #1d: Betrouwbaarheidsvermindering

Een aanvaller kan invoer samenstellen om het betrouwbaarheidsniveau van de juiste classificatie te verminderen, met name in cruciale scenario's. Dit kan ook de vorm aannemen van een groot aantal fout-positieven dat is bedoeld om beheerders of bewakingssystemen te overbelasten met frauduleuze waarschuwingen die niet te onderscheiden zijn van legitieme waarschuwingen [3].

Voorbeelden

Oplossingen

• Naast de acties die in variant #1a worden behandeld, kan gebeurtenisbeperking worden gebruikt om het aantal waarschuwingen van één bron te verminderen.

Traditionele parallellen

Niet-persistente denial of service

Ernst

Belangrijk

#2a Gerichte gegevensvergiftiging

Beschrijving

Het doel van de aanvaller is om het machinemodel te verontreinigen dat wordt gegenereerd in de trainingsfase, zodat voorspellingen over nieuwe gegevens worden gewijzigd in de testfase [1]. Bij gerichte verontreinigingsaanvallen wil de aanvaller specifieke voorbeelden verkeerd classificeren om ervoor te zorgen dat specifieke acties worden uitgevoerd of nagelaten.

Voorbeelden

AV-software als malware indienen om de software onjuist te laten classificeren als schadelijke software om zo het gebruik van gerichte AV-software op clientsystemen te elimineren.

Oplossingen

• Anomaliesensoren definiëren om iedere dag naar de gegevensdistributie te kijken en waarschuwingen te verzenden bij variaties

  -Variatie van trainingsgegevens meten op dagelijkse basis, telemetrie voor scheefheid/drift

• Invoervalidatie, zowel opschonen als integriteitscontrole

• Verontreiniging van uitschieters in trainingssamples. Er zijn twee belangrijke strategieën om deze bedreiging tegen te gaan:

  -Opschonen/valideren van gegevens: verontreinigde samples verwijderen uit trainingsgegevens -Inkapselen voor bestrijden van verontreinigingsaanvallen [14]

  -RONI-beveiliging (Reject-on-Negative-Impact) [15]

  -Robuust leren: Kies leeralgoritmen die robuust zijn in aanwezigheid van vergiftigingsmonsters.

  -Een dergelijke benadering wordt beschreven in [21] waarbij auteurs het probleem van gegevensvergiftiging in twee stappen aanpakken: 1) een nieuwe robuuste matrixfactorisatiemethode introduceren om de echte subruimte te herstellen, en 2) nieuwe robuuste principecomponentregressie om adversarial instanties te verwijderen op basis van de basis die in stap (1) is hersteld. Deze stappen karakteriseren de benodigde en afdoende voorwaarden voor het terughalen van de subruimte en vormen een grens voor het verwachte voorspellingsverlies in vergelijking met de elementaire waarheid.

Traditionele parallellen

Invasie van host via Trojaans paart waarbij de aanvaller in het netwerk aanwezig blijft. Trainings- of configuratiegegevens zijn gecompromitteerd en worden opgenomen/vertrouwd voor maken van model.

Ernst

Kritiek

#2b Gegevensvergiftiging ondiscrimineren

Beschrijving

Het doel is om de kwaliteit/integriteit te ruïneren van de gegevensset die wordt aangevallen. Veel gegevenssets zijn openbaar/niet-vertrouwd/niet-gecureerd, wat het extra lastig maakt om de schendingen van de gegevensintegriteit überhaupt vast te stellen. Het trainen van een model met gegevens die zonder het te weten gecompromitteerd zijn, betekent 'garbage-in/garbage-out'. Als het probleem is gedetecteerd, is triage nodig om vast te stellen welke gegevens zijn geschonden en in quarantaine moeten worden geplaatst/opnieuw worden getraind.

Voorbeelden

Een bedrijf gebruikt een scraper om op een bekende en vertrouwde website te zoeken naar gegevens van futures van olie om zijn modellen te trainen. De website van de gegevensprovider wordt op een gegeven moment gecompromitteerd via een SQL-injectieaanval. De aanvaller kan de gegevensset naar believen verontreinigen en het model dat wordt getraind, heeft er geen weet van dat de gegevens besmet zijn.

Oplossingen

Zelfde als variant 2a.

Traditionele parallellen

Geverifieerde denial of service tegen een zeer waardevolle asset

Ernst

Belangrijk

#3 ModelInversion-aanvallen

Beschrijving

De persoonlijke functies die worden gebruikt in machine learning-modellen kunnen worden hersteld [1]. Dit omvat het reconstrueren van privé-trainingsgegevens waartoe de aanvaller geen toegang heeft. In de biometrische gemeenschap wordt deze ook wel hill climbing-aanvallen genoemd. [16, 17] Dit wordt bereikt door de invoer te vinden die het geretourneerde betrouwbaarheidsniveau maximaliseert, afhankelijk van de classificatie die met het doel overeenkomt [4].

Voorbeelden

[4]

Oplossingen

• Interfaces naar modellen die worden getraind op basis van gevoelige gegevens vereisen een krachtig toegangsbeheer.

• Query's met frequentielimiet toegestaan per model

• Implementeer poorten tussen gebruikers/aanroepers en het model zelf door invoervalidatie toe te passen op alle voorgestelde query's, waarbij alles wordt geweigerd dat niet voldoet aan de definitie van het model ten aanzien van juist gevormde invoer en alleen de minimale hoeveelheid gegevens wordt geretourneerd die nodig is om zinvol te zijn.

Traditionele parallellen

Gerichte openbaarmaking van geheime gegevens

Ernst

Dit wordt standaard als Belangrijk beschouwd op de standaard-SDL Bug Bar, maar in het geval dat er gevoelige gegevens of persoonsgegevens worden geëxtraheerd, wordt dit verhoogd naar Kritiek.

#4 Lidmaatschapsdeductieaanval

Beschrijving

De aanvaller kan vaststellen of een bepaalde gegevensrecord al dan niet deel uitmaakte van de trainingsset van het model [1]. Onderzoekers konden de belangrijkste procedure van een patiënt voorspellen (bijvoorbeeld operatie die de patiënt doormaakte) op basis van de kenmerken (bijvoorbeeld leeftijd, geslacht, ziekenhuis) [1].

[12]

Oplossingen

Onderzoekspublicaties waarin de mogelijkheid van deze aanval wordt aangetoond, geven aan dat differentiële privacy [4, 9] een effectieve maatregel zou zijn. Dit is nog steeds een opkomende techniek bij Microsoft en AETHER Security Engineering adviseert om onderzoeksbudget vrij te maken om expertise op te doen in dit domein. In dit onderzoek zou aandacht moeten worden besteed aan de mogelijkheden van differentiële privacy en wat praktische oplossingen zijn als beveiliging, waarna er manieren moeten worden ontworpen om deze verdedigingen transparant over te nemen op onze platforms voor online services, vergelijkbaar met hoe het compileren van code in Visual Studio u de beschikking geeft over 'on-by-default' beveiligingsbeschermingen die transparant zijn voor de ontwikkelaar en gebruikers.

Het gebruik van 'neuron dropout' en modelstacking kunnen in bepaalde mate effectieve maatregelen zijn. Het gebruik van 'neuron dropout' verbetert niet alleen de flexibiliteit van een neuraal netwerk bij een dergelijke aanval, maar verhoogt ook de prestaties van het model [4].

Traditionele parallellen

Gegevensprivacy. Er worden deducties gedaan ten aanzien van de opname van een gegevenspunt in de trainingsset, maar de trainingsgegevens zelf worden niet vrijgegeven.

Ernst

Dit is een privacykwestie, geen beveiligingsprobleem. Het komt hier aan bod omdat de domeinen overlappen, maar elke reactie hier zou worden aangestuurd door privacy, niet beveiliging.

#5 Model stelen

Beschrijving

De aanvallers bouwen het onderliggende model opnieuw op door legitieme query's uit te voeren op het model. De functionaliteit van het nieuwe model is hetzelfde als die van het onderliggende model [1]. Zodra het model opnieuw is gemaakt, kan het worden omgekeerd om informatie over het kenmerk te herstellen of om trainingsgegevens te deduceren.

• Vergelijkingen oplossen – Voor een model dat klassewaarschijnlijkheden retourneert via API-uitvoer, kan een aanvaller query's maken om onbekende variabelen in een model te bepalen.

• Paden vinden – Een aanval waarbij de API-details worden misbruikt om de 'beslissingen' te extraheren die door een structuur worden genomen bij het classificeren van een invoer [7].

• Overdrachtsaanval – Een kwaadwillend iemand kan een lokaal model trainen, mogelijk door voorspellingsquery's naar het doelmodel te verzenden en dit te gebruiken om schadelijke voorbeelden te maken die worden overgedragen op het doelmodel [8]. Als uw model geëxtraheerd is en kwetsbaar blijkt te zijn voor een bepaald type schadelijke invoer, kunnen nieuwe aanvallen tegen uw productie-implementatiemodel volledig offline worden ontwikkeld door de aanvaller die een kopie van uw model heeft geëxtraheerd.

Voorbeelden

In instellingen waarbij een ML-model wordt gebruikt om schadelijk gedrag te detecteren, zoals het identificeren van spam, het classificeren van malware en het detecteren van netwerkafwijkingen, kan modelextractie leiden tot fraudeaanvallen [7].

Oplossingen

Proactieve/beschermende acties

• Minimaliseer de gegevens die worden geretourneerd in voorspellings-API's of maak deze onleesbaar zonder dat ze hun nut verliezen voor 'eerlijke' toepassingen [7].

• Definieer een goed gevormde query voor de modelinvoer en retourneer alleen resultaten in reactie op afgeronde, goed gevormde invoer die voldoen aan die indeling.

• Retourneer afgeronde betrouwbaarheidswaarden. De meeste legitieme aanroepers vereisen geen verschillende tekens achter de komma.

Traditionele parallellen

Niet-geverifieerde, alleen-lezen manipulatie van systeemgegevens, gericht op openbaarmaking van zeer waardevolle gegevens?

Ernst

Belangrijk in modellen die gevoelig zijn voor beveiliging, anders Gemiddeld

#6 Neural Net Herprogrammering

Beschrijving

Door middel van een speciaal gemaakte query van een aanvaller kunnen machine learning-systemen worden geherprogrammeerd voor een taak die afwijkt van de oorspronkelijke intentie van de maker [1].

Voorbeelden

Zwakke toegangscontroles voor een gezichtsherkennings-API waarmeeexterne partijen kunnen worden opgenomen in apps die zijn ontworpen om Microsoft-klanten te beschadigen, zoals een deep fake generator.

Oplossingen

• Sterke client-server<> wederzijdse verificatie en toegangsbeheer voor modelinterfaces

• Verwijderen van accounts in kwestie.

• Identificeer een SLA (Service Level Agreement) voor uw APIs en dwing deze af. Bepaal de acceptabele time-to-fix voor een gemeld probleem en zorg ervoor dat het probleem niet meer optreedt als de SLA is verlopen.

Traditionele parallellen

Dit is een misbruikscenario. De kans is kleiner dat u hiervoor een beveiligingsincident aanmaakt dan dat u het account van de betrokken persoon uitschakelt.

Ernst

Belangrijk tot Kritiek

#7 Adversarial Voorbeeld in het fysieke domein (bits-atoms>)

Beschrijving

Een adversarial voorbeeld is een invoer/query van een schadelijke entiteit die is verzonden met het enige doel het machine learning-systeem te misleiden [1]

Voorbeelden

Deze voorbeelden kunnen zich manifesteren in het fysieke domein, zoals een zelfrijdende auto die wordt misleid om bij een stopbord door te rijden doordat er een bepaalde kleur licht (de schadelijke invoer) op het stopbord schijnt, waardoor het systeem voor afbeeldingsherkenning het stopbord niet meer als zodanig herkent.

Traditionele parallellen

Verhoging van bevoegdheden, externe uitvoering van code

Oplossingen

Deze aanvallen zijn mogelijk omdat problemen op de machine learning-laag (de gegevens- en algoritmelaag onder AI-gestuurde besluitvorming) niet zijn aangepakt. Net als bij andere software *of* fysieke systemen, kan de laag onder het doel altijd worden aangevallen via traditionele vectoren. Om die reden zijn traditionele beveiligingsmethoden belangrijker dan ooit, zeker vanwege de laag met onopgeloste kwetsbaarheden (de gegevens- en algoritmelaag) die wordt gebruikt tussen AI en traditionele software.

Ernst

Kritiek

#8 Schadelijke ML-providers die trainingsgegevens kunnen herstellen

Beschrijving

Een kwaadwillende provider biedt een algoritme met een backdoor aan waardoor de privé-trainingsgegevens kunnen worden hersteld. Op deze manier was het mogelijk om alleen met behulp van het model gezichten en teksten te reconstrueren.

Traditionele parallellen

Gerichte openbaarmaking van gegevens

Oplossingen

Onderzoekspublicaties waarin de mogelijkheid van deze aanval wordt aangetoond, geven aan dat homomorfe versleuteling een effectieve maatregel zou zijn. Dit is een gebied waar Microsoft nog weinig aandacht aan heeft besteed en AETHER Security Engineering adviseert om onderzoeksbudget vrij te maken om expertise op te doen in dit domein. In dit onderzoek zou aandacht moeten worden besteed aan de grondbeginselen van homomorfe versleuteling en wat praktische oplossingen zijn als beveiliging ten aanzien van kwaadwillende ML-as-a-Service-providers.

Ernst

Belangrijk als het om persoonsgegevens gaat, anders Gemiddeld

#9 Aanval op de ML-toeleveringsketen

Beschrijving

Vanwege grote resources (gegevens en berekeningen) die nodig zijn voor het trainen van algoritmen, is de huidige praktijk het hergebruiken van modellen die zijn getraind door grote bedrijven en deze enigszins wijzigen voor taken (bijvoorbeeld: ResNet is een populair model voor afbeeldingsherkenning van Microsoft). Deze modellen worden gecureerd in een Model Zoo (Caffe host populaire modellen voor afbeeldingsherkenning). Bij deze aanval valt de kwaadwillende persoon de in Caffe gehoste modellen aan, waardoor de bron voor anderen wordt verontreinigd. [1]

Traditionele parallellen

• Gecompromitteerde niet-beveiligingsafhankelijkheid van externe partij

• App Store onbewust host voor malware

Oplossingen

• Minimaliseer waar mogelijk afhankelijkheden van externe partijen voor modellen en gegevens.

• Neem deze afhankelijkheden op in uw proces voor bedreigingsmodellering.

• Maak gebruik van krachtige verificatie, toegangsbeheer en versleuteling tussen systemen vanMicrosoften externe partijen.

Ernst

Kritiek

#10 Backdoor Machine Learning

Beschrijving

Het trainingsproces wordt uitbesteed aan een kwaadwillende externe partij die de trainingsgegevens manipuleert en een model met een Trojaans paard levert dat is gericht op misclassificaties, zoals het classificeren van een bepaald virus als niet-kwaadaardig [1]. Dit is een risico in ML-as-a-Service-scenario's voor het genereren van modellen.

[12]

Traditionele parallellen

• Gecompromitteerde beveiligingsafhankelijkheid van externe partij

• Gecompromitteerd mechanisme voor bijwerken van software

• Certificeringsinstantie gecompromitteerd

Oplossingen

Acties voor reactieve/defensieve detectie

• De schade is al gedaan op het moment dat deze bedreiging wordt gedetecteerd, wat betekent dat het model en eventuele trainingsgegevens van de kwaadwillende provider niet kunnen worden vertrouwd.

Proactieve/beschermende acties

• Train alle gevoelige modellen intern

• Neem trainingsgegevens op in een catalogus of zorg ervoor dat deze afkomstig zijn van een vertrouwde derde partij met afdoende beveiligingsmaatregelen

• Neem de interactie tussen de MLaaS-provider en uw eigen systemen op in het bedreigingsmodel

Responsacties

• Zelfde als voor gecompromitteerde externe afhankelijkheid

Ernst

Kritiek

#11 Softwareafhankelijkheden van het ML-systeem misbruiken

Beschrijving

In deze aanval manipuleert de aanvaller NIET de algoritmes. In plaats daarvan worden beveiligingsproblemen in de software misbruikt zoals bufferoverlopen of cross-site scripting [1]. Het is nog steeds eenvoudiger om softwarelagen onder AI/ML te compromitteren dan rechtstreeks de leerlaag. Dit betekent dat traditionele beveiligingspraktijken die worden beschreven in de Security Development Lifecycle essentieel zijn.

Traditionele parallellen

• Gecompromitteerde open source-softwareafhankelijkheid

• Kwetsbaarheid van webserver (XSS, CSRF, fout bij API-invoervalidatie)

Oplossingen

Werk samen met uw beveiligingsteam om de toepasselijke best practices van Security Development Lifecycle/Operational Security Assurance te volgen.

Ernst

Wisselend; maximaal Kritiek afhankelijk van het type traditioneel beveiligingsprobleem van de software.

Bibliografie

[1] Foutmodi in Machine Learning, Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen en Jeffrey Snover, https://learn.microsoft.com/security/failure-modes-in-machine-learning

[2] AETHER Security Engineering Workstream, Data Provenance/Lineage v-team

[3] Adversarial Examples in Deep Learning: Characterization and Divergence, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf

[4] ML-Leaks: Model and Data Independent Membership Inference Attacks and Defenses on Machine Learning Models, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf

[5] M. Fredrikson, S. Jha en T. Ristenpart, “Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures,” in Proceedings of the 2015 ACM SIGSAC Conference on Computer and Communications Security (CCS).

[6] Nicolas Papernot en Patrick McDaniel- Adversarial Examples in Machine Learning AIWTB 2017

[7] Stealing Machine Learning Models via Prediction APIs, Florian Tramèr, École Polytechnique Fédérale de Lausanne (EPFL); Fan Zhang, Cornell University; Ari Juels, Cornell Tech; Michael K. Reiter, The University of North Carolina at Chapel Hill; Thomas Ristenpart, Cornell Tech

[8] The Space of Transferable Adversarial Examples, Florian Tramèr , Nicolas Papernot , Ian Goodfellow , Dan Boneh en Patrick McDaniel

[9] Understanding Membership Inferences on Well-Generalized Learning Models Yunhui Long1 , Vincent Bindschaedler1 , Lei Wang2 , Diyue Bu2 , Xiaofeng Wang2 , Haixu Tang2 , Carl A. Gunter1 en Kai Chen3,4

[10] Simon-Gabriel et al., Adversarial vulnerability of neural networks increases with input dimension, ArXiv 2018;

[11] Lyu et al., A unified gradient regularization family for adversarial examples, ICDM 2015

[12] Wilde patronen: Tien jaar na de opkomst van adversarial Machine Learning - NeCS 2019 Battista Biggioa, Werkruimte Roli

[13] Adversarially Robust Malware Detection UsingMonotonic Classification Inigo Incer et al.

[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto en Fabio Roli. Bagging Classifiers for Fighting Poisoning Attacks in Adversarial Classification Tasks

[15] An Improved Reject on Negative Impact Defense Hongjiang Li and Patrick P.K. Chan

[16] Adler. Vulnerabilities in biometric encryption systems. 5th Int’l Conf. AVBPA, 2005

[17] Galbally, McCool, Fierrez, Marcel, Ortega-Garcia. On the vulnerability of face verification systems to hill-climbing attacks. Patt. Rec., 2010

[18] Weilin Xu, David Evans, Yanjun Qi. Functiesqueezing: Adversarial-voorbeelden detecteren in Deep Neural Networks. 2018 Network and Distributed System Security Symposium. 18-21 februari 2020

[19] Reinforcing Adversarial Robustness using Model Confidence Induced by Adversarial Training - Xi Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen, Somesh Jha

[20] Attribution-driven Causal Analysis for Detection of Adversarial Examples, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami

[21] Robust Linear Regression Against Training Data Poisoning – Chang Liu et al.

[22] Feature Denoising for Improving Adversarial Robustness, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He

[23] Certified Defenses against Adversarial Examples - Aditi Raghunathan, Jacob Steinhardt, Percy Liang