Míg az EU AI Act a „mit” és a „miért” kérdéseire fókuszál a magas kockázatú rendszerek esetében, az ISO/IEC 23053 szabvány a „hogyan”-ra ad egy rendkívül részletes, technikai választ. Ez nem egy törvény, hanem egy keretrendszer, ami a teljes gépi tanulási (ML) életciklust lefedi – a koncepciótól a leselejtezésig. Red Teamerként ez a szabvány a térképed: megmutatja a folyamat összes állomását, ahol sebezhetőségek rejtőzhetnek.
Mi is pontosan az ISO/IEC 23053?
A szabvány teljes címe: „Information technology — Artificial Intelligence (AI) — Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML)”. Lényegében egy ब्लूप्रिंटet (tervrajzot) ad egy ML-alapú AI rendszer felépítéséhez és működtetéséhez. Két fő részre bontható:
- 1. rész: AI/ML keretrendszer: Meghatározza az alapfogalmakat, a szerepköröket (pl. AI szolgáltató, adatfeldolgozó) és a teljes életciklus-modellt. Ez a rész adja a közös nyelvet, amivel a fejlesztők, az operátorok és a Red Teamerek is dolgozhatnak.
- 2. rész: Big Data referenciaarchitektúra: Részletesebben foglalkozik az adatfolyamatokkal, ami az ML rendszerek alapja. Az adatgyűjtéstől az adatok előkészítésén át a felhasználásig terjedő folyamatokat modellezi.
Számodra az 1. rész a legfontosabb, mert az abban vázolt életciklus-folyamat mentén tudod a leghatékonyabban strukturálni a vizsgálataidat. A szabvány nem mondja meg, hogyan védekezz egy adott támadás ellen, de megmutatja, a folyamat mely pontján kellene a védelemnek léteznie.
Az életciklus-folyamat a Red Teamer szemével
Az ISO/IEC 23053 egy hat fő szakaszból álló életciklust definiál. Minden egyes szakasz egy potenciális támadási felületet vagy egy gyenge pontot jelent, amit tesztelned kell. Nézzük meg ezeket a szakaszokat és a hozzájuk kapcsolódó Red Teaming relevanciát.
| Életciklus szakasz | Fő cél | Tipikus Red Teaming fókusz |
|---|---|---|
| Koncepció és tervezés | A rendszer céljainak, követelményeinek és korlátainak meghatározása. | Fenntarthatósági és etikai hiányosságok, irreális elvárások, a kockázatok alulbecslése. |
| Adatgyűjtés és -előkészítés | A tanító-, validációs és tesztadatok beszerzése, tisztítása, címkézése. | Adatmérgezés (Data Poisoning), torzítások (bias) bejuttatása, adatvédelmi szivárgások. |
| Modellépítés és -tanítás | Az ML modell architektúrájának kiválasztása és a modellen végzett tanítás. | Hátsó kapuk (backdoors) beültetése a tanítási folyamatba, a hiperparaméterek manipulációja. |
| Verifikáció és Validáció (V&V) | Annak ellenőrzése, hogy a modell megfelel-e a követelményeknek. | A tesztelési metrikák és adathalmazok elégtelensége, a V&V folyamatok megkerülése. |
| Üzembe helyezés (Deployment) | A modell integrálása az éles környezetbe. | Kikerülési támadások (Evasion Attacks), modelllopás (Model Stealing), API sebezhetőségek. |
| Üzemeltetés és karbantartás | A modell teljesítményének monitorozása, naplózás, újratanítás. | Modell-drift kihasználása, naplózás manipulálása, az anomáliadetekció kijátszása. |
Gyakorlati ellenőrző lista Red Teamereknek
Ahelyett, hogy egy száraz megfelelőségi listát adnánk, alakítsuk át a szabvány követelményeit támadó fókuszú kérdésekké. Ezzel a gondolkodásmóddal nem csak a „pipát” keresed egy listán, hanem a rendszer valós ellenállóképességét teszteled.
Adatkészlet integritása (2. szakasz)
- Kérdés: Hogyan biztosítják, hogy a külső forrásból származó adatok nem tartalmaznak szándékosan manipulatív, mérgező mintákat?
- Red Team akció: Próbálj meg alacsony százalékban, de célzottan mérgező adatokat juttatni a tanító adathalmazba, hogy egy rejtett hátsó kaput hozz létre.
- Kérdés: Milyen automatizált eszközökkel szűrik ki a statisztikai torzításokat (pl. nemi, faji) az adatokból a címkézés előtt?
- Red Team akció: Hozz létre olyan bemeneti mintákat, amelyek kihasználják a modellben maradt rejtett torzításokat, hogy diszkriminatív vagy hibás kimenetet generálj.
Modell verifikációja és validációja (4. szakasz)
- Kérdés: A V&V csapat csak a standard teszt adathalmazt használja, vagy generálnak szintetikus, ellenséges (adversarial) példákat is a modell robusztusságának mérésére?
- Red Team akció: Használj FGSM, PGD vagy más, a modell számára ismeretlen adversarial támadásokat, hogy felmérd a valós ellenállóképességét.
- Kérdés: Hogyan tesztelik a modell érzékenységét a koncepcionális elcsúszásra (concept drift), amikor a bemeneti adatok eloszlása idővel megváltozik?
- Red Team akció: Szimulálj egy fokozatos adat-eloszlás változást, és figyeld, hogy a monitorozó rendszerek mikor jeleznek, és a modell teljesítménye hogyan degradálódik.
Üzembe helyezés és API biztonság (5. szakasz)
- Kérdés: Milyen korlátozások (rate limiting, query complexity limits) vannak érvényben a modell-lekérdező API-n a modell-lopási és adatkinyerési (data extraction) támadások ellen?
- Red Team akció: Indíts nagyszámú, szisztematikusan felépített lekérdezést az API ellen, hogy megpróbáld rekonstruálni a modellt vagy kinyerni a tanító adathalmaz érzékeny részeit.
- Kérdés: A modell kimenetei közvetlenül kerülnek a felhasználóhoz, vagy van egy szanitizáló/validáló réteg, ami kiszűri a potenciálisan káros (pl. prompt injectionből eredő) tartalmakat?
- Red Team akció: Tervezz olyan promptokat, amelyek a modell belső utasításainak felülírására vagy a rendszer környezetével való interakcióra késztetik (pl. „ignore previous instructions and…”).
Összegzés
Az ISO/IEC 23053 nem egy kötelezően betartandó törvény, hanem egy szakmai mankó. Red Teamerként a legnagyobb értéke az, hogy egy strukturált, iparágilag elfogadott keretrendszert ad a kezedbe. Ha a jelentésedben az ebben a szabványban definiált életciklus-szakaszokra hivatkozol, a megállapításaid sokkal érthetőbbé és súlyosabbá válnak a fejlesztők és a menedzsment számára is. Használd ezt a szabványt arra, hogy feltérképezd a csatateret, mielőtt megterveznéd a támadásaidat.