Ievainojamību skenēšana vai ielaušanās tests: kur beidzas skenera iespējas

Uz galda divi piedāvājumi. Vienā rakstīts „ievainojamību skenēšana“, otrā – „ielaušanās tests“. Pirmās trīs apraksta rindas gandrīz sakrīt, cenas atšķiras vairākas reizes, un jautājums rodas pats no sevis: ja rīks tāpat visu atrod, kāpēc pie tā vajag vēl cilvēku?

Skeneris nav slikts rīks. Savu darbu tas izdara nevainojami – tikai atbild uz citu jautājumu, nevis uz to, ko pēc incidenta uzdos valde. Turpmāk izejam cauri tam, kur beidzas rīka iespējas: ko tas atrod droši, ko neatradīs nekad, no kurienes rodas kļūdaini pozitīvi konstatējumi, kā lasīt CVSS vērtību un kā skenēšana, novērtēšana un tests saliekas vienā programmā.

Viena piezīme par virsrakstu. Tur apzināti stāv „vai“, nevis „jeb“: šie nav divi nosaukumi vienai lietai, bet divi dažādi darbi ar dažādu rezultātu. Latvijā klāt nāk vēl viens vārdu pāris, kuru sajaukt maksā dārgāk, un pie tā tiksim uzreiz pēc terminiem.

Kas ir ievainojamību skenēšana un kas – ielaušanās tests?

Īsā atbilde ietilpst vienā teikumā. Skenēšana meklē, kur ir kļūda; ielaušanās tests – ko no atrastā var izmantot un cik tālu ar to tiek uzbrucējs. Skenēšana strādā plašumā, tests – dziļumā.

Garākajā atbildē ir vērts atšķirt četrus darbus, jo Latvijas piedāvājumos tie stāv blakus ar mulsinoši līdzīgiem nosaukumiem.

Šie četri darbi papildina cits citu, nevis aizstāj. Audits skatās uz procesiem un dokumentiem, skenēšana – uz versijām, tests – uz sekām. Kam ir tikai audits, tam kārtībā ir papīrs, bet sistēmām neviens nav pieskāries. Kam ir tikai skenēšana, tam ir garš saraksts bez secības. Kas testē reizi gadā un pa vidu nedara neko, tas nepamana ievainojamības, kas publicētas atlikušajos vienpadsmit mēnešos.

Atšķirībai ir arī komerciāla puse. Dažos cenrāžos ar vārdu „audits“ praksē tiek pārdota skenēšana ar pakalpojuma sniedzēja logo uz vāka. Trīs jautājumi parāda, kas tiek pirkts patiesībā: cik liela daļa darba ir manuāla, vai kāds pārbauda rīka konstatējumus un vai cenā ietilpst atkārtota pārbaude pēc labojumiem. Ja piedāvājums neatbild ne uz vienu no tiem, tas apraksta skenēšanu. Ko ietver pilns IT drošības audits, aprakstīts atsevišķā lapā.

Kāpēc „drošības skenēšana“ Latvijā nozīmē ko citu

Latviski šķiet dabiski teikt „drošības skenēšana“, un tieši tāpēc šis ir vienīgais termins rakstā, ko ir vērts iegaumēt. Latvijas normatīvajos aktos tas ir aizņemts vārds.

Ministru kabineta 2025. gada 25. jūnija noteikumu Nr. 397 „Minimālās kiberdrošības prasības“ (turpmāk – MK noteikumi Nr. 397) 8.2. apakšnodaļa saucas „Ielaušanās testi un drošības skenēšana“. Noteikumu 135. punkts nosaka, ka subjekta IKT infrastruktūras drošības skenēšanu veic pēc Nacionālā kiberdrošības centra pieprasījuma, pēc Satversmes aizsardzības biroja pieprasījuma vai pēc paša subjekta pieprasījuma. 139. punkts uzskaita apsvērumus, pēc kuriem šīs iestādes vērtē, vai skenēšana vispār ir vajadzīga: subjekta veidu un darbības jomu, IKT infrastruktūras kritiskumu, pēdējo triju gadu kiberincidentus un uzraudzības procesā iegūto informāciju.

