Ce este otrăvirea datelor?

Fiecare echipă de securitate este instruită să urmărească codul pe măsură ce acesta este livrat. Aproape niciuna nu este instruită să urmărească datele pe măsură ce sosesc, iar acest punct mort este exact ceea ce exploatează otrăvirea datelor. Până când un model otrăvit ajunge în producție, vulnerabilitatea nu se afla niciodată în revizuirea codului. Se afla într-un set de date pe care nimeni nu îl auditase cu luni înainte.

Această intrare din glosar explică ce este otrăvirea datelor, cum se desfășoară în practică atacurile de otrăvire a datelor, de ce otrăvirea datelor cu inteligență artificială a devenit una dintre... Riscurile cu cea mai rapidă creștere în era inteligenței artificiale SDLCși cum arată o adevărată apărare împotriva acesteia.

Semnificația otrăvirii datelor #

Intoxicația cu date este manipularea deliberată a datelor utilizate pentru antrenarea, reglarea fină sau fundamentarea unui model de inteligență artificială, astfel încât modelul să învețe ceva greșit, să se comporte într-un mod dorit de atacator sau să scurgă informații pe care nu ar trebui să le expună niciodată. În loc să atace modelul după implementare, un atacator atacă materialul brut din care este construit modelul.

Ideea centrală din spatele otrăvirii datelor este simplă și tulburătoare: un model de inteligență artificială este la fel de demn de încredere ca și datele din care a învățat. Dacă acele date sunt corupte, părtinitoare sau capcane înainte de începerea antrenamentului, nicio analiză de cod, testare sau monitorizare a rulării efectuată în aval nu va detecta defectul fundamental, deoarece modelul funcționează exact așa cum a fost (în mod rău intenționat) învățat să facă.

Intoxicația datelor prin inteligență artificială vs. vulnerabilități software tradiționale #

Securitatea tradițională a aplicațiilor presupune că pericolul se află în cod: o funcție defectuoasă, o bibliotecă fără patch-uri, un server configurat greșit. Otrăvirea datelor prin inteligență artificială încalcă complet această presupunere. Nu există nicio linie de cod vulnerabilă de găsit, deoarece coruperea a avut loc într-un set de antrenament, un set de date de reglare fină sau un index de recuperare cu mult înainte de scrierea oricărui cod sau de implementarea oricărui model.

De aceea, otrăvirea datelor prin inteligență artificială este deosebit de greu de depistat cu instrumentele vechi. SAST scanerul citește codul. Un scaner de dependențe citește manifestele pachetelor. Niciunul dintre ele nu citește un corpus de antrenament de mai mulți gigaocteți sau o bază de date vectorială plină de documente încorporate, ceea ce este precisÎn special acolo unde otrăvirea datelor prin inteligență artificială își face pagubele. Cercetătorii de securitate și dezvăluiți în mod responsabil. Altele sunt găsite și transformate în arme de către atacatori mai întâi, acesta fiind scenariul care provoacă cele mai mari daune.

Cum funcționează de fapt atacurile de otrăvire a datelor? #

Atacurile de otrăvire a datelor iau, în general, una din următoarele forme:

• Intoxicarea datelor de antrenamentUn atacator introduce exemple manipulate, etichetate greșit sau rău intenționate în setul de date utilizat pentru a antrena un model de la zero sau pentru a regla fin unul existent, determinându-l să învețe o prejudecată ascunsă sau un comportament de tip backdoor.
• Răsturnarea etichetelor: o versiune mai subtilă a celei de mai sus, în care un atacator modifică doar etichetele unui mic subset de exemple de antrenament, denaturând discret ceea ce modelul învață să asocieze cu ce.
• RAG și otrăvirea contextualăÎn sistemele de generare augmentată prin recuperare, un atacator introduce documente otrăvite în baza de cunoștințe sau în depozitul vectorial din care modelul preia date în timpul execuției, astfel încât modelul repetă cu încredere informații false sau manipulate ca și cum ar fi fapte verificate.
• Declanșatoare Backdoorun atacator încorporează un model specific în datele de antrenament astfel încât modelul se comportă normal în aproape fiecare caz, dar produce o ieșire aleasă de atacator în momentul în care apare o frază de declanșare sau o intrare ascunsă.
• Intoxicația lanțului de aprovizionare: un atacator compromite un set de date public sau partajat, un punct de control al modelului pre-antrenat sau o încorporare pipeline în amonte, astfel încât fiecare echipă din aval care trage din el moștenește otrava fără a atinge vreodată atacul inițial.

Ceea ce leagă toate aceste atacuri de otrăvire a datelor este sincronizarea. Daunele se produc înainte ca modelul să răspundă vreodată unui utilizator real, motiv pentru care sintagma „înainte să scrie vreodată o linie de cod” descrie această amenințare atât de precoce.cisely: modelul este compromis la fundația sa, nu la rezultat.

Cum corupe atacatorii un model de inteligență artificială înainte ca acesta să scrie măcar o linie de cod? #

