Wat is gegevensvergiftiging?

Elk beveiligingsteam is getraind om code te controleren tijdens de implementatie. Bijna geen enkel team is getraind om data te controleren tijdens de binnenkomst, en die blinde vlek wordt precies uitgebuit door datavergiftiging. Tegen de tijd dat een besmet model in productie gaat, is de kwetsbaarheid nooit tijdens de codecontrole ontdekt. ​​De kwetsbaarheid zat in een dataset die maanden eerder door niemand was gecontroleerd.

Deze verklarende woordenlijst legt uit wat datavergiftiging is, hoe datavergiftigingsaanvallen in de praktijk verlopen en waarom AI-datavergiftiging een van de meest voorkomende bedreigingen is geworden. snelstgroeiende risico's in het AI-tijdperk SDLCen hoe een effectieve verdediging daartegen eruitziet.

Betekenis van datavergiftiging #

Datavergiftiging is het opzettelijk manipuleren van de data die gebruikt wordt om een ​​AI-model te trainen, te verfijnen of te valideren, zodat het model de verkeerde dingen leert, zich gedraagt ​​zoals de aanvaller dat wil, of informatie lekt die het nooit zou mogen vrijgeven. In plaats van het model na de implementatie aan te vallen, valt een aanvaller het ruwe materiaal aan waaruit het model is opgebouwd.

Het kernidee achter datavergiftiging is simpel en verontrustend: een AI-model is slechts zo betrouwbaar als de data waarmee het is getraind. Als die data corrupt, bevooroordeeld of vol valstrikken zit voordat de training zelfs maar begint, zal geen enkele codecontrole, test of runtime-monitoring de onderliggende fout aan het licht brengen, omdat het model precies werkt zoals het (op kwaadwillige wijze) is getraind.

AI-datavergiftiging versus traditionele softwarekwetsbaarheden #

Traditionele applicatiebeveiliging gaat ervan uit dat het gevaar in de code schuilt: een slechte functie, een niet-gepatchte bibliotheek, een verkeerd geconfigureerde server. AI-datavergiftiging ondermijnt die aanname volledig. Er is geen kwetsbare regel code te vinden, omdat de corruptie plaatsvond in een trainingsset, een finetuning-dataset of een retrieval-index, lang voordat er code werd geschreven of een model werd geïmplementeerd.

Daarom is het met traditionele tools zo moeilijk om datavergiftiging door AI op te sporen. SAST Een scanner leest code. Een dependency scanner leest pakketmanifesten. Geen van beide leest een trainingscorpus van meerdere gigabytes of een vectordatabase vol ingebedde documenten, wat voorafgaat aan...cisVooral waar AI-datavergiftiging schade aanricht. Beveiligingsonderzoekers melden dit op verantwoorde wijze. Andere gevallen worden eerst ontdekt en door aanvallers misbruikt, wat het scenario is dat de meeste schade veroorzaakt.

Hoe werken datavergiftigingsaanvallen eigenlijk? #

Aanvallen waarbij gegevens worden vergiftigd, nemen over het algemeen een van de volgende vormen aan:

• Vergiftiging van trainingsgegevensEen aanvaller voegt gemanipuleerde, verkeerd gelabelde of kwaadaardige voorbeelden toe aan de dataset die wordt gebruikt om een ​​model vanaf nul te trainen of een bestaand model te verfijnen, waardoor het model een verborgen vooroordeel of een achterdeurgedrag aanleert.
• Label omdraaienEen subtielere versie van het bovenstaande, waarbij een aanvaller alleen de labels van een kleine subset van trainingsvoorbeelden wijzigt, waardoor ongemerkt de associaties die het model leert te maken, worden verstoord.
• RAG en contextvergiftigingIn retrieval-augmented generatiesystemen plant een aanvaller vervalste documenten in de kennisbank of vectoropslag waaruit het model tijdens de uitvoering gegevens ophaalt, zodat het model vol vertrouwen valse of gemanipuleerde informatie herhaalt alsof het een geverifieerd feit is.
• Achterdeur-triggers: een aanvaller plaatst een specifiek patroon in de trainingsgegevens zodat het model zich in bijna alle gevallen normaal gedraagt, maar een door de aanvaller gekozen uitvoer produceert zodra een verborgen triggerzin of invoer verschijnt.
• Vergiftiging van de toeleveringsketen: een aanvaller compromitteert een openbare of gedeelde dataset, een vooraf getraind modelcontrolepunt, of een embedding pipeline stroomopwaarts, zodat elk team dat er stroomafwaarts gebruik van maakt, het gif erft zonder ooit de oorspronkelijke aanval aan te raken.

Wat al deze datavergiftigingsaanvallen met elkaar verbindt, is de timing. De schade wordt aangericht voordat het model ooit een echte gebruiker antwoordt, en dat is precies waarom de uitdrukking "voordat het ook maar één regel code schrijft" deze dreiging zo treffend beschrijft.cisely: het model is fundamenteel gebrekkig, niet de output.

Hoe kunnen aanvallers een AI-model manipuleren voordat het ook maar één regel code schrijft? #