Citiem vārdiem: normatīvajā tekstā „drošības skenēšana“ ir uzraudzības instruments ar noteiktu veicēju loku, nevis rinda cenrādī. 140. punkts prasa, lai svarīgo vai būtisko pakalpojumu sniedzēja infrastruktūrā to veiktu Nacionālā kiberdrošības centra vai kompetentās kiberincidentu novēršanas institūcijas darbinieks vai persona, kas atbilst noteikumu 94. punkta prasībām. 138. punkts pievieno vēl stingrākas prasības, taču tikai IKT kritiskās infrastruktūras īpašnieka vai tiesiskā valdītāja infrastruktūrā un tikai tad, ja skenēšanu neveic pats Satversmes aizsardzības birojs: par skenēšanu rakstiski brīdina ne vēlāk kā 48 stundas iepriekš un detalizētus rezultātus nosūta arī Satversmes aizsardzības birojam.

Komerciālajam darbam Latvijas tirgū ir savs vārds, un tas ir ievainojamību skenēšana. Tā šo darbību sauc pakalpojumu sniedzēji, un tāds pats nosaukums parādās arī CERT.LV publiskajos ieteikumos. Praktiskā atšķirība ir vienkārša: ja iepirkuma dokumentā vai iekšējā politikā parādās „drošības skenēšana“, ir vērts noskaidrot, vai runa ir par to, ko organizācija pasūta pati, vai par to, ko var pieprasīt uzraudzības iestāde. Divi dažādi procesi ar diviem dažādiem veicēju lokiem, un iepirkuma tehniskajā specifikācijā tie mēdz nonākt viens otra vietā.

Kā skeneris strādā

Gaita katrā rīkā – Nessus, OpenVAS, Nuclei un pārējos – pēc būtības ir vienāda:

1. Apzināšana. Kuras adreses atbild, kuri porti ir atvērti, kāds pakalpojums aiz tiem stāv.
2. Pakalpojuma identificēšana. Kāda programmatūra un kurā versijā darbojas aiz katra porta. Uz šī soļa balstās viss pārējais, un tieši tas kļūdās pirmais.
3. Salīdzināšana. Atpazīto versiju rīks salīdzina ar publicēto ievainojamību datubāzi, kurā ierakstiem ir CVE identifikators.
4. Novērtēšana. Katrs konstatējums saņem bīstamības līmeni, parasti CVE ierakstā norādīto CVSS bāzes vērtību.

Viss balstās uz trešo soli. Lielākajā daļā konstatējumu ievainojamība ir secināta no versijas numura, nevis pierādīta. Rīks ierauga baneri „nginx 1.18.0“, atrod tam atbilstošu CVE ierakstu un ziņo. Vai konkrētajā konfigurācijā ievainojamais koda ceļš vispār ir sasniedzams, paliek nepārbaudīts.

Ko skeneris atrod droši

Neraugoties uz šo ierobežojumu, savā laukā rīks ir nepārspējams, un lauks nemaz nav šaurs:

• Nepārtrauktība. Jauni CVE ieraksti parādās katru dienu. Sistēmai, kas piektdien bija tīra, pirmdien var būt kritiska ievainojamība, lai gan tai neviens nav pieskāries. To pamana tikai regulāra skenēšana.
• Pārklājums. Simtiem adrešu dažu stundu laikā. Manuāli tam neviens neiziet cauri, un mēģinājums beidzas ar izlaistām sistēmām.
• Atkārtojamība. Palaišana ir lēta, tāpēc to var darīt reizi nedēļā, nevis reizi gadā.
• Ievainojamību pārvaldība. Salīdzinājumā ar iepriekšējo palaišanu redzama starpība: kas pienācis klāt, kas pazudis, kas jau ceturksni karājas nenovērsts.
• Kopīga valoda. Pēc CVE identifikatora un CVSS vērtības ar programmatūras piegādātāju, savu komandu un auditoru var runāt par vienu un to pašu.

