Pažeidžiamumų skenavimas ar įsilaužimų testavimas: kur baigiasi skenerio galimybės

Ant stalo du pasiūlymai. Viename parašyta „pažeidžiamumų skenavimas“, kitame – „įsilaužimų testavimas“. Pirmosios trys aprašymo eilutės beveik sutampa, kainos skiriasi kelis kartus, ir klausimas kyla savaime: jei įrankis vis tiek viską randa, kam prie jo dar reikia žmogaus?

Skeneris nėra blogas įrankis. Savo darbą jis atlieka nepriekaištingai – tik atsako į kitą klausimą nei tas, kurį po incidento užduos valdyba. Toliau aptariama, kur baigiasi įrankio galimybės: ką jis randa patikimai, ko neras niekada, iš kur atsiranda klaidingai teigiami radiniai, kaip skaityti CVSS įvertį ir kaip skenavimas, vertinimas bei testas susideda į vieną programą.

Vienas pastebėjimas dėl antraštės. Joje sąmoningai rašoma „ar“, o ne „t. y.“: tai ne du vienos paslaugos pavadinimai, o du skirtingi darbai su skirtingu rezultatu. Lietuvoje prie to prisideda dar viena aplinkybė – teisės aktai įvardija tik vieną iš šių dviejų darbų, ir būtent tą, kurį atlieka mašina. Prie šios aplinkybės grįžtama iškart po terminų.

Kas yra pažeidžiamumų skenavimas ir kas – įsilaužimų testavimas?

Trumpas atsakymas telpa į vieną sakinį. Skenavimas ieško, kur yra klaida; įsilaužimų testavimas – ką iš rasto galima išnaudoti ir kaip toli su tuo nueina užpuolikas. Skenavimas dirba į plotį, testas – į gylį.

Ilgesniame atsakyme verta atskirti keturis darbus, nes Lietuvos rinkos pasiūlymuose jie stovi greta painiai panašiais pavadinimais.

Šie keturi darbai vienas kitą papildo, o ne pakeičia. Auditas žiūri į procesus ir dokumentus, skenavimas – į versijas, testas – į pasekmes. Kas turi tik auditą, to popieriai tvarkingi, bet prie sistemų niekas neprisilietė. Kas turi tik skenavimą, tas turi ilgą sąrašą be eiliškumo. Kas testuoja kartą per metus, o tarp testų nedaro nieko, tas nepastebi pažeidžiamumų, paskelbtų per likusius vienuolika mėnesių.

Skirtumas turi ir komercinę pusę. Kai kuriuose kainoraščiuose žodžiu „auditas“ praktiškai parduodamas skenavimas su paslaugų teikėjo logotipu ant viršelio. Trys klausimai parodo, kas perkama iš tikrųjų: kokia darbo dalis atliekama rankiniu būdu, ar kas nors tikrina įrankio radinius ir ar į kainą įskaičiuotas pakartotinis patikrinimas po pataisymų. Jei pasiūlymas neatsako nė į vieną iš jų, jis aprašo skenavimą. Ką apima visas IT saugumo auditas, aprašyta atskirame puslapyje.

Kodėl šis skirtumas Lietuvoje turi ir teisinę reikšmę

Rinkoje abu darbai dažnai pristatomi kaip pasirinkimas pagal biudžetą. Lietuvos teisės aktuose jie nėra lygiaverčiai: įvardytas tik vienas, ir tai – ne testas.

Kibernetinio saugumo reikalavimų apraše, patvirtintame Vyriausybės nutarimu Nr. 945, 45.8 papunktyje nustatyta, kad visos informacinės sistemos pažeidžiamumų skenavimas atliekamas ne rečiau kaip kas 6 mėnesius. Tai automatizuotas patikrinimas, kurio apimtis – visa sistema, o ne pasirinktinė jos dalis.

