NIS2 atbilstība nav kiberdrošības garantija: kā pārbaudīt faktiskās aizsardzības spējas?

NIS2 nav universāls sertifikāts, kuru saņemot sistēma kļūst droša. Direktīva nosaka dalībvalstīm pienākumu izveidot prasību un uzraudzības ietvaru noteiktu nozaru būtiskajiem un svarīgajiem subjektiem. Tās 21. pants aptver risku analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu sistēmu iegādi un uzturēšanu, kontroles efektivitātes novērtēšanu, kiberhigiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli un aktīvu pārvaldību. Savukārt 20. pants paredz vadības struktūru iesaisti un tās atbildību par pasākumu apstiprināšanu un pārraudzību S01. Tomēr konkrētu prasību piemērošana ir atkarīga no subjekta statusa, nozaru regulējuma un jurisdikcijas.

Tas nozīmē arī pretējo: nedrīkst ikvienam NIS2 subjektam automātiski piedēvēt visas Komisijas Īstenošanas regulas (ES) 2024/2690 pielikumā noteiktās detalizētās prasības. Šī regula attiecas uz konkrētām digitālās infrastruktūras, IKT pārvaldības un digitālo pakalpojumu sniedzēju kategorijām. ENISA 2025. gada tehniskās vadlīnijas piedāvā noderīgus pierādījumu piemērus, taču pašas par sevi nav juridiski saistošs dokuments un neaizstāj Latvijas tiesību aktus S04 S05.

Būtiskākā atšķirība ir starp kontroles projektēšanu, ieviešanu, darbību un efektivitāti. Politika pierāda, ka organizācija ir noteikusi kārtību. Konfigurācijas eksports var pierādīt, ka konkrētā brīdī pasākums bija ieslēgts. Telemetrija un izmaiņu vēsture ļauj spriest, vai tas darbojās laika periodā. Kontrolēts tests parāda, vai noteiktā scenārijā pasākums sasniedza aizsardzības mērķi. Neviens atsevišķs pierādījuma veids neaptver visus četrus līmeņus.

Iedomāsimies organizāciju, kura risku novērtējumā ierakstījusi: “priviliģēta piekļuve ir aizsargāta”. Šis ir pārāk plašs apgalvojums. Vadītājam vai auditoram no tā nav iespējams saprast, vai daudzfaktoru autentifikācija attiecas uz visiem administratīvajiem kontiem, vai eksistē avārijas piekļuves izņēmumi, kā tiek atcelta bijušo darbinieku piekļuve un vai tiek fiksētas aizdomīgas darbības. Pārbaudāma versija būtu: “visiem noteiktā tvēruma interaktīvajiem administratīvajiem kontiem ir piemērots apstiprināts autentifikācijas mehānisms; izņēmumi ir reģistrēti, ierobežoti laikā un uzraudzīti”. To iespējams pārbaudīt pret identitātes sistēmas datiem, kontu inventāru, izņēmumu reģistru un kontrolētu testa scenāriju.

Katram būtiskam drošības apgalvojumam ir vajadzīgas piecas sasaistes: aizsargājamais pakalpojums, konkrētais risks, kontroles mērķis, izpildes pierādījums un atbildīgais par neatbilstības novēršanu. Ja kādas sasaistes nav, uzņēmums bieži iegūst skaistu atbilstības karti, kura neatspoguļo faktisko risku. Piemēram, “rezerves kopēšana ieslēgta” nav tas pats, kas “kritiskā datubāze noteiktajā laikā atjaunota izolētā vidē, pārbaudot datu integritāti un atkarīgo pakalpojumu darbību”.

Šāda pieeja saskan ar NIST Cybersecurity Framework 2.0, kur drošības pārvaldība organizēta ap sešām savstarpēji saistītām funkcijām: Govern, Identify, Protect, Detect, Respond un Recover. NIST ietvars nav NIS2 juridiska aizstājējs, taču palīdz pārbaudīt, vai uzņēmums vērtē ne tikai aizsardzības pasākumu ieviešanu, bet arī spēju atklāt incidentus, reaģēt un atjaunoties S06.

