Kiberdrošības sertifikācija: ko īsti pierāda kontrole, kas ir “ieviesta”?

Eiropas Kiberdrošības akta sertifikācijas modelis nav veidots kā absolūts drošības zīmogs.

Regulas (ES) 2019/881 52. pants paredz apliecinājuma līmeņus “pamata”, “būtisks” un “augsts”, sasaistot tos ar paredzētā lietojuma risku, novērtējuma stingrību un dziļumu.1

Tas ir svarīgs dizaina princips.

Sertifikācijas secinājums vienmēr ir piesaistīts:

• konkrētai shēmai;
• konkrētam objektam vai pakalpojumam;
• konkrētam scope;
• konkrētam assurance level;
• konkrētai novērtēšanas metodikai;
• konkrētam laika un konfigurācijas kontekstam.

Tāpēc pareizs jautājums nav:

“Vai pakalpojums ir sertificēts?”

Bet gan:

“Ko tieši sertifikāts aptver, pret kādām prasībām tas tika novērtēts un kas ir pārbaudīts kopš sākotnējās novērtēšanas?”

Assurance sarunās bieži vienā vārdā “evidence” tiek salikti ļoti dažādi pierādījumu veidi.

Praksē tos ir lietderīgi nošķirt.

Visi četri līmeņi ir vajadzīgi dažādos gadījumos.

Problēma rodas, ja zemāka līmeņa pierādījums tiek izmantots, lai izdarītu augstāka līmeņa secinājumu.

Piemēram:

“patch deployed” nepierāda, ka ievainojamība vairs nav ekspluatējama;

“incident playbook updated” nepierāda, ka komanda tagad spēj ātrāk reaģēt;

“MFA enabled” nepierāda, ka privileģētam kontam nav palicis paralēls legacy login ceļš;

“backup completed” nepierāda, ka restore darbojas.

Šīs nav semantiskas nianses. Tie ir atšķirīgi assurance apgalvojumi.

Eiropas Kiberdrošības aktā šī loģika nav sveša.

“Būtiska” assurance līmeņa novērtējumam jāietver ne tikai dokumentācijas pārbaude, bet arī pārbaude, ka nepieciešamās drošības funkcijas ir pareizi ieviestas. “Augstā” līmeņa loģika iet vēl tālāk, paredzot dziļāku novērtēšanu pret sarežģītākiem uzbrukumiem.1

Tas nozīmē, ka pati ES sertifikācijas arhitektūra jau atzīst: jo lielāks risks, jo mazāk pietiek ar deklarāciju un jo vairāk vajag pārbaudi.

No tā gan neizriet, ka “high” sertifikāts nozīmē absolūtu drošību.

Tas nozīmē, ka novērtēšanas dziļums un rigor ir augstāks noteiktajā sertifikācijas scope.

Pārvaldīts incident response pakalpojums šodien var nebūt tas pats pakalpojums pēc deviņiem mēnešiem.

Var mainīties:

• incident response platforma;
• klientu izolācijas mehānismi;
• subprocessor;
• threat-intelligence avots;
• dežūru modelis;
• attālinātās piekļuves kontrole;
• pierādījumu glabāšana;
• kritiska integrācija;
• piegādātājs;
• kompetences sastāvs.

Tāpēc EUMSS kandidātshēmas projektā ir paredzēta certification lifecycle loģika un ikgadēja surveillance evaluation.3

Tas ir pareizs virziens.

Taču surveillance vērtība nav pašā faktā, ka “auditors atnāca vēlreiz”.

Tās vērtība ir tajā, ko pārbauda no jauna un kāpēc.

Pieņemsim, ka sertificēts pakalpojums nomaina galveno incidentu pārvaldības platformu.

Formāli process joprojām saucas tāpat.

Bet var būt mainījušies:

• auditācijas logi;
• datu glabāšanas reģions;
• klientu segregācija;
• autentifikācija;
• privilēģētā piekļuve;
• evidence chain;
• integrācijas ar SIEM un EDR.

Šādā situācijā agrāks pierādījums var kļūt daļēji novecojis, pat ja organizācijas politika nav mainījusies.

Tāpēc certification evidence vajag sasaistīt ar konfigurāciju un laiku.

Savā EUMSS komentāru grid es piedāvāju, lai augsta assurance testēšanas pierādījumi skaidri fiksē testa datumu vai periodu, pārbaudīto pakalpojuma versiju/konfigurāciju, vidi, būtiskos ierobežojumus un remediēto atradumu retesta statusu.5

Tas nav birokrātijas papildinājums.

Tas pasaka, uz ko pierādījums vēl ir attiecināms.

