AI-risicoanalyse voor ML-technici

Ondanks de overtuigende redenen om ML-systemen te beveiligen, heeft microsoft's enquête over 28 bedrijven vastgesteld dat de meeste vakbeoefenaars nog steeds te maken hebben met adversarial machine learning (ML). Vijfentwintig van de 28 bedrijven gaven aan dat ze niet over de juiste tools beschikken om hun ML-systemen te beveiligen. Bovendien zijn ze expliciet op zoek naar richtlijnen. We hebben vastgesteld dat het gebrek aan voorbereiding niet beperkt is tot kleinere organisaties: ze variëren van Fortune 500 bedrijven, overheden tot non-profitorganisaties. Klanten erkennen de noodzaak om AI-systemen te beveiligen, maar weten gewoon niet hoe.

Dit document is een eerste stap voor organisaties om de beveiligingsstatus van hun AI-systemen te beoordelen. Maar in plaats van nog een framework toe te voegen dat organisaties kunnen volgen, hebben we geprobeerd de inhoud op een manier te bieden die kan worden aangepast aan bestaande traditionele frameworks voor beveiligingsrisico's.

Er zijn drie doelen voor dit document:

• Een uitgebreid perspectief bieden voor ai-systeembeveiliging. We hebben elk element van de levenscyclus van het AI-systeem in een productie-instelling bekeken: van gegevensverzameling, gegevensverwerking tot modelimplementatie. We hebben ook rekening gehouden met de AI-toeleveringsketen en de controles en beleidsregels met betrekking tot back-up, herstel en planning voor onvoorziene gebeurtenissen met betrekking tot AI-systemen.
• Bedreigingen voor kritieke AI-assets en richtlijnen om ze te beveiligen. Om technici en beveiligingsprofessionals rechtstreeks te helpen, hebben we de bedreigingsinstructie geïnventariseerd bij elke stap van het proces voor het bouwen van AI-systemen. Vervolgens bieden we een set richtlijnen die bestaande procedures in de context van AI-systemen overlappen en versterken.
• Organisaties in staat stellen om AI-beveiligingsrisicobeoordelingen uit te voeren. Het framework helpt bij het verzamelen van informatie over de huidige beveiligingsstatus van AI-systemen in een organisatie, het uitvoeren van een hiaatanalyse en het bijhouden van de voortgang van het beveiligingspostuur.

We hebben het geformuleerd in combinatie met belanghebbenden in Microsoft, met vertegenwoordigers van Azure Security, Responsible AI Strategy in Engineering, Microsoft Security Response Center, Azure Security en AI, Ethics and Effects in Engineering and Research (Aether).

Inleiding

We raden u aan dit document te gebruiken om de discussie te starten over het beveiligen van AI-systemen die zijn afgestemd op de voortdurende inspanningen op het gebied van informatiebeveiliging en bedrijfsdoelstellingen. Het document is gericht op AI-systemen en het opnemen van traditionele besturingselementen omdat AI-systemen zijn gebouwd op traditionele IT-infrastructuur.

We behandelen de volgende gebieden met betrekking tot AI-systemen.

Administratieve beheermaatregelen	Beschrijving
Beveiligingsbeleid voor Machine Learning	Controles en beleidsregels met betrekking tot de gedocumenteerde beleidsregels die machine learning, kunstmatige intelligentie en informatiebeveiliging bepalen.

Technische besturingselementen	Beschrijving
Gegevensverzameling	Besturingselementen en beleidsregels met betrekking tot de verzameling, opslag en classificatie van gegevens die worden gebruikt voor machine learning en kunstmatige intelligentie.
Gegevensverwerking	Controles en beleidsregels met betrekking tot de verwerking en engineering van gegevens die worden gebruikt voor machine learning en kunstmatige intelligentie.
Modeltraining	Controles en beleidsregels met betrekking tot het ontwerpen, trainen en valideren van modellen.
Modelimplementatie	Controles en beleidsregels met betrekking tot de implementatie van modellen en ondersteunende infrastructuur.
Systeembewaking	Controles en beleidsregels met betrekking tot de doorlopende bewaking van machine learning-systemen.
Incidentenbeheer	Besturingselementen en beleidsregels met betrekking tot de manier waarop incidenten met betrekking tot het AI-systeem worden verwerkt.
Zakelijke continuïteit en herstel na noodgevallen	Controles en beleidsregels met betrekking tot verlies van intellectueel eigendom door model stelen, degradatie van de service of andere ai-specifieke beveiligingsproblemen.