Aktīvu uzskaite: vai tiek aizsargāts viss būtiskais?

Pilnīgs serveru saraksts vēl nav pakalpojumu atkarību karte. Kritiska pakalpojuma darbību var noteikt identitātes pakalpojums, DNS, mākoņa pārvaldības vide, integrācijas atslēgas, datubāze, tīkla komponents vai ārējs pakalpojumu sniedzējs. Ja kāda no šīm atkarībām nav uzskaitīta, drošības kontroles tvērums var būt nepilnīgs, pat ja inventāra tabula formāli eksistē. Praktiska pārbaude ir salīdzināt konfigurāciju pārvaldības datus, mākoņa resursu inventāru, tīkla novērojumus un īpašnieku apstiprinājumus. Atšķirības jāreģistrē kā nenosegtas atkarības, nevis klusi jāizslēdz no rezultāta.

Identitātes: vai privilēģijas patiešām tiek ierobežotas?

Šeit būtisks nav tikai MFA licences pirkums vai politikas formulējums. Vajadzīgs pārskatāms privileģēto identitāšu saraksts, autentifikācijas metožu piemērošanas dati, neaktīvo kontu izslēgšanas vēsture, servisa kontu īpašnieki un ārpakalpojuma piekļuves robežas. Izņēmumiem jābūt skaidriem, nevis paslēptiem kopējā “atbilst” statusā. Drošs kontrolēts tests var verificēt, vai nepilnvarotam kontam patiešām nav iespējams piekļūt kritiskai administrēšanas funkcijai; nedrīkst aizstāt šādu pārbaudi ar pieņēmumu, ka piekļuve būs bloķēta.

Incidentu atklāšana: vai trauksme sasniedz cilvēku, kas rīkosies?

Žurnālu glabāšana nav incidentu atklāšanas spējas pierādījums. Jāpārbauda, kuri kritiskie avoti nosūta notikumus, kāds ir datu pienākšanas kavējums, vai detektēšanas noteikumi aptver būtiskos uzbrukuma scenārijus un vai izveidotais brīdinājums nonāk atbildīgajā reaģēšanas plūsmā. Piemēram, atļautā testā ģenerēts aizdomīgas privileģētas autentifikācijas notikums ļauj izsekot ķēdei no avota līdz analītiķa lēmumam. Ja notikums ir sistēmā, bet neviens to nepamana, kontroles pastāvēšana nav pielīdzināma tās efektivitātei.

Atjaunošana: vai drošības kopijas pārvēršas darbspējīgā pakalpojumā?

Rezerves kopijas statuss “success” galvenokārt raksturo konkrēta kopēšanas darba rezultātu. Tas nepierāda, ka kopija ir pilnīga, ka tā izturēs kompromitētas identitātes scenāriju vai ka pakalpojumu var atjaunot vajadzīgajā secībā. Testā jāfiksē sākuma stāvoklis, izolācijas priekšnoteikumi, faktiskais atjaunošanas ilgums, pārbaudītā datu integritāte, atkarību atjaunošana un novirzes no organizācijas noteiktajiem atjaunošanas mērķiem. Atjaunošanas spēju nevar secināt tikai no piegādātāja SLA vai pašas organizācijas procedūras S03 S06.

Piegādātāji: vai kontroles aptver reālās atkarības?

Līguma drošības pielikums ir nepieciešams pārvaldības instruments, bet tas neparāda, vai piegādātājs spēs nodrošināt kritisko pakalpojumu incidenta laikā. Uzņēmumam jāzina, kuras funkcijas faktiski atkarīgas no katra piegādātāja, kā tiek saņemti incidentu paziņojumi, kas pārbauda izmaiņas piekļuves tiesībās un vai pastāv praktiski realizējams darbības turpināšanas variants. Ne katram piegādātājam vajadzīgs vienāds kontroles dziļums: proporcionalitāte nozīmē lielāku uzmanību tiem, kuru atteice rada būtisku ietekmi uz pakalpojumu S01 S05.

