„OpenAI“ ir „Hugging Face“ incidentas(atsidaro naujame lange) tapo lūžio tašku kibernetinio saugumo srityje, nes leido pažvelgti, kaip ateinančiais mėnesiais tobulės įprastų piktavalių pajėgumai. Per pastarąsias kelias savaites kalbėjausi su daugybe organizacijų, ir viena tema akivaizdi: jos supranta, kad privalo iš esmės ir beprecedenčiu greičiu patobulinti savo kibernetinio saugumo praktiką. Šiame įraše pasidalysiu, ką darome siekdami apsaugoti „OpenAI“, kokių konkrečių žingsnių kitos organizacijos gali imtis jau šiandien ir kodėl veikti reikia būtent dabar.
Visame pasaulyje kuriami DI modeliai vis geriau geba automatizuoti tam tikrus realių kibernetinių atakų etapus, todėl įsisenėjusias saugumo spragas – nuo žmonių kuriamoje programinėje įrangoje giliai slypinčių klaidų iki pamirštų prieigos leidimų – tampa lengviau rasti ir išnaudoti. Tos pačios DI galimybės suteikia gynėjams naujų būdų rasti ir ištaisyti šias silpnybes, tačiau veikti būtina jau dabar. Jei įmonės veiks ryžtingai – tobulins savo bazines sistemas ir stiprins komandas pasitelkdamos DI – galime sukurti saugesnį internetą nei bet kada anksčiau.
Per „OpenAI“ ir „Hugging Face“ incidentą agentų kolektyvas sugebėjo savarankiškai įsibrauti ne tik į „OpenAI“ tyrimų infrastruktūrą, bet ir į kitos įmonės realiomis sąlygomis veikiančią infrastruktūrą, susiedamas įvairius pažeidžiamumus – nuo anksčiau nežinotų saugumo spragų iki internete nutekintų naudotojų paskyrų prisijungimo duomenų naudojimo. Vis akivaizdžiau, kad kiekvienos įmonės techninė skola(atsidaro naujame lange) slepia rimtų trūkumų, todėl gynėjai privalo juos rasti ir pašalinti greičiau nei puolėjai.
Siekdami suteikti pranašumą gynėjams, dar šiais metais savo kibernetinius pajėgumus pradėjome teikti tik patikimiems gynėjams. Nuo to laiko įvairios įmonės išleido atvirųjų svorių modelius, kurių kibernetiniai pajėgumai tik keliais mėnesiais atsilieka nuo priešakinių modelių. Atrodo, kad naujausias iš šių modelių bus išleistas(atsidaro naujame lange) rugpjūčio pabaigoje ir, tikėtina, gerokai paspartins grėsmių evoliuciją.
Nors DI pasitelkę puolėjai netrukus galės aptikti įsisenėjusių trūkumų daugelyje esamų sistemų, DI taip pat gerokai palengvins gynėjams šių spragų paiešką, prioritetų nustatymą ir šalinimą. Saugumo sritis vis dar primena katės ir pelės žaidimą, bet DI gali pakeisti jo ekonomiką(atsidaro naujame lange) taip, kad gynėjai įgytų esminį pranašumą. Pavyzdžiui, jau pradedame mokyti savo modelius specialiai rašyti žmogaus galimybes pranokstantį saugų kodą. Mūsų modeliai taip pat puikiai rengia matematinius įrodymus, kuriuos galima pritaikyti formaliai tikrinant programinės įrangos saugumą – o tai žmonėms iki šiol buvo neįveikiama.
Po „OpenAI“ ir „Hugging Face“ incidento paprašiau „ChatGPT Work“ (naudojančio viešai prieinamą „GPT‑5.6 Sol“ modelį) įvertinti gregbrockman.com(atsidaro naujame lange) saugumą. Tai paprasta statinė svetainė, talpinama AWS platformoje su „Cloudflare“ apsauga, todėl maniau, kad pažeidžiamumų paviršius nebus didelis.
Per maždaug 15 minučių modelis aptiko 13 problemų. Nors dauguma jų atskirai, tikėtina, pavojaus nekelia, nesunkiai įsivaizduoju, kaip susiejus jas su kitais pažeidžiamumais būtų padaryta didelė žala. Nebuvau sukonfigūravęs DNS įrašų taip, kad užpuolikai negalėtų klastoti mano vardu siunčiamų el. laiškų; svetainėje buvo naudojama nesaugi „jQuery“ versija; o „Cloudflare“ užklausas į AWS persiųsdavo per nešifruotą HTTP protokolą.
Tada paprašiau „ChatGPT Work“ ištaisyti šias problemas – ir modelis tai padarė per valandą. Jis naršyklėje atidarė „Cloudflare“ valdymo skydelį ir atliko daugybę veiksmų, kad tinkamai sukonfigūruotų DNS, TLS bei išplėstines saugumo nuostatas; visiškai pašalino „jQuery“ iš svetainės; perkėlė mane iš AWS į „Cloudflare Pages“ ir pradėjo etapinį DMARC(atsidaro naujame lange) diegimą.
Ir tai buvo tik mano asmeninė svetainė. Tai tėra nedidelis pavyzdys, kaip esami mūsų modeliai gali veikti kaip kibernetinis sargas – jie randa ilgą saugumo problemų virtinę, kuriai išspręsti žmogui neužtektų laiko ar žinių (nemažai pataisytų nuostatų man yra šiek tiek pažįstamos, bet tikrai nebūčiau iškart žinojęs, kaip jas tinkamai sukonfigūruoti), o tada pašalina jas pagal tinkamai pritaikytą diegimo planą.
„Hugging Face“ incidentas parodė, kad neįvertinome mūsų DI modelių kibernetinių galimybių realiame pasaulyje. Atitinkamai griežtiname savo saugos reikalavimus, o tai savo ruožtu skatina dar skubiau vykdyti dabartinius saugos tyrimus ir užtikrinti vidinį saugumą.
Noriu trumpai pasidalyti, kaip šiuo metu užtikriname „OpenAI“ saugumą, tikėdamasis, kad tai bus naudinga ir kitoms organizacijoms. Siekdami apsaugoti „OpenAI“, smarkiai investuojame tiek į bazines kontrolės priemones – tinkamai atlikdami pagrindinius darbus – tiek į gynybos stiprinimą pasitelkdami priešakinius modelius. Ši strategija remiasi keturiais pagrindiniais ramsčiais.
Pirma, mūsų modeliai padeda užtikrinti kuriamo kodo saugumą. „Codex“ kartu su mūsų saugumo įskiepiu tikrina kodo pakeitimus, nustato pažeidžiamumus ir padeda programuotojams ištaisyti problemas dar prieš įdiegiant kodą. Mūsų tikslas tikrai nėra tiesiog sugeneruoti daugiau saugumo įspėjimų, kuriuos turėtų tikrinti žmonės – siekiame aptikti tikrus pažeidžiamumus dar prieš išleidžiant kodą ir sutrumpinti kelią nuo problemos atradimo iki saugaus pataisos įdiegimo. Toliau mokydami savo modelius generuoti vis saugesnį kodą, siekiame visiškai pašalinti tam tikrų klasių programinės įrangos pažeidžiamumus naujai kuriamame kode.
Antra, savo modelius pasitelkiame nuolatinei infrastruktūros apsaugai. Šiandien beveik visus pirminius saugumo įspėjimus pirmiausia apdoroja dirbtinis intelektas, ir tik po to įtraukiami žmonės. Tai sumažina rutininio gynėjų darbo naštą, sutrumpina reagavimo laiką ir leidžia žmonėms skirti laiko tam, kur jų įgūdžiai teikia daugiausia naudos – įžvalgoms, vertinimui ir praktinei patirčiai taikyti. Šiuos aptikimus vis dažniau susiejame su apibrėžtais automatiniais atsakais, tačiau atsakomybė už svarbiausius sprendimus ir toliau tenka žmonėms. Mūsų tikslas – užtikrinti, kad galėtume mašininiu greičiu aptikti saugumo problemas ir į jas reaguoti.
Trečia, naudojame priešakinius modelius, kad nuolat sistemintume, tirtume ir nustatytume galimus atakų kelius. Aptikę pažeidžiamumus, netinkamas konfigūracijas, perteklines teises turinčias tapatybes ar netyčia atsiradusias pasitikėjimo ribas, galime greitai nustatyti ir pašalinti šias spragas dar prieš tai, kai jomis spės pasinaudoti užpuolikai. Tai leidžia nuolat vertinti, stebėti ir tikrinti mūsų nekintamas saugumo sąlygas – saugumo savybes, kurias laikome neginčijamomis – visuose mūsų produktuose, infrastruktūroje ir sistemose.
Galiausiai, smarkiai investuojame į didelio masto bazinius sprendimus. Toliau investuojame į saugią architektūrą ir kontrolės priemones, taikome tokias strategijas kaip daugiasluoksnė apsauga ir mažiausių teisių principas, taip pat kuriame sistemas, kuriose katastrofa galėtų įvykti tik tuo atveju, jei vienu metu sugestų kelios nepriklausomos kontrolės priemonės. Klasikinės saugumo kontrolės priemonės, tokios kaip tinklo izoliavimas, darbo krūvių apsaugos stiprinimas, stebėjimas ir saugus pataisų bei naujinių diegimas, DI ateityje bus svarbesnės nei bet kada anksčiau.
Laikas ypač svarbus, todėl gynėjai toliau nurodytus veiksmus turės atlikti didžiausiu greičiu. Toliau minėsiu „OpenAI“ technologijas, tačiau ekosistemoje yra daugybė konkurentų, kuriuos taip pat verta įvertinti. Svarbiausia ne konkreti priemonė, o tai, kad jūsų gynėjai jau dabar gautų prieigą prie pajėgaus DI.
- Užsitikrinkite organizacijos įsipareigojimą ir palaikymą. Saugumo rizika sparčiai keičiasi, todėl užtikrinkite, kad jūsų saugumo ir inžinerijos padaliniai gautų reikiamą palaikymą, bendradarbiautų ir turėtų pakankamai išteklių šiems rizikos veiksniams greitai suvaldyti. Surenkite pratybas su savo komandomis ir sumodeliuokite, kaip šios atakos galėtų pasireikšti jūsų organizacijoje ir kaip į jas reaguotumėte.
- Suteikite savo saugumo komandai agentą. Pradėkite naudoti „Codex“, „Codex“ saugumo įskiepį(atsidaro naujame lange) ar kitą pajėgų agentinio programavimo ir saugumo priemonę. Suteikite jam patvirtintą prieigą prie kodo bazių, infrastruktūros konfigūracijų ir techninių dokumentų, kuriuos turi įvertinti jūsų saugumo komanda. Nelaukite visuotinio diegimo įmonėje – pradėkite nuo svarbiausių sistemų.
- Suteikite šiam agentui saugumo srities žinių. Pradėkite nuo bendruomenės palaikomų įgūdžių(atsidaro naujame lange), apimančių statinę analizę, į saugumą orientuotą kodo peržiūrą, pažeidžiamumų variantų analizę, programinės įrangos tiekimo grandinės rizikos valdymą ir kitus saugumo procesus. Tada kurkite savo įgūdžius, pritaikytus jūsų organizacijos architektūrai, saugumo standartams, grėsmių modeliams ir veiksmų planams.
- Nedelsdami atlikite savo sistemų saugumo vertinimą. Pirmiausia vertinkite internete prieinamas paslaugas, tapatybės nustatymo procesus, infrastruktūrą kaip kodą, diegimo procesus ir sistemas, kuriose apdorojama neskelbtina informacija. Komandai įgavus užtikrintumo, plėskite nuskaitymo apimtį.
- Sutvarkykite esamų pažeidžiamumų sąrašą. Pateikite agentui kodo skaitytuvų išvadas, įspėjimus dėl priklausomybių, saugumo užklausas, programos „Bug Bounty“ ataskaitas ir ankstesnių vertinimų rezultatus. Paprašykite agento surūšiuoti šias išvadas, atskirti išnaudojamas problemas nuo triukšmo, rasti susijusius pažeidžiamumus kitose kodo bazės vietose ir rekomenduoti, ką taisyti pirmiausia.
- Įtraukite saugumo peržiūras tiesiai į kūrimo procesą. Naudokite agentus kodo pakeitimams peržiūrėti prieš juos sujungiant ir saugumo patikroms CI aplinkoje atlikti. Ieškokite tapatybės nustatymo klaidų, prieigos kontrolės apėjimų, atskleistų prisijungimo duomenų, nesaugių priklausomybių, nesaugių numatytųjų nuostatų, pakeitimų, kurie išplečia prieigą prie realiomis sąlygomis veikiančių sistemų, ir kitų pažeidžiamumų.
- Leiskite agentui padėti ištaisyti rastas problemas. Patvirtinę problemas, paprašykite agento sugeneruoti ir patikrinti tikslinę pataisą, parašyti regresijos testą ir įsitikinti, kad pažeidžiamumas nebepasikartoja. Žmogaus atliekamą peržiūrą palikite reikšmingiems pakeitimams, tačiau pašalinkite nereikalingą delsą tarp realios problemos nustatymo ir saugaus pataisos pateikimo inžinieriui.
- Palaipsniui automatizuokite aptikimų rūšiavimą. Nepradėkite nuo bandymų sukurti autonominį saugumo operacijų centrą. Pradėkite nuo saugumo patikros vienoje saugykloje turint tik skaitymo teises arba leiskite agentui peržiūrėti anksčiau išspręstus įspėjimus naudojant tik skaitymo prieigą prie esamų žurnalų. Leiskite jam apibendrinti įrodymus ir rekomenduoti tolesnius veiksmus, tačiau visus sprendimus tegul priima žmogus. Augant užtikrintumui, pereikite prie patariamojo pobūdžio „pull request“ užklausų nuskaitymo, tada – prie tiesioginio įspėjimų rūšiavimo ir galiausiai – prie automatinio griežtai apibrėžtų klaidingų teigiamų rezultatų uždarymo.
- Pasiruoškite DI paremtą incidentų tyrimo priemonę dar prieš prireikiant. Pateikite paraišką „Trusted Access for Cyber“(atsidaro naujame lange) programoje, kad jūsų komandai būtų suteiktas leidimas naudoti „GPT‑Daybreak‑Blue“ įgaliotiems gynybos darbams, įskaitant reagavimą į incidentus, aptikimo inžineriją ir kenkėjiškų programų analizę. Mokykitės naudoti šią priemonę žurnalams, telemetrijos duomenims ir saugumo įspėjimams analizuoti.
- Eksperimentuokite, organizuokite hakatonų savaites ir greitai tobulėkite. Turėsime kurti pačias įvairiausias naujas priemones, keisti savo darbo metodus ir kelti visų kvalifikaciją ruošdamiesi pasauliui, kurio link judame. Skatinkite savo darbuotojus eksperimentuoti, suplanuokite hakatonų savaitę naujoms funkcijoms kurti ir susitelkite į sparčius iteracijų ciklus, padedančius automatizuoti nedideles problemos dalis. Greita laipsniška pažanga leidžia pasiekti vis geresnių gynybos rezultatų, o komandai įgavus užtikrintumo, galite palaipsniui didinti autonomiją.
Nė viena įmonė to nepadarys viena. Kviečiame DI laboratorijas, saugumo sprendimų tiekėjus, įmones ir sistemų prižiūrėtojus dalytis patvirtintomis išvadomis, pataisomis bei praktiniais veiksmų planais, kad vienos organizacijos atradimai sustiprintų visą ekosistemą.
Gynėjų galimybių langas atviras būtent dabar. Ateinančiais mėnesiais kiekviena organizacija turės gerokai automatizuoti savo saugumo programą, kad išliktų saugi, o saugumo bendruomenė privalo skubiai sutelkti jėgas ir apibrėžti priemones, praktikas bei veiksmų planus, kurie, toliau tobulėjant DI, didintų gynėjų galią greičiau nei puolėjų. Tai pareikalaus didžiulių, beprecedenčių pastangų, tačiau susivieniję galime sukurti tokį saugų pasaulį, kokio anksčiau net neįsivaizdavome.
