Vai ielaušanās testēšana ir obligāta? Ko nosaka MK noteikumi Nr. 397

Galvenais īsumā

  • Ielaušanās testi ir obligāti Nacionālās kiberdrošības likuma subjektiem, un kārtību nosaka MK noteikumu Nr. 397 8.2. apakšnodaļa (131.–140. punkts)
  • A klases informācijas sistēmu testē pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados; ikgadēja ielaušanās testa pienākuma noteikumos nav
  • Testa veicējam 132.2.1. apakšpunkts prasa starptautiski atzītu sertifikātu ielaušanās testu jomā vai divu gadu pieredzi pēdējo piecu gadu laikā – nevis reģistrāciju sarakstā
  • Ielaušanās tests nav NKDL 44. panta atbilstības audits: cits ierosinātājs, cits veicējs, cits rezultāts, un sertifikātu piemēri normās nesakrīt nevienā punktā
  • Drošības skenēšana 135.–140. punkta izpratnē ir uzraudzības instruments, nevis pakalpojums, ko var nopirkt
  • Ikgadējs pienākums tomēr pastāv, tikai cits: NKDL 25. panta piektās daļas 2. punkts prasa IKT drošības pārbaudi reizi gadā, metodi neuzspiežot
  • Uzņēmumam ārpus likuma tvēruma testēšanas pienākuma nav vispār; prasība parasti atnāk no klienta līguma, nevis no normatīvā akta

Uz jautājumu, vai ielaušanās testēšana Latvijā ir obligāta, tirgū atrodamas divas pretējas atbildes, un neviena nav precīza. Pirmā apgalvo, ka NIS2 dēļ tests tagad jāpasūta ikvienam uzņēmumam katru gadu. Otrā apgalvo, ka obligāts ir tikai atbilstības audits, tāpēc tests paliek brīvprātīgs papildinājums. Pienākums patiesībā pastāv, tas ir uzrakstīts vienā konkrētā apakšnodaļā, un tam ir gan konkrēts adresāts, gan konkrēts biežums, gan konkrēta prasība testa veicējam. Zemāk izrakstīti attiecīgie Ministru kabineta noteikumu Nr. 397 punkti, atdalīts ielaušanās tests no Nacionālās kiberdrošības likuma (turpmāk – NKDL) 44. panta atbilstības audita un pateikts, kas paliek uzņēmumam, uz kuru likums neattiecas.

Vai ielaušanās testēšana Latvijā ir obligāta?

Īsā atbilde ir „daļēji“. Pienākums attiecas uz NKDL subjektiem, un tā apjomu nosaka nevis uzņēmuma lielums, bet informācijas sistēmas drošības klase.

Subjekti NKDL 3. panta pirmās daļas 1. punkta izpratnē ir būtisko pakalpojumu sniedzēji, svarīgo pakalpojumu sniedzēji un IKT kritiskās infrastruktūras īpašnieki vai tiesiskie valdītāji. Ja organizācija šajā uzskaitījumā neietilpst, uz to neattiecas neviens no tālāk aprakstītajiem pienākumiem. Šo gadījumu aplūkojam atsevišķi raksta beigās, jo tas ir biežākais.

CERT.LV pienākumu formulē bez atrunām:

„Subjektam ir jāveic IKT infrastruktūras drošības pārbaudes (Ielaušanās testi) atbilstoši Ministru kabineta noteikumu Nr. 397 [..] 8.2. apakšnodaļā paredzētajai kārtībai.“

Visu slodzi šajā teikumā nes vārds „atbilstoši“. Runa nav par vispārīgu aicinājumu testēt, bet par pienākumu testēt tieši tādā kārtībā, kādu apraksta 131.–140. punkts. Kārtība savukārt nosaka gan gadījumus, kuros tests jāveic, gan prasības tā veicējam, un tieši šie divi elementi tirgus materiālos pazūd visbiežāk.

Ko nosaka MK noteikumu Nr. 397 8.2. apakšnodaļa?

Apakšnodaļas nosaukums ir „Ielaušanās testi un drošības skenēšana“, un tajā vienā virsrakstā salikts kopā divējāds saturs. Pirmā daļa (131.–134. punkts) ir subjekta paša pienākums. Otrā daļa (135.–140. punkts) ir uzraudzības instruments, ko rīko valsts iestāde. Tieši šis kopīgais virsraksts ir radījis lielu daļu pārpratumu, tāpēc abas daļas aplūkojam atsevišķi.

  1. punkts uzskaita gadījumus, kuros ielaušanās testu veic.
