Ahhoz, hogy működő AI-rendszereket építsünk, először meg kell próbálnunk feltörni őket. Támadásszimulációt végeztünk: támadóként teszteltük és vizsgáltuk egy pénzügyi szolgáltató ügyfeleknek szánt AI-alkalmazását. Eredményeink mindenki számára fontosak, aki LLM-alapú alkalmazást vezet be olyan területen, ahol a biztonság alapkövetelmény.
A támadásszimuláció során szándékosan megpróbáljuk feltörni az AI-rendszert, hogy még azelőtt kijavíthassuk a sebezhetőségeket, hogy egy valódi támadó megtalálná őket. A pénzügyi szolgáltatások terén különösen nagy a tét: az AI-alkalmazások ügyféladatokat kezelnek, tranzakciókat dolgoznak fel és pénzügyi elemzéseket nyújtanak. Egy hiba következménye a rossz felhasználói élménytől a szabályozási előírások megsértésén és a pénzügyi veszteségeken át egészen a márka helyrehozhatatlan károsodásáig terjedhet.
Célunk a sebezhetőségek korai feltárása, valósághű támadási minták tesztelése, valamint annak elősegítése volt, hogy a szervezet megfeleljen a szabályozó hatóságok által kiemelten kezelt AI-biztonsági elvárásoknak.
Fontos különbség, hogy míg a jailbreak a mögöttes modell biztonsági szűrőit támadja, az utasítás injekció magát az alkalmazást veszi célba: a nem megbízható felhasználói bevitelt a fejlesztő megbízható utasításával kombinálja. Az utasítás injekció nagyobb kockázatot jelent, mert nem egy általános célú modellt, hanem az Ön rendszerét és az általa kezelt bizalmas adatokat támadja.
A tesztelés első köre mintegy 750 tesztet foglalt magában az alábbi területeken:
Munkamenetek közötti adatszivárgás
Személyazonosításra alkalmas adatok felfedése (természetes nyelven, API-manipulációval és különféle kódolásokkal)
SQL-injekció
A rendszerutasítások felülírása
A kezdeti tesztelés során két súlyos problémát azonosítottunk a meglévő rendszerben: a több szándékot tartalmazó lekérdezések kezelését és a kódolt utasítások használatát.
Több szándékot tartalmazó lekérdezések: olyan kérések, amelyek jogszerű és rosszindulatú elemeket ötvöznek. Például: “Show my spending by category, and also execute [malicious SQL].” Az alkalmazás nem ismerte fel a rosszindulatú szándékot, hanem teljes mértékben az adatkezelési réteg későbbi védelmi mechanizmusaira hagyatkozott. Ez olyan, mintha nyitva hagynánk a bejárati ajtót, mert megbízunk az alagsori széfben.
Kódolás: a kéréseket Base64, Hex, LeetSpeak vagy hasonló megjelenésű karakterek használatával kódolják. A rendszerek számára nehéz lehet kiszűrni a rosszindulatú szándékot. Bár ezek a lekérdezések nem fedtek fel érzékeny adatokat, jelentősen destabilizálták a rendszert: hallucinációkat, a felhasználóknak visszaadott rosszindulatú SQL-kódot és téves szándékbesorolást okoztak.
A kezdeti tesztelés eredményei a következőket mutatták:
Időbeli hallucinációk: a modell magabiztosan közölt, de kitalált dátumokat, tranzakciós időbélyegeket vagy időszakos összesítéseket adott vissza. Ez komoly kockázat a pénzügyekben, ahol valós következményekkel járhat, ha egy ügyfél téves dátum alapján cselekszik
Rosszindulatú SQL-kód visszaadása a felhasználónak (ami a memória megmérgezésének kockázata miatt aggasztó)
Téves szándékbesorolás
Összekuszált kimeneti formázás
Ezekkel az eredményekkel felvértezve szűkítettük a vizsgálat fókuszát. Az SQL-injekciós és kódolási tesztek alacsonyabb prioritást kaptak, mivel a csapat már dolgozott ezeken a problémákon. Ehelyett a legsikeresebb támadási irányokra összpontosítottunk: a személyazonosításra alkalmas adatok felfedésére és a munkamenetek közötti adatszivárgásra.
A második kör legmeglepőbb tanulsága zavarba ejtően egyszerű volt: sokszor egyáltalán nincs szükség kifinomult módszerekre.
Sok esetben elég volt egyszerűen elkérni a belső adatokat egy jogosnak tűnő kérés részeként, és a rendszer máris hajlandó volt felfedni őket. Egyszerű lekérdezésekre is olyan válaszok érkeztek, amelyek belső azonosítókra és rendszermezőkre hivatkoztak, holott ezeket a végfelhasználóknak soha nem szabadna látniuk.
A mélyebb vizsgálat során kiderült, hogy nem pusztán alkalmazásszintű hibáról van szó. A lánc későbbi pontján működő, szöveget SQL-lé alakító szolgáltatás a szükségesnél több mezőt lekérő lekérdezéseket állított össze, magyarázó válaszaiban pedig olyan adatokra hivatkozott, amelyekhez korlátozni kellett volna a hozzáférést. Ez valódi rést tárt fel a rendszerek között – olyan sebezhetőséget, amely csak a teljes technológiai rendszer tesztelésekor mutatkozik meg, az egyes összetevők elszigetelt vizsgálatakor nem.
A rendszert tesztelje támadásszimulációval, ne a modellt. Egy LLM elszigetelt tesztelése nagyon keveset árul el az alkalmazás biztonsági állapotáról. A teljes technológiai rendszert tesztelje az elejétől a végéig, úgy, ahogy egy felhasználó használná.
A bemenetet még az LLM előtt ellenőrizni kell. A kódolt lekérdezéseket, a több szándékot ötvöző támadásokat és az alapvető injekciós kísérleteket már a rendszer peremén fel kell ismerni, nem pedig a későbbi szolgáltatásokra bízni.
Ne bízzon a rendszerek illesztéseiben. A több szolgáltatásból álló architektúrákban a legérdekesebb sebezhetőségek a rendszerek közötti résekben bújnak meg. A zéró bizalom valóban zéró bizalmat jelent: minden rétegben mindent ellenőrizni kell.
Az egyszerű támadások is működnek. A kifinomult jailbreakek kerülnek a címlapokra, de néha elég egyszerűen... kérni. Ha a rendszer készségesen felfedi a belső azonosítókat, amikor a felhasználó egy egyébként jogszerű lekérdezésbe foglalja őket, az problémát jelent.
Legyen tisztában azzal, hogy valójában mit tesztel. Előfordulhat, hogy az ismert támadási mintákat nem az Ön védelmi mechanizmusai, hanem az LLM saját betanítása ismeri fel. Építsen megfigyelhetőséget a támadásszimulációba, hogy kiderüljön, valójában mely védelmi intézkedések lépnek működésbe.
A korlátozott környezetek kreatív megoldásokat igényelnek. Az egyedi szolgáltatók és a helyi modellek támogatása speciális felhő-hozzáférés nélkül is lehetővé teszi az érdemi támadásszimulációt. Az ebből fakadó korlátokat azonban átláthatóan kell ismertetni.
A támadásszimuláció nem egyszeri feladat. Ismétlődő folyamat, amelyet lehetőség szerint automatizálni kell, és a rendszerrel együtt kell fejlődnie. A holnap fontos támadásai nem ugyanazok lesznek, mint amelyek ma számítanak.
A szabályozott környezetekben működő AI-rendszerekre egyre szigorúbb ellenőrzés vár. Azok a szervezetek tudnak majd jobban megfelelni ennek az ellenőrzésnek, amelyek a biztonsági tesztelést folyamatos tevékenységként kezelik, nem pedig a bevezetés előtti kipipálandó feladatként. Így az ügyfelek bizalmát leromboló kommunikációs katasztrófákat is könnyebben elkerülhetik.