Drošības finding dzīves ciklā ir vilinoši izmantot vienu statusu:

Open → In Progress → Done

Taču Done var nozīmēt ļoti dažādas lietas.

Izstrādātājs ir izmainījis kodu.

Firewall noteikums ir nomainīts.

IAM politika ir pārkonfigurēta.

Procedūra ir pārrakstīta.

Darbinieks ir apmācīts.

Neviena no šīm darbībām pati par sevi vēl nepierāda, ka sākotnējā problēma ir novērsta.

Tāpēc būtiskiem findingiem vajadzīga atsevišķa verification robeža:

kas būs pierādījums, ka korekcija ir nostrādājusi?

Dažos gadījumos tas būs tehnisks retests.

Citā — kontrolēts restore.

Citā — jauna incident simulation.

Citā — logu pārbaude pēc reālas darbības.

Citā — mērījums, ka false negative vai response delay tiešām samazinājies.

EUMSS publiskajā apspriešanā tieši šo formulēju kā atšķirību starp administrative closure un pierādījumu, ka paredzētais drošības outcome ir sasniegts.5

No otras puses, sertifikāciju nevajag pārvērst par prasību visu vienmēr pārtestēt.

Tas būtu dārgi un bieži bezjēdzīgi.

Retests ir īpaši vērtīgs, ja:

• finding bija materiāls;
• labojums mainīja drošības funkciju;
• iepriekšējais defekts bija praktiski ekspluatējams;
• izmaiņa skar sertifikācijas scope;
• remediation nav vienkārši verificējama dokumentāli;
• kļūda ir atkārtojusies;
• incidents liecina, ka kontrole varētu būt izgāzusies.

Maznozīmīgai dokumentācijas korekcijai pilna tehniskā atkārtota testēšana nav saprātīga.

Tāpēc labs modelis ir risk-based verification, ne “retest everything”.

Audita un assurance praksē noder viens vienkāršs nošķīrums.

Design effectiveness

Vai kontrole, ja to īsteno kā paredzēts, vispār spēj samazināt konkrēto risku?

Piemēram, ja mērķis ir novērst privileģēta konta pārņemšanu, parole ar 18 simboliem var būt labi definēta prasība, bet tā neatrisina phishing-resistant autentifikācijas vajadzību, ja draudu modelis ir phishing.

Operating effectiveness

Vai kontrole faktiski darbojas noteiktajā periodā un tvērumā?

MFA politika var būt ļoti laba uz papīra, bet daļai kontu tā var nebūt piemērota, var būt izņēmumi vai avārijas konti ar citu ceļu.

Abas dimensijas ir vajadzīgas.

Labi projektēta kontrole, kas netiek konsekventi izpildīta, nedod vajadzīgo assurance.

Konsekventi izpildīta kontrole ar vāju dizainu arī ne.

Incident response jomā aktivitātes ir viegli uzskaitīt.

• cik incidentu izskatīti;
• cik biļešu slēgtas;
• cik playbook atjaunināti;
• cik cilvēku apmācīti;
• cik lessons-learned meeting notikušas.

Šie skaitļi var būt vajadzīgi vadībai.

Tie ne vienmēr pasaka, vai pakalpojums kļuvis drošāks.

Piemēram, lessons-learned procesā var būt perfekta dokumentācija, bet tā pati kļūda atkārtoties nākamajā incidentā.

Tāpēc būtiskam improvement action der vēl viens jautājums:

Kā mēs zināsim, ka izmaiņa patiešām samazināja iepriekš konstatēto vājumu?

Savā EUMSS komentārā ierosināju material improvement actions gadījumā, kur tas saprātīgi izmērāms, pārbaudīt ne tikai izmaiņas ieviešanu, bet arī to, vai izmaiņa sasniedza paredzēto uzlabojumu.5

Tas nav tas pats, kas pieprasīt ROI metriku katrai kontrolei.

Tas nozīmē pārbaudīt paša drošības mērķa izpildi.

Sertifikācija parasti sākas ar plānotu novērtējumu.

Reāls incidents ir neplānots tests.

Ja pēc sertifikācijas notiek kritisks incidents, kurā izgāžas sertificētajam scope būtiska kontrole, rodas loģisks jautājums: vai sākotnējais assurance secinājums vēl ir pietiekams?

Atbilde nav automātiski “sertifikāts nederīgs”.

Incidents var būt:

• ārpus sertifikācijas scope;
• jauna uzbrukuma klase;
• klienta atbildības zonā;
• saistīts ar pilnīgi citu komponenti.

