Hotmodellering av AI/ML-specifika system och beroenden

Av Andrew Marshall, Jugal Parikh, Emre Kiciman och Ram Shankar Siva Kumar

Särskilt tack till Raul Rojas och AETHER Security Engineering-gruppen

November 2019

Det här dokumentet är produkten av AETHER Engineerings riktlinjer för AI-arbetsgrupper och kompletterar befintliga SDL-hotmodelleringsmetoder med nya riktlinjer för hotkategorisering och hotreducering som är specifika för AI- och maskininlärningsområdet. Det är avsett att användas som referens vid utvärderingen av säkerhetsaspekter i

1. produkter och tjänster som interagerar med eller som är beroende av AI/ML-baserade tjänster

2. produkter och tjänster som i hög grad bygger på AI/ML.

Traditionella riskreduceringsstrategier är viktigare än någonsin. Kraven i Microsoft Security Development Lifecycle är fundamentala för att skapa en stabil säkerhetsstruktur, som dessa riktlinjer bygger på. Det är viktigt att ta itu med traditionella säkerhetshot eftersom de ökar risken för de AI/ML-specifika angrepp mot programvara och fysisk infrastruktur som diskuteras i det här dokumentet, och eftersom de exponerar de lägre skikten i programvarustacken. En introduktion till nya säkerhetshot i den här domänen finns i Framtidens säkra AI och ML med Microsoft.

Säkerhetsteknikerns och dataexpertens kompetensområden överlappar sällan varandra. Den här vägledningen är ett sätt för båda kunskapsområden att föra strukturerade konversationer om dessa nya hot och riskreduceringsmetoder utan att säkerhetstekniker behöver bli dataexperter och tvärtom.

Dokumentet är uppdelat i två avsnitt:

1. ”Viktiga nya överväganden inom hotmodellering” fokuserar på nya sätt att tänka och nya frågor att ställa i samband med hotmodellering med AI/ML-system. Både dataexperter och säkerhetstekniker bör läsa dokumentet eftersom det är en bra utgångspunkt i diskussioner kring hotmodellering och riskreducering.
2. ”AI/ML-specifika hot och riskreducering” innehåller information om specifika angrepp och beskriver specifika åtgärder som används för att skydda Microsofts produkter och tjänster mot dessa hot. Det här avsnittet riktar sig främst till dataexperter som kan behöva implementera specifik hotreducering baserat på resultatet av hotmodellerings- och säkerhetsutvärderingsprocessen.

Den här vägledningen är organiserad kring en Adversarial Machine Learning Threat Taxonomy skapad av Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen och Jeffrey Snover med titeln "Failure Modes in Machine Learning". Vägledning för incidenthantering om hur du sorterar säkerhetshot som beskrivs i det här dokumentet finns i SDL-felfältet för AI/ML-hot. Alla dessa är levande dokument som kommer att utvecklas med tiden med hotlandskapet.

Viktiga nya överväganden i hotmodellering: Ändra hur du visar förtroendegränser

Ha i åtanke att både de data som du tränar från och dataprovidern kan vara komprometterade/kontaminerade. Lär dig hur du identifierar avvikande och skadliga dataposter och hur du kan skilja mellan och återställa från dem

Sammanfattning

Arkiven med träningsdata och de system där de lagras är en viktig del av hotmodelleringen. Det största säkerhetshotet inom maskininlärning i dag är datakontaminering, som beror på bristen på standardiserad identifiering och riskreducering inom området, i kombination med beroendet av icke-betrodda/icke-kurerade offentliga datauppsättningar som källor för träningsdata. Det är viktigt att spåra härkomsten av data för att säkerställa att de är tillförlitliga och för att undvika en ”skräp in, skräp ut”-träningscykel.

Frågor att ställa vid en säkerhetsbedömning

• Hur vet du om dina data är kontaminerade eller om de har manipulerats?

  – Vilken telemetri kan du använda för att identifiera brister i kvaliteten hos dina träningsdata?

• Tränar du baserat på indata från användare?

  – Vilken typ av indatavalidering/datasanering utförs på innehållet?

  – Är själva datastrukturen dokumenterad, t.ex. som datablad för datauppsättningar?

• Om du tränar mot data i onlinedatabaser, hur skyddar du i så fall anslutningen mellan din modell och onlinedata?

  – Har de möjlighet att rapportera incidenter till användarna av deras feeds?

  – Kan de över huvud taget göra det?

