Pentru a construi sisteme IA care funcționează, trebuie mai întâi să încerci să le compromiți. Am desfășurat un exercițiu de red teaming, acționând ca atacatori pentru a testa și analiza o aplicație IA destinată clienților din sectorul serviciilor financiare. Constatările noastre sunt relevante pentru oricine implementează aplicații bazate pe LLM în domenii în care securitatea este obligatorie.
Red teamingul este practica de a încerca în mod deliberat să compromiți un sistem IA, astfel încât să poți remedia vulnerabilitățile înainte ca un atacator real să le descopere. În serviciile financiare, mizele sunt deosebit de ridicate: aplicațiile IA accesează datele clienților, procesează tranzacții și furnizează informații financiare. Consecințele unei defecțiuni pot varia de la o experiență neplăcută pentru utilizatori până la încălcări ale reglementărilor, pierderi financiare și prejudicii ireparabile aduse imaginii mărcii.
Obiectivul nostru a fost să identificăm din timp vulnerabilitățile, să testăm tipare de atac realiste și să ajutăm organizația să îndeplinească cerințele de siguranță IA pe care autoritățile de reglementare le tratează cu maximă seriozitate.
Trebuie făcută o distincție: atacurile de tip jailbreak vizează filtrele de siguranță ale modelului de bază, iar injectarea de solicitări atacă aplicația propriu-zisă, folosind date nevalidate introduse de utilizator împreună cu solicitarea de încredere a dezvoltatorului. Injectarea de solicitări prezintă un risc mai mare, deoarece vizează sistemul și datele confidențiale pe care acesta le prelucrează, nu un model de uz general.
Prima rundă a cuprins aproximativ 750 de teste privind:
Scurgerea datelor între sesiuni
Expunerea datelor cu caracter personal (prin limbaj natural, manipularea API-ului și diverse codificări)
Injectarea SQL
Suprascrierea solicitării de sistem
În timpul testării inițiale, am identificat două probleme majore ale sistemului existent: gestionarea interogărilor cu intenții multiple și utilizarea solicitărilor codificate.
Interogări cu intenții multiple: solicitări care combină cereri legitime cu unele rău intenționate. De exemplu: „Show my spending by category, and also execute [malicious SQL].” Aplicația nu detecta intenția rău intenționată, bazându-se în totalitate pe mecanismele de protecție ale nivelului de date din aval. Este ca și cum ai lăsa deschisă ușa de la intrare pentru că ai încredere în seiful din subsol.
Codificare: solicitări codificate în Base64, Hex, LeetSpeak și cu ajutorul omoglifelor. Sistemelor le poate fi dificil să filtreze intențiile rău intenționate. Deși am constatat că aceste interogări nu expuneau date sensibile, destabilizau totuși semnificativ sistemul: halucinații, repetarea către utilizatori a unor instrucțiuni SQL rău intenționate, clasificarea eronată a intențiilor etc.
Rezultatele testării inițiale au evidențiat:
Halucinații temporale: modelul furniza cu încredere date calendaristice, marcaje temporale ale tranzacțiilor sau rezumate asociate unor perioade, dar inventate, un risc semnificativ în domeniul financiar, unde deciziile unui client bazate pe o dată greșită pot avea consecințe reale
Repetarea către utilizator a unor instrucțiuni SQL rău intenționate (îngrijorătoare din perspectiva riscului de contaminare a memoriei)
Clasificarea eronată a intențiilor
Formatarea dezordonată a rezultatelor
Pornind de la aceste constatări, ne-am restrâns aria de interes. Testele de injectare SQL și de codificare au primit o prioritate mai mică, deoarece echipa lucra deja la aceste probleme. Ne-am concentrat în schimb asupra celor mai eficiente metode de atac: expunerea datelor cu caracter personal și scurgerile între sesiuni.
Cea mai frapantă constatare din a doua rundă a fost dezarmant de simplă: adesea nu trebuie să recurgi deloc la metode ingenioase.
În multe cazuri, era suficient să ceri date interne în cadrul unei solicitări aparent legitime pentru ca sistemul să accepte să le divulge. Interogările simple primeau răspunsuri care menționau ID-uri interne și câmpuri de sistem care nu ar trebui afișate niciodată utilizatorilor finali.
Analizând problema în profunzime, am constatat că nu era doar o defecțiune la nivelul aplicației. Serviciul text-to-SQL din aval construia interogări care solicitau mai multe câmpuri decât ar fi trebuit, iar răspunsurile sale explicative menționau date care ar fi trebuit restricționate. Aceasta a scos la iveală o breșă reală între sisteme, genul de vulnerabilitate care apare numai când testezi întregul ansamblu, nu componentele individuale în mod izolat.
Supune sistemul, nu modelul, unui proces de red teaming. Testarea izolată a unui LLM oferă foarte puține informații despre nivelul de securitate al aplicației. Testează întregul ansamblu, de la un capăt la altul, așa cum ar interacționa un utilizator cu acesta.
Validarea datelor de intrare trebuie să aibă loc înainte de LLM. Interogările codificate, atacurile cu intenții multiple și tentativele elementare de injectare trebuie detectate la perimetru, nu delegate serviciilor din aval.
Nu te baza pe punctele de legătură. În arhitecturile cu mai multe servicii, cele mai interesante vulnerabilități se ascund în fisurile dintre sisteme. Încrederea zero înseamnă încredere zero, așa că validează totul la fiecare nivel.
Atacurile simple funcționează. Atacurile jailbreak sofisticate ajung în prim-plan, dar uneori poți pur și simplu să... întrebi. Dacă sistemul afișează fără ezitare identificatori interni atunci când un utilizator îi include într-o interogare care, în rest, este legitimă, ai o problemă.
Înțelege ce testezi de fapt. Tiparele de atac cunoscute pot fi detectate datorită instruirii LLM-ului, nu mecanismelor tale de protecție. Integrează observabilitatea în procesul de red teaming pentru a înțelege ce mecanisme de control sunt activate efectiv.
Mediile cu restricții necesită soluții creative. Furnizorii personalizați și compatibilitatea cu modele locale permit desfășurarea unui proces relevant de red teaming fără acces specializat la servicii cloud. Trebuie însă să prezinți transparent limitările rezultate.
Red teamingul nu este o activitate singulară. Este un proces iterativ, care trebuie automatizat în măsura în care este posibil și care trebuie să evolueze odată cu sistemul. Atacurile care vor conta mâine nu sunt aceleași cu cele relevante de azi.
Sistemele IA din mediile reglementate vor fi supuse unui control tot mai atent. Organizațiile care tratează testarea securității ca pe o disciplină continuă și nu ca pe o simplă bifă înainte de lansare, vor fi mai bine pregătite să facă față acestui control și să evite crizele de imagine care le-ar putea costa încrederea clienților.