Ak chcete vytvoriť funkčné systémy AI, musíte sa ich najprv pokúsiť prelomiť. Uskutočnili sme red teaming, pri ktorom sme v úlohe útočníkov testovali zákaznícku aplikáciu AI v oblasti finančných služieb a hľadali jej slabiny. Naše zistenia sú dôležité pre každého, kto nasadzuje aplikácie využívajúce LLM tam, kde je bezpečnosť nevyhnutnosťou.
Red teaming je postup, pri ktorom sa zámerne pokúšate prelomiť svoj systém AI, aby ste mohli odstrániť zraniteľnosti skôr, než ich nájde skutočný útočník. Vo finančných službách je v stávke mimoriadne veľa: aplikácie AI pracujú s údajmi zákazníkov, spracúvajú transakcie a poskytujú finančné poznatky. Zlyhanie môže viesť k čomukoľvek od zlej používateľskej skúsenosti až po porušenie predpisov, finančné straty a nenapraviteľné poškodenie značky.
Naším cieľom bolo včas nájsť zraniteľnosti, otestovať realistické vzorce útokov a pomôcť organizácii splniť požiadavky na bezpečnosť AI, ktoré regulačné orgány berú veľmi vážne.
Treba rozlišovať medzi dvoma vecami: jailbreak útočí na bezpečnostné filtre základného modelu, kým vkladanie falošných príkazov útočí na samotnú aplikáciu tak, že kombinuje nedôveryhodný vstup používateľa s dôveryhodným príkazom vývojára. Vkladanie falošných príkazov predstavuje väčšie riziko, pretože sa zameriava na váš systém a dôverné údaje, s ktorými pracuje, nie na univerzálny model.
Naše prvé kolo zahŕňalo približne 750 testov zameraných na:
únik údajov medzi reláciami
odhalenie osobných identifikačných údajov (prostredníctvom prirodzeného jazyka, manipulácie s API a rôznych spôsobov kódovania)
SQL injection
prepísanie systémového príkazu
Počas úvodného testovania sme v existujúcom systéme odhalili dva závažné problémy: spracovanie dopytov s viacerými zámermi a používanie zakódovaných príkazov.
Dopyty s viacerými zámermi: požiadavky, ktoré spájajú legitímne a škodlivé pokyny. Napríklad: “Show my spending by category, and also execute [malicious SQL].” Aplikácia škodlivý zámer nezachytila a úplne sa spoliehala na ochranné mechanizmy nadväzujúcej dátovej vrstvy. Je to rovnaké, ako nechať vchodové dvere otvorené, pretože dôverujete trezoru v pivnici.
Kódovanie: požiadavky zakódované pomocou Base64, hexadecimálneho kódu, LeetSpeaku a homoglyfov. Pre systémy môže byť náročné odfiltrovať škodlivý zámer. Hoci sme zistili, že tieto dopyty neodhalili citlivé údaje, výrazne destabilizovali systém (halucinácie, opakovanie škodlivého SQL používateľom, chybné určovanie zámeru a podobne).
Výsledky úvodného testovania ukázali:
Časové halucinácie: model sebavedomo uvádzal vymyslené dátumy, časové pečiatky transakcií alebo súhrny viazané na určité obdobie. Vo finančnom kontexte ide o významné riziko, pretože konanie zákazníka na základe nesprávneho dátumu môže mať reálne následky
Opakovanie škodlivého SQL používateľovi (znepokojujúce vzhľadom na riziko otrávenia pamäte)
Chybné určovanie zámeru
Narušené formátovanie výstupu
Na základe týchto zistení sme zúžili svoje zameranie. Testy SQL injection a kódovania dostali nižšiu prioritu, pretože tím už tieto problémy riešil. Namiesto toho sme sa sústredili na najúspešnejšie vektory útoku: odhalenie osobných identifikačných údajov a únik údajov medzi reláciami.
Najpozoruhodnejšie zistenie z druhého kola bolo odzbrojujúco jednoduché: často vôbec netreba vymýšľať nič dômyselné.
V mnohých prípadoch stačilo o interné údaje jednoducho požiadať v rámci zdanlivo legitímnej požiadavky a systém súhlasil s ich odhalením. Systém na jednoduché dopyty odpovedal s odkazmi na interné identifikátory a systémové polia, ktoré sa koncovým používateľom nikdy nemali zobraziť.
Pri hlbšom skúmaní sme zistili, že nešlo len o zlyhanie na úrovni aplikácie. Nadväzujúca služba na prevod textu na SQL vytvárala dopyty, ktoré požadovali viac polí, než mali, a vo vysvetľujúcich odpovediach odkazovala na údaje, ku ktorým mal byť prístup obmedzený. Odhalilo to skutočnú medzeru medzi systémami – zraniteľnosť, ktorá sa prejaví iba pri testovaní celého technologického reťazca, nie jednotlivých komponentov izolovane.
Red teaming vykonávajte na systéme, nie na modeli. Testovanie izolovaného LLM vám o úrovni zabezpečenia aplikácie veľa nepovie. Testujte celý technologický reťazec od začiatku do konca tak, ako s ním pracuje používateľ.
Vstup sa musí overiť ešte pred LLM. Zakódované dopyty, útoky s viacerými zámermi a základné pokusy o vkladanie falošných príkazov treba zachytiť na hranici systému, nie ich prenechať nadväzujúcim službám.
Nedôverujte rozhraniam medzi systémami. V architektúrach s viacerými službami sa najzaujímavejšie zraniteľnosti ukrývajú v medzerách medzi systémami. Nulová dôvera znamená nulovú dôveru, preto overujte všetko na každej vrstve.
Jednoduché útoky fungujú. Dômyselné jailbreaky plnia titulky, no niekedy sa stačí jednoducho... opýtať. Ak váš systém ochotne odhalí interné identifikátory, keď ich používateľ uvedie v inak legitímnom dopyte, máte problém.
Ujasnite si, čo v skutočnosti testujete. Známe vzorce útokov môže zachytiť samotný tréning LLM, a nie vaše ochranné mechanizmy. Zahrňte do red teamingu pozorovateľnosť, aby ste vedeli, ktoré kontrolné mechanizmy sa skutočne aktivujú.
Obmedzené prostredia si vyžadujú tvorivé riešenia. Vlastní poskytovatelia a podpora lokálnych modelov umožňujú zmysluplný red teaming aj bez špecializovaného prístupu ku cloudu. O obmedzeniach, ktoré to prináša, však komunikujte otvorene.
Red teaming nie je jednorazová záležitosť. Je to opakovaný proces, ktorý treba podľa možností automatizovať a rozvíjať spolu so systémom. Útoky, ktoré budú dôležité zajtra, nie sú rovnaké ako tie dnešné.
Systémy AI v regulovaných prostrediach budú čeliť čoraz prísnejšej kontrole. Organizácie, ktoré považujú bezpečnostné testovanie za trvalú disciplínu, a nie za položku na zozname pred spustením, budú na túto kontrolu lepšie pripravené a vyhnú sa komunikačným katastrofám, ktoré ničia dôveru zákazníkov.