We hebben het bestaande framework van controles en beleidsregels aangepast aan de populaire ISO27001:2013-standaard en toegewezen aan het proces voor het bouwen van AI-systemen, van de fase voor gegevensverzameling tot het reageren op bedreigingen voor AI-systemen. Organisaties hebben mogelijk enkele of alle bestaande controles geïmplementeerd vanuit ISO27001:2013 of voldoen al aan verschillende risicoframeworks (NIST 800-53, PCI-DSS, FedRamp, enzovoort) als onderdeel van bestaande inspanningen voor gegevensbeveiliging.

Het niet adequaat beveiligen van AI-systemen verhoogt het risico voor niet alleen de AI-systemen die in deze evaluatie worden behandeld, maar meer in het algemeen voor de volledige informatietechnologie en nalevingsomgeving.

Het doel van dit document is niet om een van deze bestaande inspanningen te vervangen, maar om het beveiligen van AI-systemen te beschrijven vanuit het uitkijkpunt van bestaande hulpprogramma's en frameworks en deze uit te breiden naar alle onderdelen van het AI-bouwproces.

De hier vermelde richtlijnen zijn niet prescriptief, omdat hiervoor meer context nodig is, zoals het onderliggende platform, het onderliggende gegevenstype en de keuze van het algoritme. Als u een Azure Machine Learning-klant bent, raadpleegt u het artikel Enterprise-beveiliging en -governance.

Voorgestelde ernst, waarschijnlijkheid, impact

Niet alle besturingselementen zijn van cruciaal belang voor de beveiliging van een AI-systeem. Daarom moet elk besturingselement worden beoordeeld door de organisatie met een ernstclassificatie die relevant is voor de impact van het bedrijf van het niet implementeren van een bepaald besturingselement om een goede prioriteit te geven. Een organisatie kan ervoor kiezen om het risico van een kritieke controle te accepteren en in plaats daarvan een compenserende controle te implementeren om het risico te verlagen. Uiteindelijk zijn deze beoordelingen om te helpen bij het nemen van beslissingen op basis van risico's in plaats van activiteiten voor te schrijven.

Ernst

De ernst van een inbreuk is afhankelijk van de use-case van het AI-model. Als de gebruikte gegevens of systemen van cruciaal belang waren voordat machine learning werd geïntegreerd, zou dit hetzelfde moeten blijven. Als het gebruikte model 'kant-en-klaar' is zonder andere invoer, is de ernst van een inbreuk waarschijnlijk lager, afhankelijk van de context waarin het model wordt gebruikt. Technieken zoals differentiële privacy kunnen de mogelijke impact van een inbreuk verminderen. Deze context zou echter niet de kritiek van het systeem, de gegevens of het model verminderen. We raden u aan om modellen te beveiligen met behulp van een diepgaande strategie voor verdediging in plaats van te vertrouwen op een defensieve implementatie.

Voorgestelde ernstniveau

Voorgesteld als kritiek

• Als het AI-model wordt getraind of gevoelige persoonlijke gegevens, geclassificeerde gegevens of gegevens opneemt die onder nalevingsvereisten zoals PCI, HIPAA, GLBA, enzovoort vallen.
• Als het AI-model wordt gebruikt in een bedrijfskritieke toepassing of systeem, waardoor inbreuk een grote negatieve invloed zou hebben op bedrijfsactiviteiten
• Als het AI-model wordt gebruikt in toepassingen waarbij fysieke of schade of dood een mogelijk resultaat is
• Als het AI-model wordt gebruikt in een systeem dat kritieke infrastructuur ondersteunt (bijvoorbeeld water, stroom, status)

Voorgesteld als hoog

• Als het AI-model wordt getraind op of gevoelige persoonlijke gegevens, vertrouwelijke informatie of gegevens opneemt die anders als kritiek door de organisatie worden beschouwd
• Als inbreuk op dit AI-model grote maar beperkte gevolgen zou hebben voor bedrijfsactiviteiten
• Als het AI-model wordt gebruikt in bedrijfskritieke toepassingen of systemen

Voorgesteld als normaal

• Als het AI-model wordt getraind op een subset van trainingsgegevens die gevoelige gegevenstypen bevatten
• Als inbreuk op dit AI-model gevolgen zou hebben voor modellen die in productie zijn geïmplementeerd
• Als het AI-model wordt gebruikt in niet-kritieke maar zakelijke toepassingen
• Als het AI-model niet wordt gebruikt in productie, maar informatie bevat met betrekking tot productiemodellen

Voorgesteld als laag

• Als het AI-model wordt getraind op gegevens die niet in productie worden gebruikt
• Als het AI-model niet wordt gebruikt in productie en geen informatie over productiemodellen bevat

Voorgesteld als informatie

• Als de gegevens niet zijn geclassificeerd vanuit een gecontroleerde bron
• Als het AI-model niet wordt gebruikt in productie

Likelihood

