AI-riskbedömning för ML-tekniker

Trots de övertygande orsakerna till att skydda ML-system fann Microsofts undersökning som omfattade 28 företag att de flesta branschutövare ännu inte har kommit till rätta med kontradiktorisk maskininlärning (ML). 25 av de 28 företagen uppgav att de inte har rätt verktyg på plats för att skydda sina ML-system. Dessutom letar de uttryckligen efter vägledning. Vi fann att bristen på förberedelser inte är begränsad till mindre organisationer – de sträcker sig från Fortune 500-företag, regeringar till ideella organisationer. Kunderna är medvetna om behovet av att skydda AI-system men vet helt enkelt inte hur.

Det här dokumentet är ett första steg för organisationer att utvärdera säkerhetsstatusen för sina AI-system. Men i stället för att lägga till ytterligare ett ramverk för organisationer att följa försökte vi tillhandahålla innehållet på ett sätt som kan kopplas till befintliga traditionella ramverk för riskbedömning av säkerhetsrisker.

Det finns tre mål för det här dokumentet:

• Ge ett omfattande perspektiv på AI-systemsäkerhet. Vi tittade på varje element i AI-systemets livscykel i en produktionsinställning: från datainsamling, databearbetning till modelldistribution. Vi har även redovisat AI-leveranskedjan och kontroller och principer för säkerhetskopiering, återställning och beredskapsplanering relaterade till AI-system.
• Beskriva hot mot kritiska AI-tillgångar och vägledning för att skydda dem. För att direkt hjälpa tekniker och säkerhetspersonal räknas hotbeskrivningen upp i varje steg i AI-systemskapandeprocessen. Därefter tillhandahåller vi en uppsättning riktlinjer som lägger över och förstärker befintliga metoder i samband med AI-system.
• Gör det möjligt för organisationer att utföra riskbedömningar för AI-säkerhet. Ramverket hjälper till att samla in information om det aktuella tillståndet för säkerheten för AI-system i en organisation, utföra gapanalys och spåra förloppet för säkerhetsstatusen.

Vi formulerade den tillsammans med intressenter i Microsoft, med representanter från Azure Security, Ansvarsfull AI-strategi inom teknik, Microsoft Security Response Center, Azure Security och AI, etik och effekter inom teknik och forskning (Aether).

Introduktion

Vi föreslår att du använder det här dokumentet för att starta diskussionen om att skydda AI-system som är anpassade till pågående informationssäkerhetsarbete och affärsmål. Dokumentet fokuserar på AI-system och inkludering av traditionella kontroller eftersom AI-system bygger på traditionell IT-infrastruktur.

Vi går igenom följande områden som rör AI-system.

Administrativa kontroller	beskrivning
Säkerhetsprinciper för maskininlärning	Kontroller och principer som rör dokumenterade principer som styr maskininlärning, artificiell intelligens och informationssäkerhet.

Tekniska kontroller	beskrivning
Datainsamling	Kontroller och principer som rör insamling, lagring och klassificering av data som används för maskininlärning och artificiell intelligens.
Databearbetning	Kontroller och principer som rör bearbetning och teknik av data som används för maskininlärning och artificiell intelligens.
Modellträning	Kontroller och principer som rör utformning, utbildning och validering av modeller.
Modelldistribution	Kontroller och principer som rör distribution av modeller och stödinfrastruktur.
Systemövervakning	Kontroller och principer som rör den pågående övervakningen av maskininlärningssystem.
Incidenthantering	Kontroller och principer som rör hur incidenter relaterade till AI-system hanteras.
Affärskontinuitet och haveriberedskap	Kontroller och principer som rör förlust av immateriella rättigheter genom modellstöld, försämring av tjänsten eller andra AI-specifika sårbarheter.

