Kad uzbrucēji ir ātrāki par aizsargiem: ievainojamību izmantošanas laika problēma

Viena no izplatītākajām kļūdām ir uzskatīt CVE publikācijas dienu par brīdi, kad ievainojamība kļuva bīstama. CVE ieraksts palīdz identificēt publiski aprakstītu problēmu, tomēr pats ieraksta datums nepasaka, kad trūkums radās programmatūrā, kad kāds to neatkarīgi atklāja, vai kad sākās ļaunprātīga izmantošana. Atsevišķos gadījumos uzbrukumi notiek vēl pirms labojuma publiskas pieejamības. Google Threat Intelligence Group (GTIG) savā 2025. gada pārskatā par zero-day ekspluatāciju šādiem gadījumiem lieto skaidru robežu: ļaunprātīga izmantošana pirms publiski pieejama labojuma S03. Tas nenozīmē, ka katra zināmā vai vēl nepublicētā ievainojamība jau tiek izmantota.

GTIG 2026. gada martā publicētajā pārskatā norāda, ka 2025. gadā izsekojusi 90 savvaļā izmantotas zero-day ievainojamības; 43 no tām skāra uzņēmumiem paredzētas tehnoloģijas S03. Šie ir pētnieku identificētie gadījumi noteiktā izpētes tvērumā, nevis visu 2025. gada ievainojamību vai visu pasaules uzbrukumu skaits. To nevajadzētu pārvērst apgalvojumā, ka jebkurai uzņēmuma ievainojamībai ir augsta izmantošanas iespējamība. Toties dati atspēko vienkāršoto pieņēmumu, ka aizsardzības darbs vienmēr sākas tikai pēc publiska paziņojuma un uzbrucējam nepieciešams laiks, lai tam pielāgotos.

Publiskuma un izmantošanas laika atšķirībai ir vēl kādas sekas. Datums, kad drošības uzņēmums pirmoreiz pamanīja uzbrukumu, nav obligāti pirmā faktiskā uzbrukuma datums. Arī informācija par ekspluatāciju var tikt publiskota ar aizkavi, jo turpinās izmeklēšana, incidenta novēršana vai atbildīga ievainojamības izpaušana. Ja šos datumus sapludina vienā laukā, vēsturiskie aprēķini rada mānīgu precizitāti.

Lai par ievainojamības dzīvesciklu varētu runāt precīzi, jānošķir novērotie notikumi un novērtējumi. Piegādātāja brīdinājuma publicēšana, izlabotas versijas izdošana un uzņēmuma instalācijas žurnāls parasti ir identificējami notikumi. Savukārt uzbrukuma sākumu bieži iespējams noteikt tikai aptuveni, balstoties uz telemetriju vai forensikas rezultātiem. Arī uzstādīts ielāps vēl nepierāda, ka visas ievainojamās instances ir aizsargātas.

Šajā tabulā pēdējais posms ir svarīgākais lēmuma kvalitātei. Ja labojums ieviests serverī, bet publiskais piekļuves punkts novirza daļu pieprasījumu uz neizlabotu instanci, tehniski noslēgtais uzdevums neatbilst faktiskajam stāvoklim. Ja trūkums bija sasniedzams tikai ar ieslēgtu papildmoduli, kuru organizācija jau bija atspējojusi un pārbaudījusi, risks var būt būtiski mazināts pat pirms ražotāja ielāpa uzstādīšanas. Abos gadījumos mērījuma jēga ir pierādīt aizsardzību, nevis tikai datēt darbību.

Par ielāpa aizkavi mēdz runāt tā, it kā ražotājs publicētu atjauninājumu un gala lietotājs vienkārši kavētos to instalēt. Project Zero 2025. gada politikas analīze norāda uz agrāku problēmu — upstream patch gap. Komponentes ražotājs var būt sagatavojis labojumu, bet produkta integrators vēl nav to iekļāvis savā izlaidumā. Piemēram, mikroshēmas draivera vai bibliotēkas labojumam vēl jānonāk ierīces vai lietojumprogrammas gala versijā. Tas ir atsevišķs piegādes ķēdes posms, kuru pats uzņēmuma administrators ne vienmēr var paātrināt S01.

