Per crear sistemes d'IA que funcionin, primer cal intentar trencar-los. Vam dur a terme un exercici d'equip vermell en què vam actuar com a atacants per posar a prova i examinar una aplicació d'IA de serveis financers orientada als clients. El que vam descobrir és important per a qualsevol organització que desplegui aplicacions basades en LLM en què la seguretat sigui imprescindible.
L'equip vermell consisteix a intentar trencar deliberadament un sistema d'IA per poder corregir-ne les vulnerabilitats abans que les trobi un atacant real. En els serveis financers, hi ha molt en joc: les aplicacions d'IA tracten dades de clients, processen transaccions i ofereixen informació financera. Una fallada pot provocar des d'una mala experiència d'usuari fins a infraccions normatives, pèrdues financeres i danys irreparables a la marca.
El nostre objectiu era detectar vulnerabilitats aviat, provar patrons d'atac realistes i ajudar l'organització a complir les expectatives de seguretat de la IA que els reguladors es prenen molt seriosament.
Aquí convé fer una distinció: l'evasió de proteccions de seguretat ataca els filtres de seguretat del model subjacent; la injecció d'indicacions ataca l'aplicació mateixa mitjançant entrades d'usuari no fiables combinades amb la indicació de confiança del desenvolupador. La injecció d'indicacions comporta més risc perquè ataca el vostre sistema i les dades confidencials que gestiona, no pas un model d'ús general.
La primera ronda va incloure aproximadament 750 proves sobre:
Filtració de dades entre sessions
Exposició de dades d'identificació personal (PII) mitjançant llenguatge natural, manipulació de l'API i diverses codificacions
Injecció SQL
Anul·lació de les indicacions del sistema
Durant les proves inicials vam identificar dos problemes importants en el sistema existent: el tractament de les consultes amb diverses intencions i l'ús d'indicacions codificades.
Consultes amb diverses intencions: sol·licituds que combinen peticions legítimes i malicioses. Per exemple: "Show my spending by category, and also execute [malicious SQL]." L'aplicació no detectava la intenció maliciosa, sinó que confiava completament en les mesures de protecció de la capa de dades posterior. És com deixar oberta la porta de casa perquè confies en la caixa forta del soterrani.
Codificació: sol·licituds codificades en Base64, hexadecimal, LeetSpeak i homoglifs. Als sistemes els pot resultar difícil filtrar la intenció maliciosa. Tot i que aquestes consultes no exposaven dades sensibles, sí que desestabilitzaven considerablement el sistema: provocaven al·lucinacions, repetien SQL maliciós als usuaris, confonien la classificació d'intencions, etc.
Els resultats de les proves inicials van mostrar:
Al·lucinacions temporals: el model retornava dates, marques temporals de transaccions o resums de períodes inventats, però expressats amb seguretat. Això suposa un risc important en l'àmbit financer, on actuar basant-se en una data errònia pot tenir conseqüències reals
Repetició de SQL maliciós a l'usuari, fet preocupant pel risc d'enverinament de la memòria
Confusió en la classificació d'intencions
Format de sortida desordenat
Amb aquests resultats, vam restringir l'àmbit d'anàlisi. Vam reduir la prioritat de les proves d'injecció SQL i codificació, perquè l'equip ja hi estava treballant. En canvi, ens vam centrar en els vectors d'atac més efectius: l'exposició de PII i la filtració entre sessions.
La troballa més sorprenent de la segona ronda era desconcertantment senzilla: sovint no cal fer res d'enginyós.
En molts casos, n'hi havia prou de demanar dades internes dins d'una sol·licitud aparentment legítima perquè el sistema acceptés exposar-les. Consultes senzilles obtenien respostes que feien referència a identificadors interns i camps del sistema que mai no haurien d'arribar als usuaris finals.
En aprofundir-hi, vam descobrir que no era només una fallada de l'aplicació. El servei posterior de text a SQL generava consultes que sol·licitaven més camps dels necessaris, i les seves respostes explicatives feien referència a dades que haurien d'haver estat restringides. Això va revelar una esquerda real entre els sistemes, el tipus de vulnerabilitat que només apareix quan es prova tota la pila i no els components per separat.
Apliqueu l'equip vermell al sistema, no al model. Provar un LLM de manera aïllada aporta molt poca informació sobre el nivell de seguretat de l'aplicació. Proveu tota la pila de cap a cap, tal com hi interactuaria un usuari.
Les entrades s'han de validar abans que arribin al LLM. Les consultes codificades, els atacs amb diverses intencions i els intents bàsics d'injecció s'han de detectar al perímetre, no delegar-los als serveis posteriors.
No confieu en els punts d'unió. En les arquitectures amb diversos serveis, les vulnerabilitats més interessants s'amaguen a les esquerdes entre sistemes. Confiança zero vol dir confiança zero: valideu-ho tot a cada capa.
Els atacs senzills funcionen. Les evasions sofisticades de proteccions de seguretat acaparen els titulars, però de vegades només cal... demanar-ho. Si el vostre sistema mostra identificadors interns sense objeccions quan un usuari els inclou en una consulta que, altrament, és legítima, teniu un problema.
Enteneu què esteu provant realment. És possible que l'entrenament del mateix LLM detecti patrons d'atac coneguts, en lloc de les vostres mesures de protecció. Incorporeu observabilitat a l'equip vermell per entendre quins controls s'estan aplicant realment.
Els entorns restringits requereixen solucions creatives. Els proveïdors personalitzats i la compatibilitat amb models locals permeten fer proves d'equip vermell útils sense accés especialitzat al núvol. Tanmateix, cal ser transparents sobre les limitacions que això comporta.
L'equip vermell no és una activitat puntual. És un procés iteratiu, s'ha d'automatitzar sempre que sigui possible i ha d'evolucionar alhora que el sistema. Els atacs que importaran demà no són els mateixos que importen avui.
Els sistemes d'IA en entorns regulats estaran sotmesos a un escrutini cada vegada més gran. Les organitzacions que tractin les proves de seguretat com una disciplina contínua, i no com una casella per marcar abans del llançament, estaran més ben preparades per afrontar aquest escrutini i evitar crisis de reputació que els facin perdre la confiança dels clients.