• Hur känsliga är de data som du tränar från?

  – För du register över eller kontrollerar tillägg/uppdateringar/borttagningar av dataposter?

• Kan din modell returnera känsliga data?

  – Hämtades dessa data med tillstånd från källan?

• Matar modellen bara ut resultat som krävs för att uppnå dess mål?

• Returnerar din modell rena förtroendepoäng eller andra direkta utdata som skulle kunna registreras och dupliceras?

• Vilka konsekvenser får det om en angripare attackerar/inverterar din modell för att komma över dina träningsdata?

• Om förtroendenivåerna i dina modellutdata plötsligt sjunker, kan du i så fall ta reda på hur/varför och vilka data som orsakade det?

• Har du definierat välformulerade indata för din modell? Vad gör du för att säkerställa att indata matchar det här formatet, och vad gör du om så inte är fallet?

• Hur kan du veta om dina utdata är fel om de inte orsakar några fel som rapporteras?

• Vet du om dina träningsalgoritmer kan stå emot manipulerade indata på en matematisk nivå?

• Hur återhämtar du dig från kontaminering av dina träningsdata?

  – Kan du isolera/sätta manipulerat innehåll i karantän och träna om de berörda modellerna?

  – Kan du återställa till och träna om en modell i en tidigare version?

• Använder du förstärkningsinlärning (RL, Reinforcement Learning) för offentligt innehåll som inte granskats?

• Fundera på varifrån dina data kommer – om du stöter på problem, kan du i så fall spåra dem till deras introduktion i datauppsättningen? Om inte, är det ett problem?

• Ta reda på var dina träningsdata kommer från och identifiera statistiska normer så att du vet hur avvikelser ser ut

  – Vilka delar av dina träningsdata är känsliga för yttre påverkan?

  – Vem kan bidra till de datauppsättningar som du tränar från?

  – Hur skulle du angripa källorna till dina träningsdata för att skada en konkurrent?

Relaterade hot och riskreducering i detta dokument

• Avsiktliga störningar (alla varianter)

• Datakontaminering (alla varianter)

Exempelangrepp

• Angriparen tvingar oskadliga e-postmeddelanden att klassificera sig som skräppost eller får skadliga indata att gå obemärkt förbi

• Angriparen skapar indata som minskar förtroendenivån för en korrekt klassificering, särskilt i scenarier som kan få stora konsekvenser

• Angriparen matar in brus slumpmässigt i källdata som klassificeras för att därigenom minska sannolikheten att rätt klassificering används i framtiden, vilket försvagar modellen

• Angriparen kontaminerar träningsdata så att utvalda datapunkter klassificeras fel, vilket gör att systemet antingen utför eller ignorerar specifika åtgärder

Identifiera åtgärder som din modell eller produkt/tjänst kan vidta som skulle kunna skada kunden online eller i den fysiska miljön

Sammanfattning

Om angrepp på AI/ML-system inte avstyrs kan de sprida sig till den fysiska världen. Alla scenarier som kan manipuleras för att skada användarna psykologiskt eller fysiskt utgör en mycket allvarlig risk för din produkt/eller tjänst. Detta inbegriper även alla känsliga data om dina kunder som används för träning samt designbeslut som indirekt kan orsaka läckage av privata datapunkter.

Frågor att ställa vid en säkerhetsbedömning

• Tränar du dina data med manipulerade indata? Hur påverkar de modellens utdata i den fysiska domänen?

• Medför din produkt/tjänst några risker för nättroll? Hur kan du identifiera och hantera dem?

• Skulle det gå att få din modell att returnera ett resultat som lurar din tjänst att neka åtkomst till legitima användare?

• Vilka konsekvenser skulle det få om din modell kopierades/blev stulen?

• Kan din modell, eller dina träningsdata, användas för att ta reda på om en person tillhör en viss grupp?

• Kan en angripare skapa ryktesspridning eller negativ PR om din produkt genom att tvinga den att utföra särskilda åtgärder?

• Hur hanterar du korrekt formaterade men uppenbart vinklade data, t.ex. från nättroll?

• Är det möjligt att få fram information om träningsdata eller modellen genom att interagera med eller köra frågor mot modellen?

Relaterade hot och riskreducering i detta dokument

• Medlemskapsinferens

• Modellinversion

• Modellstöld

Exempelangrepp

• Återuppbyggnad och extrahering av träningsdata genom att upprepade gånger fråga modellen efter maximalt konfidensresultat

