Mikä on datamyrkytys?

Jokainen tietoturvatiimi on koulutettu tarkkailemaan koodia sen toimituksen yhteydessä. Lähes kukaan ei ole koulutettu tarkkailemaan dataa sen saapuessa, ja juuri tätä sokeaa pistettä datamyrkytys hyödyntää. Siihen mennessä, kun myrkytetty malli pääsee tuotantoon, haavoittuvuutta ei ollut koskaan koodin tarkistuksessa. Se oli datajoukossa, jota kukaan ei ollut auditoinut kuukausia aiemmin.

Tämä sanasto selittää, mitä datamyrkytys on, miten datamyrkytyshyökkäykset tapahtuvat käytännössä ja miksi tekoälyn datamyrkytyksestä on tullut yksi... nopeimmin kasvavat riskit tekoälyaikakaudella SDLCja miltä todellinen puolustus sitä vastaan ​​näyttää.

Tietojen myrkyttämisen merkitys #

Tietojen myrkyttäminen on tekoälymallin kouluttamiseen, hienosäätöön tai maadoittamiseen käytettävän datan tarkoituksellista manipulointia siten, että malli oppii väärän asian, käyttäytyy hyökkääjän haluamalla tavalla tai vuotaa tietoja, joita sen ei koskaan pitäisi paljastaa. Sen sijaan, että hyökkäisi malliin käyttöönoton jälkeen, hyökkääjä hyökkää mallin rakennusmateriaalia vastaan.

Datan myrkytyksen ydinajatus on yksinkertainen ja häiritsevä: tekoälymalli on yhtä luotettava kuin sen oppima data. Jos data on korruptoitunut, vääristynyt tai ansoilla varustettu ennen kuin koulutus edes alkaa, mikään määrä koodin tarkistusta, testausta tai ajonaikaista seurantaa ei löydä taustalla olevaa virhettä, koska malli toimii täsmälleen niin kuin se (haitallisesti) on opetettu.

Tekoälyn datamyrkytys vs. perinteisten ohjelmistojen haavoittuvuudet #

Perinteinen sovellusten tietoturva olettaa, että vaara piilee koodissa: viallisessa funktiossa, korjaamattomassa kirjastossa tai väärin konfiguroidussa palvelimessa. Tekoälyn aiheuttama datamyrkytys rikkoo tämän oletuksen täysin. Haavoittuvaa koodiriviä ei ole löydettävissä, koska korruptio tapahtui harjoitusjoukossa, hienosäädettävässä tietojoukossa tai hakuindeksissä kauan ennen kuin mitään koodia kirjoitettiin tai mallia otettiin käyttöön.

Tästä syystä tekoälyn datamyrkytys on ainutlaatuisen vaikea havaita perinteisillä työkaluilla. SAST skanneri lukee koodia. Riippuvuusskanneri lukee pakettien manifesteja. Kumpikaan ei lue usean gigatavun harjoituskorpusta tai vektoritietokantaa, joka on täynnä upotettuja dokumentteja, mikä on ennalta määrätty.cisjuuri siellä, missä tekoälyn datamyrkytys aiheuttaa vahinkoa. turvallisuustutkijat ja tiedot julkistetaan vastuullisesti. Toiset hyökkääjät löytävät ja aseistavat ensin, mikä on skenaario, joka aiheuttaa eniten vahinkoa.

Miten datamyrkytyshyökkäykset oikeasti toimivat? #

Tietojen myrkytyshyökkäykset voivat yleensä olla jonkin seuraavista muodoista:

• Koulutustietojen myrkytysHyökkääjä lisää manipuloituja, väärin nimettyjä tai haitallisia esimerkkejä tietojoukkoon, jota käytetään mallin kouluttamiseen tyhjästä tai olemassa olevan mallin hienosäätöön, jolloin se oppii piilevän vinouman tai takaporttikäyttäytymisen.
• Etikettien kääntäminen: hienovaraisempi versio yllä olevasta, jossa hyökkääjä muuttaa vain pienen osan harjoitusesimerkeistä tunnisteita, vääristäen hiljaa sitä, mitä malli oppii yhdistämään mihin.
• RAG ja kontekstimyrkytysHakua tukevissa generointijärjestelmissä hyökkääjä istuttaa myrkytettyjä dokumentteja mallin ajonaikaiseen tietokantaan tai vektorivarastoon, jotta malli toistaa varmasti väärää tai manipuloitua tietoa ikään kuin se olisi varmistettua faktaa.
• Takaoven laukaisimethyökkääjä upottaa tietty kaava harjoitusdatassa niin että malli käyttäytyy normaalisti lähes kaikissa tapauksissa, mutta tuottaa hyökkääjän valitseman tulosteen heti, kun piilotettu liipaisulauseke tai syöte ilmestyy.
• Toimitusketjun myrkytys: hyökkääjä vaarantaa julkisen tai jaetun tietoaineiston, esikoulutetun mallin tarkistuspiste tai upotus pipeline ylävirtaan, niin että jokainen siitä vetävä alavirran joukkue perii myrkyn koskematta koskaan alkuperäiseen hyökkäykseen.

Kaikkia näitä datamyrkytyshyökkäyksiä yhdistää ajoitus. Vahinko tapahtuu jo ennen kuin malli edes vastaa oikealle käyttäjälle, minkä vuoksi ilmaus "ennen kuin se edes kirjoittaa riviä koodia" kuvaa tätä uhkaa niin ennalta.cisely: malli on vaarantunut perustaltaan, ei tuotokselta.

Kuinka hyökkääjät korruptoivat tekoälymallin ennen kuin se edes kirjoittaa riviä koodia? #

Jokaisella edellä kuvatulla datamyrkytyshyökkäyksellä on sama ajoitusetu: tietomurto tapahtuu ylävirran puolella, kauan ennen kuin malli tuottaa yhtäkään tulostetta, jonka käyttäjä koskaan näkee. Ei ole haavoittuvaa toimintoa, jota voisi korjata, eikä haitallista ohjelmaa ole. commit kiinni tarkastelussa, koska malli ei ole vielä kirjoittanut mitään. Se on vain oppinut, ja se, mitä se oppi, on jo väärin.

Tämä tekee tekoälyn datamyrkytyksestä perustavanlaatuisesti erilaisen kuin haavoittuvuudet, joita sovellusten tietoturvatiimit on koulutettu metsästämään. Takaportin läpi kulkeva malli näyttää identtiseltä koodin erottelussa puhtaan mallin kanssa. Se läpäisee pull request tarkastelu. Se kääntää, ottaa käyttöön ja vastaa useimpiin kyselyihin oikein, aina siihen asti, kunnes hyökkääjän asettama ehto lopulta ilmestyy tuotantoympäristöön. Silloin kysymys ei ole enää "mikä koodi toi tämän käyttöön", vaan "mitä dataa käytettiin ja kuinka kauas taaksepäin se ulottuu".

Miksi tekoälyn datamyrkytys on kasvava prioriteetti? #

Tekoälyn datamyrkytys ei ole enää teoreettinen huolenaihe. Se on virallisesti tunnustettu LLM04: Data- ja mallimyrkytys OWASP:n kymmenen parhaan joukossa LLM-sovellusten alalla, nopean injektion ja toimitusketjuriskin ohella yhtenä generatiivisen tekoälyn aikakauden määrittävistä uhkista. Kolme trendiä nostavat sitä korkeammalle jokaisen tietoturvatiimin tutkassa:

• Vaurio on näkymätön, kunnes se laukeaa. Myrkytetty malli voi läpäistä kaikki toiminnalliset testit ja käyttäytyä täydellisesti kuukausien ajan, kunnes hyökkääjän asettama tietty laukaisuehto lopulta ilmestyy tuotantoon.

