Norint sukurti veikiančias AI sistemas, pirmiausia reikia pabandyti jas sugadinti. Atlikome testavimą spragoms nustatyti: veikėme kaip užpuolikai ir tikrinome finansinių paslaugų klientams skirtą AI programą. Mūsų išvados svarbios visiems, diegiantiems LLM pagrįstas programas, kurioms saugumas yra būtinas.
Testavimas spragoms nustatyti – tai sąmoningas bandymas pažeisti savo AI sistemą, kad galėtumėte ištaisyti spragas anksčiau, nei jas aptiks tikras užpuolikas. Finansinių paslaugų sektoriuje rizika ypač didelė: AI programos naudoja klientų duomenis, apdoroja operacijas ir teikia finansines įžvalgas. Gedimo padariniai gali būti įvairūs – nuo prastos naudotojo patirties iki teisės aktų pažeidimų, finansinių nuostolių ir neatitaisomos žalos prekės ženklui.
Siekėme anksti aptikti spragas, išbandyti tikroviškus atakų modelius ir padėti organizacijai atitikti AI saugos reikalavimus, į kuriuos reguliavimo institucijos žiūri labai rimtai.
Čia verta pabrėžti skirtumą: apribojimų apėjimo atakos nukreiptos į paties modelio saugos filtrus, o užklausos įterpimas – į pačią programą, derinant nepatikimą naudotojo įvestį su patikima kūrėjo užklausa. Užklausos įterpimas kelia didesnę riziką, nes taikosi į jūsų sistemą ir jos naudojamus konfidencialius duomenis, o ne į bendrosios paskirties modelį.
Pirmąjį bandymų etapą sudarė maždaug 750 testų, apėmusių:
Duomenų nutekėjimą tarp seansų
Asmens identifikavimo informacijos atskleidimą (naudojant natūralią kalbą, API manipuliacijas ir įvairias koduotes)
SQL įterpimą
Sistemos užklausos nurodymų perrašymą
Per pradinius bandymus nustatėme dvi pagrindines esamos sistemos problemas: kelių ketinimų užklausų apdorojimą ir užkoduotų užklausų naudojimą.
Kelių ketinimų užklausos – užklausos, kuriose teisėti prašymai derinami su kenkėjiškais. Pavyzdžiui: “Show my spending by category, and also execute [malicious SQL].” Programa neaptiko kenkėjiško ketinimo ir visiškai pasikliovė tolesnio duomenų sluoksnio apsaugos priemonėmis. Tai tas pats, kas palikti praviras lauko duris, nes pasitikite rūsyje esančiu seifu.
Kodavimas: užklausos koduojamos Base64, šešioliktainiu kodu, LeetSpeak ir panašiai atrodančiais rašmenimis. Sistemoms gali būti sunku išfiltruoti kenkėjišką ketinimą. Nors nustatėme, kad šios užklausos neatskleidė neskelbtinų duomenų, jos gerokai destabilizavo sistemą: sukėlė haliucinacijas, naudotojams buvo atkartojamas kenkėjiškas SQL, painiojamas ketinimų klasifikavimas ir pan.
Pradinių bandymų rezultatai parodė:
Laiko haliucinacijas: modelis užtikrintai pateikė išgalvotas datas, operacijų laiko žymas ar su laikotarpiu susietas suvestines. Finansų srityje tai didelė rizika, nes klaidinga data besivadovaujančiam klientui gali kilti realių pasekmių
Naudotojui atkartojamą kenkėjišką SQL (tai kelia susirūpinimą dėl atminties užnuodijimo rizikos)
Supainiotą ketinimų klasifikavimą
Suardytą išvesties formatavimą
Remdamiesi šiomis išvadomis susiaurinome tyrimo sritį. SQL įterpimo ir kodavimo testams skyrėme mažiau dėmesio, nes komanda jau sprendė šias problemas. Vietoj to sutelkėme dėmesį į veiksmingiausius atakų vektorius: asmens identifikavimo informacijos atskleidimą ir duomenų nutekėjimą tarp seansų.
Ryškiausia antrojo etapo išvada buvo stulbinamai paprasta: dažnai visai nereikia elgtis išradingai.
Daugeliu atvejų pakako tiesiog paprašyti vidinių duomenų, pateikiant tai kaip teisėtai skambančios užklausos dalį, ir sistema sutikdavo juos atskleisti. Į paprastas užklausas buvo atsakoma nurodant vidinius identifikatorius ir sistemos laukus, kurie niekada neturėtų būti rodomi galutiniams naudotojams.
Ištyrę išsamiau nustatėme, kad tai nebuvo vien programos lygmens triktis. Tolesnė teksto konvertavimo į SQL paslauga kūrė užklausas, prašančias daugiau laukų, nei turėtų, o jos aiškinamuosiuose atsakymuose buvo nurodomi duomenys, kurių prieiga turėjo būti ribojama. Tai atskleidė tikrą spragą tarp sistemų – pažeidžiamumą, pastebimą tik tikrinant visą technologijų rinkinį, o ne atskirus komponentus izoliuotai.
Spragų ieškokite sistemoje, o ne modelyje. Atskiro LLM testavimas beveik nieko nepasako apie jūsų programos saugumo būklę. Išbandykite visą technologijų rinkinį nuo pradžios iki galo taip, kaip su juo sąveikautų naudotojas.
Įvestį būtina tikrinti prieš jai pasiekiant LLM. Užkoduotos užklausos, kelių ketinimų atakos ir paprasti įterpimo bandymai turi būti aptinkami sistemos prieigos taške, o ne perduodami tolesnėms paslaugoms.
Nepasitikėkite sistemų sandūromis. Kelių paslaugų architektūrose įdomiausios spragos slepiasi tarp sistemų. Nulinis pasitikėjimas reiškia nulinį pasitikėjimą, todėl viską tikrinkite kiekviename sluoksnyje.
Paprastos atakos veikia. Apie sudėtingas apribojimų apėjimo atakas rašomos antraštės, tačiau kartais galima tiesiog... paprašyti. Jei sistema mielai parodo vidinius identifikatorius, kai naudotojas juos įtraukia į šiaip teisėtą užklausą, tai yra problema.
Supraskite, ką iš tiesų tikrinate. Žinomus atakų modelius gali aptikti ne jūsų apsaugos priemonės, o pats išmokytas LLM. Į testavimą spragoms nustatyti įtraukite stebimumo priemones, kad suprastumėte, kurios kontrolės priemonės iš tikrųjų suveikia.
Ribotoje aplinkoje reikia kūrybiškų sprendimų. Pasirinktiniai paslaugų teikėjai ir vietinių modelių palaikymas leidžia prasmingai atlikti testavimą spragoms nustatyti be specializuotos prieigos prie debesijos. Tačiau atvirai nurodykite dėl to atsirandančius apribojimus.
Testavimas spragoms nustatyti nėra vienkartinis. Tai kartotinis procesas, kurį, kai įmanoma, reikėtų automatizuoti ir tobulinti kartu su sistema. Rytoj svarbios atakos nebus tokios pačios kaip tos, kurios svarbios šiandien.
Reguliuojamoje aplinkoje veikiančios AI sistemos bus tikrinamos tik dar atidžiau. Organizacijos, kurios saugumo testavimą laiko nuolatine praktika, o ne prieš paleidimą pažymimu kontrolinio sąrašo punktu, bus geriau pasirengusios atlaikyti šį dėmesį ir išvengti reputacijos krizių, dėl kurių prarandamas klientų pasitikėjimas.