• Duplicering av själva modellen genom uttömmande fråge-/svarsmatchning

• Att fråga modellen på ett sätt som avslöjar att ett särskilt element av privata data ingår i träningsuppsättningen

• Självkörande bil manipuleras till att ignorera stoppskyltar/trafikljus

• Konversationsrobotar manipuleras till att trakassera oskyldiga användare

Identifiera alla källor med AI/ML-beroenden samt presentationslager på klientsidan i försörjningskedjan för data/modellen

Sammanfattning

Många attacker i AI och maskininlärning börjar med legitim åtkomst till API:er som exponeras för att ge frågeåtkomst till en modell. På grund av de omfattande datakällorna och sofistikerade användarupplevelserna utgör autentiserad men ”olämplig” (det finns en gråzon här) åtkomst av en tredje part till dina modeller en risk eftersom en tredje part kan fungera som ett presentationslager ovanför en Microsoft-tjänst.

Frågor att ställa vid en säkerhetsbedömning

• Vilka kunder/partner har åtkomstbehörighet till dina modell eller dina tjänst-API:er?

  – Kan de fungera som ett presentationslager ovanpå din tjänst?

  – Kan du snabbt återkalla åtkomsten om dina data blir komprometterade?

  – Vilken återställningsstrategi har du i händelse av skadlig användning av din tjänst eller beroenden?

• Kan en tredje part bygga upp en fasad runt din modell och ändra dess syfte så att den kan skada Microsoft eller dess kunder?

• Får du träningsdata direkt från kunderna?

  – Hur skyddar du dessa data?

  – Vad händer om de är skadliga och din tjänst är målet?

• Hur ser en falsk positiv identifiering ut i den här kontexten? Vad är effekten av en falsk negativ identifiering?

• Kan du spåra och mäta avvikelser i sanna positiva eller felaktiga positiva identifieringar över flera modeller?

• Vilken typ av telemetri behöver du för att bevisa för kunderna att modellens utdata är tillförlitliga?

• Identifiera alla tredjepartsberoenden i försörjningskedjan för dina maskininlärnings- och träningsdata – inte bara programvara med öppen källkod, utan även dataproviders

  – Varför använder du dem och hur verifierar du deras tillförlitlighet?

• Använder du färdiga modeller från tredje parter eller skickar du träningsdata till externa MLaaS-providers?

• Ta reda på mer om attacker på liknande produkter/tjänster. Många AI/ML-hot överförs mellan modelltyper. Vilka konsekvenser skulle dessa attacker ha på dina produkter?

Relaterade hot och riskreducering i detta dokument

• Omprogrammering av neurala nätverk

• Indatamanipulering i den fysiska domänen

• Skadliga ML-providers kommer över träningsdata

• Angrepp mot ML-försörjningskedjan

• Modell med bakdörr

• Komprometterade ML-specifika beroenden

Exempelangrepp

• Illvilliga MLaaS-providers kringgår dina säkerhetsmekanismer och introducerar trojaner i din modell

• En kund med onda avsikter hittar en sårbarhet i ett OSS-beroende som du använder och laddar upp en konstruerad nyttolast med träningsdata för att kompromettera din tjänst

• En skrupelfri partner använder ansiktsigenkännings-API:er och skapar ett presentationslager ovanpå din tjänst för att generera ”deep fakes”.

AI/ML-specifika hot och riskreducering

#1: Adversarial Perturbation

beskrivning

Avsiktliga störningar är en typ av attack där angriparen obemärkt modifierar frågan för att få önskat svar från en modell i produktionsmiljön[1]. Detta integritetsintrång av modellens indata leder till ett slags ”fuzzing”-angrepp, vars slutresultat inte nödvändigtvis är en åtkomstöverträdelse eller EOP, utan kompromettering av modellens klassificeringsförmåga. Detta kan också åstadkommas med nättroll som använder särskilda målord på ett sätt som gör att AI förbjuder dem, vilket effektivt nekar tjänståtkomst till legitima användare med ett namn som matchar ett ”förbjudet” ord.

[24]

Variant #1a: Riktad felklassificering

I det här fallet genererar angripare indata som inte finns i indataklassen för målklassificeraren, men som klassificeras av modellen som den specifika indataklassen. Dessa manipulerade indata kan felaktigt tolkas som slumpmässigt brus, men angriparen har viss kunskap om målmaskininlärningssystemet och kan generera vitt brus som inte är slumpmässigt utan snarare utnyttjar specifika aspekter av målmodellen. Angriparen skickar indata som inte är legitima, men som klassificeras som en legitim klass av målsystemet.

