Ievads
Drošības findings ir atvērts.
Komanda uzraksta fix.
Tickets tiek pārvietots uz Resolved.
Vadībai dashboardā kļūst par vienu sarkanu punktu mazāk.
Vai risks ir novērsts?
Ne obligāti.
Var būt, ka:
- fix vēl nav produkcijā;
- remediation sedz tikai vienu simptoma variantu;
- compensating control darbojas tikai daļā scope;
- retests nav veikts;
- residual risk ir būtisks;
- risku faktiski neviens nav apzināti pieņēmis;
- vai “Closed” vienkārši nozīmē, ka workflow beidzās.
Šeit sākas atšķirība starp drošības aktivitāti un pierādāmu drošības pārvaldību.
Organizācija nav atbildīga tikai par to, lai tai būtu:
- politika;
- risku reģistrs;
- SOC;
- pentesti;
- CVD;
- incidentu plāns.
Tai jāspēj rekonstruēt arī lēmumu:
Ko mēs zinājām, kādu risku konstatējām, ko izdarījām, ar ko pārbaudījām rezultātu un kurš pieņēma to risku, kas palika pāri?
To es sauktu par security evidence & accountability problēmu.
Regulējums arvien skaidrāk paceļ kiberdrošību līdz vadības atbildības līmenim
NIS2 20. pants prasa dalībvalstīm nodrošināt, ka būtisko un svarīgo vienību vadības struktūras apstiprina 21. pantā paredzētos kiberdrošības riska pārvaldības pasākumus, uzrauga to īstenošanu un noteiktajā nacionālo tiesību ietvarā var tikt sauktas pie atbildības par pārkāpumiem.1
Tas ir būtisks signāls.
Kiberdrošības risks nav tikai:
CISO problēma.
DORA finanšu sektorā formulējums ir vēl tiešāks. Finanšu vienības vadības struktūrai jādefinē, jāapstiprina, jāuzrauga un jāuzņemas atbildība par IKT riska pārvaldības sistēmas īstenošanu; tai ir arī galīgā atbildība par IKT risku un atbilstoša riska tolerances līmeņa noteikšanu.2
Latvijas Nacionālās kiberdrošības likuma 25. pants savukārt nosaka, ka subjekta kiberdrošības pārvaldību nodrošina un par to atbild subjekta vadītājs, bet kiberdrošības pārvaldnieks īsteno un pārrauga kiberdrošības pasākumus.4
Šie modeļi juridiski nav identiski.
Tomēr to kopīgais pārvaldības princips ir skaidrs:
tehniskās drošības funkcija palīdz pārvaldīt risku; gala atbildība nepazūd tikai tāpēc, ka organizācijā ir nosaukts drošības speciālists.
“Owner” ir bīstami neskaidrs vārds
Drošības procesos bieži redz vienu lauku:
Owner: Alice
Tas var nozīmēt piecas pilnīgi dažādas lietas.
Finding owner
Persona, kas vada konkrētā findinga apstrādi.
Remediation owner
Persona vai komanda, kas ievieš labojumu.
Control owner
Persona, kas atbild par konkrētās kontroles dizainu un darbību.
Risk owner
Persona, kuras atbildībā ir biznesa vai pakalpojuma risks un kura var pieņemt lēmumu par atlikušā riska apstrādi savas pilnvaras robežās.
Decision authority
Persona vai institūcija ar tiesībām apstiprināt konkrētā riska pieņemšanu, exception vai citu lēmumu.
Dažkārt viena persona pilda vairākas lomas.
Tas nenozīmē, ka lomas jāsapludina semantiski.
Īpaši kritisks ir šis nošķīrums:
persona, kura ieviesa fix, nedrīkst automātiski kļūt arī par vienīgo personu, kura pierāda, ka fix ir efektīvs, un vienlaikus pieņem atlikušo biznesa risku.
NIST CSF 2.0 tieši izceļ governance un accountability
NIST Cybersecurity Framework 2.0 pievienoja atsevišķu GOVERN funkciju, lai kiberdrošības risku pārvaldība tiktu sasaistīta ar uzņēmuma pārvaldību, lomām, atbildībām, pilnvarām, politiku un uzraudzību.5
CSF 2.0 apakškategorija GV.RR-01 formulē organizācijas vadības atbildību par kiberdrošības risku, bet GV.RR grupa kopumā prasa skaidri noteikt un komunicēt lomas, atbildības un pilnvaras.6
Tas nenozīmē, ka NIST dod vienu universālu RACI matricu.
Tieši pretēji — ietvars ir outcome-based.
Organizācijai pašai jāspēj pierādīt, ka tai ir saprotams atbildības modelis.
claim
→ source
→ scope
→ timestamp
→ integrity/provenance
→ limitations
→ expiry / review conditionEvidence var būt pretrunīgs
Nobriedušā pārvaldībā nav jābaidās no stāvokļa:
CONFLICT
Piemēram:
- control owner saka, ka backup ir testēts;
- change record rāda veiksmīgu backup job;
- restore test izgāžas;
- biznesa continuity plāns joprojām pieņem, ka RTO ir divas stundas.
Šeit pareizais secinājums nav:
“mums ir trīs pozitīvi dokumenti un viens negatīvs tests, tātad kopumā PASS.”
Pareizais secinājums ir:
evidence par kontroli ir konfliktējošs; effectiveness nav pietiekami pierādīta.
Drošības pārvaldībai vajag spēju saglabāt ne tikai supporting evidence, bet arī contradictory, stale un missing evidence.
DESIGNED
→ kontrole definēta
IMPLEMENTED
→ kontrole tehniski/procedurāli ieviesta
OPERATING
→ ir atkārtots evidence, ka tā tiek izpildīta
EFFECTIVE
→ tests rāda, ka tā samazina paredzēto risku
CONTINUOUSLY ASSURED
→ efektivitāti regulāri atbalsta monitoring/testēšanaResidual risk nedrīkst būt viens vārds: “Accepted”
Pēc kontroles ieviešanas risks reti kļūst par nulli.
Atlikušajam riskam vajag saturu.
Labs residual-risk statement atbild:
- kāds scenārijs vēl ir iespējams;
- kāda ietekme paliek;
- kas nav pilnībā nosegt;
- kuri pieņēmumi joprojām ir neskaidri;
- kādi compensating controls darbojas;
- ko monitorē;
- kurš risku pārvalda;
- kad lēmums jāpārskata.
Vājš residual-risk ieraksts:
Nobriedušāks:
Tas ir lēmums.
Ne krāsains lauks.
Residual risk: Medium
Status: AcceptedScenario:
privileged session theft remains possible if
hardware-backed MFA is bypassed through an unmanaged recovery flow.
Current controls:
- phishing-resistant MFA for administrators
- conditional access
- privileged-session logging
Known limitation:
legacy recovery path remains active for 14 accounts.
Decision:
temporary acceptance until migration completion.
Owner:
business service owner
Expiry:
2027-01-31
Reassessment triggers:
- recovery-path abuse
- new exploit technique
- migration delayRisk acceptance ir darbība, ne statusa etiķete
Risku pieņemt nozīmē:
mēs saprotam, kas paliek, un apzināti turpinām darbību ar šo risku noteiktā periodā un noteiktos nosacījumos.
Tāpēc acceptance vajag vismaz:
- precīzu scope;
- residual risk;
- pamatojumu;
- alternatīvas;
- decision authority;
- compensating controls;
- termiņu;
- monitoring;
- pārskatīšanas triggerus;
- expiry.
Bez expiry pagaidu exception mēdz kļūt par arhitektūru.
Bez triggeriem pieņēmums turpina dzīvot arī tad, kad realitāte mainījusies.
Security komanda konsultē. Bizness nevar paslēpties aiz security komandas.
Drošības funkcija var pateikt:
ievainojamība dod iespēju pārņemt citu tenant datus.
Tā var arī novērtēt:
- exploitability;
- evidence kvalitāti;
- kontroles efektivitāti;
- tehniskās remediation iespējas.
Bet lēmums:
“mēs nākamos četrus mēnešus turpināsim šo biznesa procesu ar šādu atlikušo risku”
bieži ir biznesa vai pakalpojuma risk ownership jautājums.
Security var ieteikt.
Risk owner pieņem vai eskalē atbilstoši deleģētajām pilnvarām.
Šī robeža ir svarīga arī pretējā virzienā:
biznesa vadītājs nevar vienkārši deklarēt:
“es risku pieņemu”
ja organizācijas policy vai tiesību akti konkrēto stāvokli nepieļauj.
Risk acceptance nav tiesības apiet ne-waivable prasības.
NIST RMF atgādina, ka authorization ir uz pierādījumiem balstīts riska lēmums
NIST SP 800-37 Rev. 2 apraksta strukturētu Risk Management Framework, kur kontroles tiek izvēlētas, ieviestas, novērtētas un uzraudzītas, bet senior leaders saņem informāciju riskā balstītu authorization lēmumu pieņemšanai.7
Svarīgais nav konkrētais ASV federālais process.
Svarīga ir konstrukcija:
Tas ir daudz nobriedušāks par:
control implementation
→ assessment
→ evidence
→ risk decision
→ monitoringcontrol documented
→ approvedRemediation owner nedrīkst pats sev izsniegt closure bez pierādījuma
Finding lifecycle bieži beidzas šādi:
Developer: fixed. Jira: Done.
Bet kas tika pārbaudīts?
Labs closure modelis nošķir:
Remediation evidence
Kas faktiski tika mainīts?
- commit;
- configuration;
- release;
- architecture change;
- compensating control;
- service retirement.
Deployment evidence
Vai fix sasniedza vidi, kur vulnerability reāli eksistēja?
Verification evidence
Vai sākotnējais security condition vairs nav reproducējams?
Residual-risk evidence
Kas paliek pāri?
Closure authority
Kurš drīkst pateikt, ka jautājums ir pietiekami novērsts vai atlikušais risks apzināti pieņemts?
Šo pašu principu detalizēti attīstīju CVD dzīves cikla rakstā.
FIXED
MITIGATED
WORKAROUND
RISK_ACCEPTED
DEFERRED
BLOCKED_EXTERNALReassessment trigger ir tikpat svarīgs kā sākotnējais lēmums
Risk lēmumi balstās pieņēmumos.
Tie var zaudēt derīgumu.
Tipiski triggeri:
- būtisks incidents;
- atkārtots findings;
- jauns exploits;
- kontroļu kļūme;
- piegādātāja maiņa;
- termiņa kavējums;
- būtiska arhitektūras izmaiņa;
- jauns regulatorais pienākums;
- risk tolerance maiņa.
DORA labi ilustrē šo principu: IKT riska pārvaldības sistēma ir regulāri jāpārskata un jāuzlabo arī pēc būtiskiem IKT incidentiem, testēšanas un auditu secinājumiem.3
Tātad governance nav tikai lēmuma pieņemšana.
Tā ir arī spēja atpazīt, kad vecais lēmums vairs nav derīgs.
Auditability nenozīmē ierakstīt visu
Te var pārregulēt.
Ja katram low-risk findingam vajag 14 cilvēku parakstītu 30 lauku protokolu, sistēma kļūs dārgāka par risku, kuru tā pārvalda.
Evidence depth jābūt proporcionālam:
- materialitātei;
- potenciālajam kaitējumam;
- neatgriezeniskumam;
- normatīvajam riskam;
- lēmuma dzīves ilgumam;
- trešo personu ietekmei.
Svarīgs princips:
proportionality samazina record depth, nevis atceļ accountability.
Mazs risks var prasīt īsu ierakstu.
Kritisks un ilgstoši pieņemts risks — daudz detalizētāku.
Decision record: minimums, ko es saglabātu būtiskam drošības lēmumam
Manā modelī būtisks security decision record saturētu:
Tas nav NIS2, DORA vai NIST obligāts datu modelis.
Tā ir autora piedāvāta Security Decision Record struktūra.
decision:
id:
date:
question:
scope:
risk:
scenario:
affected_assets:
inherent_or_current_risk:
residual_risk:
unknowns:
evidence:
supporting:
contradictory:
missing:
last_verified:
options:
- fix
- mitigate
- avoid
- defer
- accept
decision:
selected:
rationale:
conditions:
authority:
risk_owner:
treatment:
remediation_owner:
due_date:
compensating_controls:
verification:
method:
verifier:
result:
reassessment:
review_date:
triggers:
expiry:Kāpēc vajag arī contradictory un missing evidence
Lēmumu vēsture kļūst neuzticama, ja tajā glabā tikai to, kas apstiprina izvēlēto lēmumu.
Piemēram:
Ja lēmuma ierakstā paliek tikai pirmais punkts, nākamais pārskatītājs saņem mākslīgi uzlabotu realitāti.
Accountability prasa saglabāt arī nenoteiktību.
Supporting:
WAF blocks known payload.
Contradictory:
manual test bypasses WAF using alternate encoding.
Missing:
no evidence for mobile API path.Exception un waiver vajag beigu datumu
Drošības waiver parasti sākas pamatoti:
migration not yet possible.
Pēc diviem gadiem tas var kļūt par:
everybody forgot why this exists.
Tāpēc waiver ierakstam vajag:
- waived requirement;
- exact scope;
- rationale;
- compensating control;
- residual risk;
- approver;
- start;
- expiry;
- monitoring;
- closure criterion.
Ja exception tiek regulāri pagarināts, tas ir cits signāls:
iespējams, organizācijai nav īslaicīga exception — tai ir strukturāls design debt.
Outsourcing nepārvieto gala accountability
Vendor var būt atbildīgs par:
- patch;
- SaaS kontroli;
- SOC pakalpojumu;
- cloud konfigurāciju;
- pentestu.
Tas nenozīmē, ka organizācija var teikt:
“Vendor pieņēma risku mūsu vietā.”
DORA vadības modelis īpaši uzsver, ka finanšu vienības vadības struktūrai saglabājas galīgā atbildība par IKT risku.2
Plašāks princips attiecas arī ārpus DORA:
responsibility for performing a control can be outsourced; organisational accountability for the resulting business risk usually cannot be wished away.
Līgums maina pienākumu un risku sadalījumu.
Tas neatceļ vajadzību zināt, ko organizācija pati ir pieņēmusi.
Security dashboardam jāparāda lēmuma kvalitāte, ne tikai findingu skaits
Vadībai maz palīdz:
Ja nav redzams:
- kuriem nav owner;
- kuri kavēti;
- kuri ir tikai mitigated;
- kuriem nav retest;
- kuri ir risk accepted;
- kuri acceptance tuvojas expiry;
- kuriem evidence ir stale;
- kuri atkārtojas pēc closure.
Daudz noderīgāks dashboard var rādīt:
Tas pārvērš governance no statusu uzskaites par lēmumu kvalitātes uzraudzību.
Open vulnerabilities: 123
Critical: 4
High: 17Critical findings without accountable owner
High findings overdue beyond accepted treatment date
Accepted risks expiring in 30 days
Closures without independent/risk-based verification
Controls with stale effectiveness evidence
Repeat root causes after prior closureDrošības metriķim jābūt piesaistītam lēmumam
“Patch compliance 96%” izklausās labi.
Bet vadībai jāzina:
- kuri 4% nav patchoti;
- vai tie ir internet-facing;
- vai tie satur aktīvi ekspluatētas vulnerabilities;
- vai ir compensating controls;
- kurš pieņēma atlikšanu.
Tātad labs metrics nav tikai:
96%
Tas ir:
Pretējā gadījumā KPI kļūst par dekorāciju.
metric
+ population
+ exclusions
+ risk context
+ owner
+ action thresholdPiecu daļu security evidence chain
Es visu rakstu reducētu līdz piecām daļām:
1. Evidence
Ko mēs faktiski zinām?
2. Context
Ko šis evidence nozīmē konkrētam aktīvam, pakalpojumam un biznesam?
3. Decision
Kas tika nolemts, kāpēc un kam bija tiesības to izlemt?
4. Outcome
Kas reāli tika ieviests un vai tas nostrādāja?
5. Reassessment
Kas liks mums šo lēmumu pārskatīt?
Ja viena no daļām pazūd, governance kļūst vājš.
Īpaši bieži pazūd 4. un 5.
Organizācija labi dokumentē:
ko mēs plānojām darīt.
Daudz sliktāk:
vai tas faktiski samazināja risku un kad šis secinājums jāpārbauda vēlreiz.
Secinājums
Kiberdrošības pārvaldība nav laba tāpēc, ka organizācijai ir daudz kontroles dokumentu.
Tā nav laba arī tāpēc, ka dashboardā ir maz atvērtu findingu.
Tā ir laba, ja būtiskam drošības lēmumam var rekonstruēt ķēdi:
evidence → context → authority → treatment → verification → residual risk → reassessment.
Tas maina vienu būtisku jautājumu.
Ne:
“Vai findings ir aizvērts?”
Bet:
“Ko tieši mēs pierādījām, kurš pieņēma to risku, kas palika pāri, un kas liks mums šo lēmumu atvērt no jauna?”
Tā ir atšķirība starp security administration un security accountability.
Un tieši ar šo atšķirību noslēdzas arī plašāks drošības assurance cikls:
atrast → saprast → izlemt → labot → pārbaudīt → pieņemt atlikušo risku → mācīties.
Biežāk uzdotie jautājumi
Vai CISO drīkst pieņemt residual risk?
Tas atkarīgs no organizācijas deleģētajām pilnvarām un piemērojamā regulējuma. Drošības funkcija var analizēt un ieteikt risk treatment, bet būtiska biznesa/pakalpojuma riska pieņemšana bieži pieder atbildīgajam risk owner vai augstākai decision authority.
Vai findings ir slēgts, ja patch ir izstrādāts?
Ne obligāti. Jāzina, vai labojums sasniedza skarto vidi, vai tas novērš sākotnējo security condition un kas paliek kā residual risk.
Vai risk acceptance var būt bez termiņa?
Dažos risku veidos pastāvīgs lēmums var būt iespējams, bet pagaidu exception un atliktas remediation gadījumā expiry un reassessment triggers ir būtiski, lai pieņēmums nekļūtu par nekontrolētu pastāvīgu stāvokli.
Vai management approval nozīmē, ka vadībai pašai jāsaprot exploit tehniskās detaļas?
Nē. Vadībai nav jākļūst par pentesteriem. Tai jāsaņem pietiekams, uzticams un saprotams evidence par risku, alternatīvām, sekām un atlikušajiem nezināmajiem, lai pieņemtu lēmumu savas atbildības robežās.
Vai vendor var pieņemt mūsu risku?
Vendor var uzņemties līgumiskas saistības un atbildēt par savu kontroļu izpildi. Tas pats par sevi nepārvieto organizācijas gala pārvaldības atbildību par savu pakalpojumu un biznesa risku.
Vai auditability nozīmē dokumentēt katru mazu drošības lēmumu vienādi detalizēti?
Nē. Record depth jābūt proporcionālam riskam, ietekmei, neatgriezeniskumam un regulatīvajām prasībām. Proporcionalitāte samazina detalizāciju; tā neatceļ vajadzību pēc owner, lēmuma un pietiekama evidence.
Avotu statuss
Avoti un juridiskais statuss pārbaudīti 2026. gada 25. septembrī. Šajā rakstā izmantotie Security Decision Record, piecu daļu evidence chain, control-effectiveness skala, waiver/closure lauki un lomu nošķīrums ir autora analītisks pārvaldības modelis. Tie nav NIS2, DORA, NIST vai Latvijas Nacionālā kiberdrošības likuma obligāta datu shēma.
Šis raksts ir kiberdrošības governance, assurance un risk-accountability analīze, ne individuāls juridisks vai audita atzinums.
Avoti
- Eiropas Parlamenta un Padomes Direktīva (ES) 2022/2555 (NIS2), īpaši 20.–21. pants · EUR-Lex
- Eiropas Parlamenta un Padomes Regula (ES) 2022/2554 (DORA), īpaši 5.–6. pants par vadību un IKT riska pārvaldības sistēmu · EUR-Lex
- Regula (ES) 2022/2554, 6. panta 5. punkts par IKT riska pārvaldības sistēmas dokumentēšanu, periodisku pārskatīšanu un uzlabošanu pēc incidentiem, testēšanas un auditu secinājumiem · EUR-Lex
- Nacionālās kiberdrošības likums, īpaši 25. pants par subjekta vadītāja un kiberdrošības pārvaldnieka kompetenci, redakcija pārbaudīta 25.09.2026 · Likumi.lv
- NIST, Cybersecurity Framework (CSF) 2.0, 26.02.2024 · NIST
- NIST CSF 2.0 Core, GOVERN — Roles, Responsibilities, and Authorities (GV.RR), tostarp GV.RR-01 un GV.RR-02 · NIST
- NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations, Final, December 2018 · NIST