Da biste izgradili funkcionalne AI sisteme, prvo ih morate pokušati slomiti. Proveli smo red teaming, preuzevši ulogu napadača kako bismo testirali i ispitali korisničku AI aplikaciju u sektoru finansijskih usluga. Ono što smo otkrili važno je svima koji uvode aplikacije zasnovane na LLM-ovima u okruženjima gdje sigurnost nije stvar izbora.
Red teaming je praksa namjernog pokušaja da se AI sistem slomi kako biste otklonili ranjivosti prije nego što ih otkrije pravi napadač. U finansijskim uslugama ulozi su naročito visoki: AI aplikacije pristupaju podacima klijenata, obrađuju transakcije i pružaju finansijske uvide. Posljedice kvara mogu biti od lošeg korisničkog iskustva do kršenja propisa, finansijskih gubitaka i nepopravljive štete za brend.
Cilj nam je bio rano otkriti ranjivosti, testirati realistične obrasce napada i pomoći organizaciji da ispuni očekivanja u pogledu sigurnosti AI-ja, koja regulatori shvataju vrlo ozbiljno.
Ovdje vrijedi napraviti razliku: jailbreak napada sigurnosne filtere osnovnog modela, dok ubrizgavanje upita napada samu aplikaciju, koristeći nepouzdani korisnički unos zajedno s pouzdanim upitom programera. Ubrizgavanje upita predstavlja veći rizik jer cilja vaš sistem i povjerljive podatke koje obrađuje, a ne model opće namjene.
Naš prvi krug obuhvatio je približno 750 testova u sljedećim područjima:
Curenje podataka između sesija
Izlaganje ličnih podataka (PII) putem prirodnog jezika, manipulacije API-jem i različitih kodiranja
Ubrizgavanje SQL-a
Zaobilaženje sistemskog upita
Tokom početnog testiranja otkrili smo dva velika problema u postojećem sistemu: obradu upita s više namjera i korištenje kodiranih upita.
Upiti s više namjera: zahtjevi koji objedinjuju legitimne i zlonamjerne naredbe. Naprimjer: “Show my spending by category, and also execute [malicious SQL].” Aplikacija nije prepoznala zlonamjernu namjeru, već se u potpunosti oslanjala na zaštitne mjere u podatkovnom sloju. To je kao da ostavite ulazna vrata otvorena jer vjerujete sefu u podrumu.
Kodiranje: zahtjevi kodirani formatima Base64, Hex i LeetSpeak te homoglifima. Sistemima može biti teško filtrirati zlonamjerne namjere. Iako smo utvrdili da ovi upiti nisu izložili osjetljive podatke, znatno su destabilizirali sistem (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 značajan rizik u finansijskom kontekstu, gdje postupanje klijenta na osnovu pogrešnog datuma može imati stvarne posljedice
Ponavljanje zlonamjernog SQL-a korisniku (zabrinjavajuće zbog rizika od trovanja memorije)
Pogrešna klasifikacija namjere
Narušeno formatiranje izlaznih podataka
Na osnovu tih saznanja suzili smo fokus. Testovi ubrizgavanja SQL-a i kodiranja dobili su niži prioritet jer ih je tim već rješavao. Umjesto toga, usredotočili smo se na najuspješnije vektore napada: izlaganje ličnih podataka i curenje između sesija.
Najupečatljiviji nalaz iz drugog kruga bio je razoružavajuće jednostavan: često uopće ne morate biti domišljati.
U mnogim slučajevima bilo je dovoljno jednostavno zatražiti interne podatke u okviru naizgled legitimnog zahtjeva da bi sistem pristao izložiti ih. Na jednostavne upite stizali su odgovori koji su navodili interne identifikatore i sistemska polja koja se krajnjim korisnicima nikada ne bi smjela prikazati.
Daljnjim ispitivanjem otkrili smo da to nije bio samo propust na nivou aplikacije. Nizvodna usluga za pretvaranje teksta u SQL sastavljala je upite koji su tražili više polja nego što bi smjeli, a njeni odgovori s objašnjenjima navodili su podatke kojima je pristup trebao biti ograničen. Time je otkrivena stvarna pukotina između sistema — vrsta ranjivosti koja se pojavi tek kada testirate cijeli tehnološki sklop, a ne pojedinačne komponente zasebno.
Provodite red teaming sistema, a ne modela. Testiranje izoliranog LLM-a govori vam vrlo malo o nivou sigurnosti vaše aplikacije. Testirajte cijeli tehnološki sklop od početka do kraja, onako kako bi ga koristio korisnik.
Unos se mora provjeriti prije nego što dođe do LLM-a. Kodirani upiti, napadi s više namjera i osnovni pokušaji ubrizgavanja trebaju biti zaustavljeni na ulazu, a ne prepušteni nizvodnim uslugama.
Ne vjerujte spojevima između sistema. U arhitekturama s više usluga najzanimljivije ranjivosti kriju se u pukotinama između sistema. Nulto povjerenje znači upravo to, pa provjeravajte sve na svakom sloju.
Jednostavni napadi uspijevaju. Sofisticirani jailbreak napadi dospijevaju na naslovnice, ali ponekad možete samo... pitati. Ako vaš sistem bez oklijevanja prikaže interne identifikatore kada ih korisnik uključi u inače legitiman upit, imate problem.
Shvatite šta zapravo testirate. Poznate obrasce napada može zaustaviti obuka samog LLM-a, a ne vaše zaštitne mjere. Ugradite opservabilnost u red teaming kako biste razumjeli koje se kontrole zaista aktiviraju.
Ograničena okruženja zahtijevaju kreativna rješenja. Prilagođeni pružaoci usluga i podrška za lokalne modele omogućavaju smislen red teaming bez specijaliziranog pristupa oblaku. Ali budite otvoreni u pogledu ograničenja koja to donosi.
Red teaming nije jednokratan postupak. To je iterativan proces koji treba automatizirati gdje god je moguće i razvijati ga zajedno sa sistemom. Napadi koji će biti važni sutra nisu isti kao oni koji su važni danas.
AI sistemi u reguliranim okruženjima bit će izloženi samo većem, a ne manjem nadzoru. Organizacije koje testiranje sigurnosti tretiraju kao kontinuiranu disciplinu, a ne kao stavku koju treba označiti prije pokretanja, bit će spremnije odgovoriti na taj nadzor i izbjeći PR katastrofe zbog kojih gube povjerenje klijenata.