Vi har anpassat det befintliga ramverket för kontroller och principer från den populära standarden ISO27001:2013 och mappat det över AI-systemskapandeprocessen – från datainsamlingsfasen till att svara på hot mot AI-system. Organisationer kan ha vissa eller alla befintliga kontroller implementerade från ISO27001:2013 eller redan följer flera riskramverk (NIST 800-53, PCI-DSS, FedRamp osv.) som en del av befintliga informationssäkerhetsinsatser.

Om AI-systemen inte skyddas på ett tillfredsställande sätt ökar risken inte bara för de AI-system som behandlas i den här utvärderingen, utan mer generellt för hela informationstekniken och efterlevnadsmiljön.

Målet med det här dokumentet är inte att ersätta något av dessa befintliga insatser – utan att beskriva hur AI-system kan skyddas från utgångspunkten för befintliga verktyg och ramverk och utöka det till alla delar av AI-byggprocessen.

Vägledningen som anges här är inte normativ, eftersom det skulle kräva mer kontext, till exempel den underliggande plattformen, den underliggande datatypen och valet av algoritm. Om du är Azure Machine Learning-kund kan du läsa artikeln Företagssäkerhet och styrning.

Föreslagen allvarlighetsgrad, sannolikhet, påverkan

Alla kontroller är inte av avgörande betydelse för säkerheten i ett AI-system. För att prioritera arbetet korrekt bör därför varje kontroll klassificeras av organisationen med en allvarlighetsgrad som är relevant för affärspåverkan av att inte implementera en viss kontroll. En organisation kan välja att acceptera risken för en kritisk kontroll och i stället implementera en kompenserande kontroll för att minska risken. I slutändan är dessa klassificeringar till att hjälpa till att vägleda riskbaserat beslutsfattande snarare än att föreskriva aktiviteter.

Allvarlighet

Allvarlighetsgraden för en kompromiss beror på användningsfallet för AI-modellen. Lyckligtvis, om de data eller system som används var av avgörande betydelse innan maskininlärning integrerades, bör det förbli detsamma. På samma sätt, om modellen som används är "off-the-shelf" utan andra indata, beroende på vilken kontext modellen används i, är allvarlighetsgraden för en kompromiss sannolikt lägre. Tekniker som differentiell sekretess kan minska den potentiella effekten av en kompromiss. Den här kontexten skulle dock inte minska systemets, datas eller modellens allvarlighetsgrad. Vi rekommenderar att modeller skyddas med hjälp av en strategi för skydd på djupet i stället för att förlita sig på någon defensiv implementering.

Föreslagen allvarlighetsgrad

Föreslås som kritisk

• Om AI-modellen tränas på eller matar in känsliga personuppgifter, klassificerade data eller data som styrs av efterlevnadskrav som PCI, HIPAA, GLBA osv.
• Om AI-modellen används i ett affärskritiskt program eller system så att kompromisser skulle ha en stor negativ inverkan på verksamheten
• Om AI-modellen används i program där fysisk eller skada eller död är ett möjligt resultat
• Om AI-modellen används i ett system som stöder kritisk infrastruktur (till exempel vatten, kraft, hälsa)

Föreslås som hög

• Om AI-modellen tränas på eller matar in känsliga personuppgifter, konfidentiell information eller data som annars anses vara kritiska av organisationen
• Om en kompromiss med den här AI-modellen skulle ha stor men begränsad inverkan på verksamheten
• Om AI-modellen används i affärskritiska program eller system

Föreslås som medel

• Om AI-modellen tränas på en delmängd träningsdata som innehåller känsliga datatyper
• Om en kompromiss med den här AI-modellen skulle få konsekvenser för modeller som distribueras i produktion
• Om AI-modellen används i icke-kritiska men affärsinriktade program
• Om AI-modellen inte används i produktion men har information om produktionsmodeller

Föreslås som låg

• Om AI-modellen tränas på data som inte används i produktion
• Om AI-modellen inte används i produktion och inte har information om produktionsmodeller

Föreslås som information