Taču dažreiz incidents tieši parāda, ka kontrolē, uz kuru balstījās assurance, ir būtiska problēma.

EUMSS draftā paredzēta special evaluation iespēja pēc būtiskiem notikumiem un neatbilstībām.3

Savā komentārā piedāvāju augsta assurance līmenī ieviest rebuttable trigger: kritisks breach vai materiāla neatbilstība, kas norāda uz sertifikācijai būtiskas kontroles iespējamu izgāšanos, izraisa special evaluation, ja vien CAB dokumentēti nepamato, kāpēc mērķēta pārbaude nav vajadzīga.5

Svarīga ir tieši pēdējā daļa.

Ne katrs incidents prasa pilnu recertification.

Bet būtisks incidents nedrīkst pazust starp ikgadējiem kalendāra datumiem tikai tāpēc, ka nākamā surveillance vēl nav pienākusi.

Vulnerability prioritisation un service assurance ir cieši saistīti ar laiku.

Threat environment mainās.

Ievainojamība, kuru pērn uzskatīja par zema riska, var kļūt aktīvi izmantota.

Mainās exposure.

Parādās jauns exploit.

Mainās service configuration.

Tāpēc vulnerability impact analysis nav vienreiz aizpildāms lauks.

Savā EUMSS komentārā ierosināju material vulnerability analysis pierādījumos saglabāt izmantotos draudu vai ievainojamību avotus, to retrieval/observation datumu, skarto service version/context un būtisku nenoteiktību.5

Šeit saikne ar ievainojamību prioritizācijas rakstu ir tieša: risku nevar korekti rekonstruēt, ja nav zināms, kādi signāli un kurā datumā bija pieejami lēmuma brīdī.

Organizācija var uzrādīt perfekti uzrakstītu vulnerability disclosure policy.

Assurance jautājums sākas nākamajā brīdī:

• vai ziņošanas kanālu kāds tiešām uzrauga;
• vai pētnieks saņem acknowledgement;
• vai finding tiek triage;
• vai tam ir owner;
• vai statusu var izsekot;
• vai kritisks ziņojums tiek eskalēts;
• vai remediation tiek koordinēta;
• vai finding tiek korekti aizvērts.

Tāpēc savā EUMSS komentārā piedāvāju CVD prasību sasaistīt ar operacionālu intake lifecycle, ne tikai publisku policy dokumentu.5

Šis ir labs piemērs plašākajai tēzei.

Dokuments pierāda, ka organizācijai ir politika. Process pierāda, ka organizācija kaut ko dara. Rezultāta pierādījums rāda, vai process izpilda savu drošības funkciju.

“Service restored” var nozīmēt tikai to, ka aplikācija atkal atbild.

Tas ne vienmēr nozīmē, ka atjaunots autoritatīvs stāvoklis.

Pēc degradēta vai manuāla režīma var būt:

• dublikāti;
• neizpildīti darījumi;
• pretrunīgi ieraksti;
• pagaidu pilnvarojumi;
• neatrisināts queued state;
• auditācijas pēdas nepilnības.

Tāpēc effectiveness pārbaude recovery gadījumā nav tikai uptime.

Tā var ietvert datu integritāti, reconciliation un atgriešanās kritērijus.

Šo tēmu detalizēti analizēju atsevišķi rakstā par drošu ierobežotas darbības režīmu.

EUMSS komentāros piedāvāju līdzīgu principu izmantot continuity prasībās: pēc degraded/manual operation salāgot ierakstus, queued actions un authorisations pirms sistēma atkal tiek uzskatīta par normāli darbojošos.5

EUMSS kandidātshēmas horizontālā un vertikālā struktūra ir praktiska.

Horizontālo kopīgo prasību pierādījumus var izmantot vairāk nekā vienam service profile, samazinot dublētu novērtēšanu.3

Tas ir īpaši svarīgi mazākiem pakalpojumu sniedzējiem.

Taču evidence reuse ir drošs tikai tad, ja var atbildēt:

• tas pats control tiešām attiecas uz jauno service profile;
• architecture nav būtiski mainījusies;
• evidence nav novecojis;
• nav noticis incidents, kas apšauba control;
• nav mainījies threat context;
• nav atšķirīgs deployment model;
• iepriekšējais finding ir verificēti aizvērts.

Pretējā gadījumā “reuse” kļūst par “copy-paste assurance”.

Sertifikācijas efektivitāte nav maksimāla dokumentu daudzuma sinonīms.

Dažreiz labākais modelis ir tieši pretējs: mazāk pierādījumu, bet skaidri sasaistīti ar konkrētu claim, scope, konfigurāciju un freshness.