Elke hierboven beschreven datavergiftigingsaanval heeft hetzelfde timingvoordeel: de inbreuk vindt stroomopwaarts plaats, lang voordat een model ook maar één uitvoer genereert die een gebruiker ooit te zien krijgt. Er is geen kwetsbare functie om te patchen en geen kwaadaardige code. commit Om tijdens de review te controleren, omdat het model nog niets heeft geschreven. Het heeft alleen nog maar geleerd, en wat het heeft geleerd is al fout.

Dit is wat AI-datavergiftiging fundamenteel onderscheidt van de kwetsbaarheden waarop applicatiebeveiligingsteams getraind zijn om te zoeken. Een model met een backdoor ziet er in een codevergelijking identiek uit aan een schoon model. Het slaagt voor een pull request review. Het compileert, implementeert en beantwoordt de meeste vragen correct, tot het moment dat de specifieke situatie die een aanvaller heeft gecreëerd zich uiteindelijk in de productieomgeving voordoet. Tegen die tijd is de vraag niet langer "welke code heeft dit veroorzaakt", maar "welke data heeft dit veroorzaakt, en hoe ver gaat dit terug?".

Waarom wordt het vergiftigen van AI-data een steeds belangrijkere prioriteit? #

Het vergiftigen van AI-data is niet langer een theoretische zorg. Het wordt formeel erkend als LLM04: Gegevens- en modelvergiftiging Het staat in de OWASP Top 10 voor LLM-toepassingen, samen met promptinjectie en risico's in de toeleveringsketen, als een van de bepalende bedreigingen van het tijdperk van generatieve AI. Drie trends zorgen ervoor dat het steeds hoger op de radar van elk beveiligingsteam komt te staan:

• De schade is onzichtbaar totdat deze wordt geactiveerd. Een gemanipuleerd model kan maandenlang elke functionele test doorstaan ​​en perfect functioneren, totdat de specifieke triggerconditie die een aanvaller heeft gecreëerd zich uiteindelijk in de productieomgeving voordoet.

• Retrieval-augmented generation is overal. Elk systeem dat een model in staat stelt om live context te halen uit documenten, wiki's, tickets of een vectordatabase, heeft een nieuw, niet-gecontroleerd invoeroppervlak, en dat oppervlak is precies het doelwit van datavergiftigingsaanvallen.

• Datasets zijn tegenwoordig waardevolle activa in de toeleveringsketen. Teams halen routinematig voorgeïnstalleerde modellen, embeddings en openbare datasets van externe bronnen, net zoals ze open-sourcepakketten downloaden. Net als een gecompromitteerd pakket kan een gecompromitteerde dataset de aanval ongemerkt verspreiden naar elk team dat er gebruik van maakt.

Het opsporen van en beschermen tegen datavergiftiging #

Omdat datavergiftiging al vóór het model zelf plaatsvindt, moet de verdediging ook al vóór het model beginnen:

• Let op afwijkende gegevensbronnen, niet alleen op afwijkende code. Gedrags- en anomaliedetectie moet zich uitstrekken tot de plek waar de data binnenkomt. pipeline, en niet stoppen bij de grens van de repository.

• Ken elke dataset in de pipeline. Je kunt het risico op vergiftiging niet inschatten in een dataset waarvan je niet weet dat die bestaat. Continue ontdekking van trainings-, evaluatie- en ophaaldatasets is de eerste verdedigingslinie.

• Volg de herkomst van de dataset naar het model naar de output. Door het pad in kaart te brengen dat een dataset aflegt naar een model, en van een model naar een agent, een eindpunt of een programmeertool, verandert "we kregen slechte output" in "we weten precies welke dataset dit veroorzaakte".

• Onderzoek de bronnen voor het ophalen van informatie kritisch, niet alleen de trainingssets. In RAG-systemen hebben de vectoropslag en de kennisbank dezelfde integriteitscontroles nodig als de trainingsgegevens, omdat contextvervalsing plaatsvindt tijdens het opvragen van gegevens, niet tijdens de training.

Hoe helpt Xygeni de kloof in de bestrijding van datavergiftiging te dichten? #

Bescherming tegen datavergiftiging begint met inzicht, iets wat de meeste organisaties simpelweg niet hebben. Xygeni's AI Inventory ontdekt continu alle AI-assets in de SDLCinclusief de datasets die eraan ten grondslag liggen: trainingsdata, evaluatiesets en RAG- of ophaalbronnen, en brengt deze in kaart in een dynamische relatiegrafiek die loopt van dataset naar model naar eindpunt. naar agent naar MCP-server naar codeertool. Die grafiek maakt van een verdachte modeluitvoer een traceerbare vraag: welke dataset is hiervoor gebruikt en waar komt deze vandaan?

Bovenop die voorraad, Xygeni's AI-beveiliging Detecteert zwakke punten in vectoren en embeddings, waaronder vergiftigde context bij retrieval en RAG. pipelines, afgestemd op de OWASP Top 10 voor LLM-aanvragen. In plaats van erop te vertrouwen dat de trainings- en ophaalbronnen van een model schoon zijn, beschouwt Xygeni ze als onderdeel van het aanvalsoppervlak, op dezelfde manier als code, afhankelijkheden en andere bronnen. pipelineAls u momenteel geen antwoord kunt geven op de vraag "welke data hebben dit model getraind en kunnen we dat bewijzen?", dan is dat precies de lacune die u moet dichten voordat een incident met AI-datavergiftiging u dwingt die vraag te stellen.

FAQ #