SistēmaKad testēNorma
A klases informācijas sistēmaPirms nodošanas ekspluatācijā131.1.1.
A klases informācijas sistēmaVismaz reizi trijos gados ekspluatācijas laikā131.1.2.
Jebkura informācijas sistēmaPēc subjekta iniciatīvas131.2.
Jebkura informācijas sistēmaPēc Nacionālā kiberdrošības centra vai Satversmes aizsardzības biroja pieprasījuma131.3.

Divas lietas šajā tabulā pelna uzmanību. Pirmkārt, biežums ir trīs gadi, nevis gads. Ikgadēja ielaušanās testa pienākuma noteikumos nav nevienā punktā. Otrkārt, pienākums ir piesaistīts sistēmas klasei, nevis organizācijai: uzņēmumā ar piecpadsmit informācijas sistēmām tas var attiekties uz vienu no tām un uz pārējām ne.

Klasi nosaka pats subjekts atbilstoši noteikumu 5. pielikuma metodikai (32. punkts). Sistēma ir A klases jeb paaugstinātas drošības sistēma, ja vismaz vienai no trim īpašībām – konfidencialitātei, integritātei vai pieejamībai – ir noteikta A klase (33.1. apakšpunkts). Kritiskās infrastruktūras kopumā iekļautu sistēmu par A klases sistēmu uzskata automātiski, klasificēšanas kārtību nepiemērojot (34. punkts).

No tā izriet praktiskā secība. Vispirms klasifikācija, tad testēšanas plāns. Kas pasūta testu pirms klasifikācijas, tas tvērumu izvēlas pēc nojautas, un nojauta parasti nostrādā par labu lētākajam variantam.

Kas drīkst veikt ielaušanās testu?

  1. punkts atbild uz šo jautājumu trijos apakšpunktos, un tos ir vērts izlasīt burtiski, jo tirgū tie tiek pārstāstīti brīvi.
  • Subjekta paša personāls (132.1. apakšpunkts): darbinieks, kurš pēdējo triju gadu laikā nav bijis iesaistīts testējamās informācijas sistēmas izstrādē vai uzturēšanā.

  • Cita persona (132.2. apakšpunkts): svarīgo vai būtisko pakalpojumu sniedzēja sistēmai, ja šis sniedzējs nav IKT kritiskās infrastruktūras īpašnieks vai tiesiskais valdītājs. Nosacījumi ir divi vienlaikus. 132.2.1. apakšpunkts prasa starptautiski atzītu sertifikātu, kas apliecina personas kvalifikāciju ielaušanās testu jomā (kā piemēri normā minēti CEH un OSCP), vai vismaz divu gadu darba pieredzi ielaušanās testu veikšanā, kas iegūta pēdējo piecu gadu laikā. 132.2.2. apakšpunkts prasa to pašu neatkarību, ko iepriekšējais gadījums prasa darbiniekam.

  • IKT kritiskā infrastruktūra (132.3. apakšpunkts): abiem iepriekšējiem nosacījumiem papildus vajadzīgs Satversmes aizsardzības biroja atzinums noteikumu 98. punktā noteiktajā kārtībā.

Šie trīs apakšpunkti attiecas uz 131.1. un 131.2. apakšpunktā minētajiem testiem. Ja testu pieprasa Nacionālais kiberdrošības centrs vai Satversmes aizsardzības birojs (131.3. apakšpunkts), veicēju loku nosaka 133. punkts: ārpus IKT kritiskās infrastruktūras to veic centra vai kompetentās kiberincidentu novēršanas institūcijas amatpersonas un darbinieki vai persona, kas atbilst 132.2. apakšpunkta prasībām, bet IKT kritiskajā infrastruktūrā – minētās institūcijas darbinieki pēc biroja pieprasījuma vai persona, par kuru saņemts biroja atzinums.

Ievērojiet, ko šī norma neprasa. Ārpus IKT kritiskās infrastruktūras tā neprasa ne reģistrāciju kādā sarakstā, ne akreditāciju, ne valsts izsniegtu atļauju. Tā prasa divas lietas: kompetenci un neatkarību. Abas ir pierādāmas ar dokumentiem, kas testa veicējam jau ir, un tieši tāpēc ir vērts tos pieprasīt.