• Om data är oklassificerade från en granskad källa
• Om AI-modellen inte används i produktion

Sannolikheten

Sannolikheten har två viktiga komponenter, modellens tillgänglighet och tillgängligheten för tekniker. För att minska risken för ett angrepp bör en organisation implementera kontroller som:

1. Ta bort attackytan eller gör attackytan svårare att räkna upp.
2. Se till att loggning och aviseringar fungerar som de är utformade för att säkerställa snabb lösning av problem.
3. Se till att alla stödsystem är uppdaterade med säkerhetskrav.

Kontrollerna kan omfatta att skapa slutpunkter, nätverkssegmentering eller hastighetsbegränsning. Särskild uppmärksamhet bör ägnas åt trafikflöden och nätverks- eller pipelinediagram, till exempel en angripare som komprometterar och externt riktad slutpunkt och arbetar bakåt genom en pipeline.

Påverkan

Påverkan är relaterad till påverkan på organisationen. Vi föreslår att du börjar bekanta dig med olika sätt som ML-system kan angripas på och överväga hur produktionsmodeller kan påverka organisationen. Mer information finns i artikeln Fellägen i Machine Learning. När den här förtrogenheten är klar kan den mappas till en allvarlighetsgradsmatris.

Allvarlighetsgradsmatris

Följande tabell är en grundläggande matris för risk- och sårbarhetsgrader för att komma igång med organisationer. Vi föreslår att du fyller upp en liknande kategorisering genom att sammankalla säkerhetsarkitekter, maskininlärningstekniker och ai-röda teammedlemmar.

Attacktyp	Sannolikheten	Påverkan	Exploabilitet
Extraktion	Högt	Låg	Hög
Skatteflykt	Högt	Medium	Högt
Slutledning	Medium	Medium	Medium
Inversion	Medium	Högt	Medium
Förgiftning	Låg	Hög	Låg

"Att utforma och utveckla säker AI är en hörnsten i AI-produktutveckling på BCG. I takt med att samhällets behov av att skydda våra AI-system blir allt tydligare kan tillgångar som Microsofts RAMVERK för ai-säkerhetsriskhantering vara grundläggande bidrag. Vi implementerar redan metodtips som finns i det här ramverket i de AI-system som vi utvecklar för våra kunder och är glada över att Microsoft har utvecklat och öppen källkod detta ramverk till förmån för hela branschen." — Jack Molloy, säkerhetstekniker, Boston Consulting Group

Grundläggande användning

Resten av dokumentet följer den här strukturen:

• En riskkontroll innehåller en beskrivning av vilket område kontrollen omfattar.
• Målet med kontrollen och vad den ska åstadkomma.
• En hotbeskrivning som ger en beskrivning av risken som minimeras.
• Vägledning för att implementera en kontroll. Vi förstår att inte all vägledning kan implementeras av legitima affärsskäl. Vi föreslår att du dokumenterar riktlinjer som inte kan implementeras.

Följande tabell är en kontroll som hämtas från riskbedömningen av AI-system, anteckningar läggs till för att beskriva varje del av en riskkategoristruktur.

Exempelkontroll

Så här läser du den

1. Datainsamling

Primär kategori

Kontroller och principer som rör insamling och lagring av data från alla källor som används för maskininlärning och artificiell intelligens.

Beskriver vilka kontroller i den här kategorin som täcker på hög nivå.

2. Datakällor

Kontrollkategori

Mål: För att säkerställa integriteten för data som samlas in som används för tränade modeller.

Bör beskriva den risk som minimeras med kontrollerna.

Hotuttryck: Data samlas in från ej betrodda källor som kan innehålla känsliga personuppgifter, andra oönskade data som kan påverka säkerheten för en modell eller som utgör efterlevnadsrisker för organisationen.

En instruktion som beskriver resultatet av att inte implementera kontrollen.

Kontroll: Data ska samlas in från betrodda källor. En lista över betrodda källor bör behållas och uppdateras. Godkännanden för insamling av ej betrodda data bör övervägas från fall till fall.