Fiecare atac de otrăvire a datelor descris mai sus are același avantaj temporal: compromiterea are loc în amonte, cu mult înainte ca un model să genereze o singură ieșire pe care utilizatorul să o vadă vreodată. Nu există nicio funcție vulnerabilă la patch-uri și nicio aplicație rău intenționată. commit de prins în revistă, deoarece modelul nu a scris încă nimic. A doar învățat, iar ceea ce a învățat este deja greșit.

Asta face ca otrăvirea datelor de către inteligența artificială să fie fundamental diferită de vulnerabilitățile pe care echipele de securitate ale aplicațiilor sunt antrenate să le vâneze. Un model cu backdoor arată identic cu unul curat într-o diferență de cod. Acesta trece printr-un pull request revizuire. Compilează, implementează și răspunde corect la majoritatea interogărilor, până când condiția specifică plantată de un atacator apare în cele din urmă în producție. Până atunci, întrebarea nu mai este „ce cod a introdus asta”, ci „ce date au făcut și cât de mult timp în urmă merge”.

De ce otrăvirea datelor generate de inteligența artificială este o prioritate din ce în ce mai mare? #

Intoxicația cu date despre inteligența artificială nu mai este o preocupare teoretică. Este recunoscută oficial ca fiind LLM04: Intoxicație cu date și modele în Top 10 OWASP pentru aplicații LLM, alături de injectarea promptă și riscul lanțului de aprovizionare, ca una dintre amenințările definitorii ale erei inteligenței artificiale generative. Trei tendințe o împing mai sus pe radarul fiecărei echipe de securitate:

• Daunele sunt invizibile până când nu sunt declanșate. Un model otrăvit poate trece fiecare test funcțional și se poate comporta perfect timp de luni de zile, până când condiția de declanșare specifică plantată de un atacator apare în sfârșit în producție.

• Generarea augmentată prin recuperare este peste tot. Orice sistem care permite unui model să extragă context live din documente, wiki-uri, tichete sau o bază de date vectorială are o suprafață de intrare nouă, neauditată, iar acea suprafață este exact ceea ce vizează atacurile de otrăvire a datelor.

• Seturile de date sunt acum active ale lanțului de aprovizionare. Echipele extrag în mod curent modele pre-antrenate, încorporări și seturi de date publice din surse externe în același mod în care extrag pachete open-source și, la fel ca un pachet compromis, un set de date compromis poate transmite atacul în mod silențios în fiecare echipă care îl utilizează.

Detectarea și apărarea împotriva otrăvirii datelor #

Deoarece otrăvirea datelor are loc în amonte de modelul în sine, apărarea trebuie să înceapă și ea în amonte:

• Fiți atenți la sursele de date anormale, nu doar la codul anormal. Detectarea comportamentului și a anomaliilor trebuie să se extindă până la locul unde datele intră în pipeline, nu se oprește la limita depozitului.

• Cunoașteți fiecare set de date din pipeline. Nu poți audita un risc de otrăvire într-un set de date despre care nu știi că există. Descoperirea continuă a seturilor de date de antrenare, evaluare și recuperare este prima linie de apărare.

• Urmăriți linia de la setul de date la model și la rezultat. Maparea traseului pe care îl parcurge un set de date într-un model și de la un model la un agent, un punct final sau un instrument de codare este ceea ce transformă ideea „am obținut un rezultat greșit” în „știm exact ce set de date l-a introdus”.

• Examinați sursele de recuperare, nu doar seturile de antrenament. În sistemele RAG, depozitul de vectori și baza de cunoștințe necesită aceleași verificări de integritate ca și datele de antrenament, deoarece otrăvirea contextului are loc în momentul interogării, nu în momentul antrenamentului.

Cum ajută Xygeni la eliminarea decalajului de intoxicație a datelor? #

Apărarea împotriva otrăvirii datelor începe cu vizibilitatea pe care majoritatea organizațiilor pur și simplu nu o au. Xygeni'Inventarul AI descoperă continuu fiecare activ AI din întreaga rețea SDLC, inclusiv seturile de date din spatele lor: date de antrenament, seturi de evaluare și surse RAG sau de recuperare, și le mapează într-un grafic de relații live care rulează de la setul de date la model și la punct final către agent către serverul MCP către instrumentul de codare. Acel grafic este cel care transformă un rezultat suspect al modelului într-o întrebare trasabilă: ce set de date a alimentat acest rezultat și de unde a provenit.

Pe lângă acel inventar, Xygeni's Securitate AI detectează punctele slabe ale vectorilor și integrării, inclusiv contextul otrăvit în recuperarea datelor și RAG pipelines, aliniat cu Top 10 OWASP pentru aplicații LLM. În loc să aibă încredere că sursele de antrenament și recuperare ale unui model sunt curate, Xygeni le tratează ca parte a suprafeței de atac, la fel cum tratează deja codul, dependențele și... pipelineDacă în prezent nu puteți răspunde la întrebarea „ce date au antrenat acest model și putem demonstra acest lucru”, aceasta este exact discrepanța care merită eliminată înainte ca un incident de otrăvire a datelor de către inteligența artificială să impună întrebarea.

FAQ #