Exempel

[6]

Åtgärder

• Förstärka kontradiktorisk robusthet med hjälp av modellförtroende som framkallas av adversarial träning [19]: Författarna föreslår Highly Confident Near Neighbor (HCNN), ett ramverk som kombinerar konfidensinformation och närmaste grannsökning, för att förstärka den kontradiktoriska robustheten hos en basmodell. Det här ramverket gör det enklare att skilja mellan riktiga och felaktiga modellförutsägelser i ett närhetsområde för en punkt som hämtas från den underliggande träningsdistributionen.

• Attributionsdriven kausal analys [20]: Författarna studerar sambandet mellan motståndskraften mot skadliga störningar och den attributionsbaserade förklaringen av enskilda beslut som genereras av maskininlärningsmodeller. De rapporterar att manipulerade indata inte är robusta i attributionsområdet. Det betyder att maskeringen av några få funktioner med hög attribution leder till nya beslut av maskininlärningsmodellen vid förekomst av manipulerade indata. Naturliga indata är däremot robusta i attributionsområdet.

  [20]

Dessa metoder kan göra maskininlärningsmodeller mer motståndskraftiga mot angrepp med manipulerade indata eftersom det för att lura det här kognitionssystemet med två lager inte räcker att bara angripa den ursprungliga modellen; attributionen som genereras för manipulerade indata måste dessutom likna ursprungliga indata. Båda systemen måste komprometteras samtidigt för att attacken ska lyckas.

Traditionella motsvarigheter

Upphöjning av privilegier genom fjärrkörning av kod när angriparen har fått kontroll över din modell

Allvarlighet

Kritiskt

Variant #1b: Felklassificering av källa/mål

En angripare försöker få en modell att returnera önskad märkning för givna indata. Vanligtvis tvingas en modell att returnera ett falskt positivt eller falskt negativt värde. Slutresultatet är ett diskret övertagande av modellens klassificeringsrelevans, vilket innebär att en angripare kan göra specifika omdirigeringar efter eget godtycke.

Det här angreppet försämrar kraftigt klassificeringsrelevansen, men kan också vara mer tidskrävande att genomföra eftersom angriparen förutom att manipulera källdata så att de inte längre märks korrekt, även måste märka dem specifikt med den felaktiga märkningen. Dessa attacker involverar ofta flera steg/försök att framtvinga en felklassificering [3]. Om modellen är sårbar för inlärningsöverföringsangrepp som framtvingar riktad felklassificering, kanske det inte finns några tydliga fotavtryck från angreppstrafiken eftersom avsökningsangreppen kan utföras offline.

Exempel

Att få legitima e-postmeddelanden klassificerade som skräppost eller att få skadliga meddelanden att inte klassificeras. Den här typen av angrepp involverar manipulerade indata eller imitation.

Åtgärder

Reaktiva/defensiva identifieringsåtgärder

• Implementera en minsta tidströskel mellan anrop till API:et som tillhandahåller klassificeringsresultatet. På så sätt saktar du ned testningen i flerstegsangrepp genom att öka mängden tid som krävs för att hitta en störning.

Proaktiva/skyddande åtgärder

• Feature Denoising for Improving Adversarial Robustness [22]: Författarna utvecklar en ny nätverksarkitektur som ökar den kontradiktoriska robustheten genom att utföra funktionsnekande. Mer specifikt innehåller nätverken block som reducerar brus i funktioner via icke-lokala metoder eller andra filter. Hela nätverken tränas från slutpunkt till slutpunkt. I kombination med träning med manipulerade indata tar brusreduceringsnätverken robustheten vid manipulerade indata till en ny nivå i både white-box- och black-box-scenarier.

• Adversarial Training and Regularization: Träna med kända kontradiktoriska exempel för att skapa motståndskraft och robusthet mot skadliga indata. Det här kan också ses som en form av reglering, som utdelar straff enligt normen om indataförändring och som effektiviserar klassificerarens förutsägelser (genom en större indatamarginal). Här inbegrips rätt klassificeringar med lägre konfidensnivåer.

Investera i utvecklingen av en monoton klassificering med ett urval av monotona funktioner. Detta säkerställer att angripare inte kan kringgå klassificeraren genom att bara fylla ut funktioner från den negativa klassen [13].