Specifikt verbiage som beskriver bästa praxis för kontrollen.

Riktlinjer:

1. Alla rimliga ansträngningar bör göras för att säkerställa att data kan vara betrodda innan du tränar en modell. Ej betrodda eller okända data kan medföra säkerhetsrisker senare i pipelinen.
2. Data som innehåller känsliga personuppgifter oavsett om de används för datavetenskapsändamål eller på annat sätt ska antingen rensas eller lagras och få åtkomst på lämpligt sätt.
3. Att samla in data utan hänsyn till kontexten kan resultera i datauppsättningar som innehåller olagliga data. Datainsamlingsinsatser bör vara medvetna om upphovsrättsskyddat material, dataintrång, osäkra slutpunkter som oavsiktligt läcker data.

Vägledning är rekommendationer för att uppfylla ovanstående kriterier. Vi tillhandahåller dem på ett produkt- och leverantörsoberoende sätt för att ge organisationer utrymme att lösa problemet på ett sätt som passar dem.

Säkerhetsbedömning för maskininlärning

Innan du startar

Syftet med den här utvärderingen är att hjälpa organisationer att formulera, spåra och åtgärda risker för affärsåtgärder som introduceras av AI-system. Den här utvärderingen bör användas för att:

1. Samla in information om det aktuella tillståndet för AI-säkerhet i organisationen.
2. Utför en gap-analys och skapa en översikt för att implementera rekommendationer.
3. Spåra säkerhetsförloppet genom att utföra den här utvärderingen årligen eller varannan år.

Om en organisation inte har något säkerhetsprogram är den här utvärderingen inte rätt plats att börja på. En organisation bör ha ett fungerande informationssäkerhetsprogram innan rekommendationer implementeras i den här utvärderingen. Mer information finns i artikeln Om Azures säkerhetsvägledning i Cloud Adoption Framework.

Datainsamling

Kontroller och principer som rör insamling och lagring av data från alla källor som används för maskininlärning och artificiell intelligens.

Mål: För att säkerställa integriteten för data som samlas in som används i AI-system.

Datakällor

Kontroll: Data ska samlas in från betrodda källor. En lista över betrodda källor bör behållas och uppdateras. Hanteringsgodkännanden för insamling av ej betrodda data bör övervägas från fall till fall. Om en ej betrodd källa godkänns ska den dokumenteras.

Hotuttryck: Data samlas in från ej betrodda källor som kan innehålla känsliga personuppgifter, andra oönskade data som kan påverka modellens prestanda eller medföra efterlevnadsrisker för organisationen.

Riktlinjer:

1. Indata ska verifieras och vara betrodda via hanteringsgodkännande innan de används i ett AI-system.
2. Data som samlas in för ett AI-system bör granskas före användning eller lagring.
3. Vid behov bör insamlade data rensas från oönskade poster.
4. Datakällan ska dokumenteras och bevaras med data.
5. Slutsatsdragningsdata som används för att träna en modell bör inte vara implicit betrodda och bör behandlas som nya data.
6. Datainsamlingen bör dokumenteras och granskas. Insamlade data ska ha en ägare som ansvarar för att de följer dokumenterade principer.

Typer av känsliga data

Kontroll: För att säkerställa att lagrade data för AI-system skyddas, spåras och klassificeras korrekt enligt dess känslighets- och användningsfall. Den här kontrollen omfattar lämpliga dataklassificeringsetiketter, åtkomstprinciper, licensinformation, beskrivande statistik, ursprungskälla och samlingsdatum.

Hotuttryck: Data som används i AI-system används, lagras eller används på ett olämpligt sätt på grund av brist på obligatoriska attribut, metadata eller dokumentation.

Riktlinjer:

1. Utveckla en dataprincip som omfattar sekretess och skydd av känsliga datatyper och kommunicera principen till all personal som är involverad i användningen eller skapandet av AI-system.
2. Implementera tränings- och distributionspipelines som skyddar konfidentialiteten och integriteten för de data som används i AI-system.

Datalagring

Kontroll: Data bör lagras korrekt enligt en dokumenterad klassificeringsprocess. Datauppsättningar bör indexeras och betraktas som en tillgång som omfattas av principer för tillgångshantering och åtkomstkontroll.

Hotuttryck: Data lagras osäkert och kan manipuleras eller ändras av obehöriga parter eller system. Data är inte korrekt klassificerade, vilket leder till att konfidentiell information eller känsliga personuppgifter avslöjas.

Vägledning

1. Se till att utveckling eller AI-forskningssystem eller -konton inte har åtkomst till produktionsdatabaser och vice versa.
2. Data som används i AI-system ska klassificeras och skyddas enligt en dokumenterad klassificeringsprincip.
3. Data som används i AI-system spåras under en dokumenterad princip för tillgångshantering.
4. Data som används för känsliga AI-användningsfall lagras i godkända och hanterade system.
5. Åtkomst till data bör granskas och användare som begär åtkomst bör genomgå en formell åtkomstkontrollprocess som omfattar godkännande av hantering.
6. Data som används i maskininlärningsprocesser bör inte exponeras för Internet.
7. Data som hämtas från Internet (eller andra ej betrodda källor) bör genomgå en filtreringsprocess som omfattar godkännande av hantering.
8. Datauppsättningar bör vara versionshanterade med formella ändringskontrollprocesser på plats.

Dataåtkomst

Kontroll: Datauppsättningar bör spåras och verifieras korrekt via kryptografisk hash före användning.

Hotuttryck: Datauppsättningar ändras utan auktorisering.

Riktlinjer:

1. Rollbaserad åtkomstkontroll för datauppsättningar bör tillämpas.
2. Utför regelbundna åtkomstgranskningar för att säkerställa att konton med åtkomst till datauppsättningar ska ha åtkomst till datauppsättningar. Kontrollera att varje konto fungerar inom normala gränser.
3. Om en central spårningsplattform inte används bör åtkomst till data via rådataåtkomstloggar granskas för ändamålet. Kontrollera att varje konto fungerar inom normala gränser.
4. Tredjepartsresursleverantörer, entreprenörer eller andra externa parter bör inte ha överskott eller olämplig åtkomst till ett företags tillgångar för tåg-/testdata utan kontrakt på plats.

Dataintegritet

Kontroll: Datauppsättningar bör vara betrodda och förbli betrodda under hela AI-systemets livscykel.

Hotuttryck: Datauppsättningar ändras under AI-livscykeln utan möjlighet att granska eller spåra ändringar.

Riktlinjer:

1. Datauppsättningar bör identifieras unikt så att obehöriga ändringar i en godkänd datauppsättning skulle orsaka en granskning av datamängden.
2. Datauppsättningar och deras kryptografiska beskrivningar ska spåras på en central plats. Åtkomst till datamängden bör granskas.
3. Ändringar i datauppsättningen bör innehålla uppdaterade kryptografiska beskrivningar och hanteringsgodkännande innan de skickas till den centrala spårningstjänsten.

Databehandling

Kontroller och principer som rör bearbetning av data som används för maskininlärning och artificiell intelligens.

Syfte: Att säkerställa säker bearbetning av data från dess rådata till en mellanhandsblankett som är redo för utbildning.

Bearbeta pipelines

Kontroll: Bearbetningspipelines bör vara tillräckligt skyddade.

Hotuttryck: En hotskådespelare kan göra obehöriga ändringar i systemet genom att ändra pipelines för databearbetning.

Riktlinjer:

1. Alla data som rör sig genom ett produktionssystem är inte relevanta för datavetenskapsinsatser. Det är viktigt att bara parsa ut nödvändiga data och se till att alla data som flyttas från en säker produktionsinställning till en utvecklingsinställning spåras korrekt. Tänk på att vissa typer av data kanske inte kan flyttas till en utvecklingsmiljö. Datavetenskap kan behöva utföras i en säker mellanliggande miljö.
2. Korrekt granskning av dataåtkomst under hela livscykeln för databehandling är viktigt. Utan separata konton kan det inte finnas någon tillräcklig granskning av åtkomsten. Dessutom kan förmågan att svara på en incident inte inträffa utan att påverka affärsprocesser. Om ett enskilt konto komprometteras skulle det leda till att alla data lämnar den säkra produktionsmiljön.
3. Datavetenskapsprocesser kan kräva resurser som ligger utanför en strikt efterlevnadsgräns.
4. Datavetenskapsprocesser bör alltid vara kompatibla med befintliga krav. Den här processen kan omfatta att flytta datavetenskapsresurser och processer till en kompatibel miljö.
5. Data bör spåras genom hela livscykeln. Den här spårningen omfattar delmängder av större datamängder. Det bör krävas att en modell kan spåras tillbaka till de data som den har tränats på. Dessutom bör en kopia av dessa data finnas i sin helhet.

Datamängdens bländare

Kontroll: För att säkerställa delmängder (till exempel tidsmässiga, kategoriska sektorer) av data som ingår i modellskapandet och hur kan det medföra säkerhetsrisker (integritetsläckage, förgiftning/integritet via överanalys av feedback osv.).

Hotuttryck: Hotskådespelare kan återställa delar av data genom att rekonstruera/återställa delmängder av data.

Riktlinjer:

1. Delmängder av data är själva datauppsättningarna. Dessa underuppsättningar måste ha samma metadata kopplade till sig som den överordnade datamängden och bör granskas på liknande sätt för känsliga datatyper.
2. Beroende på principer för maskininlärningsmetoder (serviceavtal, bias-mått osv.) bör alla angivna datamängder (inklusive delmängder) uppfylla en minsta dokumenterad standard som omger dessa mått om de ska användas i modellskapandet. Metadata ska alltid kopplas till datauppsättningen.
3. Alla datauppsättningar som bryter mot befintliga principer bör ha ett dokumenterat undantag som godkänts av hanteringen. Inkluderad i undantaget bör vara en dokumenterad orsak till undantaget utöver de metadata som krävs.
4. Alla data som används för modellskapande bör spåras på en central plats. Data bör vara granskningsbara när som helst. Dessutom bör modeller som befinns tränas på ospårade data hämtas från produktion tills de matchas med en känd datauppsättning med nödvändiga metadata.
5. Datauppsättningar bör ha rätt version så att alla metadata uppdateras och användarna av data förstår innehållet och de statistiska egenskaperna. Vid behov bör hanteringsgodkännande för känsliga användningsfall krävas.

Modellträning

Kontroller och principer som rör träning av modeller och algoritmer.

Modelldesign

Kontroll: Modellträningskoden granskas av en ansvarig part.

Hotuttryck: Felaktig kod eller säkerhetsrisker i modellkoden medför risker för tillgänglighet, integritet eller konfidentialitet.

Riktlinjer:

1. Modelldesign och forskning bör ske i lämplig miljö. Modelldesign och arkitektur kan ha en stor effekt på modellens effekt. Produktionsmiljöer är inte platsen för forskning eller för att testa icke-godkända påståenden om effektiviteten hos en design.
2. Modellval för ett produktionssystem ska granskas och godkännas av ledningen. Den här processen bör ske tidigt i utvecklingsfasen och bör spåras via alla tillgängliga mekanismer (Excel, DevOps, Git osv.). Undantag ska dokumenteras.
3. Modeller är ofta domänspecifika och det bör finnas tillräcklig dokumentation som medföljer modellen under hela dess användning i en organisation.
4. Se till att modellmetadata är tillgängliga för användare och att icke godkända användningar av modeller dokumenteras och framtvingas. Det är acceptabelt för en användare att finjustera en befintlig modell så länge nya metadata bifogas och spåras korrekt.

