Készítsen fenyegetési modellt az AI-fejlesztési munkafolyamathoz

Válasszon körülhatárolt helyzetet

Kezdjen egy könnyen érthető munkafolyamattal. Például az agent elolvas egy hibajegyet, szerkeszti a repozitárt, teszteket futtat, és megnyit egy pull requestet. Vegye fel azokat a rendszereket is, amelyek ezeket a műveleteket lehetővé teszik.

Sorolja fel a védendő értékeket: forráskód, ügyfélinformációk, hitelesítő adatok, kiadási artifactok és a szolgáltatás rendelkezésre állása. Azonosítsa a felelőseiket. Ezután azonosítsa, mely személyek és rendszerek olvashatják vagy módosíthatják az egyes értékeket.

Az OWASP a rendszer modellezését, a fenyegetések azonosítását, a válaszok kiválasztását és az eredmény ellenőrzését javasolja. Alkalmazza korán a módszert, és frissítse a modellt a rendszer változásakor. Útmutató a fenyegetési modellezéshez.

Rajzolja fel a bizalmi határokat

A fiktív, hibajegytől PR-ig tartó munkafolyamathoz rajzolja fel ezeket a kapcsolatokat:

Issue → agent → repository → test runner → artifact store → deployment

Adja hozzá a modellszolgáltatót és a titokkezelő tárat. Jelölje, hol érkezik tartalom kevésbé megbízható forrásból. Jelölje, hol kap egy identitás új műveleti lehetőséget, például amikor a hibajegy olvasásáról repozitárfájlok írására lép tovább.

Az alkalmazás ábrája önmagában nem mutatja meg a fejlesztés teljes kockázatát. Az éles adatbázis lehet privát, miközben egy CI-feladat hitelesítő adatot fed fel. Vegye fel az ideiglenes környezeteket és az ügyféltámogatási hozzáférést is, ha érintik a helyzetet.

Írjon le konkrét hibafolyamatot

Kerülje az olyan bejegyzéseket, mint „az AI veszélyes lehet”. Nevezzen meg szereplőt, műveletet, érintett értéket és következményt. Adja meg a helyzet bekövetkezéséhez szükséges feltételeket is.

Ezek példák, nem teljes fenyegetési lista. A releváns helyzeteket az adatok, az eszközök és az üzemeltetési környezet határozzák meg.

Válasszon kezelési módot, és rendeljen hozzá felelőst

A következmények és a reális kitettség alapján állítson fel prioritást. Ne keltsen számszerű pontszámmal olyan pontosságot, amely nem áll rendelkezésre. Rögzítse a bizonytalanságot és a prioritást módosító lehetséges bizonyítékot.

A válasz megszüntetheti a kockázatos műveleti lehetőséget, szűkítheti a hatókörét, hozzáadhat kontrollt, vagy elfogadhat egy meghatározott fennmaradó kockázatot. Az elfogadáshoz felhatalmazott felelős és indoklás kell. Nem lehet az agent felülvizsgálat nélküli következtetése.

Alakítsa a választ olyan feladattá, amelynek megfigyelhető elfogadási feltétele van. Az „agent biztonságának javítása” nehezen ellenőrizhető. A „tesztfeladat nem olvashatja az éles titkos értéket” ellenőrizhető határt határoz meg.

Lényeges változás után vizsgálja felül

Egy új connector, modellútvonal, környezet vagy jogosultság megváltoztathatja a fenyegetési modellt. Vegye fel ezeket a felülvizsgálatot kiváltó események közé. Az incidensek és a sikertelen értékelések alapján is frissítse a feltételezéseket.

A kockázatértékelési gyakorlatban módosíthatja egy helyzet adatait, jogosultságait, felhasználói körét és helyreállítási feltételeit. Az eredmény kérdéseket javasol. Nem helyettesíti a rendszerre szabott fenyegetési modellt, és nem ad engedélyt a munkára.