De kans bestaat uit twee belangrijke onderdelen, de beschikbaarheid van het model en de beschikbaarheid van technieken. Om de kans op een aanval te verminderen, moet een organisatie besturingselementen implementeren die:

1. Verwijder de kwetsbaarheid voor aanvallen of maak de kwetsbaarheid voor aanvallen moeilijker te inventariseren.
2. Zorg ervoor dat logboekregistratie en waarschuwingen werken zoals ontworpen om snelle oplossing van problemen te garanderen.
3. Zorg ervoor dat alle ondersteunende systemen up-to-date zijn met beveiligingsvereisten.

Besturingselementen kunnen betrekking hebben op gatingseindpunten, netwerksegmentatie of snelheidsbeperking. Er moet speciale aandacht worden besteed aan verkeersstromen en netwerk- of pijplijndiagrammen, bijvoorbeeld een aanvaller die in gevaar komt en een extern eindpunt in gevaar brengt en achteruit werkt via een pijplijn.

Impact

Impact is gerelateerd aan gevolgen voor de organisatie. We raden u aan om vertrouwd te raken met verschillende manieren waarop ML-systemen kunnen worden aangevallen en bedenken hoe productiemodellen van invloed kunnen zijn op de organisatie. Zie het artikel Foutmodi in Machine Learning voor meer informatie. Zodra deze vertrouwdheid is voltooid, kan deze worden toegewezen aan een ernstmatrix.

Ernstmatrix

De volgende tabel is een basismatrix voor risico's en ernst van beveiligingsproblemen om organisaties op weg te helpen. We raden u aan om een vergelijkbare categorisatie in te vullen door beveiligingsarchitecten, machine learning-engineers en AI red-teamleden bijeen te roepen.

Aanvalstype	Likelihood	Impact	Exploitabiliteit
Extractie	Hoog	Laag	Hoog
Evasion	Hoog	Gemiddeld	Hoog
Gevolgtrekking	Gemiddeld	Gemiddeld	Gemiddeld
Inversie	Gemiddeld	Hoog	Gemiddeld
Vergiftiging	Laag	Hoog	Beperkt

"Het ontwerpen en ontwikkelen van beveiligde AI is een hoeksteen van ai-productontwikkeling bij BCG. Naarmate de maatschappelijke noodzaak om onze AI-systemen te beveiligen steeds duidelijker wordt, kunnen assets zoals het AI Security Risk Management Framework van Microsoft fundamentele bijdragen zijn. We implementeren al best practices die in dit framework zijn gevonden in de AI-systemen die we ontwikkelen voor onze klanten en zijn verheugd dat Microsoft dit framework heeft ontwikkeld en open source heeft ontwikkeld voor het voordeel van de hele branche." — Jack Molloy, Senior Security Engineer, Boston Consulting Group

Basisgebruik

De rest van het document volgt deze structuur:

• Een risicobeheersing bevat een beschrijving van het gebied waarop het besturingselement betrekking heeft.
• Het doel van de controle en wat het moet bereiken.
• Een bedreigingsverklaring die een beschrijving geeft van het risico dat wordt beperkt.
• Richtlijnen voor het implementeren van een besturingselement. We begrijpen dat niet alle richtlijnen kunnen worden geïmplementeerd om legitieme zakelijke redenen. We raden u aan richtlijnen te documenteren die niet kunnen worden geïmplementeerd.

De volgende tabel is een besturingselement dat wordt opgehaald uit de risicoanalyse van AI-systemen. Notities worden toegevoegd om elk onderdeel van een structuur van risicocategorieën te beschrijven.

Voorbeeld van besturingselement

Lezen

1. Gegevensverzameling

Primaire categorie

Controles en beleidsregels met betrekking tot het verzamelen en opslaan van gegevens uit alle bronnen die worden gebruikt voor machine learning en kunstmatige intelligentie.

Beschrijft welke besturingselementen in deze categorie op hoog niveau worden behandeld.

2. Gegevensbronnen

Besturingselementcategorie

Doelstelling: Om de integriteit te waarborgen van verzamelde gegevens die worden gebruikt voor getrainde modellen.

Beschrijf het risico dat met de besturingselementen wordt beperkt.

Bedreigingsverklaring: gegevens worden verzameld uit niet-vertrouwde bronnen die gevoelige persoonsgegevens kunnen bevatten, andere ongewenste gegevens die van invloed kunnen zijn op de beveiliging van een model of die nalevingsrisico's voor de organisatie kunnen opleveren.

Een instructie die het resultaat beschrijft van het niet implementeren van het besturingselement.

Beheer: gegevens moeten worden verzameld uit vertrouwde bronnen. Een lijst met vertrouwde bronnen moet worden bewaard en bijgewerkt. Goedkeuringen voor het verzamelen van niet-vertrouwde gegevens moet per geval worden overwogen.