Modellträning

Kontroll: Kriteriet för modellval (mått- och holdout-uppsättningar) efterliknar naturlig drift och eventuella kontradiktoriska villkor som kan förväntas vid distributionen.

Hotuttryck: En modell som tränas under idealiska förhållanden kommer sannolikt att vara skör när den distribueras i adversariella inställningar.

Vägledning

1. Utbildnings- och valideringsuppsättningar bör respektera naturliga temporala beroenden. För klassificerare av skadlig kod bör en valideringsuppsättning till exempel endast innehålla programvaruversioner som är senare än de som finns i träningsuppsättningen.
2. Lägg uttryckligen till modell robusthet genom att utöka datauppsättningar med vanliga skador som rimligen kan identifieras i naturen.
3. Träna uttryckligen mot värsta tänkbara förhållanden med hjälp av kontradiktorisk omträning.
4. Spåra experiment och tillhörande meta.

Modellval

Modellval består av att välja en modell från en uppsättning kandidater, där varje kandidat har en unik uppsättning modellparametrar, träningsalgoritm och träning av hyperparametrar. Urvalskriteriet för den vinnande modellen baseras ofta på ett enda kvantifierbart mått (till exempel minsta förlust, maximal identifieringshastighet) mätt på en gemensam holdout-datauppsättning eller som medelvärde för en K-faldig valideringsuppsättning.

Kontroll: Modelldesign och träningsalgoritm innehåller explicit eller implicit modell regularisering.

Hotuttryck: Modeller är överanpassade till en tränings- och/eller enstaka valideringsdatauppsättning och är mer sårbara för fellägen.

Riktlinjer:

1. Om det är beräkningsbart bör korsvalidering av K-vik användas för att förhindra överanpassning till en enda holdout-uppsättning.
2. Kontrollera att de valda modellerna fungerar bra på olika holdout-uppsättningar för att verifiera att de inte har överanpassats.
3. Se till att processer finns.

Versionshantering för modell

Kontroll: Modeller tränas kontinuerligt om när nya träningsdata flödar in i träningspipelines.

Hotuttryck: En incident inträffar men den aktuella modellen kan inte finnas för undersökning.

Riktlinjer:

1. Versionsmodeller så att varje gång en modell tränas tilldelas den en ny version. Kvalificerare som my_model_dev_1.1 eller my_model_prod_1.1 bör användas för att avgränsa produktion från förproduktionsmodeller. Den här versionshantering hjälper till att isolera problem med antingen ett produktions- eller förproduktionsproblem. Referera till befintliga säkra SDL-processer eller principer.

Modelldistribution

Kontroller och principer som rör distribution av modeller, algoritmer och stödjande infrastruktur.

Säkerhetstest

Kontroll: Modeller som sätts i produktion är tillräckligt säkra.

Hotuttryck: AI-system testas inte tillräckligt för sårbarheter före distributionen.

Riktlinjer:

1. Formella kriterier för godkännandetestning har inte definierats och dokumenterats för nya AI-system, uppgraderingar och nya versioner.
2. Nya AI-system, uppgraderingar eller nya versioner bör implementeras med formell testning.
3. Automatiserade verktyg bör användas för att testa informationssystem, uppgraderingar eller nya versioner.
4. Testmiljön bör likna den slutliga produktionsmiljön.
5. Frekvensen, omfånget och metoderna för oberoende säkerhetsgranskningar bör dokumenteras.

Säkerhets- och efterlevnadsgranskning

Kontroll: Robust hantering av det underliggande nätverket är nyckeln till att skydda ML-systemet och infrastrukturen.

Hotuttryck: Kompromettering av ML-systemet genom åtkomst till det oskyddade nätverket.

Riktlinjer:

1. Gatewayenheter till ML-system ska konfigureras för att filtrera trafik mellan domäner och blockera obehörig åtkomst.
2. Relevanta lagstadgade, regelmässiga och avtalsmässiga krav bör uttryckligen definieras och dokumenteras och hanteras, tillsammans med särskilda kontroller och individuella ansvarsområden.
3. Riktlinjer för säker konfiguration bör också dokumenteras, implementeras eller granskas.
4. Kriteriet för uppdelning av ML-nätverk i domäner bör vara förenligt med organisationens åtkomstkontrollprincip eller åtkomstkrav för organisationen.
5. Mekanismer som säker gateway, VPN, routning för ML-system bör implementeras tillräckligt för att möjliggöra en graderad uppsättning kontroller.
6. Användare och ML-tekniker bör använda eller följa kraven för implementering av kontroller för att korrekt separera och begränsa användningen av offentligt tillgängliga system, interna nätverk och kritiska tillgångar.

Systemövervakning

Kontroller och policyer som rör kontinuerlig övervakning av maskininlärningssystem och stödinfrastruktur.

Loggar och logggranskning

Kontroll: Loggning och övervakning är avgörande för ML-system av säkerhetsskäl.

Hotuttryck: Under en undersökning hittas inte loggar för ML-system.

Riktlinjer:

1. Loggning och övervakning bör ske konsekvent i alla AI-system och deras komponenter, inklusive lagring, pipelines, produktionsservrar osv.
2. Händelse- och säkerhetsloggar bör granskas regelbundet för onormalt beteende.
3. Konsoliderade rapporter och aviseringar om systemaktivitet ska genereras och granskas av hantering eller en säkerhetsrepresentant.

Incidenthantering

Roller och ansvar

Kontroll: Säkerhetsloggar ska samlas in på en central plats.

Hotuttryck: Under en undersökning har säkerhetsanalytiker inte någon formaliserad spelbok.

Riktlinjer:

1. Organisationer för måste följa en formell process för att rapportera AI-systemincidenter i samband med förlust av tjänst, förlust av utrustning, förlust av anläggningar, systemfel, systemöverbelastningar, mänskliga fel, inkompatibilitet med principer eller riktlinjer, brott mot fysisk säkerhet, okontrollerade systemändringar, programvarufel, maskinvarufel och åtkomstöverträdelser.
2. Formella förfaranden för incidenthantering och eskalering bör utvecklas för att dokumentera åtgärder som vidtas när en rapport om en informationssäkerhetshändelse tas emot.
3. Procedurer för incidenthantering bör testas regelbundet och spåra svarsmått.

Planering av affärskontinuitet

Planering, granskning och resultat

Kontroll: Se till att ML-system kan repareras och återställas efter en incident.

Hotuttryck: Incidenter orsakar beständiga sekretess-, integritets- eller tillgänglighetsproblem för kritiska ML-system.

Riktlinjer:

1. Viktiga AI-tillgångar bör identifieras och inventeras.
2. Organisationen bör utveckla en process för affärskontinuitetsplan (BCP) eller haveriberedskap (DR) inför attacker mot AI-system.
3. Organisationen måste identifiera de risker som är associerade med effekten av att förlora kritiska AI-system till attacker.
4. Organisationer måste ha en verksamhetskontinuitetstestning som körs enligt ett upprepat schema för kritiska AI-system.

Referenser

• ISO 27001 Bilaga A-kontroller – Översikt (isms.online)
• Officiell webbplats för PCI Security Standards Council
• Fellägen i Machine Learning
• Hotmodellering av AI/ML-system och beroenden
• AI/ML-pivoter till felsökningsfältet för säkerhetsutvecklingslivscykel
• Företagssäkerhet och styrning

Om du har frågor, kommentarer eller feedback kontaktar du atml@microsoft.com.

Ladda ned en PDF av det här dokumentet från vår GitHub-lagringsplats.