Kas yra duomenų apsinuodijimas?

Kiekviena saugumo komanda yra apmokyta stebėti kodą, kai jis siunčiamas. Beveik nė viena nėra apmokyta stebėti duomenis jiems atvykstant, ir būtent šią akląją zoną išnaudoja duomenų užkrėtimas. Kai užkrėstas modelis pasiekia gamybos aplinką, pažeidžiamumas niekada nebuvo kodo peržiūroje. Jis buvo duomenų rinkinyje, kurio niekas nebuvo auditavęs prieš kelis mėnesius.

Šiame žodynėlio įraše paaiškinama, kas yra duomenų apsinuodijimas, kaip praktiškai vyksta duomenų apsinuodijimo atakos, kodėl dirbtinio intelekto duomenų apsinuodijimas tapo viena iš... sparčiausiai augančios rizikos dirbtinio intelekto eroje SDLC, ir kaip atrodo tikroji gynyba nuo jos.

Duomenų apsinuodijimo reikšmė #

Duomenų užkrėtimas – tai sąmoningas duomenų, naudojamų dirbtinio intelekto modeliui mokyti, tiksliai derinti ar įžeminti, manipuliavimas, kad modelis išmoktų netinkamų dalykų, elgtųsi taip, kaip nori užpuolikas, arba nutekintų informaciją, kurios niekada neturėtų atskleisti. Užuot atakavęs modelį po diegimo, užpuolikas atakuoja žaliavą, iš kurios sukurtas modelis.

Pagrindinė duomenų užkrėtimo idėja yra paprasta ir nerimą kelianti: dirbtinio intelekto modelis yra toks pat patikimas, kokie yra duomenys, iš kurių jis mokėsi. Jei tie duomenys yra sugadinti, šališki arba užminuoti dar prieš pradedant mokymą, jokia kodo peržiūra, testavimas ar vykdymo laiko stebėjimas neaptiks pagrindinio trūkumo, nes modelis veikia tiksliai taip, kaip buvo (piktavališkai) išmokytas.

Dirbtinio intelekto duomenų užkrėtimas ir tradicinės programinės įrangos pažeidžiamumai #

Tradicinė programų apsauga daro prielaidą, kad pavojus slypi kode: blogoje funkcijoje, netaisytoje bibliotekoje, netinkamai sukonfigūruotame serveryje. Dirbtinio intelekto duomenų užkrėtimas visiškai pažeidžia šią prielaidą. Nėra pažeidžiamos kodo eilutės, kurią reikėtų rasti, nes iškraipymas įvyko mokymo rinkinyje, tikslinamajame duomenų rinkinyje arba paieškos indekse gerokai anksčiau, nei buvo parašytas kodas ar įdiegtas modelis.

Štai kodėl dirbtinio intelekto duomenų užkrėtimą išskirtinai sunku aptikti naudojant senesnius įrankius. SAST Skaitytuvas skaito kodą. Priklausomybių skaitytuvas skaito paketų manifestus. Nei vienas iš jų neskaito kelių gigabaitų mokymo korpuso, nei vektorinės duomenų bazės, pilnos įterptųjų dokumentų, kurie yra iš ankstocisbūtent ten, kur DI duomenų užkrėtimas daro žalą. saugumo tyrėjai ir atskleidžiama atsakingai. Kitus pirmiausia aptinka ir ginkluoja užpuolikai, o tai yra scenarijus, kuris padaro daugiausia žalos.

Kaip iš tikrųjų veikia duomenų apsinuodijimo atakos? #

Duomenų apsinuodijimo atakos paprastai būna vienos iš kelių formų:

• Mokymo duomenų apsinuodijimas: užpuolikas į duomenų rinkinį, naudojamą modeliui apmokyti nuo nulio arba esamam modeliui tikslinti, įterpia manipuliuojamus, neteisingai paženklintus arba kenkėjiškus pavyzdžius, dėl ko jis išmoksta paslėptą šališkumą arba „užpakalinių durų“ elgesį.
• Etikečių apvertimasSubtilesnė aukščiau pateikto metodo versija, kai užpuolikas pakeičia tik nedidelio mokymo pavyzdžių pogrupio etiketes, tyliai iškreipdamas tai, ką modelis išmoksta susieti su kuo.
• RAG ir konteksto apsinuodijimasPaieškos papildytose generavimo sistemose užpuolikas į žinių bazę arba vektorinę saugyklą, iš kurios modelis vykdymo metu gauna duomenis, įterpia užterštus dokumentus, kad modelis užtikrintai kartotų klaidingą arba manipuliuotą informaciją, tarsi tai būtų patikrintas faktas.
• Užpakalinių durų paleidikliai: užpuolikas įterpia konkretus mokymo duomenų modelis taip, kad modelis beveik kiekvienu atveju elgtųsi normaliai, bet pateikdamas užpuoliko pasirinktą išvestį, jis pateikia paslėptą suveikimo frazę arba įvesties duomenis.
• Tiekimo grandinės apsinuodijimas: užpuolikas pažeidžia viešą arba bendrai naudojamą duomenų rinkinį, iš anksto apmokyto modelio kontrolinis taškas arba įterpimas pipeline prieš srovę, kad kiekviena pasroviui esanti komanda, iš kurios ji išeina, paveldėtų nuodus niekada neprisiliesdama prie pradinės atakos.

Visas šias duomenų užkrėtimo atakas sieja laikas. Žala padaroma dar prieš modeliui pateikiant atsakymą realiam vartotojui, todėl frazė „prieš jam parašant kodo eilutę“ apibūdina šią grėsmę taip iš anksto.cisely: modelis yra pažeistas pačiame pagrinde, o ne rezultatuose.

Kaip užpuolikai sugadina dirbtinio intelekto modelį dar prieš jam parašant kodo eilutę? #

Kiekviena aukščiau aprašyta duomenų užkrėtimo ataka turi tą patį laiko pranašumą: kompromitacija įvyksta prieš pradedant procesą, gerokai anksčiau, nei modelis sugeneruoja bent vieną išvestį, kurią vartotojas pamatys. Nėra pažeidžiamos funkcijos, kurią būtų galima pataisyti, ir nėra kenkėjiškų programų. commit pagauti peržiūros metu, nes modelis dar nieko neparašė. Jis tik išmoko, o tai, ką išmoko, jau yra neteisinga.

Štai kuo dirbtinio intelekto duomenų užkrėtimas iš esmės skiriasi nuo pažeidžiamumų, kuriuos apmokytos ieškoti programų saugumo komandos. Kodo skirtumo analizėje užkoduotas modelis atrodo identiškai švariam. Jis praeina... pull request peržiūra. Jis teisingai sukompiliuoja, diegia ir atsako į daugumą užklausų, iki pat tol, kol konkreti sąlyga, kurią sukūrė užpuolikas, galiausiai pasirodo gamybinėje aplinkoje. Tuomet klausimas nebėra „koks kodas tai įdiegė“, o „kokius duomenis tai padarė ir kiek seniai jie siekia“.

Kodėl dirbtinio intelekto duomenų užkrėtimas tampa vis svarbesniu prioritetu? #

Dirbtinio intelekto duomenų apsinuodijimas nebėra teorinė problema. Tai oficialiai pripažinta kaip LLM04: Duomenų ir modelių apsinuodijimas pateko į OWASP dešimtuką LLM programų kategorijoje, kartu su greito įvedimo ir tiekimo grandinės rizika, kaip viena iš pagrindinių generatyviojo dirbtinio intelekto eros grėsmių. Trys tendencijos kelia šį klausimą kiekvienos saugumo komandos akiratyje:

• Žala nematoma, kol nesuveikia. Užnuodytas modelis gali išlaikyti visus funkcinius testus ir nepriekaištingai elgtis mėnesius, kol konkreti užpuoliko sukurta suveikimo sąlyga pagaliau pasirodo gamyboje.

