MI-biztonság

MI-biztonsági tanácsadás

A promptbefecskendezés, a modell kimenetén át történő adatkiszivárgás, az eszközökkel való visszaélés és a mérgezett keresés nem a meglévő webes sebezhetőségek változatai. Kifejezetten MI-rendszerekre készítünk fenyegetésmodellt, és megtervezzük azt az architektúrát és azokat a kontrollokat, amelyek határok közé szorítják a találtakat.

Az üzleti probléma

A bizalmi határ elmozdult, és senki nem húzta meg újra

A hagyományos alkalmazásokban az adat és az utasítás elkülönül. A nyelvi modellek köré épült rendszerekben ugyanazon a csatornán érkeznek, így bármely tartalom, amit a modell elolvas, potenciálisan utasítás. Ez az egyetlen tulajdonság a biztonsági modell egészében megtöri a feltevéseket: egy dokumentum, egy weboldal, egy e-mail vagy egy ügyfélszolgálati jegy olyan utasítást hordozhat, amelyet a modell követni fog. Adjunk hozzá eszközöket és rendszerhozzáférést, és a következmény már nem rossz válasz, hanem cselekvés.

Amivel foglalkozunk

Fenyegetésmodell, aztán tervezés szerinti korlátozás

Megállapítjuk, mit céloznak meg a támadók és mit nyernének vele, majd úgy tervezünk, hogy az elérhető kár korlátos legyen, függetlenül attól, hogyan viselkedik a modell. Ez a legkisebb jogosultságú eszközhatóköröket, a validált eszközhívásokat, a lekért tartalom nem megbízhatóként kezelését, a következményekkel járó műveletek jóváhagyási kapuit és a kimeneti kontrollokat jelenti ott, ahol a modell szövege másik rendszerbe kerül. Azt is meghatározzuk, mit kell naplózni, mert az észlelés nélküli elszigetelés csak fél kontroll.

MI-biztonsági tanácsadás

Képességek

  • MI-fenyegetésmodellezés

  • LLM-biztonsági architektúra

  • Ügynökbiztonsági architektúra

  • MI-kockázatfelmérés

  • Promptbefecskendezési kockázat

  • Adatszivárgási felmérés

  • MI-ellátásilánc-kockázat

  • Biztonságos MI-architektúra

Gyakori felhasználási esetek

Gyakori felhasználási esetek

  • Fenyegetésmodellt készíteni egy MI-alkalmazáshoz, mielőtt élesbe kerül.
  • Biztonságos referenciaarchitektúrát felállítani, amelyhez más csapatok igazodnak.
  • Felmérni egy meglévő asszisztenst, amelynek olyan rendszerhozzáférése van, amit senki nem vizsgált át.
  • Meghatározni, mit kell egy beszállítónak bizonyítania, mielőtt az MI-funkcióját jóváhagyják.

Hogyan dolgozunk

Hogyan dolgozunk

  1. Fenyegetésmodell

    Megállapítani, mit céloznának meg a támadók, és mit nyernének, ha elérnék.

  2. Tesztelés

    Ellenséges tesztelés valósághű visszaélésekkel szemben, nem ismert karakterláncok listájával.

  3. Jelentés

    Megállapítások reprodukciós lépésekkel, súlyossággal és javítással, kihasználhatóság szerint rangsorolva.

  4. Újratesztelés

    Ellenőrizni, hogy a javítások tartanak, és otthagyni a teszteket, hogy a regressziók előjöjjenek.

Technológia

Technológia

  • OWASP LLM Top 10
  • MITRE ATLAS
  • Garak
  • Burp Suite
  • ISO/IEC 27001

Biztonság és irányítás

Biztonság és irányítás

A tesztelést írásban engedélyezik, megállapodott célokra korlátozzuk, és alapértelmezés szerint nem éles környezetben végezzük, hacsak másként nem döntenek. A megállapításokat bizalmasan kezeljük, és mindenki más előtt Önöknek tárjuk fel. A megbízáson túl semmit nem őrzünk meg a jelentésen és a kért regressziós teszteken kívül.

Együttműködési modellek

Együttműködési modellek

MI-tanácsadás

Tapasztalt tanácsadók stratégiai, architektúra-, értékelési és átalakítási útmutatást adnak.

MI-projekt

Felelősséget vállalunk egy meghatározott MI-megoldás tervezéséért és szállításáért.

Menedzselt MI

Üzemeltetjük, figyeljük és folyamatosan javítjuk az éles MI-rendszereket.

Miért a TeamExtension.ai

Az architektúra az egyetlen tartós kontroll

A szűrőket és a védőkorlátokat érdemes használni, és előbb-utóbb megkerülik őket. Azok a kontrollok tartanak, amelyek architekturálisak: mit érhet el a rendszer, mit tehet ott, és mihez kell ember. Ebből a feltevésből tervezünk, ezért szólnak az ajánlásaink inkább jogosultságokról és határokról, mint észlelési szabályokról.

Válogatott ügyfelek

Gyakori kérdések

Gyakori kérdések

Megoldható a promptbefecskendezés?
Megszüntetni nem. Architektúrával mérsékelhető: minden lekért tartalmat nem megbízhatóként kezelni, az eszközöket szűkre szabni, a következményekkel járó műveleteket jóváhagyás mögé tenni, és úgy tervezni, hogy egy sikeres befecskendezés valami korlátosat érjen el. Aki teljes megelőzést ígér, szűrőt árul.
Lefedik ezt a meglévő behatolásteszteink?
Csak részben. A hagyományos tesztelés a modell körüli alkalmazásfelületet fedi le. Jellemzően nem fedi le a lekért tartalmon át történő befecskendezést, a modell kimenetén át történő kiszivárogtatást vagy az eszközökkel való visszaélést, mert ezek nem hagyományos sebezhetőségi osztályok.
Mi a leggyakoribb megállapítás?
A túlzottan tág eszközjogosultságok. A rendszerek fejlesztés közben kapnak széles hozzáférést, mert kényelmes, és a hatókört élesítés előtt soha nem szűkítik. Ez egyben rendszerint a legolcsóbban javítható megállapítás is.
Hogyan illik ez a meglévő biztonsági funkciónkhoz?
Kiterjeszti. A biztonsági csapatukkal dolgozunk, nem mellettük, és a kimenet arra szolgál, hogy az ő szabványuk legyen, ne a mi jelentésünk. Ahol hiányzik az MI-specifikus mélység, velük együtt építjük fel.

Beszéljük meg MI-kezdeményezését

Készítsenek fenyegetésmodellt MI-rendszerekhez, és tervezzék meg azt az architektúrát, kontrollokat és határokat, amelyek kordában tartják a kockázatot.