• Haun avulla täydennettyä sukupolvea on kaikkialla. Missä tahansa järjestelmässä, joka antaa mallin hakea reaaliaikaista kontekstia dokumenteista, wikistä, tiketistä tai vektoritietokannasta, on uusi, auditoimaton syöttöpinta, ja juuri tämä pinta on se, mihin datapoisoning-hyökkäykset kohdistuvat.

• Datajoukot ovat nyt toimitusketjun resursseja. Tiimit hakevat rutiininomaisesti esikoulutettuja malleja, upotuksia ja julkisia datajoukkoja ulkoisista lähteistä samalla tavalla kuin he hakevat avoimen lähdekoodin paketteja, ja aivan kuten vaarantunut paketti, vaarantunut datajoukko voi kuljettaa hyökkäyksen hiljaa jokaiseen sitä käyttävään tiimiin.

Tietojen myrkytyksen havaitseminen ja siltä suojautuminen #

Koska datan myrkytys tapahtuu mallin itsensä ylävirtaan, puolustuksen on myös aloitettava ylävirtaan:

• Tarkkaile poikkeavia tietolähteitä, äläkä pelkkää poikkeavaa koodia. Käyttäytymisen ja poikkeavuuksien havaitsemisen on ulotuttava siihen, mihin tiedot saapuvat pipeline, ei pysähdy arkiston rajalle.

• Tunne jokainen tietojoukko pipeline. Et voi auditoida myrkytysriskiä tietojoukossa, jonka olemassaolosta et tiedä. Koulutus-, arviointi- ja hakutietojoukkojen jatkuva etsintä on ensimmäinen puolustuslinja.

• Jäljitä sukulinja aineistosta malliin ja tuotokseen. Datasetin polun kartoittaminen malliin ja mallista agenttiin, päätepisteeseen tai koodaustyökaluun muuttaa tilanteen, jossa "saimme huonon tuloksen" tilaan, jossa "tiedämme tarkalleen, mikä datasetti toi sen".

• Tutki hakulähteitä, älä pelkästään harjoitusjoukkoja. RAG-järjestelmissä vektorivarasto ja tietämyskanta tarvitsevat samat eheystarkistukset kuin harjoitusdata, koska kontekstin myrkytys tapahtuu kyselyn, ei harjoitusajan, aikana.

Kuinka Xygeni auttaa kuromaan umpeen datamyrkytysaukkoa? #

Tietojen myrkytyksen torjunta alkaa näkyvyydestä, jota useimmilla organisaatioilla ei yksinkertaisesti ole. Xygeni's AI Inventory etsii jatkuvasti kaikki tekoälyresurssit SDLC, mukaan lukien sen taustalla olevat datajoukot: harjoitusdata, arviointijoukot ja RAG- tai hakulähteet, ja yhdistää ne reaaliaikaiseksi suhdegraafiksi, joka kulkee datajoukosta malliin ja päätepisteeseen agentille MCP-palvelimelle koodaustyökaluun. Tuo kaavio muuttaa epäilyttävän mallin tuotoksen jäljitettäväksi kysymykseksi: mikä tietojoukko syötti tämän ja mistä se on peräisin.

Tuon varaston lisäksi Xygenin AI turvallisuus havaitsee vektori- ja upotusheikkouksia, mukaan lukien myrkytetty konteksti haussa ja RAG:ssa pipelines, linjassa OWASP Top 10 LLM-hakemuksiin. Sen sijaan, että Xygeni luottaisi mallin koulutus- ja hakulähteiden puhtauteen, se käsittelee niitä osana hyökkäyspintaa samalla tavalla kuin se jo käsittelee koodia, riippuvuuksia ja... pipelines. Jos et pysty tällä hetkellä vastaamaan kysymykseen "millä datalla tätä mallia koulutettiin ja voimmeko todistaa sen", juuri se aukko kannattaa paikata ennen kuin tekoälyn datamyrkytys pakottaa kysymyksen esiin.

FAQ #