Specifieke verbiage die de best practice voor het besturingselement beschrijft.

Richtlijnen:

1. Alle redelijke inspanningen moeten worden gedaan om ervoor te zorgen dat gegevens kunnen worden vertrouwd voordat een model wordt getraind. Niet-vertrouwde of onbekende gegevens kunnen later in de pijplijn beveiligingsproblemen veroorzaken.
2. Gegevens die gevoelige persoonsgegevens bevatten, ongeacht of ze worden gebruikt voor data science-doeleinden of anderszins, moeten worden opgeschoond of opgeslagen en op de juiste manier worden geopend.
3. Het verzamelen van gegevens zonder overweging voor de context kan leiden tot gegevenssets die illegale gegevens bevatten. Het verzamelen van gegevens moet rekening houden met het auteursrechtelijke materiaal, gegevensschendingen, onbeveiligde eindpunten die per ongeluk gegevens lekken.

Richtlijnen zijn aanbevelingen voor het voldoen aan de bovenstaande criteria. We bieden ze op een agnostische manier aan producten en leveranciers om organisaties ruimte te geven om het probleem op te lossen op een manier die zinvol is voor hen.

Machine learning-beveiligingsevaluatie

Voordat u aan de slag gaat

Het doel van deze evaluatie is organisaties te helpen bij het formuleren, volgen en oplossen van risico's voor bedrijfsactiviteiten die door AI-systemen worden geïntroduceerd. Deze evaluatie moet worden gebruikt voor het volgende:

1. Verzamel informatie over de huidige status van AI-beveiliging binnen de organisatie.
2. Voer een gap-analyse uit en bouw een roadmap voor het implementeren van aanbevelingen.
3. Houd de voortgang van de beveiliging bij door deze evaluatie jaarlijks of bi-jaarlijks uit te voeren.

Als een organisatie geen beveiligingsprogramma heeft, is deze evaluatie niet de plek om te beginnen. Een organisatie moet een functionerend informatiebeveiligingsprogramma hebben voordat aanbevelingen in deze evaluatie worden geïmplementeerd. Zie het artikel Azure-beveiligingsrichtlijnen in het Cloud Adoption Framework voor meer informatie.

Gegevens verzamelen

Controles en beleidsregels met betrekking tot het verzamelen en opslaan van gegevens uit alle bronnen die worden gebruikt voor machine learning en kunstmatige intelligentie.

Doelstelling: Om de integriteit te waarborgen van gegevens die worden verzameld in AI-systemen.

Gegevensbronnen

Beheer: gegevens moeten worden verzameld uit vertrouwde bronnen. Een lijst met vertrouwde bronnen moet worden bewaard en bijgewerkt. Beheergoedkeuringen voor het verzamelen van niet-vertrouwde gegevens moeten per geval worden overwogen. Als een niet-vertrouwde bron is goedgekeurd, moet deze worden gedocumenteerd.

Bedreigingsverklaring: gegevens worden verzameld uit niet-vertrouwde bronnen die gevoelige persoonsgegevens kunnen bevatten, andere ongewenste gegevens die van invloed kunnen zijn op de prestaties van een model of die nalevingsrisico's voor de organisatie kunnen opleveren.

Richtlijnen:

1. Invoergegevens moeten worden gevalideerd en vertrouwd via beheergoedkeuring voordat ze worden gebruikt in een AI-systeem.
2. Gegevens die voor een AI-systeem worden verzameld, moeten worden gecontroleerd voordat ze worden gebruikt of opgeslagen.
3. Indien nodig moeten verzamelde gegevens worden opgeschoond van ongewenste vermeldingen.
4. De gegevensbron moet worden gedocumenteerd en bewaard met de gegevens.
5. Deductiegegevens die worden gebruikt om een model te trainen, mogen niet impliciet worden vertrouwd en moeten worden behandeld als nieuwe gegevens.
6. De inspanningen voor het verzamelen van gegevens moeten worden gedocumenteerd en gecontroleerd. Verzamelde gegevens moeten een eigenaar hebben die verantwoordelijk is voor de naleving van gedocumenteerd beleid.

Typen gevoelige gegevens

Controle: Om ervoor te zorgen dat opgeslagen gegevens voor AI-systemen correct worden beveiligd, bijgehouden en geclassificeerd op basis van de gevoeligheid en het gebruiksscenario. Dit besturingselement omvat toepasselijke labels voor gegevensclassificatie, toegangsbeleid, licentiegegevens, beschrijvende statistieken, bron en datum van verzameling.

Bedreigingsinstructie: gegevens die worden gebruikt in AI-systemen, worden ongepast gebruikt, opgeslagen of geopend vanwege een gebrek aan vereiste kenmerken, metagegevens of documentatie.