Praktiskais solis pircējam ir vienkāršs. Pirms līguma parakstīšanas lūdziet testa veicēju rakstiski apliecināt abus 132. punkta nosacījumus un pievienojiet apliecinājumu savai testa dokumentācijai. Vēlāk tas ir vienkāršākais pierādījums, ka tests veikts atbilstoši noteikumiem, un tā sagatavošana neizmaksā neko.

Vēl viena detaļa, ko vērts zināt. IKT kritiskās infrastruktūras īpašnieks vai tiesiskais valdītājs par ielaušanās testa rezultātiem informē Satversmes aizsardzības biroju nekavējoties, bet ne vēlāk kā 10 darbdienu laikā (134. punkts). Pārējiem subjektiem šāda ziņošanas pienākuma nav, un tas ir viens no ātrākajiem veidiem, kā pārbaudīt, vai piedāvājums ir sagatavots pareizajai auditorijai.

Ielaušanās tests nav atbilstības audits

Šeit Latvijas tirgus kļūdās visbiežāk, un kļūda dārgi maksā abos virzienos. Pasūtīts ielaušanās tests neizpilda NKDL 44. panta prasības, un algots kiberdrošības auditors neizpilda MK noteikumu Nr. 397 8.2. apakšnodaļas prasības. Runa ir par divām procedūrām, kuras sakrīt tikai ar to, ka abas beidzas ar dokumentu.

PazīmeIelaušanās tests (MK noteikumu Nr. 397 8.2.)Atbilstības audits (NKDL 44. pants)
Kas ierosinaSubjekts pats vai Nacionālā kiberdrošības centra vai Satversmes aizsardzības biroja pieprasījumsNacionālais kiberdrošības centrs vai Satversmes aizsardzības birojs, ja ir aizdomas par kiberdrošības pārkāpumiem vai tie ir konstatēti
Kas veicSubjekta personāls vai cita persona, kas atbilst 132. punkta prasībām; pēc uzrauga pieprasījuma – 133. punktā noteiktās personasNeatkarīgs kiberdrošības auditors, kuram ar subjektu nav interešu konflikta
Ko pārbaudaVai sistēmā ir praktiski izmantojamas ievainojamībasVai subjekts atbilst likumā un Ministru kabineta noteikumos noteiktajām kiberdrošības prasībām
Sertifikātu piemēri normāCEH, OSCP (132.2.1. apakšpunkts)CISA, ISO/IEC 27001 Lead Auditor, CISSP (122.2. apakšpunkts)
BiežumsA klases sistēmai vismaz reizi trijos gadosNav periodisks; notiek pēc uzraudzības iestādes lēmuma
Kur nonāk rezultātsTehnisks ziņojums subjektamĀrējā audita ziņojums, kura kopiju subjekts iesniedz uzraudzības iestādei (44. panta piektā daļa)

Vienkāršākais pierādījums, ka runa ir par divām dažādām lietām, ir pašos normatīvajos aktos minētie sertifikātu piemēri. Ielaušanās testa veicējam nosaukti CEH un OSCP, tātad ofensīvas kvalifikācijas. Auditoram nosaukti CISA, ISO/IEC 27001 Lead Auditor un CISSP, tātad audita un pārvaldības kvalifikācijas. Sarakstiem nav neviena kopīga elementa, un tas nav nejaušība: darbs nav viens un tas pats.

Ir vēl viena atšķirība, ko pamana reti. NKDL 44. panta pirmā daļa ļauj uzraudzības iestādei veikt atbilstības auditu vai uzdot subjektam veikt ārēju auditu tikai tad, „ja ir aizdomas par kiberdrošības pārkāpumiem vai tie ir konstatēti“. Tas nav periodisks pienākums, ko ieplāno kalendārā, bet uzraudzības solis ar iemeslu. Regulārā, plānojamā procedūra ir cita: pašvērtējuma ziņojums, ko iesniedz reizi gadā vai reizi trijos gados līdz kārtējā gada 1. oktobrim (noteikumu 141. un 142. punkts). Kā gatavoties gan pašvērtējumam, gan auditam, aprakstīts rakstā par atbilstības audita sagatavošanu.