• Funktionssammanslagning [18] kan användas för att härda DNN-modeller genom att identifiera manipulerade indata. Den begränsar sökområdet som kan utnyttjas av angriparen genom att slå ihop typfall som matchar många olika funktionsvektorer i ursprungsområdet till ett. Genom att jämföra en DNN-modells förutsägelse om ursprungliga indata med den för sammanslagna indata kan en funktionssammanslagning göra det enklare att identifiera manipulerade indata. Om ursprungliga och sammanslagna indata genererar mycket olika utdata från modellen, är risken stor att det rör sig om manipulerade indata. Genom att jämföra avvikelserna mellan förutsägelser och välja ett tröskelvärde kan systemet returnera rätt förutsägelse för legitima indata och avvisa manipulerade indata.

  

  [18]

• Certified Defenses against Adversarial Examples [22]: Författarna föreslår en metod baserad på en halvavslappning som matar ut ett certifikat som för ett visst nätverk och testindata inte kan tvinga felet att överskrida ett visst värde. För det andra, eftersom denna verifiering är differentierbar, optimerar författarna den med nätverksparametrar för att skapa en flexibel regleringsmekanism som ökar robustheten mot alla former av angrepp.

Svarsåtgärder

• Utfärda aviseringar om klassificeringsresultat med hög varians mellan klassificerare, särskilt om det handlar om en enskild användare eller en mindre grupp med användare.

Traditionella motsvarigheter

Fjärrstyrd upphöjning av privilegier

Allvarlighet

Kritiskt

Variant #1c: Slumpmässig felklassificering

Detta är en specialvariant där angriparens målklassificering kan vara vad som helst annat än den legitima källklassificeringen. Angreppet involverar normalt inmatning av slumpmässigt brus i källdata som klassificeras för att minska sannolikheten att rätt klassificering används i framtiden [3].

Exempel

Åtgärder

Samma som variant 1a.

Traditionella motsvarigheter

Icke-beständig DoS (Denial of Service)

Allvarlighet

Viktigt!

Variant #1d: Konfidensreducering

En angripare kan skapa indata som minskar förtroendenivån för en korrekt klassificering, särskilt i scenarier som kan få betydande konsekvenser. Detta kan också ske i form av ett stort antal falska positiva identifieringar som är avsedda att överbelasta administratörer eller övervakningssystem med bedrägliga aviseringar som är svåra att skilja från legitima varningar [3].

Exempel

Åtgärder

• Förutom de åtgärder som beskrivs i Variant #1a kan händelsebegränsning användas för att minska mängden aviseringar från en enda källa.

Traditionella motsvarigheter

Icke-beständig DoS (Denial of Service)

Allvarlighet

Viktigt!

#2a riktad dataförgiftning

beskrivning

Angriparens mål är att kontaminera datormodellen som genereras i träningsfasen, så att förutsägelser om nya data modifieras i testningsfasen[1]. I riktade kontamineringsangrepp vill angriparen felklassificera specifika indata så att specifika åtgärder antingen utförs eller ignoreras.

Exempel

Att skicka AV-programvara som skadlig kod för att framtvinga en felklassificering som skadlig kod och stoppa användningen av riktad AV-programvara i klientsystem.

Åtgärder

• Definiera avvikelsesensorer så att de granskar datafördelningen varje dag och aviserar om det förekommer variationer

  – Mät variation i träningsdata dagligen, telemetri för skevning/avvikelse

• Indataverifiering, både sanerings- och integritetskontroll

• Inmatning av kontaminerade data utanför träningsindata. Det finns två huvudstrategier för att hantera det här hotet:

  – Datasanering/datavalidering: ta bort kontaminerade indata från träningsdata – Bagging-teknik för att bekämpa kontamineringsangrepp [14]

  – RONI-skydd (Reject On Negative Impact) [15]

  -Robust inlärning: Välj inlärningsalgoritmer som är robusta i närvaro av förgiftningsprover.

  -En sådan metod beskrivs i [21] där författarna tar itu med problemet med dataförgiftning i två steg: 1) introducerar en ny robust matrisfaktoriseringsmetod för att återställa det sanna underområdet och 2) ny robust principkomponentregression till beskära kontradiktoriska instanser baserat på den grund som återställs i steg (1). De definierar nödvändiga och tillräckliga villkor för att kunna återskapa det egentliga delutrymmet och jämför förväntad förlust enligt förutsägelsen med verkliga fakta.

Traditionella motsvarigheter