Richtlijnen:

1. Ontwikkel een gegevensbeleid dat de privacy en bescherming van gevoelige gegevenstypen omvat en communiceer het beleid aan alle medewerkers die betrokken zijn bij het gebruik of het maken van AI-systemen.
2. Implementeer trainings- en implementatiepijplijnen die de vertrouwelijkheid en integriteit van de gegevens beschermen die worden gebruikt in AI-systemen.

Gegevensopslag

Controle: gegevens moeten op de juiste wijze worden opgeslagen volgens een gedocumenteerd classificatieproces. Gegevenssets moeten worden geïndexeerd en beschouwd als een asset die onderhevig is aan beleid voor assetbeheer en toegangsbeheer.

Bedreigingsverklaring: gegevens worden onveilig opgeslagen en kunnen worden gemanipuleerd of gewijzigd door onbevoegde partijen of systemen. Gegevens worden niet correct geclassificeerd, wat leidt tot de openbaarmaking van vertrouwelijke informatie of gevoelige persoonsgegevens.

Hulp

1. Zorg ervoor dat ontwikkel- of AI-onderzoekssystemen of -accounts geen toegang hebben tot productiedatabases en vice versa.
2. Gegevens die in AI-systemen worden gebruikt, moeten worden geclassificeerd en beveiligd volgens een gedocumenteerd classificatiebeleid.
3. Gegevens die in AI-systemen worden gebruikt, worden bijgehouden onder een gedocumenteerd assetbeheerbeleid.
4. Gegevens die worden gebruikt voor gevoelige AI-use cases worden opgeslagen op goedgekeurde en beheerde systemen.
5. Toegang tot gegevens moet worden gecontroleerd en gebruikers die toegang aanvragen, moeten een formeel toegangsbeheerproces doorlopen dat beheergoedkeuring omvat.
6. Gegevens die worden gebruikt in machine learning-processen mogen niet worden blootgesteld aan internet.
7. Gegevens die van internet (of andere niet-vertrouwde bronnen) worden opgehaald, moeten een filterproces doorlopen dat beheergoedkeuring omvat.
8. Gegevenssets moeten worden geversied met formele wijzigingsbeheerprocessen.

Toegang tot gegevens

Beheer: Gegevenssets moeten op de juiste wijze worden bijgehouden en geverifieerd via cryptografische hash voordat ze worden gebruikt.

Bedreigingsinstructie: gegevenssets worden gewijzigd zonder autorisatie.

Richtlijnen:

1. Op rollen gebaseerd toegangsbeheer voor gegevenssets moet worden afgedwongen.
2. Voer regelmatig toegangscontroles uit om ervoor te zorgen dat accounts met toegang tot gegevenssets toegang moeten hebben tot gegevenssets. Zorg ervoor dat elk account binnen de normale grenzen werkt.
3. Als er geen centraal traceringsplatform wordt gebruikt, moet de toegang tot gegevens via onbewerkte toegangslogboeken worden gecontroleerd voor het doel. Zorg ervoor dat elk account binnen de normale grenzen werkt.
4. Externe resourceproviders, contractanten of andere externe partijen mogen geen overtollige of ongepaste toegang hebben tot de gegevensassets van een bedrijf zonder contracten.

Gegevensintegriteit

Beheer: gegevenssets moeten worden vertrouwd en blijven vertrouwd gedurende de levenscyclus van het AI-systeem.

Bedreigingsinstructie: gegevenssets worden tijdens de LEVENSCYCLUS van AI gewijzigd zonder de mogelijkheid om wijzigingen te controleren of bij te houden.

Richtlijnen:

1. Gegevenssets moeten uniek worden geïdentificeerd, zodat niet-geautoriseerde wijzigingen in een goedgekeurde gegevensset een beoordeling van de gegevensset veroorzaken.
2. Gegevenssets en de bijbehorende cryptografische beschrijvingen moeten worden bijgehouden op een centrale locatie. Toegang tot de gegevensset moet worden gecontroleerd.
3. Wijzigingen in de gegevensset moeten een bijgewerkte cryptografische beschrijvingen en goedkeuring voor beheer bevatten voordat ze worden verzonden naar de centrale traceringsservice.

Gegevensverwerking

Controles en beleidsregels met betrekking tot de verwerking van gegevens die worden gebruikt voor machine learning en kunstmatige intelligentie.

Doelstelling: Om de veilige verwerking van gegevens van de onbewerkte vorm naar een intermediair formulier gereed te maken voor training.

Pijplijnen verwerken

Controle: De verwerking van pijplijnen moet adequaat worden beveiligd.

Bedreigingsinstructie: een bedreigingsacteur kan niet-geautoriseerde wijzigingen aanbrengen in het systeem door de pijplijnen voor gegevensverwerking te wijzigen.