Droši parādās novecojušas komponentes ar zināmu CVE ierakstu, skaidri atpazīstamas konfigurācijas kļūdas – vaļā atstāta administratora saskarne, noklusējuma parole, direktoriju satura rādīšana, ieslēgts atkļūdošanas režīms –, vāji TLS iestatījumi un beigušies sertifikāti, trūkstošas drošības galvenes, kā arī izmaiņas kopš iepriekšējās palaišanas.

Šis nav darbs cilvēkam: tā ir daudz, tas ir viendabīgs, un manuāli tajā var kļūdīties. Tāpēc arī mūsu ievainojamību novērtēšana sākas ar automatizētu skenēšanu. Tikai tur tā nebeidzas.

Ko skeneris neatradīs nekad

Turpmākās kļūdu klases automatizētam rīkam nav grūtas – tās tam ir strukturāli nesasniedzamas, jo rīks nezina, kas konkrētajā lietotnē ir atļauts:

• Nepareiza piekļuves tiesību pārvaldība. Lietotājs A redz lietotāja B pasūtījumus. Skenerim tā ir korekta atbilde ar statusu 200. Kam ieraksts pieder, rīks nezina.
• Biznesa loģikas kļūdas. Atlaides kods, ko var izmantot vairākkārt. Pasūtījuma solis, kuram var pārlēkt pāri. Negatīva summa, ko sistēma ieskaita klienta kontā.
• Konstatējumu ķēdes. Nekaitīga informācijas noplūde, vāja paroles atjaunošanas procedūra un aizmirsts testa konts kopā dod administratora konta pārņemšanu. Skeneris ziņo par trim sīkumiem ar zemu prioritāti trijās dažādās ziņojuma vietās un saikni starp tiem neredz.
• Daudzfaktoru autentifikācijas apiešana. Piemēram, caur API, kas otro faktoru neprasa.
• Pārāk runīgas atbildes. Galapunkts atdod vairāk lauku, nekā saskarne parāda. Tehniski viss strādā pareizi, praksē noplūst personas dati.

Šīs kļūdu klases apraksta OWASP metodoloģija, un nevienu no tām neatklāj versiju salīdzināšana. Tās nonāk ziņojumā tikai tad, ja kāds izdomā, kas lietotnē ir atļauts un kas nav.

No kurienes rodas kļūdaini pozitīvi konstatējumi

Praksē biežākais gadījums ir atpakaļportēts drošības labojums. Debian, Red Hat un pārējie izplatījumi iestrādā ielāpu savā pakotnes versijā, nemainot pakalpojuma uzrādīto versijas numuru. Caurums ir aizvērts, skeneris par to tik un tā ziņo, jo pazīst tikai numuru.

Klāt nāk vēl trīs:

• Nesasniedzams kods. Ievainojamā funkcija bibliotēkā ir, tikai lietotne to nekad neizsauc.
• Kompensējoši pasākumi. Priekšā stāvošs lietotņu līmeņa ugunsmūris, tīkla segmentācija vai autentifikācija padara uzbrukuma ceļu praksē neizmantojamu.
• Nepareiza identifikācija. Priekšā novietots starpniekserveris vai apzināti pārrakstīts baneris noved rīku pie pavisam citas programmatūras.

Tāpēc posms, kas no rīka izdrukas veido ievainojamību novērtējumu, vienmēr izskatās vienādi: katru nopietno konstatējumu pārbaudām manuāli, pārējo atzīmējam kā troksni un pierakstām, kāpēc. Bez šī soļa saraksts uz nedēļām aizņem komandu ar lietām, kurām nav nozīmes, un pa ceļam iemāca, ka drošības ziņojumus var mierīgi atlikt malā. Tas maksā visdārgāk.

Kā lasīt CVSS vērtību

