Képzeld el, hogy az AI modelled egy pénzügyi szolgáltatás agya. Naponta több millió tranzakciót dolgoz fel: átutalásokat, kártyás vásárlásokat, befektetéseket. Minden felhasználónak megvan a maga szokásos mintázata. Te például jellemzően Magyarországon, hétköznapokon, kisebb összegekért vásárolsz. A rendszer ezt megtanulja. Aztán egy kedd hajnali hármas tranzakció érkezik a nevedben egy indonéz webshopból, egy szokatlanul nagy összegről. A rendszernek megszólal a vészcsengője. Ez nem te vagy! Vagy legalábbis nagyon nem úgy viselkedsz, mint ahogy szoktál. Ez a lényege az anomália észlelésnek: a normálistól való eltérés felismerése.
Az anomália észlelő rendszerek az AI védelmének csendes őrei. Nem specifikus, ismert támadásokat keresnek (mint egy víruskereső, ami szignatúrákat használ), hanem a viselkedésben bekövetkező furcsaságokat, a megszokottól való eltéréseket figyelik. Az AI Red Teaming szempontjából ezek a rendszerek egyszerre jelentenek kihívást és célpontot. Kihívást, mert egy jól beállított anomália detektor már a támadás előkészületeit is jelezheti. Célpontot, mert ha sikerül megtéveszteni vagy „átnevelni” őket, akkor a támadó láthatatlanná válhat.
A normalitás megteremtése: A baseline
Minden anomália észlelő rendszer lelke a baseline, vagyis az alapvonal. Ez egy modell arról, hogy mi számít normális működésnek. Ez lehet egy egyszerű statisztikai átlag, de egy komplex, több ezer változós gépi tanulási modell is.
A baseline minősége határozza meg a rendszer hatékonyságát.
Ha a baseline pontatlan, a rendszer vagy túl sokszor riaszt feleslegesen (hamis pozitív), vagy nem veszi észre a valódi problémákat (hamis negatív)!
Az alapvonal létrehozása általában egy „tanulási” fázisban történik, ahol a rendszer megfigyeli a zavartalan, üzemszerű működést. Ez lehet:
- API hívások gyakorisága és paraméterei: Egy adott végpontot átlagosan percenként 10-szer hívnak, 200-300 bájtos lekérésekkel. Egy hirtelen, percenkénti 1000 hívásos, több kilobájtos csomagokkal bombázó roham egyértelműen anomália.
- Felhasználói interakciók: Egy felhasználó átlagosan 5 percet tölt egy oldalon, mielőtt tovább lép. Ha egy bot másodpercenként 50 aloldalt tölt be, az egyértelmű anomália.
- Rendszererőforrások: A CPU használat normál esetben 20-40% között mozog. Egy tartósan 99%-os terhelés anomália, ami utalhat egy rosszindulatú folyamatra vagy egy végtelen ciklusra.
A Red Team feladata gyakran az, hogy olyan tevékenységet végezzen, ami elég közel marad ehhez a baseline-hoz ahhoz, hogy ne keltsen feltűnést, de mégis elérje a célját.
Vizuális reprezentáció: Normális vs. Anomália
Főbb megközelítések
Az anomáliák észlelésére többféle technika létezik, az egyszerűbb statisztikai módszerektől a komplex, mélytanuláson alapuló modellekig. Mindegyiknek megvan a maga helye és ideje.
Statisztikai módszerek
Ezek a legegyszerűbb és a gyakran leggyorsabb technikák. Azt feltételezik, hogy a normális adatok egy ismert statisztikai eloszlást követnek (pl. normál eloszlás). Bármi, ami ettől az eloszlástól jelentősen eltér (pl. több szórással arrébb van az átlagtól), anomáliának minősül.
# Pszeudokód egy egyszerű, Z-score alapú anomália észlelésre
# A Z-score megmutatja, hány szórásnyira van egy adatpont az átlagtól.
function anomaliat_eszlel(adatpont, atlag, szoras, kuszobertek=3):
# Ha az adatoknak nincs szórása (minden érték ugyanaz), nincs anomália
if szoras == 0:
return False
# Kiszámítjuk a Z-score-t
z_score = abs(adatpont - atlag) / szoras
# Ha a Z-score nagyobb, mint a küszöbérték (pl. 3), anomáliának tekintjük
if z_score > kuszobertek:
return True # Anomália!
else:
return False # NormálisGépi tanuláson alapuló módszerek
Itt már komplexebb modelleket használunk a normalitás leírására. Ezek képesek több változó közötti bonyolult összefüggéseket is megtanulni, ami a statisztikai módszerekkel nehézkes lenne.
- Félig-felügyelt (Semi-supervised): A leggyakoribb megközelítés. A modellt kizárólag normális adatokon tanítjuk. Amikor a rendszer egy olyan adatponttal találkozik, amit a modell nem tud jól rekonstruálni vagy alacsony valószínűséget rendel hozzá, azt anomáliaként jelöli meg. Ilyenek például az autoenkóderek.
- Felügyelet nélküli (Unsupervised): A rendszer címkézetlen adatokon dolgozik, és megpróbálja azokat csoportosítani (klaszterezni). Azok az adatpontok, amelyek egyik klaszterbe sem illeszkednek jól, vagy magányos „szigeteket” alkotnak, gyanússá válnak. Ilyen módszer a DBSCAN vagy az Isolation Forest.
Idősoros elemzés
Sok rendszeradat (pl. hálózati forgalom, CPU terhelés) idősoros jellegű. Itt nemcsak az értékek, hanem azok időbeli lefutása, szezonalitása és trendje is fontos. Az anomália itt egy hirtelen tüske, a trend megtörése vagy a szezonális mintázat felborulása lehet. Az olyan modellek, mint az ARIMA vagy az LSTM neurális hálók, hatékonyak az ilyen típusú anomáliák észlelésében.
AI Red Teaming szempontok: Hogyan teszteljük az anomália észlelőket?
Egy AI Red Team számára az anomália észlelő nem egy áthatolhatatlan fal, hanem egy szenzorháló, amit ki lehet játszani.
A cél nem feltétlenül a rendszer „kikapcsolása”, hanem az, hogy a radar alatt maradjunk.
- Fokozatos eltolódás (Gradual Drift): A „forralt béka” effektus. Ahelyett, hogy egyetlen, nagy anomáliát okozó műveletet hajtanánk végre, a támadást apró, szinte észrevehetetlen lépésekre bontjuk. Lassan növeljük a hálózati forgalmat, apránként férünk hozzá több adathoz. Ha a rendszer adaptív és folyamatosan újratanulja a baseline-t, akkor a rosszindulatú tevékenység lassan a „normális” részévé válhat.
- Baseline mérgezés (Baseline Poisoning): Ha lehetőség van a tanító adathalmaz befolyásolására, akkor ez rendkívül hatékony támadási lehetőség! Az AI Red Team olyan adatokat injektál a tanítási fázisban, amelyek a későbbi támadó tevékenységet normálisnak tüntetik fel. Például, ha a tanító adatok közé csempészünk néhány nagy méretű, titkosított adatcsomagot, a rendszer később a valódi adatlopást is normális forgalomnak nézheti.
- Mimikri támadások (Mimicry Attacks): A támadó megpróbálja a rosszindulatú tevékenységét a normális felhasználói vagy rendszeraktivitás mintázataiba ágyazni. Például egy adatlopást nem egyetlen nagy csomagban, hanem sok apró, legitimnek tűnő HTTP kérésbe rejtve hajt végre, a normál munkaidő alatt, amikor a rendszer amúgy is nagy forgalmat bonyolít.
Ezeknek a rendszereknek a tesztelése során a legfontosabb kérdésünk mindig az: „Mi a rendszer definíciója a normalitásra, és hogyan tudom ezt a definíciót a saját javamra fordítani anélkül, hogy riasztást váltanék ki?”