Kiekvieną dieną viešai paskelbiama dešimtys naujų pažeidžiamumų, o per metus jų susidaro dešimtys tūkstančių. Jokia organizacija negali ištaisyti visų iš karto. Todėl pažeidžiamumų valdymas yra ne vienkartinis skenavimas, o nuolatinis procesas: rasti spragas, įvertinti, kurios iš tikrųjų pavojingos, jas pašalinti ir patikrinti rezultatą. Šioje temoje išnagrinėsime, kaip šis procesas veikia ir kaip nuspręsti, ką taisyti pirmiausia.
Pažeidžiamumų valdymo ciklas
Pažeidžiamumų valdymas paprastai aprašomas kaip ciklas, kurį sudaro penki etapai.
1. Inventorizavimas. Negalima apsaugoti to, apie ką nežinoma. Pirmiausia sudaromas visų įrenginių, serverių, programų, debesijos išteklių ir jų programinės įrangos versijų sąrašas.
2. Aptikimas. Pažeidžiamumai randami skenuojant sistemas, analizuojant programų komponentus, stebint gamintojų pranešimus ir atliekant skverbties testus.
3. Vertinimas ir prioritetų nustatymas. Kiekvienam pažeidžiamumui nustatoma, kiek jis pavojingas būtent šiai organizacijai.
4. Šalinimas. Įdiegiama pataisa, pakeičiama konfigūracija arba, jei pataisos nėra, taikomos laikinos apsaugos priemonės.
5. Patikrinimas ir ataskaitos. Pakartotinai patikrinama, ar spraga tikrai pašalinta, o rezultatai apibendrinami vadovybei.
Ciklas kartojasi nuolat, nes atsiranda naujų sistemų, naujų pažeidžiamumų ir naujų grėsmių.
CVE: bendri pažeidžiamumų pavadinimai
Kad visi kalbėtų apie tą patį pažeidžiamumą, kiekvienas viešai žinomas pažeidžiamumas gauna unikalų CVE (angl. Common Vulnerabilities and Exposures) identifikatorių, pavyzdžiui, CVE-2021-44228. Jį sudaro metai ir eilės numeris. CVE sistemą koordinuoja organizacija MITRE, o identifikatorius suteikia daugybė įgaliotų institucijų, įskaitant didžiuosius programinės įrangos gamintojus.
CVE identifikatorius leidžia tiksliai susieti gamintojo pranešimą, skenerio radinį, grėsmių žvalgybos ataskaitą ir pataisą. JAV nacionalinė pažeidžiamumų duomenų bazė NVD prie CVE įrašų prideda papildomą informaciją, įskaitant sunkumo įvertinimą, o Europoje panašią duomenų bazę kuria ES kibernetinio saugumo agentūra ENISA.
CVSS: pažeidžiamumo sunkumas
CVSS (angl. Common Vulnerability Scoring System) yra standartas, pagal kurį pažeidžiamumui suteikiamas balas nuo 0 iki 10. Balas paverčiamas sunkumo lygiu: nuo 0,1 iki 3,9 yra žemas, nuo 4,0 iki 6,9 vidutinis, nuo 7,0 iki 8,9 aukštas, o nuo 9,0 iki 10,0 kritinis. Standartą prižiūri tarptautinė incidentų reagavimo komandų organizacija FIRST, o naujausia jo versija yra CVSS 4.0.
Balas apskaičiuojamas pagal pažeidžiamumo savybes: ar jį galima išnaudoti per tinklą, ar reikia vietinės prieigos; ar ataka sudėtinga; ar užpuolikui reikia turėti kokias nors teises; ar reikia naudotojo veiksmo, pavyzdžiui, paspaudimo ant nuorodos; ir koks poveikis konfidencialumui, vientisumui bei prieinamumui.
Svarbu suprasti, ką CVSS nerodo. Pagrindinis balas apibūdina techninį pažeidžiamumo sunkumą bendrai, bet nežino, ar pažeidžiama sistema organizacijoje pasiekiama iš interneto, ar joje yra jautrūs duomenys ir ar užpuolikai šį pažeidžiamumą jau naudoja. Todėl prioritetus nustatyti vien pagal CVSS yra dažna klaida.
Rizika grįstas prioritetų nustatymas
Kadangi pažeidžiamumų yra per daug, juos tenka rūšiuoti pagal tikrąją riziką. Be CVSS, atsižvelgiama į keletą kitų veiksnių.
Ar pažeidžiamumas aktyviai išnaudojamas? JAV kibernetinio saugumo agentūra CISA skelbia KEV (angl. Known Exploited Vulnerabilities) katalogą, kuriame yra tik tie pažeidžiamumai, kurių išnaudojimas realiai užfiksuotas. Tai viena naudingiausių nemokamų priemonių prioritetams nustatyti: į KEV patekęs pažeidžiamumas turi būti taisomas pirmiausia.
Kokia tikimybė, kad jis bus išnaudotas? EPSS (angl. Exploit Prediction Scoring System), kurį taip pat prižiūri FIRST, pagal statistinį modelį įvertina tikimybę, kad pažeidžiamumas bus išnaudotas artimiausiu metu. Tyrimai rodo, kad realiai išnaudojama tik nedidelė dalis visų paskelbtų pažeidžiamumų.
Koks turto svarbumas ir pasiekiamumas? Pažeidžiamumas iš interneto pasiekiamame serveryje su klientų duomenimis yra daug pavojingesnis nei tas pats pažeidžiamumas izoliuotame testiniame kompiuteryje.
Ar yra kompensuojančių priemonių? Jei pažeidžiamą funkciją blokuoja ugniasienė ar segmentavimas, rizika mažesnė.
Praktinis pavyzdys: vidutinio CVSS balo pažeidžiamumas, esantis KEV kataloge, iš interneto pasiekiamame VPN įrenginyje, dažnai yra skubesnis nei kritinio balo pažeidžiamumas uždarame vidiniame serveryje, kurio niekas neišnaudoja.
Pažeidžiamumų skenavimas
Pažeidžiamumų skeneriai automatiškai tikrina sistemas ir lygina rastas programinės įrangos versijas bei konfigūracijas su žinomų pažeidžiamumų duomenų bazėmis. Žinomi komerciniai sprendimai yra „Tenable Nessus“, „Qualys“ ir „Rapid7“, o atvirojo kodo alternatyva yra „OpenVAS“ („Greenbone“).
Skenavimas būna dviejų tipų. Neautentifikuotas skenavimas mato sistemą taip, kaip ją matytų išorinis užpuolikas. Autentifikuotas skenavimas prisijungia prie sistemos ir mato visas įdiegtas programas bei jų versijas, todėl randa daug daugiau pažeidžiamumų ir rečiau klysta. Išoriniai skenavimai rodo, ką mato internetas, o vidiniai padeda įvertinti, kas nutiktų, jei užpuolikas jau būtų viduje.
Skeneriai nėra tobuli. Jie generuoja klaidingai teigiamų radinių, pavyzdžiui, praneša apie pažeidžiamumą, nors gamintojas pataisą įdiegė nepakeisdamas versijos numerio, ir klaidingai neigiamų, kai realios spragos nepastebi. Todėl rezultatus būtina vertinti kritiškai. Svarbu prisiminti ir tai, kad skenuoti galima tik savo arba aiškiai leistas sistemas: neleistinas svetimų sistemų skenavimas gali būti laikomas neteisėta veika.
Šalinimas ir pataisų valdymas
Pagrindinis pažeidžiamumų šalinimo būdas yra pataisų diegimas. Organizacijos nustato šalinimo terminus pagal sunkumą, pavyzdžiui, kritiniams iš interneto pasiekiamiems pažeidžiamumams kelias dienas, aukštiems kelias savaites, o kitiems iki kelių mėnesių. Šie terminai įrašomi į saugumo politiką ir stebimi.
Pataisos diegiamos per pakeitimų valdymo procesą: pirmiausia testinėje aplinkoje, tada bandomajai grupei, galiausiai visoms sistemoms. Būtinas ir atsitraukimo planas, jei pataisa sutrikdytų veiklą.
Kai pataisos nėra arba jos neįmanoma greitai įdiegti, taikomos kompensuojančios priemonės: išjungiama pažeidžiama funkcija, apribojama prieiga ugniasiene, sistema izoliuojama segmentavimu ar sustiprinama stebėsena. Jei pažeidžiamumas sąmoningai paliekamas neištaisytas, tai turi būti dokumentuota kaip rizikos priėmimas, patvirtintas atsakingo vadovo ir su peržiūros data.
Pažeidžiamumai be pataisų ir atsakingas atskleidimas
Nulinės dienos pažeidžiamumas (angl. zero-day) yra spraga, kurią užpuolikai išnaudoja anksčiau, nei gamintojas apie ją sužino ar išleidžia pataisą. Nuo jo apsaugoti gali tik gynyba sluoksniais: segmentavimas, mažiausios privilegijos, EDR ir stebėsena, leidžianti pastebėti neįprastą elgseną.
Saugumo tyrėjai, radę pažeidžiamumą, laikosi atsakingo arba koordinuoto atskleidimo principo: pirmiausia slapta praneša gamintojui ir duoda laiko pataisai paruošti, o tik tada informaciją skelbia viešai. Daugelis organizacijų tam skelbia pažeidžiamumų atskleidimo politiką ir saugumo kontaktą, dažnai faile security.txt savo svetainėje. Kai kurios taip pat vykdo klaidų paieškos programas (angl. bug bounty), kuriose už rastus pažeidžiamumus moka atlygį. Lietuvoje pranešti apie pažeidžiamumus galima ir Nacionaliniam kibernetinio saugumo centrui.
Rodikliai
Pažeidžiamumų valdymo veiksmingumas matuojamas rodikliais. Dažniausiai stebimi vidutinis šalinimo laikas (angl. Mean Time to Remediate), terminų laikymosi procentas, atvirų kritinių pažeidžiamumų skaičius ir aprėptis, t. y. kokia turto dalis apskritai yra skenuojama. Paskutinis rodiklis dažnai pamirštamas, nors neskenuojamos sistemos yra akli taškai.
Svarbiausios temos išvados
Pažeidžiamumų valdymas yra nuolatinis ciklas: inventorizavimas, aptikimas, prioritetų nustatymas, šalinimas ir patikrinimas. CVE suteikia pažeidžiamumams bendrus pavadinimus, o CVSS įvertina jų techninį sunkumą, tačiau prioritetus reikia nustatyti pagal tikrąją riziką, atsižvelgiant į KEV katalogą, EPSS tikimybę, turto svarbą ir pasiekiamumą. Autentifikuotas skenavimas randa daugiau, bet rezultatus būtina vertinti kritiškai. Pataisos diegiamos pagal nustatytus terminus per pakeitimų valdymą, o kai jų nėra, taikomos kompensuojančios priemonės arba dokumentuotas rizikos priėmimas. Kitoje temoje nagrinėsime saugumo stebėseną, SIEM sistemas ir SOC komandos darbą.
Savikontrolės klausimai
1. Kodėl pažeidžiamumų valdymas prasideda nuo turto inventorizavimo?
2. Ko nerodo pagrindinis CVSS balas ir kodėl prioritetai vien pagal jį gali būti klaidingi?
3. Kodėl pažeidžiamumas, esantis CISA KEV kataloge, paprastai taisomas pirmiausia?
4. Kuo autentifikuotas skenavimas pranašesnis už neautentifikuotą?
5. Ką daryti, jei pataisos pažeidžiamumui dar nėra arba jos neįmanoma greitai įdiegti?
Visos pamokos