En värd som egentligen är en trojan som gör att angriparen kan gömma sig kvar i nätverket. Tränings- eller konfigurationsdata komprometteras och matas in/betraktas som tillförlitliga för modellgenerering.

Allvarlighet

Kritiskt

#2b urskillningslös dataförgiftning

beskrivning

Målet är att omintetgöra kvaliteten/integriteten i den datauppsättning som angrips. Många datauppsättningar är offentliga/icke-betrodda/icke-kurerade, vilket gör det ännu svårare att identifiera överträdelser av integriteten i sådana data. Att utan vetskap träna data som är komprometterade leder till en ”skräp in/skräp ut”-situation. När problemet har identifierats måste man undersöka hur stor skadan är och träna om eller sätta dessa data i karantän.

Exempel

Ett företag tränar sina modeller med en välkänd och betrodd webbplats som tillhandahåller data om oljeterminer. Dataleverantörens webbplats komprometteras genom en SQL-inmatningsattack. Angriparen kan godtyckligt kontaminera datauppsättningen utan att modellen har någon aning om att webbplatsens data har komprometterats.

Åtgärder

Samma som variant 2a.

Traditionella motsvarigheter

Autentiserad Denial of Service mot en resurs med stort värde

Allvarlighet

Viktigt!

#3 Modellinversionsattacker

beskrivning

De privata funktioner som används i maskininlärningsmodeller kan återställas [1]. Det handlar om att rekonstruera privata träningsdata som angriparen inte har åtkomst till och kallas ibland för ”hill climbing”-angrepp inom biometrivärlden [16, 17] I den här typen av angrepp hittar angriparen de indata som maximerar konfidensnivån som returneras, med hänsyn till klassificeringen som matchar målet [4].

Exempel

[4]

Åtgärder

• Stark åtkomstkontroll krävs för gränssnitt till modeller som har tränats med känsliga data.

• Frågor med frekvensbegränsning tillåts av modellen

• Implementera portar mellan användare/anropare och själva modellen genom att verifiera indata i alla föreslagna frågor, och avvisa allt som inte matchar modellens definition av korrekta indata och returnera den minsta mängden användbar information som behövs.

Traditionella motsvarigheter

Exponering av riktad, maskerad information

Allvarlighet

Klassificeras som standard som viktigt i SDL-felfältet, men känsliga eller personligt identifierbara data som extraheras klassificeras som kritiska.

#4 Angrepp på slutsatsdragning av medlemskap

beskrivning

Angriparen kan avgöra om en specifik datapost ingick i modellens träningsdatauppsättning eller inte [1]. Forskare kunde förutsäga patientens huvudprocedur (t.ex. kirurgi som patienten gick igenom) baserat på attributen (t.ex. ålder, kön, sjukhus) [1].

[12]

Åtgärder

Forskningsrapporter som bekräftar genomförbarheten av det här angreppet visar att differentiell integritet [4, 9] är en effektiv åtgärd. Det här är fortfarande ett nytt fält hos Microsoft och AETHER Security Engineering rekommenderar investering i forskning inom detta område. Sådan forskning bör fokusera på möjligheterna med differentiell integritet och utvärdera den praktiska nyttan för riskreducering, för att sedan utveckla metoder som gör att dessa skydd kan ärvas transparent på våra onlinetjänstplattformar, på ungefär samma sätt som kodkompilering i Visual Studio ger skydd med ”säkerhet som är aktiverad som standard”, som är transparent för såväl utvecklaren som användaren.

Användningen av ”neuron dropout”-metoden och modellstackning kan i viss mån effektivt minska riskerna. ”Neuron dropout”-metoden ökar inte bara återhämtningsförmågan i ett neuralt nätverk vid den här typen av angrepp, utan förbättrar även modellens prestanda [4].

Traditionella motsvarigheter

Datasekretess. Slutsatser dras om huruvida en datapunkt ingår i en träningsuppsättning, men själva träningsinformationen avslöjas inte

Allvarlighet

Detta är ett sekretessproblem, inte ett säkerhetsproblem. Den här typen av problem beskrivs i hotmodelleringsguiden eftersom domänerna överlappar varandra, men här är svarsåtgärderna knutna till sekretessöverväganden, inte till säkerhetsfrågor.

#5 Modellstöld

beskrivning

Angriparna återskapar den underliggande modellen genom att legitima frågor körs mot modellen. Den nya modellens funktioner är samma som den underliggande modellens funktioner [1]. När modellen återskapas kan den inverteras för att återskapa funktionsinformation eller dra slutsatser om träningsdata.