Įsilaužimų testo tuose pačiuose dokumentuose nėra. Nei Kibernetinio saugumo įstatymas, nei Aprašas jo nereikalauja – nei kasmet, nei prieš paleidžiant sistemą į eksploataciją. Nėra ir testuotojų licencijų ar registro: Kibernetinio saugumo įstatyme licencijavimas neminimas.

Todėl praktinė išvada Lietuvoje skamba priešingai, nei tikisi dauguma: privaloma yra pigesnioji dalis. Spragų skenavimas – tai reguliavimo minimumas, o įsilaužimų testavimas – savanoriškas organizacijos sprendimas, priimamas todėl, kad skeneris atsako tik į dalį klausimo. Kokios trys pareigos kartojasi reguliariai, kaip dažnai ir kuo jos skiriasi, surašyta toliau, skyriuje apie Lietuvos reguliavimą.

Kaip veikia skeneris

Eiga kiekviename įrankyje – Nessus, OpenVAS, Nuclei ir kituose – iš esmės ta pati:

1. Aptikimas. Nustatoma, kurie adresai atsako, kurie prievadai atviri ir kokia paslauga už jų veikia.
2. Paslaugos identifikavimas. Nustatoma, kokia programinė įranga ir kuri jos versija veikia už kiekvieno prievado. Šiuo žingsniu remiasi visa kita, ir būtent jis suklysta pirmas.
3. Palyginimas. Atpažinta versija lyginama su paskelbtų pažeidžiamumų duomenų baze, kurios įrašai turi CVE identifikatorių.
4. Įvertinimas. Kiekvienam radiniui priskiriamas pavojingumo lygis, paprastai CVE įraše nurodytas CVSS bazinis įvertis.

Viskas laikosi ant trečiojo žingsnio. Daugumoje radinių pažeidžiamumas tik numanomas iš versijos numerio, o ne įrodytas. Įrankis pamato banerį „nginx 1.18.0“, randa jį atitinkantį CVE įrašą ir praneša. Ar konkrečioje konfigūracijoje pažeidžiamas kodo kelias apskritai pasiekiamas, lieka nepatikrinta.

Ką skeneris randa patikimai

Nepaisant šio apribojimo, savo lauke įrankis nepralenkiamas, o laukas visai nesiauras:

• Nepertraukiamumas. Nauji CVE įrašai atsiranda kasdien. Sistema, kuri penktadienį buvo švari, pirmadienį gali turėti kritinį pažeidžiamumą, nors prie jos niekas neprisilietė. Tai pastebi tik reguliarus skenavimas.
• Aprėptis. Šimtai adresų per kelias valandas. Rankiniu būdu jų niekas neperžiūri, o bandymas baigiasi praleistomis sistemomis.
• Pakartojamumas. Paleisti pigu, todėl tai daroma kartą per savaitę, o ne kartą per metus.
• Pažeidžiamumų valdymas. Palyginus su ankstesniu paleidimu matyti skirtumas: kas atsirado, kas dingo, kas jau ketvirtį kabo nepašalinta.
• Bendra kalba. Pagal CVE identifikatorių ir CVSS įvertį su programinės įrangos tiekėju, savo komanda ir auditoriumi kalbama apie tą patį dalyką.

Patikimai išryškėja pasenę komponentai su žinomu CVE įrašu, aiškiai atpažįstamos konfigūracijos klaidos (atvira palikta administratoriaus sąsaja, numatytasis slaptažodis, katalogų turinio rodymas, įjungtas derinimo režimas), silpni TLS nustatymai ir pasibaigę sertifikatai, trūkstamos saugumo antraštės ir pokyčiai nuo ankstesnio paleidimo.

Tai ne darbas žmogui: jo daug, jis vienodas, ir rankiniu būdu jame lengva suklysti. Todėl ir mūsų pažeidžiamumų vertinimas prasideda automatizuotu skenavimu. Tik ten jis nesibaigia.

Ko skeneris neras niekada

