Da biste izgradili funkcionalne AI sustave, najprije ih morate pokušati slomiti. Proveli smo red-team testiranje, preuzevši ulogu napadača kako bismo testirali i ispitali korisničku AI aplikaciju u sektoru financijskih usluga. Naši su nalazi važni svima koji uvode aplikacije pogonjene LLM-ovima u okruženjima u kojima sigurnost nije opcionalna.
Red-team testiranje podrazumijeva namjerne pokušaje probijanja AI sustava kako biste otklonili ranjivosti prije nego što ih pronađe pravi napadač. U financijskim su uslugama ulozi osobito visoki: AI aplikacije obrađuju podatke o klijentima i transakcije te pružaju financijske uvide. Posljedice propusta mogu biti sve od lošeg korisničkog iskustva do kršenja propisa, financijskih gubitaka i nepopravljive štete za ugled brenda.
Cilj nam je bio rano pronaći ranjivosti, testirati realistične obrasce napada i pomoći organizaciji da ispuni zahtjeve za sigurnost umjetne inteligencije koje regulatori shvaćaju vrlo ozbiljno.
Ovdje valja istaknuti jednu razliku: jailbreak napada sigurnosne filtre temeljnog modela, dok ubrizgavanje upita napada samu aplikaciju, spajajući nepouzdani korisnički unos s pouzdanim upitom razvojnog programera. Ubrizgavanje upita predstavlja veći rizik jer cilja vaš sustav i povjerljive podatke koje obrađuje, a ne model opće namjene.
Naš prvi krug obuhvatio je približno 750 testova iz sljedećih područja:
Curenje podataka između sesija
Izlaganje osobnih identifikacijskih podataka (PII) putem prirodnog jezika, manipulacije API-jem i različitih kodiranja
Umetanje SQL koda
Nadjačavanje sistemskih upita
Tijekom početnog testiranja utvrdili smo dva velika problema postojećeg sustava: obradu upita s više namjera i upotrebu kodiranih upita.
Upiti s više namjera: zahtjevi koji objedinjuju legitimne i zlonamjerne naredbe. Na primjer: „Prikaži moju potrošnju po kategorijama i izvrši [zlonamjerni SQL kôd].” Aplikacija nije prepoznavala zlonamjernu svrhu dijela upita, nego se u potpunosti oslanjala na zaštitne mehanizme podatkovnog sloja. To je kao da ostavite ulazna vrata otvorena jer vjerujete sefu u podrumu.
Kodiranje: zahtjevi kodirani formatima Base64, Hex i LeetSpeak te homoglifima. Sustavima može biti teško filtrirati zlonamjerne namjere. Iako smo utvrdili da ti upiti nisu izlagali osjetljive podatke, znatno su destabilizirali sustav (halucinacije, ponavljanje zlonamjernog SQL-a korisnicima, pogrešna klasifikacija namjere itd.).
Rezultati početnog testiranja pokazali su sljedeće:
Vremenske halucinacije: model samouvjereno navodi izmišljene datume, vremenske oznake transakcija ili vremenski ograničene sažetke. To je znatan rizik u financijskom kontekstu, u kojem postupanje klijenta na temelju pogrešnog datuma može imati stvarne posljedice
Ponavljanje zlonamjernog SQL-a korisniku (zabrinjavajuće zbog rizika od trovanja memorije)
Pogrešna klasifikacija namjere
Neuredno oblikovanje izlaznih podataka
Na temelju tih nalaza suzili smo fokus. Testovi umetanja SQL koda i kodiranja dobili su manji prioritet jer se tim već bavio tim problemima. Umjesto toga usredotočili smo se na najuspješnije vektore napada: izlaganje osobnih podataka i curenje podataka između sesija.
Najupečatljiviji nalaz drugog kruga bio je razoružavajuće jednostavan: često uopće ne morate biti domišljati.
U mnogim je slučajevima bilo dovoljno jednostavno zatražiti interne podatke u sklopu naizgled legitimnog zahtjeva da ih sustav pristane izložiti. Na jednostavne upite stizali su odgovori koji su spominjali interne identifikatore i sistemska polja koja se krajnjim korisnicima nikada ne bi smjela prikazati.
Dubljom analizom otkrili smo da to nije bio samo propust na razini aplikacije. Nizvodna usluga za pretvaranje teksta u SQL sastavljala je upite koji su tražili više polja nego što bi smjeli, a njezini su odgovori s objašnjenjima spominjali podatke kojima je pristup trebao biti ograničen. Time je otkrivena stvarna pukotina između sustava, vrsta ranjivosti koja izlazi na vidjelo samo kada testirate cijeli tehnološki stog, a ne pojedinačne komponente zasebno.
Red-team testirajte sustav, a ne model. Testiranje LLM-a zasebno otkriva vrlo malo o sigurnosti vaše aplikacije. Testirajte cijeli tehnološki stog od početka do kraja, onako kako bi ga koristio korisnik.
Ulazni podaci moraju se validirati prije LLM-a. Kodirane upite, napade s više namjera i osnovne pokušaje ubrizgavanja treba zaustaviti na ulazu, a ne prepustiti nizvodnim uslugama.
Ne vjerujte spojevima između sustava. U arhitekturama s više usluga najzanimljivije se ranjivosti kriju u pukotinama između sustava. Nulto povjerenje doista znači nulto povjerenje, stoga sve validirajte na svakom sloju.
Jednostavni napadi uspijevaju. Sofisticirani jailbreak napadi pune naslovnice, ali ponekad je dovoljno samo... pitati. Ako vaš sustav spremno prikaže interne identifikatore kada ih korisnik uključi u inače legitiman upit, imate problem.
Shvatite što zapravo testirate. Poznate obrasce napada možda zaustavlja obuka samog LLM-a, a ne vaši zaštitni mehanizmi. U red-team testiranje ugradite mogućnost praćenja kako biste razumjeli koje se kontrole doista aktiviraju.
Ograničena okruženja zahtijevaju kreativna rješenja. Prilagođeni pružatelji usluga i podrška za lokalne modele omogućuju učinkovito red-team testiranje bez specijaliziranog pristupa oblaku. No budite transparentni u pogledu ograničenja koja to donosi.
Red-team testiranje nije jednokratan postupak. To je iterativan proces koji treba automatizirati gdje god je moguće i razvijati usporedno sa sustavom. Napadi koji će biti važni sutra nisu isti kao oni koji su važni danas.
AI sustavi u reguliranim okruženjima bit će izloženi sve većem, a ne manjem nadzoru. Organizacije koje sigurnosno testiranje smatraju trajnom disciplinom, a ne stavkom koju treba označiti prije lansiranja, bit će spremnije odgovoriti na taj nadzor i izbjeći komunikacijske katastrofe zbog kojih gube povjerenje klijenata.