DI saugumas

DI saugumo konsultacijos

Užklausų įterpimas, duomenų nutekėjimas per modelio išvestį, piktnaudžiavimas įrankiais ir užnuodyta paieška nėra įprastų žiniatinklio pažeidžiamumų atmainos. Kuriame grėsmių modelį būtent DI sistemoms ir projektuojame architektūrą bei kontrolės priemones, ribojančias tai, ką randame.

Verslo problema

Pasitikėjimo riba pasislinko, ir niekas jos neperbraižė

Įprastose programose duomenys ir nurodymai atskirti. Sistemose apie kalbos modelius jie ateina tuo pačiu kanalu, todėl bet koks turinys, kurį modelis skaito, potencialiai yra nurodymas. Vien ši savybė laužo prielaidas visame saugumo modelyje: dokumentas, tinklalapis, laiškas ar palaikymo užklausa gali nešti nurodymą, kurio modelis laikysis. Pridėkite įrankius ir prieigą prie sistemų, ir pasekmė bus nebe klaidingas atsakymas, o veiksmas.

Ką darome

Sumodeliuoti grėsmes ir apriboti sandara

Nustatome, kas taptų užpuoliko taikiniu ir ką jis laimėtų, o paskui projektuojame taip, kad pasiekiama žala būtų ribota nepriklausomai nuo modelio elgsenos. Tai reiškia mažiausias būtinas įrankių teises, patikrintus iškvietimus, požiūrį į rastą turinį kaip į nepatikimus duomenis, patvirtinimo taškus prie reikšmingų veiksmų ir išvesties kontrolę ten, kur modelio tekstas patenka į kitą sistemą. Taip pat nurodome, ką registruoti, nes ribojimas be aptikimo yra pusė kontrolės.

DI saugumo konsultacijos

Kompetencijos

  • DI grėsmių modeliavimas

  • Kalbos modelių saugumo architektūra

  • Agentų saugumo architektūra

  • DI rizikos vertinimas

  • Užklausų įterpimo rizika

  • Duomenų nutekėjimo vertinimas

  • DI tiekimo grandinės rizika

  • Saugi DI architektūra

Dažniausi panaudojimo atvejai

Dažniausi panaudojimo atvejai

  • Sukurti grėsmių modelį DI programai prieš jai išeinant į gamybą.
  • Nustatyti saugią etaloninę architektūrą, pagal kurią kuria kitos komandos.
  • Įvertinti esamą asistentą, turintį prieigą prie sistemų, kurios niekas netikrino.
  • Apibrėžti, ką tiekėjas turi pagrįsti, kad jo DI funkcija būtų patvirtinta.

Kaip dirbame

Kaip dirbame

  1. Grėsmių modelis

    Nustatyti, kas taptų užpuoliko taikiniu ir ką jis laimėtų, iki jo prisikasęs.

  2. Testavimas

    Priešiškas testavimas prieš realistišką piktnaudžiavimą, o ne žinomų eilučių sąrašas.

  3. Ataskaita

    Radiniai su atkūrimo žingsniais, sunkumu ir pataisymu, surikiuoti pagal išnaudojamumą.

  4. Pakartotinis tikrinimas

    Įsitikinti, kad pataisymai laikosi, ir palikti testus, kad regresijos taptų matomos.

Technologijos

Technologijos

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

Saugumas ir valdysena

Saugumas ir valdysena

Testavimas leidžiamas raštu, apribojamas sutartais taikiniais ir pagal numatytuosius nustatymus vykdomas ne gamybinėje aplinkoje, jei nenusprendžiate kitaip. Radiniai laikomi konfidencialiais ir atskleidžiami jums anksčiau nei bet kam kitam. Nieko nesaugoma už darbų ribų, išskyrus ataskaitą ir regresijos testus, kuriuos prašėte palikti.

Bendradarbiavimo modeliai

Bendradarbiavimo modeliai

DI konsultacijos

Patyrę konsultantai teikia rekomendacijas dėl strategijos, architektūros, vertinimo ir transformacijos.

DI projektas

Prisiimame atsakomybę už apibrėžto DI sprendimo projektavimą ir pristatymą.

Valdomas DI

Eksploatuojame, stebime ir nuolat tobuliname gamybines DI sistemas.

Kodėl TeamExtension.ai

Architektūra yra vienintelė tvari kontrolė

Filtrai ir apsauginiai mechanizmai reikalingi, ir kada nors jie bus apeiti. Tvarios kontrolės priemonės yra architektūrinės: ką sistemai leidžiama pasiekti, ką ji ten gali padaryti ir kas reikalauja žmogaus. Projektuojame iš šios prielaidos, todėl mūsų rekomendacijos dažniau apie teises ir ribas nei apie aptikimo taisykles.

Atrinkti klientai

Dažniausiai užduodami klausimai

Dažniausiai užduodami klausimai

Ar galima išspręsti užklausų įterpimo problemą?
Pašalinti negalima. Ji švelninama architektūra: visą rastą turinį laikyti nepatikimu, siaurai riboti įrankius, reikšmingus veiksmus statyti už patvirtinimo ir projektuoti taip, kad sėkmingas įterpimas pasiektų kažką riboto. Kas žada visišką užkardymą, parduoda filtrą.
Ar tai apima mūsų dabartiniai įsilaužimo testai?
Tik iš dalies. Įprastas testavimas apima programos paviršių aplink modelį. Jis paprastai neapima įterpimo per rastą turinį, nutekėjimo per modelio išvestį ar piktnaudžiavimo įrankiais, nes tai nėra įprastos pažeidžiamumų klasės.
Kuris radinys pasitaiko dažniausiai?
Per plačios įrankių teisės. Sistemoms suteikiama plati prieiga kūrimo metu, nes taip patogu, ir ta apimtis niekada nesusiaurinama prieš gamybą. Paprastai tai ir pigiausias radinys pataisyti.
Kaip tai dera su mūsų saugumo tarnyba?
Ją praplečia. Dirbame su jūsų saugumo komanda, o ne aplenkdami ją, ir rezultatas turi tapti jų standartu, o ne mūsų ataskaita. Ten, kur jiems trūksta DI gilumo, jį auginame kartu su jais.

Aptarkite savo DI iniciatyvą

Modeliuokite grėsmes DI sistemoms ir projektuokite architektūrą, kontrolės priemones ir ribas, kurios riboja jų riziką.