Auditoram izvirzāmās prasības pašlaik pārkārtojas, un to ir vērts pieminēt atsevišķi. Ar 2026. gada 4. jūnija grozījumiem, kas stājās spēkā 18.06.2026., šīs prasības nodotas Ministru kabineta kompetencē. Kamēr jaunie noteikumi nav izdoti, NKDL pārejas noteikumu 14. punkts liek piemērot tās prasības, kas bija noteiktas MK noteikumos Nr. 397, taču ne ilgāk kā līdz 2026. gada 1. decembrim. Kas plāno auditu pēc šā datuma, tas aktuālo redakciju pārbauda no jauna.

Kāpēc drošības skenēšanu nevar nopirkt kā pakalpojumu

Otra 8.2. apakšnodaļas puse rada otru izplatīto pārpratumu. Noteikumu 135.–140. punkts apraksta drošības skenēšanu, un Latvijas normatīvajā valodā šis vārdu savienojums apzīmē uzraudzības darbību, nevis to, ko var iekļaut cenrādī.

  1. punkts nosaka trīs ierosināšanas ceļus: pēc Nacionālā kiberdrošības centra pieprasījuma, pēc Satversmes aizsardzības biroja pieprasījuma un pēc paša subjekta pieprasījuma. Trešais no tiem izskatās pēc atvērtām durvīm, taču veicēju loks paliek šaurs arī tad. IKT kritiskajā infrastruktūrā (136. punkts) skenēšanu veic Satversmes aizsardzības biroja amatpersonas, kompetentā kiberincidentu novēršanas institūcija pēc biroja pieprasījuma vai persona, par kuru saņemts biroja atzinums. Pārējiem subjektiem (140. punkts) to veic 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 par reģistrācijas valsti, valdes sastāvu un patiesajiem labuma guvējiem.

Arī procedūras režīms nav komerciāls. 138. punkts, kas attiecas uz skenēšanu IKT kritiskajā infrastruktūrā 136.2. un 136.3. apakšpunkta gadījumos, prasa rakstiski brīdināt par skenēšanas laiku un ilgumu vismaz 48 stundas iepriekš, iegūt tikai to informāciju un tādā apjomā, kas nepieciešams pārvaldāmo risku identificēšanai, un detalizētus rezultātus nekavējoties nosūtīt gan infrastruktūras īpašniekam, gan Satversmes aizsardzības birojam. Kritiskajā infrastruktūrā rezultāti tātad nonāk arī pie uzrauga, un neviens komercpakalpojums tā nedarbojas.

No tā izriet ērts pārbaudes kritērijs. Piedāvājums, kurā drošības skenēšana ir nosaukta par pakalpojumu, lieto uzrauga procedūras nosaukumu, un tas parasti liecina, ka teksts sarakstīts, normu neatverot. Komerciālais ekvivalents saucas citādi: pakalpojums ir ievainojamību novērtēšana, bet tā automatizētā daļa – ievainojamību skenēšana. Kur beidzas viena un sākas otra, aplūkots rakstā ievainojamību skenēšana vai ielaušanās tests.

Ikgadējais pienākums, par kuru runā vismazāk

Ielaušanās tests nav ikgadējs, bet viens ikgadējs pienākums NKDL tomēr ir, un tas attiecas uz katru subjektu neatkarīgi no sistēmu klasēm. 25. panta piektās daļas 2. punkts uzliek kiberdrošības pārvaldniekam pienākumu „ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un atbilstoši tās rezultātiem organizēt konstatēto trūkumu novēršanu“.

Norma nenosauc metodi. Tā neprasa ne ielaušanās testu, ne ārēju izpildītāju, ne konkrētu standartu. Tā prasa pārbaudi un konstatēto trūkumu novēršanu, un otrā puse ir tā, kas parasti paliek nepadarīta: pārbaudes ziņojums bez novēršanas plāna šo normu neizpilda.

CERT.LV iesaka pārbaudes plānot pēc satura, nevis pēc kalendāra: „CERT.LV ieskatā ikgadējām pārbaudēm būtu jābūt tematiskām, un tās jāveic atbilstoši informācijas sistēmu risku analīzes rezultātiem.“ Piemērs, ko iestāde min pati, ir rezerves kopijas: ja nav pārliecības, vai kritisko sistēmu darbību var atjaunot, tad gada pārbaudi vērts vērst uz atjaunošanas plānu un rezerves kopiju integritāti, nevis kārtējo reizi uz publisko tīmekļa lietotni.