• Ekvationslösning – för en modell som returnerar klassannolikheter via API-utdata kan en angripare konstruera frågor för att få fram de okända variablerna i en modell.

• Sökvägsidentifiering – Ett angrepp som utnyttjar API-information för att extrahera de ”beslut” som fattas av ett träd när indata klassificeras [7].

• Överföringsangrepp – En angripare kan träna en lokal modell – t.ex. genom att skicka förutsägelsefrågor till målmodellen – och använda den för att konstruera manipulerade indata som sedan överförs till målmodellen [8]. Om din modell extraheras och visar sig vara sårbar för en viss typ av indatamanipulering så kan nya angrepp mot modellen i produktion utvecklas offline av angriparen som extraherade kopian av modellen.

Exempel

I scenarier där en maskininlärningsmodell används för att identifiera skadligt beteende, till exempel identifiering av skräppost, klassificering av skadlig kod och identifiering av avvikelser i nätverket, kan modellextrahering göra det lättare att komma runt skyddsmekanismer [7].

Åtgärder

Proaktiva/skyddande åtgärder

• Minimera eller förvräng informationen som returneras i förutsägelse-API:er med bibehållen användbarhet för legitima program [7].

• Definiera en välformulerad fråga för dina modellindata och returnera endast resultat som svar på välformulerade indata som matchar det formatet.

• Returnera avrundade konfidensvärden. De flesta legitima anropare behöver inte en precision på flera decimaler.

Traditionella motsvarigheter

Oautentiserad, skrivskyddad manipulering av systemdata; riktad information med stort värde

Allvarlighet

Klassificeras som viktigt i säkerhetskänsliga modeller, annars med en medelhög allvarlighetsgrad

#6 Omprogrammering av neuralt nät

beskrivning

Med hjälp av en specialkonstruerad fråga från en angripare kan maskininlärningssystem omprogrammeras till en uppgift som avviker från utvecklarens ursprungliga avsikt [1].

Exempel

Svaga åtkomstkontroller i ett API för ansiktsigenkänning som gör det möjligt för en tredje part att utnyttja appar som är utformade för att skada Microsofts kunder, till exempel en ”deep fakes”-generator.

Åtgärder

• Stark ömsesidig autentisering och åtkomstkontroll för klient-server<> till modellgränssnitt

• Borttagning av skadliga konton.

• Identifiera och kräv ett serviceavtal för dina API:er. Fastställ den godtagbara tiden för att åtgärda ett problem när det har rapporterats och se till att problemet inte längre kan reproduceras när serviceavtalet upphör att gälla.

Traditionella motsvarigheter

Detta är ett missbruksscenario. Oftast inaktiverar du bara den illvilliga användarens konto, utan att skapa någon säkerhetsincident.

Allvarlighet

Från viktigt till kritiskt

#7 Kontradiktoriskt exempel i den fysiska domänen (bits-atomer>)

beskrivning

Ett kontradiktoriskt exempel är en indata/fråga från en skadlig entitet som skickas med det enda syftet att vilseleda maskininlärningssystemet [1]

Exempel

Den här manipuleringen av indata kan förekomma i den fysiska världen. Till exempel kan en självkörande bil luras att köra förbi en stoppskylt när den belyses med en viss färg (manipulerade indata), så att bildigenkänningssystemet inte längre uppfattar skylten som en stoppskylt.

Traditionella motsvarigheter

Utökade privilegier, fjärrkörning av kod

Åtgärder

Dessa angrepp uppdagas när problem i maskininlärningslagret (data- och algoritmlagret under AI-styrt beslutsfattande) inte förhindrats. Precis som med andra program *eller* fysiska system kan lagret under målet alltid attackeras genom traditionella vektorer. Detta innebär att traditionell säkerhetspraxis är viktigare än någonsin, särskilt då lagret med olösta sårbarheter (data- och algoritmlagret) används mellan AI och traditionell programvara.

Allvarlighet

Kritiskt

#8 Skadliga ML-leverantörer som kan återställa träningsdata

beskrivning

En skadlig provider presenterar en algoritm med en bakdörr, genom vilken privata träningsdata hämtas in. De lyckades återskapa ansikten och text endast med hjälp av modellen.

Traditionella motsvarigheter

Riktad åtkomst till information

Åtgärder

