Haavatavuste skaneerimine või penetratsioonitest: mida skanner leiab ja kus ta lõpeb
·Kõige olulisem lühidalt
- Skanner leiab teadaolevad CVE-d ja väärseadistused usaldusväärselt – loogikavigu struktuurselt mitte
- Märkimisväärne osa teadetest on valehäired, sest haavatavus järeldatakse versiooninumbrist
- CVSS-i baasväärtus kirjeldab haavatavust, mitte sinu riski
- Skaneerimine on jooksev ja odav, testimine perioodiline ja sügav – koos annavad nad programmi
- NIS2 või ISO 27001 mõjususe tõendamiseks skaneeringust üksi üldjuhul ei piisa
Peaaegu iga haavatavuste analüüsi päring algab ühtemoodi: keegi käivitas skaneerimise, laual on nüüd 340 leidu, neist 28 märgitud kriitiliseks, ja pole aimu, kust alustada. Õige reaktsioon on harva kõik 28 ära teha – enamasti on see välja selgitada, millised neist sinu keskkonnas üldse midagi tähendavad.
See artikkel käib läbi, kuidas haavatavuste skaneerimine tehniliselt töötab, mida ta usaldusväärselt leiab, mida ta struktuurselt leida ei suuda, miks nii paljud teated on valehäired, kuidas CVSS-i väärtust lugeda ja kuidas skaneering, analüüs ja penetratsioonitest kokku üheks programmiks kasvavad.
Kuidas haavatavuste skaneerimine töötab
Käik on igas tööriistas – Nessus, OpenVAS, Nuclei ja ülejäänud – sisuliselt sama:
- Tuvastamine. Millised hostid vastavad, millised pordid on lahti, millised teenused nende taga töötavad.
- Sõrmejälje võtmine. Milline tarkvara ja milline versioon iga teenuse taga on. See on samm, millele kõik ülejäänu tugineb – ja samm, mis kõige sagedamini mööda paneb.
- Võrdlemine. Tuvastatud versioon kõrvutatakse avaldatud haavatavuste andmebaasiga, mis on tavaliselt tähistatud CVE-numbriga.
- Hindamine. Iga tabamus saab raskusastme, enamasti CVSS-i baasväärtuse CVE-kirjest.
Otsustav koht: enamiku kontrollide puhul haavatavus järeldatakse, mitte ei tõendata. Skanner näeb „nginx 1.18.0“, leiab sellele CVE-kirje ja teatab sellest. Kas auk on sinu konkreetses seadistuses tegelikult kättesaadav, on kontrollimata.
Mida skanner leiab usaldusväärselt
Sellest piirangust hoolimata on skanner oma valdkonnas suurepärane – ja see valdkond ei ole sugugi väike:
- Aegunud komponendid teadaolevate CVE-dega, sadade süsteemide lõikes tundidega.
- Väärseadistused, millel on selge allkiri: avatud haldusliidesed, vaikimisi paroolid, kataloogiloendid, sisse jäetud silumisotspunktid.
- Nõrk TLS-i seadistus, aegunud sertifikaadid, toetatud vananenud protokolliversioonid.
- Puuduvad turvapäised ja ilmselgelt liiga laiaks jäetud õigused.
- Kõrvalekalded lähtejoonest – mis on eelmisest skaneeringust saadik muutunud.
Oma püsivara kandvate seadmete puhul lõpeb võrguskanneri ulatus siiski seadme pinnal: seda, mis selle all on, kontrollivad IoT- ja sardsüsteemide penetratsioonitestid.
Just see on töö, mida inimene tegema ei peaks: seda on palju, see on ühetaoline ja käsitsi tehtuna vearohke. Seetõttu algab ka meie haavatavuste analüüs automaatsete skaneeringutega – ta lihtsalt ei lõpe sealsamas.
Mida skanner leida ei suuda
Järgmised leiuklassid ei ole automaatse tööriista jaoks lihtsalt rasked, vaid struktuurselt kättesaamatud – sest tööriist ei tea, mis sinu rakenduses lubatud olema peaks:
- Vigane autoriseerimine. Kasutaja A näeb kasutaja B tellimusi. Skanneri jaoks on see edukas HTTP-vastus staatusega 200. Tal ei ole mingit ettekujutust, kellele milline kirje kuuluma peaks.
- Äriloogika vead. Sooduskood, mida saab mitu korda lunastada. Tellimuse samm, millest saab üle hüpata. Negatiivne summa, mis kantakse arvele krediidina.
- Aheldatud leiud. Kahjutu infoleke pluss nõrk parooliprotseduur pluss ununenud testkonto annavad koos täieliku ülevõtmise. Skanner teatab kolmest madala raskusastmega leiust ega näe ahelat.
- Mitmeastmelisest autentimisest möödaminek kõrvalteed pidi, näiteks API kaudu, mis teist tegurit ei nõua.
- Sisulised andmelekked. Liides, mis tagastab rohkem välju, kui kasutajaliides kuvab – tehniliselt korrektne, sisuliselt andmekaitseintsident.
Kõik need klassid on OWASPi metoodikates nähtaval kohal ja ühtki neist ei ole versioonide võrdlemisega võimalik tuvastada.
Valehäired ja miks neid nii palju on
Praktikas kõige sagedasem juhtum: tagasiporditud turvapaigad. Debian, Red Hat ja teised distributsioonid võtavad turvaparanduse oma pakiversiooni üle, ilma et rakenduse teatatud versiooninumber tõuseks. Auk on suletud, skanner teatab sellest sellegipoolest – ta tunneb ainult numbrit.
Sinna lisanduvad:
- Kättesaamatu kood. Haavatav funktsioon on teegis olemas, kuid sinu rakendus ei kutsu seda kunagi välja.
- Kompenseerivad meetmed. Ees olev veebirakenduse tulemüür, võrgu segmenteerimine või autentimine muudab ründetee praktikas kasutuskõlbmatuks.
- Vale sõrmejälg. Pöördproksi või sihilikult muudetud bänner viib täiesti vale seoseni.
Seetõttu on tööetapp, mis muudab tööriista väljavõtte analüüsiks, alati sama: kontrolli iga tõsiseltvõetav leid käsitsi üle, märgi ülejäänu müraks ja põhjenda, miks. Nimekiri ilma selle sammuta hoiab sinu meeskonda nädalaid kinni asjade juures, millel ei ole tähtsust.
Kuidas CVSS-i õigesti lugeda
CVSS-i väärtust loetakse rutiinselt riskina. Ta seda ei ole. Ta kirjeldab haavatavust ennast, standardeelduste juures, sinu keskkonda tundmata.
Baasväärtus 9,8 tähendab: võrgust ärakasutatav, ilma ligipääsuandmeteta, täieliku mõjuga konfidentsiaalsusele, terviklusele ja käideldavusele – kui süsteem on nii kättesaadav, nagu hinnang eeldab. Neli küsimust tõlgivad selle väärtuse sinu tegelikuks prioriteediks:
| Küsimus | Tõstab prioriteeti | Langetab prioriteeti |
|---|---|---|
| Kas süsteem on kättesaadav? | kättesaadav internetist | sisevõrk, VPN, isoleeritud segment |
| Kas avalik ärakasutuskood on olemas? | töötav kood saadaval, seda kasutatakse aktiivselt | kirjeldatud ainult teoreetiliselt |
| Mis sellel süsteemil on? | kliendiandmed, makseandmed, ligipääsuandmed | testandmed ilma isikuandmeteta |
| Mis on selle ees? | otse eksponeeritud | WAF, autentimine, segmenteerimine |
Praktikas on CVSS 6,5 haavatavus kliendiportaalis peaaegu alati kiireloomulisem kui 9,8 suletud testsüsteemil. See ongi haavatavuste prioriseerimine – ja see on osa tööst, mis paneb paika sinu järgmise kolme kuu järjekorra.
Skaneering, haavatavuste analüüs, penetratsioonitest
Kolm mõistet, mis pakkumistes segamini lähevad, kuigi nad vastavad eri küsimustele. Eesti turul kohtab penetratsioonitesti kohta ka nimetust läbistustest – see on sama teenus, mitte neljas tase.
| Haavatavuste skaneerimine | Haavatavuste analüüs | Penetratsioonitest | |
|---|---|---|---|
| Vastab küsimusele | Mis on aegunud? | Mis sellest meie juures loeb? | Mis on ärakasutatav ja kui kaugele sellega jõuab? |
| Kes seda teeb | tööriist | tööriist pluss inimese kontroll | testija, tööriistad on abivahendid |
| Valehäired | jäävad sisse | eemaldatakse ja põhjendatakse | neid ei ole, iga leid on tõendatud |
| Loogikavead | ei | ei | jah |
| Kestus | tunnid, korratav piiramatult | 2–5 päeva | 5–15 inimtööpäeva |
| Takt | kord nädalas kuni kord kuus | kord kvartalis | kord aastas ja pärast suuri muudatusi |
Järjekord on tõusev, mitte alternatiivne. Kes ainult skaneerib, sellel on pikk nimekiri ilma prioriteetideta. Kes testib ainult kord aastas, sellel jäävad märkamata CVE-d, mis avaldati vahepealse üheteistkümne kuu jooksul.
Kuidas seda kokku panna
Programm, mis keskmise suurusega organisatsioonides töötab:
- Skaneeri jooksvalt – väljastpoolt kättesaadavaid süsteeme kord nädalas, sisemisi kord kuus, pluss pärast iga olulist muudatust.
- Kontrolli kord kvartalis üle – inimene käib tõsiseltvõetavad leiud läbi, eemaldab valehäired ja järjestab nimekirja tegeliku prioriteedi järgi. See ongi päris haavatavuste analüüs.
- Testi kord aastas – penetratsioonitest katab need klassid, mida ükski tööriist ei leia, ja annab tõendi, mida audiitor näha tahab.
- Kontrolli pärast parandusi uuesti. Ilma kordustestita on sul dokumenteeritud probleem, mitte dokumenteeritud lahendus.
Reguleeritud variandi jaoks: ISO 27001 nõuab lisa A punktis 8.8 tehniliste haavatavuste haldamist ja punktis A 8.29 lisaks turvateste; NIS2 nõuab artikli 21 lõike 2 punktis f korda, millega hinnatakse meetmete mõjusust. Kuidas seda konkreetselt tõendada, on kirjas ISO 27001 ja NIS2 lehel.
Haavatavuste skaneerimine – korduvad küsimused
01Mis on haavatavuste skaneerimine?
Haavatavuste skaneerimine on sinu süsteemide automaatne võrdlemine teadaolevate turvaaukude andmebaasiga. Tööriist tuvastab töötavad teenused ja nende versioonid, kõrvutab need avaldatud CVE-kirjetega ning teatab tabamustest koos raskusastmega. See võtab tunde, mitte päevi, seda saab korrata nii tihti kui vaja ja see on jooksva haavatavuste halduse alus – penetratsioonitesti see aga ei asenda.
02Mis vahe on haavatavuste skaneerimisel ja penetratsioonitestil?
Skaneering vastab küsimusele, mis on aegunud või valesti seadistatud. Penetratsioonitest vastab küsimusele, mis sellest on tegelikult ärakasutatav ja kui kaugele ründaja sellega jõuab. Skaneering on tööriista väljavõte, test on valdavalt käsitsi tehtav töö, mille käigus leiud kontrollitakse üle, aheldatakse omavahel ja täiendatakse loogikavigadega, mida ükski skanner kirjeldada ei oska.
03Kui tihti tuleks haavatavusi skaneerida?
Internetist kättesaadavate süsteemide puhul on mõistlik takt kord nädalas, sisevõrkude puhul kord kuus ja lisaks alati pärast olulist muudatust. Põhjus ei ole selles, et sinu süsteemid nii kiiresti muutuksid, vaid selles, et iga päev avaldatakse uusi CVE-sid: süsteem, mis eile oli puhas, võib täna sisaldada kriitilist auku, ilma et keegi oleks seal midagi muutnud.
04Kas CVSS 9,8 tähendab automaatselt kriitilist riski?
Ei. CVSS-i baasväärtus kirjeldab haavatavust ennast, mitte sinu keskkonda. Sama 9,8 hindega auk võib internetist kättesaadaval serveril olla tõesti kriitiline ja isoleeritud testsüsteemil ilma andmeteta praktiliselt tähtsusetu. Tegeliku prioriteedi otsustavad kättesaadavus, olemasolevad kompenseerivad meetmed, andmete tundlikkus ja küsimus, kas avalik ärakasutuskood on olemas.
05Miks teatab skanner asjadest, mida tegelikult ei ole?
Sest enamik kontrolle järeldab haavatavuse teatatud versiooninumbrist, selle asemel et seda tõendada. Paljude Linuxi distributsioonide tagasiporditud turvapaigad ei tõsta versiooninumbrit, auk on aga suletud – skanner teatab sellest sellegipoolest. Just see ülekontrollimine ongi haavatavuste analüüsi see osa, mille peab üle võtma inimene.
06Kas haavatavuste skaneerimisest piisab NIS2 või ISO 27001 jaoks?
Jooksva haavatavuste halduse jaoks on see oluline alustala, meetmete mõjususe tõendamiseks sellest aga üldjuhul ei piisa. ISO 27001 lisa A punkt 8.8 nõuab tehniliste haavatavuste haldamist, punkt A 8.29 lisaks turvateste, ja NIS2 nõuab artikli 21 lõike 2 punktis f korda, millega hinnatakse meetmete mõjusust. Tavapärane kombinatsioon on jooksev skaneerimine pluss perioodiline penetratsioonitest koos aruande ja kordustestiga.