Kopā salikti, četri pienākumi izskatās šādi.

PienākumsKas to pildaBiežumsNorma
IKT drošības pārbaudeKiberdrošības pārvaldnieksNe retāk kā reizi gadāNKDL 25. panta piektās daļas 2. punkts
Ielaušanās tests A klases sistēmaiSubjektsPirms ekspluatācijas un vismaz reizi trijos gadosMK noteikumu Nr. 397 131.1. apakšpunkts
Pašvērtējuma ziņojumsSubjektsReizi gadā vai reizi trijos gados, līdz 1. oktobrimMK noteikumu Nr. 397 141. un 142. punkts
Atbilstības auditsUzraudzības iestāde vai tās uzdevumā auditorsNav periodisksNKDL 44. pants

Tabula paskaidro, kāpēc apgalvojums „NIS2 prasa ikgadēju pentestu“ ir vienlaikus nepareizs un tuvu patiesībai. Ikgadējs pienākums tiešām pastāv, bet tas nav ielaušanās tests. Ielaušanās tests tiešām ir obligāts, bet reizi trijos gados un tikai A klases sistēmai. Divas patiesas puses, saliktas kopā nepareizi, dod apgalvojumu, uz kura pamata organizācijas pērk gan par daudz, gan ne to.

Ja uzņēmums nav NKDL subjekts

Šeit atbilde ir īsa, un to nav vērts ietērpt atrunās. Likumā noteikta ielaušanās testēšanas pienākuma nav – ne netieša, ne tāda, kas „drīz stāsies spēkā“. Ja organizācija neietilpst NKDL 3. panta pirmās daļas 1. punkta uzskaitījumā, uz to neattiecas ne 131. punkts, ne 25. panta piektā daļa.

Testēt tomēr ir vērts, tikai cita iemesla dēļ, un iemesli ir pietiekami konkrēti, lai tos varētu ielikt budžetā.

  • Piegādes ķēde. MK noteikumu Nr. 397 41.2. apakšpunkts liek subjektam analizēt arī ar piegādes ķēdēm saistītos riskus. Prasība tāpēc ceļo lejup pa līgumiem: uzņēmums, uz kuru likums neattiecas, testu bieži veic tāpēc, ka to prasa klients, uz kuru tas attiecas. Šis ir biežākais ceļš, pa kuru ielaušanās tests nonāk pie neregulēta piegādātāja.

  • Standarti un sertifikācija. ISO/IEC 27001 sagaida tehnisko ievainojamību pārvaldību un drošības testēšanu izstrādes un pieņemšanas gaitā. Vai sertifikāts vienlaikus sedz arī NKDL prasības, aplūkots rakstā [ISO 27001 un NKDL prasības](/lv/raksti/vai-ar-iso-27001-pietiek-nkdl-prasibam).

  • Finanšu sektors. Finanšu vienībām ir atsevišķs regulējums, proti, regula (ES) 2022/2554, un NKDL 3. panta trešā daļa to tieši atrunā. Šis raksts finanšu sektora testēšanas prasības neaptver.

  • Iepirkumi un apdrošināšana. Publiskā un privātā iepirkuma nolikumos drošības testēšana parādās kā kvalifikācijas prasība arvien biežāk, un kiberapdrošinātāji jautā to pašu. Abos gadījumos vajadzīgs dokuments ar datumu un tvērumu, nevis apliecinājums, ka drošība ir svarīga.

  • Vienkāršākais iemesls. Uzbrucējs neskatās, vai uzņēmums ir kādā sarakstā. Publiskā tīmekļa lietotne ar autorizācijas kļūdu ir vienlīdz izmantojama abos gadījumos, un atšķirība ir tikai tā, ka neregulētam uzņēmumam neviens neuzdos to pārbaudīt.

Kā saplānot testēšanu, ja pienākums attiecas uz jums