Šī atšķirība ir būtiska iepirkumos, ārpakalpojumos un produkta drošības pārvaldībā. Var būt situācija, kurā komponentes ražotājs jau paziņojis par novērstu ievainojamību, bet produkta piegādātājam vēl nav pieejama instalējama, savietojama versija. Formāli uzņēmums nevar izpildīt ielāpa uzstādīšanas uzdevumu, kas nav tehniski iespējams. Tomēr tam joprojām jāvērtē alternatīvas: ievainojamās funkcijas atslēgšana, piekļuves ierobežošana, segmentācija, uzraudzības pastiprināšana vai pakalpojuma pagaidu apturēšana.

Arī pēc labojuma nonākšanas pie gala lietotāja šķēršļi nepazūd. Kritiskai sistēmai var būt augstas pieejamības prasības, novecojušas integrācijas un sarežģīta atjaunošanas procedūra. NIST SP 800-40 Rev. 4 aicina ielāpu pārvaldību uzskatīt par plānotu uzņēmuma preventīvās uzturēšanas funkciju, nevis periodisku IT administrēšanas formalitāti S02. Secinājums nav tāds, ka savietojamības testi jāatceļ; tie jāorganizē tā, lai ārkārtas labojumiem jau iepriekš būtu sagatavots lēmumu, testēšanas un atcelšanas ceļš.

Izplatīts rādītājs ir MTTR — vidējais laiks līdz novēršanai. Taču bez precīzas sākuma un beigu notikuma definīcijas šāds skaitlis ir grūti salīdzināms. Viena organizācija skaita no skenera atraduma līdz uzdevuma aizvēršanai, cita — no piegādātāja paziņojuma līdz atjauninājuma instalēšanai. Vēl cita mēra tikai ierīces, kuras ir pastāvīgi sasniedzamas pārvaldības sistēmai. Šādus rezultātus nevar godīgi salīdzināt kā vienu un to pašu drošības rādītāju.

Vidējais lielums var arī noslēpt riska koncentrāciju. Ja uzņēmums ātri izlabo simtiem maznozīmīgu darba staciju, bet publiski pieejama kritiska sistēma ilgstoši paliek ievainojama, vidējais novēršanas laiks izskatīsies labāks, nekā to attaisno faktiskā ekspozīcija. Es prasītu atsevišķi parādīt mediānu, garākās aizkaves, izmantošanai pakļauto aktīvu nozīmīgumu un gadījumus, kuros sākuma datums nav zināms. Bez šīm detaļām rādītājs vairāk raksturo uzdevumu apstrādes ātrumu nekā aizsardzības līmeni.

Piedāvāju izmantot četrus atšķirīgus rādītājus. Tie nav starptautiska standarta noteikts universāls komplekts, bet praktiska analītiska konstrukcija, kuru iespējams atkārtot un auditēt.

Pēdējā rādītāja aprēķins ne vienmēr būs iespējams. Ja nav zināms, kad ievainojamā funkcija pirmoreiz kļuva sasniedzama, nedrīkst automātiski izvēlēties CVE publikācijas datumu un iegūto rezultātu pasniegt kā pilnu ekspozīcijas ilgumu. Korektāk ir norādīt zināmo sākuma robežu un marķēt intervālu kā daļēji novērotu. Arī negatīvs ārējais tests ne vienmēr pilnībā pierāda, ka ekspluatācija nav iespējama citā konfigurācijā vai ar citu priekšnosacījumu kopumu.

