Trumpai: pažeidžiamumų valdymas vidutinėse ir mažose įmonėse yra lengvas, pasikartojantis ciklas: pažinti savo sistemas, tikslingai sekti pranešimus, vertinti pagal riziką, spręsti, įgyvendinti ir įrodyti. Lemia ne brangūs įrankiai, o aiškios atsakomybės ir prioritetų nustatymas, atsižvelgiant į pasiekiamumą, duomenis ir atakų situaciją. PHP2Shell yra geras mokomasis pavyzdys, nes jame pasitaiko visi šie žingsniai.
Šimtai pranešimų, mažai darbuotojų
Kiekvieną savaitę paskelbiama naujų saugumo spragų: operacinėse sistemose, programavimo kalbose, programose ir papildiniuose. Koncernas tam turi komandą. Vidutinė įmonė dažnai turi IT vadovą, vieną ar du administratorius ir kelis išorinius paslaugų teikėjus. Niekas negali perskaityti kiekvieno pranešimo, ir to daryti nereikia.
Reikia filtro: kurie pranešimai liečia mūsų sistemas, kurie iš jų skubūs ir kas jais rūpinasi? Be šio filtro nutinka vienas iš dviejų dalykų. Arba viskas ignoruojama, kol kas nors įvyksta, arba kiekvienas pranešimas sukelia sujudimą, o iš tiesų kritinis pranešimas pasimeta triukšme.
Pažeidžiamumų valdymo ciklas
Tinkamą MVĮ procesą galima apibūdinti šešiais žingsniais:
- Užfiksuoti, kas veikia. Be inventoriaus nėra ką lyginti. Kokias svetaines, serverius, PHP versijas ir programas eksploatuojate ir kur? Kaip tai pavyksta, aprašyta straipsnyje Žinoti, kas veikia: visų svetainių ir serverių inventorius.
- Sekti pranešimus. Užsiprenumeruokite kelis patikimus šaltinius: BSI įspėjimus, jūsų naudojamos programinės įrangos gamintojų pranešimus, jūsų Linux distribucijos saugumo puslapius, o PHP atveju – php.net pagrindinį puslapį.
- Vertinti. Ar pranešimas mus liečia? Jei taip, kiek jis skubus? Daugiau apie tai žemiau.
- Spręsti. Pašalinti, laikinai apsaugoti, izoliuoti sistemą ar sąmoningai prisiimti riziką. Kas ką turi teisę spręsti?
- Įgyvendinti. Įdiegti atnaujinimą, taikyti pereinamąją priemonę, pavesti darbą paslaugų teikėjui.
- Įrodyti ir stebėti. Ar spraga tikrai uždaryta? Kada pereinamasis sprendimas bus pakeistas galutiniu?
Po to ciklas prasideda iš naujo. Atsiranda naujų sistemų, senos išnyksta, pasirodo nauji pranešimai.
Atliekant 2 žingsnį padeda paprasta taisyklė: geriau reguliariai skaityti kelis šaltinius nei retkarčiais daug. Tipinei vidutinės įmonės žiniatinklio aplinkai paprastai pakanka CERT-Bund įspėjimų prie BSI, naudojamos Linux distribucijos saugumo pranešimų, CMS ir parduotuvių sistemų gamintojų puslapių ir php.net pagrindinio puslapio. Nustatykite, kas šiuos šaltinius skaito, ir tam įsteigkite bendrą pašto dėžutę ar kanalą, kuris nepriklauso nuo vieno asmens.
Naudinga ir išorinė perspektyva. Reguliarus viešai pasiekiamų sistemų pažeidžiamumų skenavimas parodo, ar matoma pasenusi programinė įranga arba be reikalo atviros paslaugos. Jis nepakeičia nei inventoriaus, nei atnaujinimų, bet atskleidžia sistemas, kurių nėra jokiame sąraše.
Vertinimas: kas pirmiausia
CVSS vertė, standartizuotas sunkumo laipsnio įvertinimas, yra geras atspirties taškas. Tačiau eilės tvarkai savo įmonėje jos nepakanka. Lemia dar trys klausimai:
| Klausimas | Didina skubumą | Mažina skubumą |
|---|---|---|
| Ar sistema pasiekiama iš interneto? | vieša svetainė, parduotuvė, portalas | tik viduje, už VPN |
| Ar spragai išnaudoti reikia prisijungimo? | ne, be autentifikavimo | taip, tik administratoriams |
| Kokius duomenis sistema tvarko? | klientų duomenis, mokėjimus, prieigas | viešą turinį be paskyrų |
| Ar yra pranešimų apie atakas? | pranešta apie atakų bandymus | žinomų bandymų nėra |
| Ar yra pereinamoji priemonė? | ne | taip, su įrodytu poveikiu |
PHP2Shell parodo, kaip tai veikia kartu. Abiejų pažeidžiamumų CVSS v4.0 vertė yra 9,2, jie leidžia vykdyti kodą be prisijungimo ir veikia viešai pasiekiamus žiniatinklio serverius. Pasak žiniasklaidos, Cloudflare ir Patchstack pranešė apie atakų bandymus, o BSI situaciją įvertino 3 įspėjimo lygiu. php.net pereinamosios priemonės aiškiai nesuteikia visiškos apsaugos. Visi klausimai rodo ta pačia kryptimi: veikti nedelsiant. Ką BSI konkrečiai rekomendavo, rasite skyriuje Ką BSI rekomenduoja dėl PHP2Shell.
Spręsti ir dokumentuoti
Ne kiekvieną spragą galima uždaryti iš karto. Senoji sistema veikia su PHP 8.1, kuriai oficialių atnaujinimų nebėra (žr. PHP 8.1 ir senesnės: kas dabar galioja), o specializuota programa dar nepakenčia atnaujinimo. Tada reikia sprendimo, ir jis priklauso ne vien technikos sričiai.
Gera sprendimo pastaba apima paveiktą sistemą, spragą, vertinimą, pasirinktą variantą, pereinamąsias priemones, atsakingą asmenį ir pakartotinės patikros terminą. Jei rizika prisiimama sąmoningai, sprendžia vadovybė, o ne vien administratorius. OWASP Cheat Sheet apie pažeidžiamų priklausomybių tvarkymą taip pat rekomenduoja rizikos priėmimą aiškiai įtvirtinti vadovybės lygmeniu.
Tvarkykite vieną atvirų pažeidžiamumų sąrašą su būsena, atsakingu asmeniu ir terminu. Pakanka lentelės. Svarbu, kad ji būtų reguliariai peržiūrima, pavyzdžiui, kas mėnesį vykstančiame susitikime su vadovybe.
Ką su tuo bendra turi NIS2 ir paslaugų teikėjai
Įmonėms, kurioms taikoma NIS2, darbas su pažeidžiamumais yra rizikos valdymo pareigų dalis. Išsamiau tai aprašyta straipsnyje NIS2 ir žiniatinklio serverių saugumas. Bet net be teisinės pareigos dokumentuotas procesas yra pranašumas, pavyzdžiui, klientų, draudikų ir savo vadovybės akyse.
Daugelį žingsnių galima perduoti išorei, pavyzdžiui, pranešimų sekimą ar atnaujinimų diegimą. Tačiau sprendimai dėl rizikos ir bendra apžvalga turėtų likti įmonėje. Kas visą ciklą perduoda paslaugų teikėjui, kritiniu atveju nebežino, kokias sistemas apskritai turi. Kaip įgyvendinimą organizuoti kaip rutiną, aprašyta straipsnyje Pataisų valdymas kaip procesas, o ne gaisrininkų darbas.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis sudarome jūsų svetainių ir serverių inventorių kaip kiekvieno palyginimo pagrindą.
- Sekame jūsų sistemoms aktualius pranešimus ir pateikiame vertinimą aiškiais žodžiais su rekomendacija.
- Parengiame sprendimų pastabas tiems atvejams, kai atnaujinimo iškart įdiegti neįmanoma.
- Per saugumo stebėseną nuolat tikriname, ar sistemos nepradeda elgtis įtartinai, kol spraga dar atvira.
Išvada: pažeidžiamumų valdymas vidutinėse įmonėse neturi būti didelis, bet turi būti įpareigojantis. Kas pažįsta savo sistemas, skaito kelis gerus šaltinius ir užfiksuoja sprendimus, kitą kartą gavęs kritinį pranešimą reaguoja greitai ir teisingai.
Dažni klausimai
Kas yra pažeidžiamumų valdymas?
Pasikartojantis procesas, kurio metu įmonė sužino apie savo sistemų saugumo spragas, jas įvertina, pašalina arba sąmoningai priima, o rezultatą užfiksuoja. Svarbus ne įrankis, o atsakomybių pasidalijimas ir sprendimai.
Ar prioritetams nustatyti pakanka CVSS vertės?
Tai geras atspirties taškas, bet ne pakankamas. Papildomai lemia, ar paveikta sistema pasiekiama iš interneto, kokius duomenis ji tvarko ir ar jau stebimos atakos. Didelio įvertinimo spraga vidinėje bandomojoje sistemoje gali palaukti, parduotuvėje – ne.
Ar mažai įmonei tam reikia atskiro įrankio?
Pradžioje ne. Pakanka prižiūrimo sistemų sąrašo, užsiprenumeruotų saugumo pranešimų ir lentelės su neišspręstais klausimais. Pažeidžiamumų skeneriai verta naudoti, kai sistemų daugėja arba kai patikras reikia reguliariai dokumentuoti.
Ar galima sąmoningai nepašalinti pažeidžiamumo?
Taip, jei rizika įvertinta, sprendimą priėmė atsakinga vadovybė ir jis užfiksuotas raštu, geriausia kartu su pereinamosiomis priemonėmis ir pakartotinės patikros terminu.