CVSS vērtību pēc ieraduma lasa kā riska līmeni. Tā tas nav. Tā apraksta pašu ievainojamību ar standarta pieņēmumiem, nezinot vidi, kurā ievainojamība atrodas.

Bāzes vērtība 9,8 nozīmē: kļūda ir izmantojama pa tīklu, bez autentifikācijas, ar pilnu ietekmi uz konfidencialitāti, integritāti un pieejamību – ar nosacījumu, ka sistēma ir tik sasniedzama, cik novērtējums pieņem. Četri jautājumi šo skaitli pārvērš par reālu prioritāšu secību jūsu vidē:

Praksē 6,5 vērtības kļūda klientu portālā gandrīz vienmēr ir steidzamāka nekā 9,8 slēgtā testa sistēmā. Tieši šīs secības noteikšana arī ir riska novērtējums, un tā sakārto nākamā ceturkšņa labošanas darbus.

Atvērts ports un reāla iekļūšana

Skenēšana beidzas ar fakta konstatējumu: ports ir atvērts, pakalpojuma versija ir novecojusi, vērtība 8,1, blakus CVE identifikators. Ielaušanās tests sākas tieši šeit un jautā, kas ir aiz porta.

Šāda ķēde praksē izskatās tā: aizmirsta administratora saskarne internetā, tajā konts ar paroli no ieviešanas dokumentācijas, saskarnē nolasāmajā konfigurācijā – servisa konta piekļuves dati, ar to kontu sasniedzama tīkla koplietošanas mape ar rezerves kopijām, bet rezerves kopijās – privileģēto kontu paroļu jaucējvērtības. Četri sīkumi cits aiz cita, galā – domēna pārņemšana.

Skeneris šeit ziņotu par trim vidējas prioritātes konstatējumiem trijās dažādās ziņojuma nodaļās, un neviens no tiem neizklausītos steidzams. Testētājs uzraksta vienu konstatējumu: domēnu var pārņemt – ar soļiem, pierādījumiem un norādi, kuru ķēdes posmu ir lētāk pārcirst. Atšķirība ietilpst vienā teikumā: skenēšana pierāda, ka ports ir atvērts, tests – cik tālu pa to tiek uzbrucējs.

No turienes nāk arī cenu starpība: skenēšana atbild uz vienkāršāku jautājumu, un to dara mašīna. Kas kustina paša testa cenu, apkopots rakstā Cik maksā ielaušanās tests, bet jēdzienus un darba gaitu izskaidro raksts Kas ir ielaušanās testēšana.

Kuru pasūtīt un kad

Ko no tā prasa Latvijas regulējums

Latvijā pienākums nāk no divām vietām, un tās prasa dažādas lietas.

Ikgadējā IKT drošības pārbaude. NKDL 25. panta piektās daļas 2. punkts nosaka, ka kiberdrošības pārvaldniekam ne retāk kā reizi gadā ir jāveic informācijas un komunikācijas tehnoloģiju drošības pārbaude un atbilstoši tās rezultātiem jāorganizē konstatēto trūkumu novēršana. Likums nepasaka, ka tam jābūt tieši ielaušanās testam; tas prasa pārbaudi un – kas praksē izrādās grūtākā daļa – novēršanu. Ar skenera izdruku bez novēršanas plāna šis pienākums nav izpildīts.

Ielaušanās testi konkrētās situācijās. MK noteikumu Nr. 397 131. punkts nosaka, kad ielaušanās testus veic: A klases informācijas sistēmai – pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados; jebkurai informācijas sistēmai – pēc paša subjekta iniciatīvas vai pēc Nacionālā kiberdrošības centra vai Satversmes aizsardzības biroja pieprasījuma. Ikgadējs ielaušanās tests visiem subjektiem no noteikumiem tātad neizriet; kas no tiem izriet, sīkāk izsvērts rakstā Vai ielaušanās testēšana ir obligāta.