CISA Known Exploited Vulnerabilities (KEV) katalogs palīdz atšķirt ievainojamības, kuru izmantošana ir apstiprināta saskaņā ar kataloga iekļaušanas kritērijiem, no tām, kurām ir tikai potenciāla izmantošanas iespēja S04. Tomēr KEV ieraksta pievienošanas datums nav automātiski pirmās ļaunprātīgās izmantošanas datums. Tāpat kataloga neesamība nepierāda, ka konkrēts trūkums netiek izmantots. Tas ir ļoti būtiski, analizējot laikus un veidojot organizācijas reakcijas sliekšņus.

Ja ievainojamība jau tiek izmantota un attiecas uz konkrētu publiski sasniedzamu, nozīmīgu sistēmu, normāls plānotās uzturēšanas ritms bieži vairs nav pietiekams. Drošības komandai jāspēj eskalēt lēmumu, noteikt pagaidu mazināšanas pasākumus un pārbaudīt, vai tie ietekmē attiecīgo uzbrukuma ceļu. Savukārt publiski zināms ekspluatācijas fakts nedod pamatu pieņemt, ka ievainojama ir ikviena organizācija, kuras inventārā atrodams tas pats produkta nosaukums. Joprojām jāpārbauda versija, sasniedzamība, priekšnosacījumi un iespējamā ietekme.

FIRST EPSS piedāvā citu informācijas veidu: modeli, kas katrai publicētai CVE katru dienu novērtē izmantošanas iespējamību tuvākajās 30 dienās S05. Prognoze nav novērotas ekspluatācijas pierādījums, un tā nav arī organizācijas konkrētās sistēmas kompromitēšanas varbūtība. EPSS izmantošana šajā rakstā ir ierobežota ar laika kontekstu: kā var mainīties gaidāmās ekspluatācijas signāls, kamēr organizācija vēl nav ieviesusi aizsardzību. Vispārīga ievainojamību prioritizācijas metodika ir atsevišķs jautājums; šeit galvenais ir, ko organizācija dara ar pagājušo laiku.

Pētot vēsturiskus lēmumus, jāizmanto tā laika dati. FIRST publiskais datu arhīvs īpaši brīdina, ka modeļa versijas maiņa var radīt vērtējumu līmeņa nobīdi S06. Piemēram, EPSS v5 sāka publicēt vērtējumus 2026. gada 15. jūnijā. Nav korekti paņemt šodienas vērtējumu un ar to izskaidrot, kāpēc lēmums pirms vairākiem mēnešiem bija pareizs vai nepareizs. Tas būtu skatījums atpakaļ ar informāciju, kas toreiz nebija pieejama.

MI izmantošana draudu izlūkošanā, koda analīzē un drošības darbplūsmās var paātrināt atsevišķus uzdevumus. Tāpat automatizācija var palīdzēt potenciālajiem uzbrucējiem meklēt ievainojamu kodu, analizēt publiskus labojumus vai pielāgot zināmus uzbrukuma paņēmienus. Tomēr no šīm tehniskajām iespējām vien neizriet, ka 2026. gadā visi uzbrucēji kļuvuši noteiktu reižu ātrāki vai ka visa ekspluatācija sākas dažu stundu laikā. Šādam apgalvojumam vajadzīgs precīzs empīrisks mērījums, populācijas definīcija un salīdzināms vēsturiskais periods.

Automatizācija aizsardzībā arī nav beznosacījumu ieguvums. Ja sistēma kļūdaini identificē skarto produktu, atjaunina nesavietojamu komponenti vai aizver kritisku pakalpojumu bez droša atjaunošanas ceļa, tā var nodarīt reālu kaitējumu. Saprātīgs mērķis ir automatizēt pierādījumu iegūšanu, aktīvu sasaisti, standarta testus un atkārtotas pārbaudes, vienlaikus saglabājot cilvēka apstiprinājumu tur, kur izmaiņas var nopietni ietekmēt pieejamību vai datu integritāti. Autonomijas līmenis jānosaka pēc darbības riska, nevis pēc tehnoloģijas pieejamības.