Piecas darbības visu iepriekš teikto pārvērš kalendārā. Secība nav brīvi maināma: katra nākamā izmanto iepriekšējās rezultātu.

  1. Klasificējiet savas sistēmas. Noteikumu 32.–34. punkts dod metodiku, un bez klasifikācijas nav zināms ne tvērums, ne biežums. Šis solis parasti ir arī lētākais.

  2. Plānojiet no termiņa atpakaļ. Trīs gadu cikls šķiet garš, taču konstatējumu novēršana un pārtestēšana aizņem nedēļas, un tās ieplānojiet pirms termiņa, nevis pēc tā.

  3. Nošķiriet ikgadējo pārbaudi no trīs gadu testa. Tie ir divi dažādi pienākumi ar dažādu apjomu. Ikgadējā pārbaude var būt tematiska; A klases sistēmas tests nevar.

  4. Pārbaudiet testa veicēja atbilstību 132. punktam. Kvalifikācija un neatkarība, abas rakstiski un abas līgumā. Ja piedāvājumā tiek solīta „licence“ vai „valsts atzīta akreditācija“ ielaušanās testu jomā, tā ir zīme, ka normā rakstītais nav lasīts.

  5. Saglabājiet pierādījumus. Tvērums, datumi, konstatējumi ar reproducēšanas soļiem, novēršanas gaita un pārtestēšanas rezultāts. Tieši šī lieta pēc tam kalpo gan pašvērtējuma ziņojumam, gan sarunai ar uzraugu.

Ko saņemat ielaušanās testa beigās

Normatīvais akts ziņojuma saturu nenosaka, tāpēc prasību līmeni nosaka pircējs. Zemāk uzskaitīts tas, kas ziņojumā vajadzīgs, lai to varētu izmantot gan tehniskajā darbā, gan atbilstības dokumentācijā.

  • Tvērums un laiks. Kuras sistēmas, kuras saskarnes un kuri piekļuves līmeņi pārbaudīti, kādā modelī un kurās dienās.

  • Konstatējumi ar pierādījumiem. Katram konstatējumam reproducēšanas soļi un pierādījums, ka ievainojamība ir praktiski izmantojama, nevis tikai skenera atzīmēta.

  • Riska novērtējums jūsu vidē. Blakus CVSS vērtējumam apraksts, ko konkrētā kļūda nozīmē tieši šajā organizācijā: klientu dati, dīkstāve, finansiāls zaudējums.

  • Novēršanas secība. Nevis „atjauniniet sistēmu“, bet kura komponente, uz kuru versiju, kurš iestatījums un ar ko sākt.

  • Pārtestēšanas apliecinājums. Pēc labojumiem konstatējumus pārbauda atkārtoti un rakstiski fiksē, kuri ir slēgti. Šis dokuments pārvērš ievainojamību sarakstu par paveiktu darbu.

Metodoloģiju nosaucam ziņojumā: tīmekļa lietotnēm strādājam atbilstoši OWASP ASVS un OWASP WSTG, lai testa tvērumu varētu salīdzināt ar publisku kritēriju sarakstu, nevis ar mūsu vārdu.

HAXORIS ir Slovākijā reģistrēts uzņēmums, un Latvijā tam nav ne biroja, ne pārstāvniecības. Neveicam NKDL 44. pantā noteikto atbilstības auditu: to veic neatkarīgs kiberdrošības auditors, kas atbilst likumā un Ministru kabineta noteikumos izvirzītajām prasībām. Piedāvājam tehnisku drošības testēšanu un gatavības novērtēšanu, tostarp ielaušanās testēšanu NIS2 un NKDL gatavībai.

Kopsavilkums: viena apakšnodaļa, divi pārpratumi

Ielaušanās testēšana Latvijā ir obligāta NKDL subjektiem, un pienākuma apjomu nosaka MK noteikumu Nr. 397 8.2. apakšnodaļa: A klases informācijas sistēmu testē pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados, pārējās – pēc subjekta iniciatīvas vai uzraudzības iestādes pieprasījuma. Testa veicējam prasīta kompetence un neatkarība, nevis reģistrācija sarakstā. Ikgadējs ir cits pienākums, proti, IKT drošības pārbaude saskaņā ar 25. panta piektās daļas 2. punktu, un metodi tā neuzspiež. Atbilstības audits saskaņā ar 44. pantu ir trešā, atsevišķa procedūra, kuru ierosina uzraugs. Drošības skenēšana saskaņā ar 135.–140. punktu ir ceturtā, un pārdošanā tās nav vispār.

Praktiskais secinājums ir īsāks par normām. Vispirms noskaidrojiet savu sistēmu klases, pēc tam plānojiet testus, un tikai pēc tam salīdziniet piedāvājumus. Ja noderētu otrs skatījums, aicinām pieteikties bezmaksas konsultācijai un paņemt līdzi sistēmu sarakstu: pusstundā parasti kļūst skaidrs, kuri no četriem pienākumiem attiecas uz organizāciju un kuram no tiem termiņš ir tuvākais.

