Pastaruosius du mėnesius vadovavome programinės įrangos prižiūrėtojų, tyrėjų ir saugumo paslaugų teikėjų koalicijai, siekiančiai pašalinti kritines PHP – atvirojo kodo programavimo kalbos, naudojamos svetainėms ir žiniatinklio programoms – spragas. Dalyvaudama mūsų iniciatyvoje Patch the Planet(atsidaro naujame lange), „Calif“ aptiko kritinę spragą naudodama GPT‑5.6 Sol. „Wiz“ taip pat nepriklausomai aptiko abi spragas ir apie jas pranešė. PHP prižiūrėtojai vadovavo pataisų rengimui ir išleidimui, o mūsų komandos ir partneriai, įskaitant „Wiz“ ir „Cloudflare“, prisidėjo tyrimais, technine pagalba ir koordinavimu, kad apsaugos priemonės būtų parengtos iki spragų paviešinimo.
PHP naudojančioms organizacijoms dabar svarbiausia įdiegti pataisas. Dalinamės PHP versijos tikrinimo įrankiu kaip „Codex“ įgūdžiu(atsidaro naujame lange) – jis padės administratoriams nustatyti galimai pažeidžiamas PHP versijas ir, remiantis PHP bei paslaugų teikėjų rekomendacijomis, išsiaiškinti, kurių naujinimų reikia.
Atsižvelgdami į šių spragų rimtumą ir platų PHP naudojimą, tai laikome viena didžiausią poveikį turinčių pastarojo meto saugumo problemų. Tai parodo, kaip DI gali aptikti saugumo spragas, kurių poveikis apima visą internetą, tačiau tie patys pajėgumai gali padėti užpuolikams sparčiai kurti atakų ir spragų išnaudojimo įrankius.
Mūsų žiniomis, priešakinis DI šias spragas aptiko anksčiau nei užpuolikai, taip atverdamas gynėjų galimybių langą: prižiūrėtojai ir saugumo paslaugų teikėjai galėjo parengti pataisas bei apsaugos priemones iki paviešinimo.
Kad šiais pajėgumais galėtų naudotis daugiau gynėjų, įsipareigojome skirti 1 mlrd. JAV dolerių subsidijuojamai prieigai prie „Daybreak“ pagal programą „Daybreak“ priešakinės linijos gynėjams. Ji skirta ribotus saugumo išteklius turinčioms organizacijoms, saugančioms esmines paslaugas.
Kad ir kokios reikšmingos būtų šios klaidos, jos tėra dalis jau aptiktų svarbių spragų, kurias siekiame pašalinti. Tikimės, kad artimiausiais mėnesiais panašių atradimų smarkiai padaugės. Remdamiesi sukaupta patirtimi, siūlome DI erai pritaikytą reagavimo į kritines plačiai naudojamos programinės įrangos spragas metodiką ir kviečiame saugumo bendruomenę padėti ją tobulinti. Ji sujungia mūsų modelius, saugumo kompetenciją ir prižiūrėtojų darbą, kad atradimai virstų apsauga, o reagavimo mastas galėtų augti kartu su DI pajėgumais.
Kad pataisa būtų pradėta naudoti, gali tekti ją pritaikyti senesnėms versijoms, parengti paslaugų teikėjų rizikos mažinimo priemones ir atnaujinti daugelio organizacijų sistemas. Pakartojamas procesas padeda šioms komandoms veikti greitai, kai aptinkama vis daugiau spragų.
Per „Patch the Planet“ prisidėjome prie reagavimo į PHP spragas savo saugumo kompetencija ir prieiga prie modelių, o su prižiūrėtojais ir tyrimų partneriais išbandėme pataisas bei rengėme rekomendacijas. Taip pat padėjome derinti paveiktų sistemų apsaugą su infrastruktūros teikėjais ir įtraukėme valstybines kibernetinio saugumo institucijas, kad rekomendacijos pasiektų kritiškai svarbias organizacijas. Tai sustiprino prižiūrėtojų vadovaujamą atsaką ir padėjo pasirengti kitiems gynėjams.
Kai kurias aptiktas spragas tyrėjai gali tirti ir taisyti tiesiogiai su programinės įrangos prižiūrėtojais. Kitoms reikia platesnio atsako, nes jos paveikia daug produktų arba platintojams ir paslaugų teikėjams reikia laiko naujinimams bei apsaugos priemonėms parengti. To laiko gali trūkti, jei priešakiniai pajėgumai nedaug lenkia plačiai prieinamus. Tokiais atvejais siūloma metodika gali padėti prižiūrėtojams nustatyti, ką reikia įtraukti, ir koordinuoti darbus. Reagavimas gali apimti penkis etapus:
Patvirtinti ir pašalinti spragą pirminiame projekte. Prižiūrėtojas, tyrėjai ir pagrindiniai techniniai partneriai patvirtina atradimą, įvertina jo poveikį, parengia ir išbando pataisą. Šis procesas apima atakas imituojančius bandymus su priešakiniais modeliais, ieškant būdų apeiti pataisą ir susijusių spragos variantų.
Duoti paveiktoms organizacijoms laiko veikti. Siūlome metodiką, padedančią įvertinti, kurioms organizacijoms reikia išankstinės informacijos apsaugai parengti, tačiau ką įtraukti, sprendžia prižiūrėtojai. Padedame užmegzti ryšius, sudaryti informacijos mainų susitarimus ir koordinuoti komandų darbą. Platintojas gali pritaikyti pataisą senesnei versijai, prieglobos teikėjas – išbandyti rizikos mažinimo priemonę, o saugumo paslaugų teikėjas – parengti aptikimo ar prevencijos priemones, įskaitant žiniatinklio programų užkardos (WAF) taisykles.
Derinti veiksmus su valstybiniais partneriais, siekiant apsaugoti kritines sistemas. Valstybės institucijos atlieka esminį vaidmenį koordinuodamos platesnį atsaką ir padėdamos saugumo rekomendacijoms pasiekti organizacijas, atsakingas už kritinę infrastruktūrą ir kitas esmines paslaugas. PHP atveju kartu su partneriais siekėme įtraukti įvairias JAV valdžios institucijas, įskaitant Baltųjų rūmų superintelekto darbo grupę, Nacionalinio kibernetinio saugumo direktoriaus biurą (ONCD), Kibernetinio saugumo ir infrastruktūros saugumo agentūrą (CISA), taip pat tarptautinius partnerius.
Parengti visų paveiktų produktų naujinimus. Kai pataisa, rekomendacijos ir paviešinimo planai nusistovi, prižiūrėtojai gali įtraukti daugiau platintojų, prieglobos ir paslaugų teikėjų, reagavimo komandų bei administratorių, kad parengtų naujinimus ir užpildytų apsaugos aprėpties spragas.
Kai pataisa prieinama, paskelbti rekomendacijas ir padėti ją diegti. Viešos rekomendacijos padeda įvertinti pažeidžiamumą, rasti patikimus naujinimus ar laikinas rizikos mažinimo priemones ir patikrinti, ar pataisa veikia. Reagavimas tęsiasi administratoriams diegiant naujinimus ir pranešant, kur reikia pagalbos.
Siūlomoje metodikoje atsižvelgiama į organizacijos vaidmenį užtikrinant apsaugą, įskaitant savo sistemų ir klientų apsaugą, veiksmams reikalingą laiką ir gebėjimą tvarkyti jautrią informaciją. Panašioms organizacijoms būtų taikomi tie patys kriterijai, o prižiūrėtojai spręstų, ką įtraukti iki paviešinimo.
Kiekvienas dalyvis gauna apsaugos darbui reikalingą informaciją – nuo tinklo žurnalų su įsilaužimo požymiais iki jautresnių veikiančių spragos išnaudojimo demonstracijų. Net menkos detalės gali atskleisti spragą, todėl jų dalijimosi riziką vertiname atsižvelgdami į tai, kokią apsaugą jos leidžia užtikrinti.
Pagal šią metodiką dirbančios komandos su prižiūrėtojais suteiktų gynėjams laiko pasirengti ir peržiūrėtų terminus, jei spraga būtų aktyviai išnaudojama, nutekėtų informacija, spragą atskleistų vieša pataisa arba dėl užsitęsusio taisymo išaugtų rizika naudotojams.
„Patch the Planet“ svetainėje(atsidaro naujame lange) pateikiami vieši pranešimai ir rekomendacijos, padedančios administratoriams nustatyti paveiktas sistemas, rasti tinkamą naujinimą ir patikrinti, ar atnaujinta programinė įranga veikia tinkamai. PHP atveju joje pateikiamos nuorodos į oficialią prižiūrėtojų pataisą, atnaujinimo instrukcijas ir mūsų partnerių techninius tyrimus. Rekomendacijos taip pat apima laikinas rizikos mažinimo priemones, atvejus, kada kreiptis į teikėją ar ekspertą, atsarginių kopijų kūrimą ir atkūrimą. Laikinos apsaugos priemonės gali sumažinti riziką, tačiau aiškiai nurodysime jų ribotumą ir poveikį sistemų veikimui.
Administratoriai gali remtis CISA prioritetų nustatymo ir spragų šalinimo rekomendacijomis(atsidaro naujame lange), kad pagal pažeidžiamumą, išnaudojimą ir galimą poveikį įvertintų, kaip greitai reikia veikti. Gali prireikti skubiai įdiegti pataisą, nedelsiant sumažinti riziką arba suplanuoti naujinimą, o prireikus – atlikti pirminį skaitmeninį tyrimą ir įvertinti, ar į sistemas jau neįsilaužta. Keičiantis aplinkybėms, prioritetus reikėtų peržiūrėti, išlaikant aiškų kelią į ilgalaikį spragos pašalinimą.
Pasaulinis koordinavimas priklauso nuo žmonių, prižiūrinčių programinę įrangą. Daug projektų vykdo nedidelės komandos, kurios saugumo pranešimus nagrinėja greta kasdienių kūrimo darbų. Šioms komandoms reikia pagalbos atskiriant naujas problemas nuo pasikartojančių pranešimų, vertinant poveikį ir išbandant pataisas visose palaikomose versijose. Šį darbą remiame finansavimu, prieiga prie pajėgių modelių ir praktine inžinerine pagalba.
Visame sektoriuje DI pajėgumai auga, ir tikimės, kad DI vaidmuo padedant gynėjams aptikti spragas, stebėti sistemas ir reaguoti į grėsmes vis didės. Investuojame į modelius, įrankius ir partnerystes, kad padėtume gynėjams praktiškai panaudoti šiuos pajėgumus.
Mūsų investicijos apima prenumeratas visiems prižiūrėtojams per Codex for OSS ir tiesioginę paramą tokiems projektams kaip „Rust“ fondas(atsidaro naujame lange), skirtą prižiūrėtojams ir techniniams darbams. Kiekvienas projektas pats nustato savo prioritetus. Pakartotinai naudojami testai ir saugumo darbo procesai gali sumažinti pastangas, kurių prireiks ateityje aptiktoms spragoms šalinti. Atvirojo kodo projektai gali teikti paraiškas „Patch the Planet“(atsidaro naujame lange) praktinei pagalbai gauti.
Taip pat deriname papildomus „Daybreak“ blokavimo klasifikatorius, kad sumažintume piktnaudžiavimo galimybes. Čia tenka ieškoti sudėtingų kompromisų: apsaugos priemonės, skirtos užkirsti kelią piktnaudžiavimui, gali blokuoti ir teisėtą saugumo darbą. Tiek plati prieiga prie pajėgių modelių, tiek veiksminga apsauga nuo piktnaudžiavimo yra būtinos. Siekiame išsaugoti gynėjams reikalingus pajėgumus spragoms aptikti ir šalinti, kartu ribodami žalingą naudojimą. Toliau tobulinsime šią pusiausvyrą augant pajėgumams ir mokydamiesi iš to, kaip šie įrankiai naudojami.
Modeliams tampant pajėgesniems, atsiveria galimybių ne tik aptikti ir šalinti pavienes spragas. Norime padėti inžinieriams nuo pat pradžių kurti saugesnę programinę įrangą. Patobulinus plačiai naudojamą komponentą, galima išvengti klaidų arba apriboti jų poveikį daugelyje produktų ir paslaugų.
DI gali padėti inžinieriams suprasti esamą kodą, parengti pakeitimus ir kurti testus, o prižiūrėtojai ir saugumo ekspertai patikrina, ar pakeitimai išsaugo naudotojams svarbų veikimą. Galimybių matome keliose srityse:
Saugus kodas nuo pat pradžių. Programavimui skirti modeliai gali padėti kūrėjams pasirinkti saugesnes numatytąsias nuostatas, tinkamai naudoti saugumo bibliotekas ir pastebėti rizikingus šablonus dar rašant kodą. Užkirtus kelią spragoms kūrimo metu, prižiūrėtojams ir naudotojams reikia mažiau skubių pataisų.
Saugiai atmintį naudojanti programinė įranga. Perrašius kritinius komponentus atminties saugą užtikrinančiomis kalbomis, galima pašalinti dažnas atminties klaidų klases. DI gali padėti perkelti kodą, o testai ir ekspertų peržiūra – patikrinti veikimą bei suderinamumą.
Formalusis tikrinimas. Matematiniais įrodymais galima parodyti, kad, esant nurodytoms prielaidoms, kritiniai komponentai atitinka apibrėžtas saugumo savybes. Taikant šiuos metodus plačiai naudojamiems komponentams, būtų galima pašalinti ištisas spragų klases nuo jų priklausančiose paslaugose ir kritinėje infrastruktūroje.
Griežtesnis izoliavimas. Sistemas reikia saugoti ir nuo dar neaptiktų ar nepašalintų spragų. Jei programinė įranga, apdorojanti nepatikimus failus, vaizdus ar mediją, veikia griežtai apribotose izoliuotose aplinkose, įsilaužimo atveju galima sumažinti žalą. DI gali padėti inžinieriams išbandyti ir sustiprinti plačiai naudojamas izoliavimo technologijas, taip gerinant daugelio programų apsaugą.
Pristatome savo požiūrį, kad prižiūrėtojai, tyrėjai, reagavimo komandos, teikėjai ir administratoriai galėtų padėti jį pritaikyti praktikoje. Norime suprasti, kur jis būtų naudingas, kur galėtų lėtinti darbą ar didinti naštą ir ką praleidome. Ypač praverstų ankstesnių spragų paviešinimo pavyzdžiai.
Mus ypač domina:
Terminai iki paviešinimo. Kiek laiko prižiūrėtojams, administratoriams ir gynėjams reikia patikimoms pataisoms parengti ir įdiegti? Kokie įrodymai turėtų paskatinti paviešinti spragą anksčiau, ypač kai vienus naudotojus galima apsaugoti greičiau nei kitus?
Skubus pataisų diegimas. Ar valdžios institucijos arba kiti administratoriai, netekę administravimo prieigos, turėtų išnaudoti spragą, kad įdiegtų pataisas jiems priklausančiose arba jų teisėtai valdomose sistemose? Jei taip, kada? Kokios apsaugos priemonės turėtų būti taikomos? Galime įsivaizduoti ateitį, kai visame internete nuolat ieškoma žinomų spragų, o jas aptikus pranešama svetainių savininkams arba sistemoje įdiegiama pataisa.
Išankstinis pranešimas. Kam reikia išankstinio įspėjimo, kad galėtų imtis naudingų apsaugos veiksmų, įskaitant gynėjus, kurių galime nepastebėti? Kada pranešimas etapais veikia geriau nei platesnės grupės informavimas vienu metu ir kaip derinti aprėptį su informacijos nutekėjimo rizika?
Pagal numatytąsias nuostatas saugūs programinės įrangos paketai. Kaip galime padėti aptikti ir šalinti spragas išvestiniuose paketuose, kol laukiama pirminio projekto pataisų, arba pritaikyti pataisas senesnėms versijoms, kurios nebegauna saugumo naujinimų? Kokie bandymai ir priežiūra leistų patikimai rinktis šiuos paketus, kai laiku atnaujinti versijos neįmanoma?
Taip pat laukiame rekomendacijų dėl nepriklausomų saugumo ekspertų, kurie galėtų peržiūrėti šį požiūrį, kritiškai įvertinti jo prielaidas ir nustatyti trūkumus. Jūsų įžvalgos padės mums tobulinti reagavimą ir nustatyti pagalbos prioritetus. Pasidalykite atsiliepimais čia(atsidaro naujame lange).