Kas testu drīkst veikt. MK noteikumu Nr. 397 132.2. apakšpunkts izvirza prasības testa veicējam: starptautiski atzīts sertifikāts, kas apliecina kvalifikāciju ielaušanās testu jomā (kā piemēri noteikumos nosaukti CEH un OSCP), vai vismaz divu gadu darba pieredze ielaušanās testu veikšanā, kas iegūta pēdējo piecu gadu laikā. Klāt nāk neatkarības prasība: pēdējo triju gadu laikā veicējs nav bijis iesaistīts testējamās informācijas sistēmas izstrādē vai uzturēšanā. Šos divus punktus ir vērts pārbaudīt par jebkuru pakalpojuma sniedzēju, arī par mums, un pieprasīt tos rakstiski jau piedāvājuma stadijā.

Novēršanas termiņš. Ja kompetentā kiberincidentu novēršanas institūcija paziņo par atklātu ievainojamību, NKDL 40. panta pirmā daļa dod subjektam institūcijas noteikto termiņu, bet ne ilgāku par 90 dienām; pēc pieprasījuma to var pagarināt, bet ne vairāk kā līdz 180 dienām no ievainojamības atklāšanas ziņojuma iesniegšanas brīža. Termiņš sākas ar paziņojumu, nevis ar brīdi, kad saraksta rinda nonāk uzdevumu sistēmā.

Ko dara valsts. NKDL 10. panta 10. punkts uzliek kiberincidentu novēršanas institūcijai pienākumu pēc subjekta pieprasījuma veikt tā tīklu un informācijas sistēmu proaktīvu skenēšanu, lai atklātu ievainojamības ar iespējami būtisku ietekmi, bet 11. panta 6. punkts dod tiesības publiski pieejamos tīklus skenēt arī bez pieprasījuma. Privāto tiesību juridiskajām personām šos uzdevumus veic Latvijas Universitātes Matemātikas un informātikas institūts, kura vienība darbojas ar nosaukumu CERT.LV. Tas ir bezmaksas resurss. Manuāli pārbaudītu novērtējumu ar novēršanas secību tas neaizstāj, taču sākt no tā ir lētāk nekā nesākt vispār.

Un vēl viena robeža, ko labāk pateikt uzreiz. HAXORIS ir Slovākijas uzņēmums, un mūsu darbs ir tehniska drošības testēšana un gatavības novērtēšana. NKDL 44. pantā noteikto auditu neveicam, un neveicam arī MK noteikumu Nr. 397 135.–140. punktā noteikto drošības skenēšanu.

Kā to salikt vienā programmā

Vidēja izmēra organizācijā kopā strādā četri elementi:

1. Skenējiet regulāri. No interneta sasniedzamās sistēmas reizi nedēļā, iekšējo tīklu reizi mēnesī un papildus pēc katras būtiskas izmaiņas.
2. Pārbaudiet reizi ceturksnī. Kāds izstaigā nopietnos konstatējumus, izsijā kļūdaini pozitīvos un sakārto sarakstu pēc reāla riska. Tā ir ievainojamību novērtēšana, nevis rīka izdruka.
3. Testējiet reizi gadā un pēc lielām izmaiņām. Ielaušanās testēšana sedz tās kļūdu klases, ko neatrod neviens rīks, un rada to pierādījumu, kuru meklē auditors.
4. Pārbaudiet labojumus. Bez atkārtotas pārbaudes rokās ir dokumentēta problēma, nevis dokumentēts risinājums.

Skenēšana un tests nekonkurē par vienu budžeta rindu, jo pieskata dažādas lietas. Skenēšana raugās, lai starp diviem testiem klusi nesabojātos nekas. Tests raugās, lai rīka saraksts nebūtu viss, ko organizācija zina par savām sistēmām. Kas pasūta tikai vienu no tiem, samaksā par pusi atbildes.

Ievainojamību skenēšana un ielaušanās testi – biežāk uzdotie jautājumi

Saistītie Haxoris pakalpojumi: sistēmu un lietotņu ievainojamību novērtēšana · tīmekļa lietotņu un IT infrastruktūras ielaušanās testēšana