Ielaušanās testu pienākums – biežāk uzdotie jautājumi

01

Vai ielaušanās testēšana Latvijā ir obligāta?

Daļēji. Pienākums attiecas uz Nacionālās kiberdrošības likuma subjektiem, proti, uz būtisko un svarīgo pakalpojumu sniedzējiem un IKT kritiskās infrastruktūras īpašniekiem vai tiesiskajiem valdītājiem. Kārtību nosaka Ministru kabineta noteikumu Nr. 397 8.2. apakšnodaļa: A klases informācijas sistēmu testē pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados. Uzņēmumam, kas šajā uzskaitījumā neietilpst, likumā noteikta testēšanas pienākuma nav.

02

Cik bieži jāveic ielaušanās tests?

A klases informācijas sistēmai – pirms nodošanas ekspluatācijā un vismaz reizi trijos gados ekspluatācijas laikā (MK noteikumu Nr. 397 131.1. apakšpunkts). Ikgadēja ielaušanās testa pienākuma noteikumos nav. Ikgadējs ir cits pienākums: Nacionālās kiberdrošības likuma 25. panta piektās daļas 2. punkts liek kiberdrošības pārvaldniekam ne retāk kā reizi gadā veikt IKT drošības pārbaudi, taču metodi šī norma nenosaka.

03

Kas drīkst veikt ielaušanās testu?

Subjekta paša personāls, kas pēdējo triju gadu laikā nav bijis iesaistīts testējamās sistēmas izstrādē vai uzturēšanā, vai cita persona. Citai personai 132.2.1. apakšpunkts prasa starptautiski atzītu sertifikātu, kas apliecina kvalifikāciju ielaušanās testu jomā (kā piemēri normā minēti CEH un OSCP), vai vismaz divu gadu darba pieredzi ielaušanās testu veikšanā, kas iegūta pēdējo piecu gadu laikā. Reģistrācija sarakstā vai akreditācija netiek prasīta. IKT kritiskajā infrastruktūrā papildus vajadzīgs Satversmes aizsardzības biroja atzinums.

04

Vai ielaušanās tests aizstāj NKDL 44. panta atbilstības auditu?

Nē, un otrādi arī nē. Tās ir divas procedūras ar atšķirīgu ierosinātāju, veicēju un rezultātu. Ielaušanās testu plāno pats subjekts, un to veic persona, kas atbilst 132. punkta prasībām. Atbilstības auditu ierosina Nacionālais kiberdrošības centrs vai Satversmes aizsardzības birojs, ja ir aizdomas par kiberdrošības pārkāpumiem vai tie ir konstatēti, un ārējo auditu veic neatkarīgs kiberdrošības auditors. To, ka darbs nav viens un tas pats, apliecina jau normās minētie sertifikātu piemēri: testētājam CEH un OSCP, auditoram CISA, ISO/IEC 27001 Lead Auditor un CISSP.

05

Kas ir drošības skenēšana un vai to var pasūtīt kā pakalpojumu?

Drošības skenēšana MK noteikumu Nr. 397 135.–140. punkta izpratnē ir uzraudzības instruments, nevis komercpakalpojums. To veic pēc Nacionālā kiberdrošības centra vai Satversmes aizsardzības biroja pieprasījuma, bet veicēju loks paliek šaurs pat tad, ja skenēšanu prasa pats subjekts, un IKT kritiskajā infrastruktūrā rezultātus nosūta arī uzraugam. Komerciālais ekvivalents saucas citādi: ievainojamību novērtēšana un tās automatizētā daļa – ievainojamību skenēšana.

06

Vai uzņēmumam ārpus NKDL tvēruma ir jāveic ielaušanās testi?

Likumā noteikta pienākuma nav. Prasība tomēr bieži atnāk pa citu ceļu: MK noteikumu Nr. 397 41.2. apakšpunkts liek subjektam analizēt arī piegādes ķēdes riskus, tāpēc testēšanu no apakšuzņēmēja pieprasa klients, uz kuru likums attiecas. Testēšanu prasa arī sertifikācijas shēmas, iepirkumu nolikumi un apdrošinātāji.

Noskaidrosim, kas tieši attiecas uz jūsu sistēmām

Pieteikties bezmaksas konsultācijai