Toliau išvardytos klaidų klasės automatizuotam įrankiui nėra sunkios – jos jam struktūriškai nepasiekiamos, nes įrankis nežino, kas konkrečioje aplikacijoje leidžiama:

• Netinkamas prieigos teisių valdymas. Naudotojas A mato naudotojo B užsakymus. Skeneriui tai korektiškas atsakymas su 200 būsenos kodu. Kam įrašas priklauso, įrankis nežino.
• Verslo logikos klaidos. Nuolaidos kodas, kurį galima panaudoti daug kartų. Užsakymo žingsnis, kurį galima peršokti. Neigiama suma, kurią sistema įskaito kliento sąskaitai.
• Radinių grandinės. Nekalta informacijos nutekėjimo vieta, silpna slaptažodžio atkūrimo procedūra ir pamiršta testinė paskyra kartu duoda administratoriaus paskyros perėmimą. Skeneris praneša apie tris smulkmenas su žemu prioritetu trijose skirtingose ataskaitos vietose, o ryšio tarp jų nemato.
• Daugiaveiksnio autentifikavimo apėjimas. Pavyzdžiui, per API galinį tašką, kuriame antrojo veiksnio neprašoma.
• Per daug šnekūs atsakymai. Galinis taškas grąžina daugiau laukų, nei rodo sąsaja. Techniškai viskas veikia teisingai, praktiškai nuteka asmens duomenys.

Šias klaidų klases aprašo OWASP metodika, ir nė vienos iš jų neatskleidžia versijų palyginimas. Į ataskaitą jos patenka tik tada, kai kas nors išsiaiškina, kas aplikacijoje leidžiama, o kas – ne.

Iš kur atsiranda klaidingai teigiami radiniai

Praktikoje dažniausias atvejis – atgal perkeltas saugumo pataisymas (angl. backport). Debian, Red Hat ir kiti platintojai pataisą įdiegia į savo paketo versiją, nekeisdami paslaugos rodomo versijos numerio. Spraga uždaryta, o skeneris apie ją vis tiek praneša, nes pažįsta tik numerį.

Prisideda dar trys:

• Nepasiekiamas kodas. Pažeidžiama funkcija bibliotekoje yra, tik aplikacija jos niekada nekviečia.
• Kompensuojančios priemonės. Priekyje stovinti aplikacijų lygmens ugniasienė, tinklo segmentavimas ar autentifikavimas atakos kelią praktiškai paverčia neišnaudojamu.
• Neteisingas identifikavimas. Priekyje pastatytas tarpinis serveris arba sąmoningai perrašytas baneris nuveda įrankį prie visai kitos programinės įrangos.

Todėl etapas, kuris iš įrankio išklotinės padaro pažeidžiamumų vertinimą, visada atrodo vienodai: kiekvienas rimtas radinys patikrinamas rankiniu būdu, likusieji pažymimi kaip triukšmas ir užrašoma, kodėl. Be šio žingsnio sąrašas savaitėms užima komandą dalykais, kurie neturi reikšmės, ir pakeliui ją išmoko, kad saugumo ataskaitas galima ramiai atidėti į šalį. Tai kainuoja brangiausiai.

Kaip skaityti CVSS įvertį

CVSS įvertis iš įpročio skaitomas kaip rizikos lygis. Taip nėra. Jis apibūdina patį pažeidžiamumą su standartinėmis prielaidomis, nežinodamas aplinkos, kurioje pažeidžiamumas atsidūrė.

Bazinis įvertis 9,8 reiškia: klaida išnaudojama per tinklą, be autentifikavimo, su visiška įtaka konfidencialumui, vientisumui ir prieinamumui – su sąlyga, kad sistema iš tikrųjų pasiekiama taip, kaip numato vertinimo prielaidos. Keturi klausimai šį skaičių paverčia realiu prioritetų eiliškumu organizacijos aplinkoje:

Praktikoje 6,5 įverčio klaida kliento portale beveik visada skubesnė nei 9,8 uždaroje testinėje sistemoje. Būtent šio eiliškumo nustatymas ir yra rizikos vertinimas – jis sudėlioja kito ketvirčio taisymo darbus.

Atviras prievadas ir tikras įsilaužimas

Skenavimas baigiasi fakto konstatavimu: prievadas atviras, paslaugos versija pasenusi, įvertis 8,1, greta CVE identifikatorius. Įsilaužimų testavimas prasideda būtent čia ir klausia, kas yra už prievado.

Tokia grandinė praktikoje atrodo taip: pamiršta administratoriaus sąsaja internete, joje paskyra su slaptažodžiu iš diegimo dokumentacijos, sąsajoje perskaitomoje konfigūracijoje – tarnybinės paskyros prieigos duomenys, su ta paskyra pasiekiamas tinkle bendrinamas aplankas su atsarginėmis kopijomis, o atsarginėse kopijose – privilegijuotų paskyrų slaptažodžių maišos. Keturios smulkmenos viena po kitos, o gale – domeno perėmimas.

Skeneris čia praneštų apie tris vidutinio prioriteto radinius trijuose skirtinguose ataskaitos skyriuose, ir nė vienas iš jų neskambėtų skubiai. Testuotojas parašo vieną radinį: domeną galima perimti – su žingsniais, įrodymais ir nuoroda, kurią grandinės grandį pigiau nutraukti. Skirtumas telpa į vieną sakinį: skenavimas įrodo, kad prievadas atviras, o testas – kaip toli pro jį nueina užpuolikas.

Iš čia ir kainų skirtumas: skenavimas atsako į paprastesnį klausimą, ir tai daro mašina. Kas lemia paties testo kainą, surinkta straipsnyje Kiek kainuoja įsilaužimų testavimas, o sąvokas ir darbo eigą paaiškina straipsnis Kas yra įsilaužimų testavimas.

Kurį užsisakyti ir kada

Ko iš to reikalauja Lietuvos reguliavimas

Pareigos Lietuvoje kyla iš dviejų dokumentų. NIS2 čia perkelta ne atskiru įstatymu, o Kibernetinio saugumo įstatymą išdėstant nauja redakcija (įstatymas Nr. XIV-2902, įsigaliojęs 2024 m. spalio 18 d.); konkrečios techninės ir organizacinės priemonės surašytos Vyriausybės nutarimu Nr. 945 patvirtintame Kibernetinio saugumo reikalavimų apraše. Kibernetinio saugumo subjektams jie nustato tris reguliariai pasikartojančias pareigas, ir nė viena iš jų nėra įsilaužimų testas.

Skenavimas – ne pasirinkimas, o minimumas. Aprašo 45.8 papunktis kalba apie visos informacinės sistemos pažeidžiamumų skenavimą, o ne apie pasirinktinę patikrą. „Ne rečiau kaip kas 6 mėnesius“ reiškia du kartus per metus kaip apatinę ribą; aplinkoje, kuri keičiasi kas mėnesį, ši riba dengia mažiau, nei atrodo. Skenerio išklotinė be šalinimo plano taip pat nėra pareigos įvykdymas – Aprašas kalba apie priemonę, kuri veikia, o ne apie failą aplanke.

Atitikties vertinimas nėra techninis testas. Aprašo 48.1 papunktyje numatytą kasmetinį atitikties vertinimą subjektas atlieka pats sau: peržiūrimos įdiegtos priemonės, dokumentai ir įrodymai, o rezultatas parodo, kurių reikalavimų dalis dar neuždengta. Skenavimo ataskaita čia yra vienas iš įrodymų, o ne pats vertinimas.