Tieši tādēļ es organizācijai neprasītu vispirms ieviest kārtējo MI drošības aģentu. Es prasītu pierādīt, ka tā jau šodien prot sasaistīt konkrētu ievainojamību ar konkrētu aktīvu, noteikt lēmuma īpašnieku un savākt pierādījumu, ka uzbrukuma ceļš ir aizvērts. Ja šo informāciju sistēmas savā starpā nepārnes, MI tikai ātrāk apstrādās nepilnīgu procesu.

Pieņemsim ilustratīvu situāciju: ārēji pieejamai tīkla iekārtai ražotājs ir izdevis drošības labojumu, bet uzņēmuma izmaiņu logs ieplānots pēc piecām dienām. Draudu izlūkošanas avots ziņo par šādas ievainojamības izmantošanu. Tas nav konkrēta incidenta apraksts un šeit nav pieņēmuma, ka uzņēmuma ierīce jau būtu kompromitēta. Šajā situācijā ātruma uzdevumu es sadalītu pa darbībām, kuras var pārbaudīt, nevis vienkārši pārceltu termiņu uz šodienu.

Vispirms — faktiskā piemērojamība. Jāapstiprina ierīces modelis, programmatūras versija, ievainojamā komponenta izmantošana un piekļuves ceļš. Skenera paziņojums bez šīs sasaistes ir sākotnējs signāls, ne pilns secinājums. Turklāt jānovērtē, vai pastāv pierādījumi par iespējamu iepriekšēju kompromitēšanu: ielāps novērš ievainojamību, bet pats par sevi neizdzēš uzbrucēja jau iegūtu piekļuvi.

Tad — drošākā tūlītējā rīcība. Ja pilns atjauninājums prasa testus, var būt lietderīgi pagaidām ierobežot pārvaldības interfeisa sasniedzamību, atslēgt ievainojamu funkciju vai izolēt pakalpojumu. Tas nav universāls ieteikums jebkuram produktam: droša pagaidu pasākuma izvēle jābalsta ražotāja norādēs un konkrētajā arhitektūrā. Pasākumam jābūt reģistrētam ar izpildes laiku, atbildīgo, konfigurācijas pierādījumu un paredzēto darbības laiku.

Visbeidzot — pierādāma noslēgšana. Pēc atjauninājuma jāapstiprina gan faktiski darbojošā versija, gan tas, ka attiecīgais uzbrukuma ceļš vairs nav izmantojams. Ja atklāti kompromitēšanas indikatori, jāveic incidenta izmeklēšana, nevis jāpieturas tikai pie ielāpu pārvaldības procedūras. Rezultātam jābūt saprotamam sistēmas īpašniekam, drošības komandai un auditoram arī pēc vairākiem mēnešiem.

Praktiski šāda procesa minimums ir vienots ieraksts ar CVE, asset_id, skartās versijas pierādījumu, pirmās konstatēšanas laiku, ekspluatācijas avota publikācijas laiku, izvēlēto pasākumu, lēmuma un ieviešanas laiku, verifikācijas rezultātu un pierādījumu identifikatoriem. Ierakstā būtu jānorāda arī nenoteiktība: vai pirmā ekspozīcija zināma, vai tikai aptuvena; vai pasākums ir pagaidu, vai pastāvīgs; vai iespējamu kompromitēšanu izdevies izslēgt. Šāda lauka struktūra nav kāda regulatora noteikts standarts, bet reproducējama pārvaldības pieeja.

Ja mērķis ir noskaidrot, vai uzbrucēju izmantošanas cikls patiešām saīsinās, nepietiek salīdzināt dažus plaši izskanējušus gadījumus. Jādefinē ievainojamību kohorta, novērošanas periods un katra datuma nozīme. Vismaz būtu jāsaglabā sākotnējais ražotāja paziņojuma datums, pirmās publiski dokumentētās ekspluatācijas datums, labojuma izdošanas datums, informācijas iegūšanas datums un izmantoto avotu versijas. Ja ekspluatācija sākusies agrāk, nekā to spēj atklāt publiskie avoti, atšķirība jāapraksta kā novērošanas ierobežojums.