Matrica ir praktisks autora analītisks instruments, nevis oficiāla NIS2 sertifikācijas vai Latvijas uzrauga kontrolsaraksta veidlapa. Tās uzdevums nav aizstāt normatīvu interpretāciju, bet padarīt apgalvojumus falsificējamus: ja tehnisks tests parāda pretējo, dokumentētais “atbilst” jāpārskata. Auditoram jāredz arī pārbaudes tvērums, datums, vide, metodes ierobežojumi un pārbaudē neatklātās zonas.

Skaitlis “95% atbilstība” bez saucēja un pierādījumu kvalitātes var būt maldinošs. Nav skaidrs, vai tas nozīmē pārbaudītas sistēmas, atzīmētas prasības, savāktus dokumentus vai sekmīgus testus. Tā vietā vadības pārskatam ir lietderīgi nodalīt vismaz trīs dimensijas: tvērums (cik no attiecīgajiem aktīviem un procesiem pārbaude aptvēra), testa rezultāts (cik kontrolētajos gadījumos mērķis tika sasniegts) un pierādījuma svaigums (kad tas iegūts un kas kopš tā laika mainījies). Šīs dimensijas nedrīkst mehāniski sapludināt vienā universālā kiberdrošības vērtējumā.

Piemēram, ja piekļuves kontrole pārbaudīta desmit atlasītās sistēmās un divās atrastas neatļautas administrēšanas tiesības, korekts ziņojums norāda izlases metodi, atrastās novirzes, risku un pārbaudes robežas. Nekorekts ziņojums ir secinājums, ka “organizācijas identitāšu drošība ir 80%”, jo no šādas izlases par visu organizāciju nav pamata izdarīt precīzu vispārinājumu. Līdzīgi viens sekmīgs atjaunošanas tests pierāda konkrēta scenārija izpildi konkrētos apstākļos, nevis garantē darbspēju pie jebkura uzbrukuma.

Pārbaudes rezultātam jābūt reproducējamam: identificēts aktīvs, kontroles versija, testa scenārijs, izpildes datums, gaidītais un faktiskais rezultāts, atbildīgais, pierādījuma glabāšanas vieta un novirzes novēršanas statuss. Ja pārbaude skar produkciju vai piegādātāja vidi, nepieciešama skaidra autorizācija, ierobežots tvērums un drošas apstādināšanas nosacījumi. Noturības pierādīšana nedrīkst radīt jaunu nekontrolētu incidentu.

Vadībai nav jāinterpretē katrs SIEM noteikums vai autentifikācijas žurnāls. Tai jāspēj iegūt pamatotas atbildes uz jautājumiem: kuri pakalpojumi rada lielāko risku, kur kontroles tvērums nav zināms, kuri testi pēdējā periodā izgāzušies, cik kritisku noviržu vēl nav novērsts un kā pārbaudīts, ka novēršana tiešām nostrādājusi. Šāds pārskats atšķiras no dokumentu paketes ar zaļām atzīmēm, jo parāda arī nenoteiktību un atlikušā riska uzņemšanos. NIS2 20. pantā vadības struktūru uzraudzības loma ir skaidri noteikta; tehniska pakalpojuma līgums šo lomu neizdzēš S01.