Auditą atlieka ne kiekvienas. Aprašo 48.3 papunktis ir Kibernetinio saugumo įstatymo 14 straipsnio 8 dalis numato kibernetinio saugumo auditą ne rečiau kaip kas 3 metus. Įstatymas riboja ne pavadinimą, o gebėjimą: auditą atlieka nepriklausomi, tarptautiniu mastu sertifikuoti auditoriai, papildomai baigę Nacionalinio kibernetinio saugumo centro nustatytus mokymus ir išlaikę jo kvalifikacinį egzaminą. Kas šiuos reikalavimus atitinka ir kaip tai pasitikrinti, plačiau aptarta straipsnyje Kas gali atlikti kibernetinio saugumo auditą.

Įsilaužimų testo nereikalauja niekas. Nei Kibernetinio saugumo įstatyme, nei Apraše nėra pareigos atlikti įsilaužimų testą, o testuotojų licencijų ar registro Lietuvoje nėra – licencijavimas įstatyme apskritai neminimas. Todėl pasiūlymas, teigiantis, kad „NIS2 įpareigoja kasmet atlikti įsilaužimų testą“, aprašo rinkos praktiką, o ne Lietuvos teisę. Kur eina ši riba, išsamiau aptarta straipsnyje Ar įsilaužimų testavimas privalomas.

Terminai skaičiuojami kiekvienam subjektui atskirai. Aprašo 71 ir 72 punktai nustato pereinamuosius terminus: organizaciniams reikalavimams – 12 mėnesių, išvardytiems techniniams – 24 mėnesiai. Abu skaičiuojami nuo to paties subjekto registracijos Kibernetinio saugumo informacinėje sistemoje (KSIS) datos, todėl visai rinkai bendros kalendorinės datos nėra. Pirmas praktinis žingsnis – pasitikrinti savo registracijos datą, o ne kieno nors paskelbtą terminą.

Kur baigiasi mūsų darbas. HAXORIS – Slovakijos įmonė, o mūsų darbas – techninis saugumo testavimas ir pasirengimo vertinimas. Kibernetinio saugumo įstatymo 14 straipsnio 8 dalyje numatyto kibernetinio saugumo audito neatliekame ir sertifikatų neišduodame. Dirbame pagal rašytinį užsakovo leidimą ir sutartą apimtį.

Kaip visa tai sudėlioti į vieną programą

Vidutinio dydžio organizacijoje kartu veikia keturi elementai:

1. Skenuokite reguliariai. Iš interneto pasiekiamas sistemas kartą per savaitę, vidinį tinklą kartą per mėnesį ir papildomai po kiekvieno reikšmingo pakeitimo. Kibernetinio saugumo subjektams teisės aktų minimumas – kas 6 mėnesius, tačiau tai apatinė riba, o ne rekomendacija.
2. Tikrinkite kartą per ketvirtį. Kas nors pereina rimtus radinius, atsijoja klaidingai teigiamus ir sudėlioja sąrašą pagal realią riziką. Tai ir yra pažeidžiamumų vertinimas, o ne įrankio išklotinė.
3. Testuokite kartą per metus ir po didelių pakeitimų. Įsilaužimų testavimas dengia tas klaidų klases, kurių neranda joks įrankis, ir sukuria tą įrodymą, kurio ieško auditorius.
4. Patikrinkite pataisymus. Be pakartotinio patikrinimo rankose lieka dokumentuota problema, o ne dokumentuotas sprendimas.

Skenavimas ir testas nekonkuruoja dėl tos pačios biudžeto eilutės, nes prižiūri skirtingus dalykus. Skenavimas žiūri, kad tarp dviejų testų tyliai niekas nesugestų. Testas žiūri, kad įrankio sąrašas nebūtų viskas, ką organizacija žino apie savo sistemas. Kas užsisako tik vieną iš jų, sumoka už pusę atsakymo.

Pažeidžiamumų skenavimas ir įsilaužimų testavimas – dažniausiai užduodami klausimai

Susijusios Haxoris paslaugos: sistemų ir aplikacijų pažeidžiamumų vertinimas · web aplikacijų ir IT infrastruktūros įsilaužimų testavimas