Vēsturiskā pētījumā īpaši jāuzmanās no atlases nobīdes. Skaļākie incidenti rada vairāk publisku pierādījumu, savukārt neveiksmīgi vai neatklāti uzbrukuma mēģinājumi dažkārt vispār nenonāk statistikā. Zero-day kohortu nedrīkst bez atrunām salīdzināt ar visām publicētajām CVE, jo tās atlasītas pēc atšķirīga kritērija. Arī produkta kategorijām ir nozīme: interneta perimetra iekārtu izmantošanas dinamika nav automātiski pārnesama uz darbvirsmas lietotni vai iekšēju bibliotēku.

Es izmantotu vismaz divas analīzes: atsevišķi pētītu novēroto ekspluatāciju attiecībā pret publisko labojuma izdošanu un atsevišķi — konkrētu organizāciju aizsardzības ieviešanas aizkavi pēc informācijas saņemšanas. Pirmais raksturo draudu ainavu, otrais — organizācijas darbības spēju. To sajaukšana vienā skaitlī ļauj radīt dramatiskus secinājumus, bet apgrūtina pareizo lēmumu pieņemšanu.

Ne GTIG apkopojums, ne Project Zero publiskās atklāšanas politika neļauj noteikt vienu universālu dienu skaitu, pēc kura visas ievainojamības tiek ekspluatētas. GTIG 2025. gada dati raksturo identificētus zero-day gadījumus un paša pētnieku tīkla redzamību S03. Project Zero dati savukārt labi izgaismo labojuma izstrādes un piegādes šķēršļus, bet nav visu pasaules programmatūras produktu reprezentatīva izlase S01. FIRST EPSS ir statistiska prognozēšanas sistēma, ne katra konkrētā incidenta vēsturiska rekonstrukcija S05.

No šiem avotiem nevar arī izdarīt secinājumu, ka konkrētā Latvijas organizācijā ievainojamību novēršana ir pārāk lēna. Šādam vērtējumam nepieciešama organizācijas aktīvu inventarizācija, drošības atradumu vēsture, izmaiņu žurnāli, novēršanas pierādījumi un kritisko pakalpojumu konteksts. Publiska konferences prezentācija par ātrākiem uzbrucējiem var būt vērtīgs sākumpunkts jautājumam, taču prezentācijas nosaukums nav empīrisks ātruma mērījums.

Ievainojamības publicēšana ir tikai viens notikums garākā ķēdē. Reālais risks var būt radies pirms tās, un faktiska aizsardzība var sākties ilgi pēc ražotāja labojuma izdošanas. Tāpēc organizācijai jāprot redzēt ne vien ārējās ziņas par apdraudējumu, bet arī savas iekšējās aizkaves — kur pazūd laiks, kur nav īpašnieka, kur trūkst inventāra un kur uzdevums tiek aizvērts bez tehniskas pārbaudes.

Ātrāka ielāpu uzstādīšana ir vēlama, ja tā nesagrauj kritisko sistēmu darbību un patiešām novērš konkrēto trūkumu. Tomēr vienmērīgs termiņš visām CVE nevar aizvietot lēmumu par apstiprināti izmantotu ievainojamību publiski pieejamā sistēmā. Manuprāt, uzticamas drošības programmas atšķirības zīme ir spēja uz šo gadījumu reaģēt ārpus parastā izmaiņu kalendāra, vienlaikus saglabājot verifikāciju un atbildību. Laiks līdz pārbaudītai aizsardzībai ir daudz vērtīgāks rādītājs nekā laiks līdz aizvērtam uzdevumam.