Pircējam sertifikāts var būt ļoti vērtīgs.

Tas var samazināt atkārtotu due diligence un dot neatkarīgu assurance par konkrētu scope.

Taču piegādātāja izvēlē es pēc sertifikāta vēl prasītu:

Tas nenozīmē “sertifikātam nevar uzticēties”.

Tas nozīmē sertifikātu lasīt tā, kā tas ir paredzēts — kā scoped assurance, ne universālu reputācijas zīmogu.

2025. gada grozījumi Eiropas Kiberdrošības aktā paplašināja Eiropas sertifikācijas ietvaru, lai tajā varētu iekļaut managed security services.2

2026. gada 24. jūlijā ENISA publicēja EUMSS kandidātshēmas v1.1 projektu publiskai apspriešanai. Projekts izmanto horizontālo bāzes prasību un vertikālo service-profile modeli un pirmajā versijā fokusējas uz Incident Response.3

Šai shēmai ir reāla nākotnes nozīme. Cyber Solidarity Act paredz, ka EU Cybersecurity Reserve izmantotajiem trusted managed security service providers, kad EUMSS shēma būs spēkā, divu gadu laikā no shēmas piemērošanas sākuma būs jābūt sertificētiem atbilstoši tai.4

Tieši tāpēc EUMSS nav tikai vēl viens audit framework.

Tas var kļūt par vienu no Eiropas pārrobežu incident response uzticības mehānismiem.

Un tieši tāpēc jautājums “vai kontrole eksistē?” ir par mazu.

2026. gada 24. augustā EUMSS public review iesniedzu detalizētu komentāru kopu un 10 konkrētus drafting proposals.5

Tie aptvēra:

• test evidence piesaisti konkrētai service version/configuration un testa periodam;
• auditable timestamps material event notification procesam;
• threat/vulnerability source provenance un freshness;
• residual vulnerability ownership un event-based reassessment;
• CVD kā operacionālu intake lifecycle;
• degraded/minimum-service režīmu;
• reconciliation pirms atgriešanās normālā režīmā;
• material remediation verification un retesting;
• improvement effectiveness pārbaudi;
• special evaluation trigger pēc būtiska breach vai control failure.

Šie priekšlikumi nav ENISA pieņemta politika.

Tie ir komentāri EUMSS kandidātshēmas apspriešanā.

Uz 2026. gada 25. septembri ENISA publiski joprojām norāda EUMSS v1.1 kā draft candidate scheme; konsultācijas termiņš bija 13. septembris, un galīgā shēma vēl nav pieņemta.3

Šo statusu ir svarīgi nesajaukt ar spēkā esošu sertifikācijas pienākumu.

Organizācijai nav jāgaida sertifikācijas shēma, lai šo pašu disciplīnu izmantotu iekšēji.

Vienam materiālam control var pietikt ar īsu ierakstu:

Svarīgākais lauks nav status: compliant.

Svarīgākie ir:

ko kontrolei bija jāsasniedz;

kā to pārbaudīja;

uz kuru scope un konfigurāciju rezultāts attiecas;

kas anulēs šo secinājumu.

Tas ir daudz grūtāk nekā checkbox.

Tieši tāpēc tas dod lielāku assurance.

Kiberdrošības sertifikācija ir vērtīga, ja tā precīzi ierobežo savu apgalvojumu un sasaista to ar pārbaudāmu pierādījumu.

Politika pierāda, ka kaut kas ir definēts.

Konfigurācija pierāda, ka kaut kas ir ieviests.

Logi un izpildes vēsture pierāda, ka kaut kas darbojas.

Efektivitātes tests palīdz pamatot, ka kontrole dara to, ko no tās sagaidām konkrētā riska kontekstā.

Un material change, incidents vai jauns threat context var nozīmēt, ka agrāks pierādījums ir jāpārbauda vēlreiz.

Tāpēc nobriedis certification modelis nemēģina apsolīt “drošību”.

Tas dara ko noderīgāku:

pasaka, ko mēs pārbaudījām, cik dziļi pārbaudījām, ko pierādījums atbalsta un kad šo secinājumu vajag atvērt no jauna.

Juridiskais un institucionālais statuss pārbaudīts 2026. gada 25. septembrī. EUMSS ir kandidātshēmas projekts, ne spēkā esoša Eiropas sertifikācijas shēma. Rakstā lietotais četru pierādījumu līmeņu modelis un control-effectiveness record ir autora praktiska assurance metode, ne ES normatīvi noteikta forma.

Šis raksts ir kiberdrošības assurance, sertifikācijas un kontroles efektivitātes analīze, nevis individuāla juridiska konsultācija.