• Atgavimo papildyta karta yra visur. Bet kuri sistema, leidžianti modeliui išgauti tiesioginį kontekstą iš dokumentų, wiki, bilietų ar vektorinės duomenų bazės, turi naują, neaudituotą įvesties paviršių, ir būtent į tą paviršių nukreipiamos duomenų užkrėtimo atakos.

• Duomenų rinkiniai dabar yra tiekimo grandinės turtas. Komandos įprastai iš išorinių šaltinių ištraukia iš anksto apmokytus modelius, įterptuosius elementus ir viešuosius duomenų rinkinius taip pat, kaip jos ištraukia atvirojo kodo paketus, ir kaip ir pažeistas paketas, pažeistas duomenų rinkinys gali tyliai perduoti ataką kiekvienai jį naudojančiai komandai.

Duomenų užkrėtimo aptikimas ir apsauga nuo jo #

Kadangi duomenų apsinuodijimas vyksta prieš patį modelį, gynyba taip pat turi prasidėti prieš jį:

• Stebėkite anomalius duomenų šaltinius, ne tik anomalius kodus. Elgesio ir anomalijų aptikimas turi būti vykdomas iki tos vietos, kur duomenys patenka į pipeline, nesustoja ties saugyklos riba.

• Žinokite kiekvieną duomenų rinkinį pipeline. Negalite audituoti apsinuodijimo rizikos duomenų rinkinyje, apie kurio egzistavimą nežinote. Nuolatinis mokymo, vertinimo ir paieškos duomenų rinkinių aptikimas yra pirmoji gynybos linija.

• Atsekite duomenų rinkinio, modelio ir išvesties liniją. Duomenų rinkinio kelio į modelį ir iš modelio į agentą, galinį tašką ar kodavimo įrankį atvaizdavimas yra tai, kas „gavome blogą rezultatą“ paverčia „tiksliai žinome, kuris duomenų rinkinys jį įvedė“.

• Atidžiai tikrinkite paieškos šaltinius, o ne tik mokymo rinkinius. RAG sistemose vektorių saugyklai ir žinių bazei reikalingi tie patys vientisumo patikrinimai kaip ir mokymo duomenims, nes konteksto užkrėtimas įvyksta užklausos, o ne mokymo metu.

Kaip „Xygeni“ padeda panaikinti duomenų apsinuodijimo spragą? #

Apsauga nuo duomenų užkrėtimo prasideda nuo matomumo, kurio dauguma organizacijų tiesiog neturi. Ksigeni„DI Inventory“ nuolat aptinka kiekvieną DI išteklių visame įrenginyje. SDLC, įskaitant už jo esančius duomenų rinkinius: mokymo duomenis, vertinimo rinkinius ir RAG arba paieškos šaltinius, ir susieja juos į tiesioginį ryšių grafiką, veikiantį nuo duomenų rinkinio iki modelio ir galinio taško. iš agento į MCP serverį kodavimo įrankiui. Būtent tas grafikas paverčia įtartiną modelio išvestį atsekamu klausimu: koks duomenų rinkinys jį pateikė ir iš kur jis atsirado.

Be to inventoriaus, Xygeni AI saugumas aptinka vektorių ir įterpimo silpnybes, įskaitant užterštą kontekstą paieškos ir RAG procesuose pipelines, suderintas su OWASP 10 geriausių LLM programų. Užuot pasitikėjusi, kad modelio mokymo ir paieškos šaltiniai yra švarūs, „Xygeni“ juos traktuoja kaip atakos paviršiaus dalį, taip pat, kaip jau elgiasi su kodu, priklausomybėmis ir... pipelines. Jei šiuo metu negalite atsakyti į klausimą „kokie duomenys apmokė šį modelį ir ar galime tai įrodyti“, tai yra būtent ta spraga, kurią verta užpildyti, kol dirbtinio intelekto duomenų apsinuodijimo incidentas neprivers užduoti šį klausimą.

DUK #