Ārpakalpojuma sniedzējam savukārt nevar prasīt neierobežotu piekļuvi vai neierobežotu garantiju. Līgumā un operacionālajā kārtībā ir jāvienojas par pārbaudāmiem rezultātiem: aptverto sistēmu kopu, piekļuves robežām, telemetrijas kvalitātes pārbaudēm, eskalācijas ceļu, incidentu pierādījumu saglabāšanu un pakalpojuma sniedzēja paša atkarībām. Ja sniedzējs atsakās nodrošināt kāda veida tehnisku pierādījumu, iespējami arī leģitīmi iemesli, piemēram, citu klientu konfidencialitāte. Tad jāvienojas par alternatīvu apliecinājumu, neatkarīgu pārbaudi vai godīgi jāfiksē atlikusī nenoteiktība, nevis automātiski jāpaziņo par neatbilstību.

Latvijā NIS2 sistēmu īsteno Nacionālās kiberdrošības likums un tam pakārtotie noteikumi. 2025. gada 25. jūnija Ministru kabineta noteikumi Nr. 397 aptver minimālās kiberdrošības prasības, kiberrisku pārvaldības un IKT darbības nepārtrauktības jautājumus, pašvērtējumu, incidentu ziņošanu un citas tajos norādītās jomas S02 S03. Pirms piemērot konkrētu prasību, ir jānoskaidro, kādā statusā organizācija atrodas, kuras informācijas sistēmas un pakalpojumi ir attiecīgajā tvērumā, vai pastāv speciāls nozaru regulējums un kura normatīvā redakcija ir piemērojama attiecīgajam datumam.

Šeit ir svarīga juridiska piesardzība. Eiropas Savienības direktīvas teksts, Latvijas likums, Ministru kabineta noteikumi un ENISA metodiskie skaidrojumi nav vienāds juridisks instruments. Komisijas Īstenošanas regula (ES) 2024/2690 nosaka detalizētu prasību kopu tieši tajā minētajām subjektu kategorijām S04. Organizācija, kas šos līmeņus sajauc, var kļūdaini pasludināt kādu labās prakses piemēru par visiem obligātu normu vai, pretēji, neievērot sev piemērojamu prasību. Kontroļu tehniskā pārbaude jāsasaista ar precīzu tiesisko tvērumu, nevis tikai ar birku “NIS2”.

Sākums nav vēl viena plaša politiku pārrakstīšana. Izvēlas vienu kritisku pakalpojumu, nosaka tā tehniskās un piegādātāju atkarības, piesaista jau esošos riskus un katrai būtiskajai kontrolei formulē pārbaudāmu apgalvojumu. Pēc tam novērtē, vai pierādījums attiecas uz noteikto tvērumu un vai tas apliecina tikai konfigurācijas esamību vai faktisku darbību. Tur, kur pietrūkst efektivitātes pierādījuma, veic autorizētu tehnisku pārbaudi, fiksē neatbilstību, nosaka īpašnieku un atkārto testu pēc labojuma.

Šis process ir iteratīvs. Sākotnēji pierādījumu iespējams iegūt manuāli; automatizācijai ir jēga tur, kur stāvoklis bieži mainās, piemēram, administratīvo kontu, mākoņa resursu, drošības žurnālu avotu vai kritisko konfigurāciju uzskaitē. Automātiski iegūts pierādījums nav uzticamāks tikai tāpēc, ka tas iegūts ar API: jāpārbauda datu avota pilnīgums, piekļuves tiesības, izgūšanas laiks un pārveidošanas loģika. Organizācijai jāspēj paskaidrot, ko konkrētais rādītājs nepierāda.

Galvenais secinājums ir nevis tas, ka atbilstības dokumenti ir lieki, bet tas, ka tie ir tikai viena pierādījumu ķēdes daļa. NIS2 mērķis nav izveidot nevainojamu atskaišu kolekciju. Organizācija, kura spēj sasaistīt normatīvo pienākumu ar tehnisko kontroli, izmēģinātu scenāriju un dokumentētu novirzes novēršanu, labāk saprot savu faktisko drošības stāvokli. Tā joprojām nevar garantēt, ka incidents nenotiks, taču var daudz pārliecinošāk pamatot, kāpēc tās aizsardzības pasākumiem ir pamats uzticēties.