Richtlijnen:

1. Niet alle gegevens die door een productiesysteem worden verplaatst, zijn relevant voor data science-inspanningen. Het is belangrijk om alleen de vereiste gegevens te parseren en ervoor te zorgen dat alle gegevens die zijn verplaatst van een beveiligde productie-instelling naar een ontwikkelinstelling, op de juiste wijze worden bijgehouden. Houd er rekening mee dat bepaalde typen gegevens mogelijk niet kunnen worden verplaatst naar een ontwikkelomgeving. Gegevenswetenschap moet zich mogelijk voordoen in een veilige tussenliggende omgeving.
2. De juiste controle van gegevenstoegang gedurende de levenscyclus van de gegevensverwerking is belangrijk. Zonder afzonderlijke accounts is er onvoldoende controle van de toegang. Verder kan de mogelijkheid om te reageren op een incident niet gebeuren zonder dat dit mogelijk van invloed is op bedrijfsprocessen. Inbreuk op één account zou leiden tot inbreuk op alle gegevens die de beveiligde productieomgeving verlaten.
3. Data science-processen kunnen resources vereisen die buiten een strikte nalevingsgrens vallen.
4. Data science-processen moeten altijd voldoen aan bestaande vereisten. Dit proces kan bestaan uit het verplaatsen van data science-resources en -processen naar een compatibele omgeving.
5. Gegevens moeten gedurende de volledige levenscyclus worden bijgehouden; deze tracering omvat subsets van grotere gegevenssets. Het moet vereist zijn dat een model kan worden teruggeleid naar de gegevens waarop het is getraind. Verder moet er een kopie van die gegevens in zijn geheel bestaan.

Opening van gegevensset

Controle: Om ervoor te zorgen dat subsets (bijvoorbeeld tijdelijke, categorische segmenten) van gegevens die zijn opgenomen voor het bouwen van modellen en hoe kan dat beveiligingsrisico's veroorzaken (privacylekken, vergiftiging/integriteit via overschrijding van feedback, enzovoort).

Bedreigingsinstructie: De bedreigingsacteur kan delen van de gegevens herstellen door subsets van gegevens te reconstrueren/herstellen.

Richtlijnen:

1. Subsets van gegevens zijn gegevenssets zelf. Deze subsets moeten dezelfde metagegevens hebben als de bovenliggende gegevensset en moeten op dezelfde manier worden gecontroleerd op gevoelige gegevenstypen.
2. Afhankelijk van beleidsregels met betrekking tot machine learning-procedures (SLA's, metrische gegevens over vooroordelen, enzovoort), moet elke gegeven gegevensset (inclusief subsets) voldoen aan een minimaal gedocumenteerde standaard rondom deze metrische gegevens als deze moeten worden gebruikt in het bouwen van modellen. De metagegevens moeten altijd worden gekoppeld aan de gegevensset.
3. Alle gegevenssets die in strijd zijn met bestaand beleid, moeten een gedocumenteerde uitzondering hebben die is goedgekeurd door beheer. Opgenomen in de uitzondering moet een gedocumenteerde reden zijn voor de uitzondering, naast de vereiste metagegevens.
4. Alle gegevens die worden gebruikt voor het bouwen van modellen, moeten worden bijgehouden op een centrale locatie. Gegevens moeten op elk gewenst moment kunnen worden gecontroleerd. Daarnaast moeten modellen die zijn getraind op niet-bijgehouden gegevens, worden opgehaald uit productie totdat ze overeenkomen met een bekende gegevensset met de vereiste metagegevens.
5. Gegevenssets moeten op de juiste wijze worden geversied, zodat alle metagegevens worden bijgewerkt, en gebruikers van de gegevens begrijpen de inhoud en de statistische eigenschappen. Indien nodig moet beheergoedkeuring voor gevoelige use cases vereist zijn.

Modeltraining

Controles en beleidsregels met betrekking tot de training van modellen en algoritmen.

Modelontwerp

Controle: Modeltrainingscode wordt beoordeeld door een verantwoordelijke partij.

Bedreigingsinstructie: onjuiste code of beveiligingsproblemen in modelcode produceren beschikbaarheids-, integriteits- of vertrouwelijkheidsrisico's.

Richtlijnen:

1. Modelontwerp en -onderzoek moeten plaatsvinden in de juiste omgeving. Modelontwerp en -architectuur kunnen een groot effect hebben op de werkzaamheid van een model. Productieomgevingen zijn niet de plaats voor onderzoek of het testen van niet-bewezen claims over de werkzaamheid van een ontwerp.
2. Modelselectie voor een productiesysteem moet worden beoordeeld en goedgekeurd door het management. Dit proces moet vroeg in de ontwikkelingsfase plaatsvinden en moet worden bijgehouden via elk beschikbaar mechanisme (Excel, DevOps, Git, enzovoort). Uitzonderingen moeten worden gedocumenteerd.
3. Modellen zijn vaak domeinspecifiek en er moet voldoende documentatie zijn bij het model tijdens het gebruik ervan in een organisatie.
4. Zorg ervoor dat modelmetagegevens toegankelijk zijn voor gebruikers en niet-goedgekeurde toepassingen van modellen worden gedocumenteerd en afgedwongen. Het is acceptabel voor een gebruiker om een bestaand model af te stemmen zolang er nieuwe metagegevens worden gekoppeld en op de juiste wijze worden bijgehouden.

Modeltraining

Controle: Het modelselectiecriterium (metrische en holdoutsets) nabootst natuurlijke drift en eventuele adversarial voorwaarden die tijdens de implementatie kunnen worden verwacht.

Bedreigingsinstructie: Een model dat onder ideale omstandigheden wordt getraind, is waarschijnlijk broos wanneer het wordt geïmplementeerd in adversarial-instellingen.

Hulp

1. Trainings- en validatiesets moeten natuurlijke tijdelijke afhankelijkheden respecteren. Voor malwareclassificaties moet een validatieset bijvoorbeeld alleen softwareversies bevatten die later zijn dan de versies in de trainingsset.
2. Voeg expliciet modelvastheid toe door gegevenssets te verbeteren met veelvoorkomende beschadigingen die redelijkerwijs in het wild kunnen worden gedetecteerd.
3. Train expliciet tegen slechtste omstandigheden met adversarial retraining.
4. Experimenten en bijbehorende meta bijhouden.

Modelselectie

Modelselectie bestaat uit het kiezen van één model uit een set kandidaten, waarbij elke kandidaat een unieke set modelparameters, trainingsalgoritmen en training hyperparameters heeft. Het selectiecriterium voor het winnende model is vaak gebaseerd op één kwantificeerbare meetwaarde (bijvoorbeeld minimumverlies, maximale detectiesnelheid) zoals gemeten op een algemene bewaringsgegevensset of zoals gemiddelden in een K-vouwvalidatieset.

Beheer: Modelontwerp- en trainingsalgoritmen omvatten expliciete of impliciete model regularisatie.

Bedreigingsinstructie: modellen zijn overfit voor een trainings- en/of enkele validatiegegevensset en zijn kwetsbaarder voor foutmodi.

Richtlijnen:

1. Indien rekenkundig haalbaar, moet kruisvalidatie met K-vouwen worden gebruikt om overfitting naar één holdoutset te voorkomen.
2. Controleer of geselecteerde modellen goed presteren op verschillende holdoutsets om te controleren of ze niet overfit zijn.
3. Zorg ervoor dat er processen bestaan.

Versiebeheer model

Controle: Modellen worden continu opnieuw getraind als nieuwe trainingsgegevens stromen naar trainingspijplijnen.

Bedreigingsinstructie: er treedt een incident op, maar het betrokken model kan niet worden gevonden voor onderzoek.

Richtlijnen:

1. Versiemodellen, zodat telkens wanneer een model wordt getraind, een nieuwe versie wordt toegewezen. Kwalificaties zoals my_model_dev_1.1 of my_model_prod_1.1 moeten worden gebruikt om de productie van preproductiemodellen af te bakenen. Deze versiebeheer helpt bij het isoleren van problemen met een productie- of preproductieprobleem. Verwijzen naar bestaande beveiligde SDL-processen of -beleidsregels.

Modelimplementatie

Besturingselementen en beleidsregels met betrekking tot de implementatie van modellen, algoritmen en ondersteunende infrastructuur.

Testen van beveiliging

Controle: Modellen die in productie worden geplaatst, worden adequaat beveiligd.

Bedreigingsinstructie: AI-systemen worden niet adequaat getest op beveiligingsproblemen voorafgaand aan de implementatie.

Richtlijnen:

1. Formele acceptatietestcriteria zijn niet gedefinieerd en gedocumenteerd voor nieuwe AI-systemen, upgrades en nieuwe versies.
2. Nieuwe AI-systemen, upgrades of nieuwe versies moeten worden geïmplementeerd met formele tests.
3. Geautomatiseerde hulpprogramma's moeten worden gebruikt voor het testen van informatiesystemen, upgrades of nieuwe versies.
4. Testomgeving moet nauw lijken op de uiteindelijke productieomgeving.
5. De frequentie, het bereik en de methoden voor onafhankelijke beveiligingsbeoordelingen moeten worden gedocumenteerd.

Beveiligings- en nalevingsbeoordeling

Beheer: Robuust beheer van het onderliggende netwerk is essentieel voor het beveiligen van het ML-systeem en de infrastructuur.

Bedreigingsverklaring: Inbreuk op het ML-systeem door toegang te krijgen tot het onbeveiligde netwerk.

Richtlijnen:

1. Gatewayapparaten naar ML-systemen moeten worden geconfigureerd om verkeer tussen domeinen te filteren en onbevoegde toegang te blokkeren.
2. De relevante wettelijke, wettelijke en contractuele vereisten moeten expliciet worden gedefinieerd en gedocumenteerd en aangepakt, naast specifieke controles en afzonderlijke verantwoordelijkheden.
3. Veilige configuratierichtlijnen moeten ook worden gedocumenteerd, geïmplementeerd of gecontroleerd.
4. Het criterium voor de scheiding van ML-netwerken in domeinen moet consistent zijn met het toegangsbeheerbeleid of de toegangsvereisten van de organisatie.
5. Mechanismen zoals beveiligde gateway, VPN, routering voor ML-systemen moeten voldoende worden geïmplementeerd om een gegradeerde set besturingselementen mogelijk te maken.
6. Gebruikers en ML-technici moeten vereisten hanteren of volgen voor de implementatie van controles om het gebruik van openbaar toegankelijke systemen, interne netwerken en kritieke activa op de juiste wijze te scheiden en te beperken.

Systeembewaking

Controles en beleidsregels met betrekking tot de doorlopende bewaking van machine learning-systemen en ondersteunende infrastructuur.

Logboeken en logboekbeoordeling

Controle: logboekregistratie en bewaking is essentieel voor ML-systemen om veiligheidsredenen.

Bedreigingsinstructie: tijdens een onderzoek worden logboeken voor ML-systemen niet gevonden.

Richtlijnen:

1. Logboekregistratie en bewaking moet consistent plaatsvinden in alle AI-systemen en hun onderdelen, waaronder opslag, pijplijnen, productieservers, enzovoort.
2. Gebeurtenis- en beveiligingslogboeken moeten regelmatig worden gecontroleerd op abnormaal gedrag.
3. Geconsolideerde rapporten en waarschuwingen over systeemactiviteiten moeten worden gegenereerd en gecontroleerd door beheer of een beveiligingsvertegenwoordiger.

Incidenten beheren

Rollen en verantwoordelijkheden

Beheer: Beveiligingslogboeken moeten worden verzameld op een centrale locatie.

Bedreigingsverklaring: tijdens een onderzoek hebben beveiligingsanalisten geen geformaliseerd playbook.

Richtlijnen:

1. Organisaties moeten een formeel proces volgen om incidenten van AI-systemen te rapporteren in de context van verlies van service, verlies van apparatuur, verlies van faciliteiten, systeemstoringen, systeemoverbelastingen, menselijke fouten, niet-naleving van beleid of richtlijnen, schendingen van fysieke beveiliging, onbeheerde systeemwijzigingen, softwarestoringen, hardwarestoringen en toegangsschendingen.
2. Formele procedures voor het reageren op incidenten en escalatie moeten worden ontwikkeld om acties te documenteren die worden uitgevoerd na ontvangst van een rapport van een informatiebeveiligingsevenement.
3. Procedures voor incidentrespons moeten periodiek worden getest, metrische gegevens van reacties bijhouden.

Planning voor bedrijfscontinuïteit

Planning, beoordeling en resultaten

Controle: Zorg ervoor dat ML-systemen na een incident kunnen worden hersteld en hersteld.

Bedreigingsverklaring: incidenten veroorzaken permanente vertrouwelijkheid, integriteit of beschikbaarheidsproblemen met kritieke ML-systemen.

Richtlijnen:

1. Kritieke AI-assets moeten worden geïdentificeerd en geïnventariseerd.
2. De organisatie moet een BCP-proces (Business Continuity Plan) of herstel na noodgevallen (DR) ontwikkelen ten aanzien van aanvallen op AI-systemen.
3. De organisatie moet prioriteit geven aan de risico's die zijn gekoppeld aan de impact van het verliezen van kritieke AI-systemen aan aanvallen.
4. Organisaties moeten een bedrijfscontinuïteitstest hebben uitgevoerd volgens een herhaald schema voor kritieke AI-systemen.

Verwijzingen

• ISO 27001 Bijlage A - Overzicht (isms.online)
• Officiële site van DE PCI Security Standards Council
• Foutmodi in Machine Learning
• Threat Modeling AI/ML-systemen en -afhankelijkheden
• AI/ML-pivots naar de bugbalk voor de levenscyclus van security development
• Bedrijfsbeveiliging en -governance

Als u vragen, opmerkingen of feedback hebt, neemt u contact op met atml@microsoft.com.

Download een PDF van dit document vanuit onze GitHub-opslagplaats.