Forskningsrapporter som bekräftar genomförbarheten av den här typen av angrepp visar att homomorfisk kryptering är en effektiv åtgärd. Det här är fortfarande ett nytt fält hos Microsoft och AETHER Security Engineering rekommenderar investering i forskning inom detta område. Sådan forskning bör fokusera på möjligheterna med homomorfisk kryptering och utvärdera den praktiska nyttan för riskreducering i scenarier med skadliga ML-as-a-Service-providers.

Allvarlighet

Klassificeras som viktigt om det handlar om personligt identifierbar information, annars med medelhög allvarlighetsgrad

#9 Attackerar ML-leveranskedjan

beskrivning

På grund av stora resurser (data + beräkning) som krävs för att träna algoritmer är den nuvarande metoden att återanvända modeller som tränats av stora företag och ändra dem något för aktuella uppgifter (t.ex. ResNet är en populär bildigenkänningsmodell från Microsoft). De här modellerna väljs ut till ett Model Zoo (Caffe är värd för populära bildigenkänningsmodeller). Vid den här typen av angrepp attackeras modellerna i Caffe, vilket innebär att de även blir skadliga för andra. [1]

Traditionella motsvarigheter

• Kompromettering av icke-säkerhetsrelaterat tredjepartsberoende

• Appbutik som ovetandes lagrar skadlig kod

Åtgärder

• Minimera tredjepartsberoenden för modeller och data då det är möjligt.

• Integrera dessa beroenden i hotmodelleringsprocessen.

• Dra nytta av stark autentisering, åtkomstkontroll och kryptering mellan första-, andra- och tredjepartssystem.

Allvarlighet

Kritiskt

#10 Maskininlärning för bakdörr

beskrivning

En tredje part som anlitats för att ta hand om träningen manipulerar träningsdata och levererar en modell med en trojan som framtvingar riktade felklassificeringar, t.ex. klassificering av ett virus som oskadligt [1]. Detta utgör en risk i ML-as-a-Service-modellgenereringsscenarier.

[12]

Traditionella motsvarigheter

• Kompromettering av säkerhetsrelaterat tredjepartsberoende

• Komprometterad programuppdateringsmekanism

• Kompromettering av certifikatutfärdare

Åtgärder

Reaktiva/defensiva identifieringsåtgärder

• Skadan är redan skedd när detta hot uppdagas, och det går inte att lita på modellen eller träningsdata som erhålls av den skadliga providern.

Proaktiva/skyddande åtgärder

• Träna alla känsliga modeller internt

• Katalogisera träningsdata eller se till att de kommer från en betrodd tredje part med strikta säkerhetsrutiner

• Modellera och simulera hot i interaktionen mellan MLaaS-providern och dina egna system

Svarsåtgärder

• Samma som för kompromettering av externt beroende

Allvarlighet

Kritiskt

#11 Utnyttja programvaruberoenden i ML-systemet

beskrivning

I den här typen av angrepp manipulerar angriparen INTE algoritmerna. I stället utnyttjas sårbarheter i programvaran, till exempel buffertspill eller skriptkörning mellan webbplatser [1]. Det är fortfarande lättare att kompromettera programvarulager under AI/ML än att angripa inlärningslagret direkt. Därför är de traditionella skyddsmetoder som beskrivs i Security Development Lifecycle ytterst viktiga.

Traditionella motsvarigheter

• Komprometterat beroende för programvara med öppen källkod

• Sårbarheter i webbservern (misslyckad XSS-, CSRF- eller API-indataverifiering)

Åtgärder

Arbeta med ditt säkerhetsteam och se till att följa rekommendationerna i Microsoft Security Development Lifecycle/Operational Security Assurance.

Allvarlighet

Varierar: upp till kritiskt beroende på typ av sårbarhet i traditionell programvara.

Referenslista

[1] Fellägen i Machine Learning, Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen och 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-Läckor: Modell- och dataoberoende slutsatsdragningsattacker och skydd för maskininlärningsmodeller, Salem, m.fl. https://arxiv.org/pdf/1806.01246v2.pdf

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

[6] Nicolas Papernot & 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 och 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 och 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] Vilda mönster: Tio år efter uppkomsten av Adversarial Machine Learning - NeCS 2019 Battista Biggioa, Fabio Roli

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

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

[15] Ett förbättrat utskottssvar på negationpåverkanförsvar Hongjiang Li och 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. Funktionspressning: Identifiera kontradiktoriska exempel i djupa neurala nätverk. 2018 Network and Distributed System Security Symposium. 18-21 February.

[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