Drošības izpēte kritiskajās sistēmās: atvērta ziņošana nenozīmē atvērtu testēšanu

Kā saglabāt neatkarīgu drošības pētnieku pienesumu, nepadarot augsta kaitējuma production vidi par nekontrolētu testēšanas laukumu.

Zigmārs AncveirsTechnology Leader in FinTech & RegTech · Cybersecurity & Ethical HackingPublicēts: 2026. gada 26. septembrīPārskatīts: 2026. gada 26. septembrī12 min

Ievads

Drošības pētnieks atrod aizdomīgu endpointu publiski pieejamā slimnīcas, bankas, elektroenerģijas uzņēmuma vai transporta sistēmā.

Ko darīt tālāk?

Vienkāršā tīmekļa lietotnē vēl viens kontrolēts pieprasījums var būt samērā zema riska darbība.

Citā sistēmā tas pats princips var:

izmainīt ārstniecības procesa datus;
ietekmēt maksājumu vai norēķinu plūsmu;
bloķēt autentifikāciju;
aktivizēt drošības automātiku;
pārslogot iekārtu;
ietekmēt trešās puses;
radīt kaskādes sekas ārpus paša testējamā servisa.

Tāpēc “atļaut security research” nav binārs politikas lēmums.

Pareizais jautājums ir:

Kādu pētniecības darbību konkrētā sistēma var droši paciest, kāds evidence ir vajadzīgs un cik stingrai jābūt testēšanas kontrolei?

Šeit ir svarīgs arī otrs princips:

atvērts vulnerability-reporting kanāls nenozīmē, ka visam production scope jābūt atvērtam aktīvai testēšanai.

CVD var būt publisks.

Aktīvās testēšanas tiesības var būt diferencētas.

Tieši kritiskās un augsta kaitējuma sistēmās šis nošķīrums ir īpaši svarīgs.

“Kritiska sistēma” nav viens juridisks statuss

Vispirms terminoloģija.

ES regulējumā blakus pastāv vairāki atšķirīgi jēdzieni.

NIS2 izmanto “essential” un “important” entities un Annex I definē sectors of high criticality, tostarp enerģētiku, transportu, bankas, finanšu tirgus infrastruktūru, veselību, dzeramo ūdeni, notekūdeņus, digitālo infrastruktūru, IKT pārvaldītos pakalpojumus, kosmosu un publisko pārvaldi.1

Critical Entities Resilience Directive (CER) paredz dalībvalstu identificētas critical entities, kas sniedz būtiskus pakalpojumus vitāli svarīgu sabiedrības funkciju, ekonomiskās darbības, sabiedrības veselības, drošības vai vides uzturēšanai.2

DORA finanšu sektoram nosaka atsevišķu digitālās darbības noturības un, izraudzītām vienībām, threat-led penetration testing režīmu.3

Šīs kategorijas pārklājas, bet nav sinonīmi.

Arī tehniski kritiska sistēma var nebūt atsevišķi nosaukta “critical entity” statusā.

Piemēram, neliela komponenta atteice var kļūt kritiska tāpēc, ka tas ir vienīgais autentifikācijas, dispečervadības vai datu integritātes mezgls daudz lielākā pakalpojumā.

Tāpēc šajā rakstā “kritiska sistēma” ir riska un potenciālā kaitējuma kategorija, ne mēģinājums aizvietot konkrētu juridisko kvalifikāciju.

Kritiskums maina ne tikai vulnerability prioritāti, bet arī paša testa risku

Security testing parasti domā par vulnerability risku.

Kritiskajās sistēmās tikpat svarīgs ir testing risk.

Tie ir divi dažādi jautājumi.

Piemēram, teorētiski ļoti nopietnu race condition var būt bīstami pierādīt produkcijā.

Savukārt read-only autorizācijas kļūdu var būt iespējams demonstrēt ar vienu minimālu requestu bez būtiska pakalpojuma riska.

Tāpēc testēšanas režīmu nedrīkst izvēlēties tikai pēc CVSS vai iespējamās vulnerability severity.

Jāvērtē arī:

pieejamības jutīgums;
datu integritātes jutīgums;
fiziskā/sabiedriskā drošība;
datu sensitivitāte;
kļūdas reversējamība;
blast radius;
trešo pušu ietekme;
kaskādes risks;
recovery iespējas;
testēšanas novērojamība;
regulatora vai citas kompetentas iestādes prasības.

vulnerability risk:
kas notiek, ja ievainojamību izmanto īsts uzbrucējs?

testing risk:
kas var notikt tikai tāpēc, ka mēs mēģinām to pierādīt?

Publisks CVD var pastāvēt arī tad, ja aktīvā testēšana ir ļoti šaura

Šis nošķīrums praksē jau eksistē.

Latvijas Bankas publiskā ievainojamību atklāšanas politika atļauj pētniekiem pārbaudīt konkrēti nosauktas publiskas tīmekļvietnes — bank.lv, e-monetas.lv un naudasskola.lv — un vienlaikus skaidri norāda, ka citu Latvijas Bankas resursu un sistēmu testēšana šīs iniciatīvas ietvaros nav atļauta.7

Politika papildus aizliedz:

social engineering;
vairāk datu iegūšanu par stingri nepieciešamo minimumu;
datu dzēšanu vai mainīšanu;
DoS/DDoS;
robotizētu paroļu minēšanu.7

Ja pētnieks saskaras ar identificējošu, finanšu vai komercnoslēpuma informāciju, testēšana jāpārtrauc un jāsazinās ar Latvijas Banku.7

Šis ir labs piemērs principam:

Tas nav pretrunīgi.

Tas ir diferencēts risk modelis.

public vulnerability intake
+
limited public test scope
+
sensitive/core systems outside public testing scope

CERT.LV 2026. gada noteikumi pastiprina minimālās ietekmes principu

CERT.LV 2026. gada augustā atkārtoti uzsvēra, ka ētiska ievainojamību testēšana neietver DoS/DDoS, ja vien konkrētā programma to nav nepārprotami atļāvusi, un vulnerability demonstrēšanai jāizmanto minimālais nepieciešamais pieprasījumu un darbību apjoms.6

Platformas noteikumi prasa pētniekam samērot metodes un intensitāti ar resursa veiktspēju un neradīt kaitējumu resursam vai tā pārzinim.5

Šis princips ir svarīgs visur.

Kritiskā sistēmā tas kļūst par centrālo dizaina prasību.

PoC mērķis ir iegūt pietiekamu pierādījumu, nevis maksimāli demonstrēt teorētiski iespējamo kaitējumu.

Atvērta pētniecība nav vienīgais modelis

Publiska VDP/CVD politika ir ļoti vērtīga.

Taču “public CVD” un “ikviens drīkst aktīvi testēt visu” nav viens jēdziens.

Augstāka riska sistēmām var izmantot vairākus piekļuves profilus.

Es tos neuzskatītu par brieduma līmeņiem.

Tie ir atšķirīgi riska režīmi.

1. Report-only / passive discovery

Ikviens var ziņot par:

nejauši pamanītu problēmu;
publisku konfigurācijas kļūdu;
exposed secret;
noplūdušu dokumentu;
publiski redzamu security weakness.

Aktīva ekspluatācijas validācija nav autorizēta.

Tas ir minimums sistēmām, kur pat neliela aktīva pārbaude var radīt nepieņemamu risku.

2. Public low-impact testing

Publiski atļautas konkrētas metodes un konkrēti aktīvi:

parasti tīmekļa/API virsma;
minimāls PoC;
bez DoS;
bez datu izmaiņām;
bez persistence;
bez social engineering.

Tas ir klasisks VDP/CVD profils.

3. Registered research

Pirms plašākas testēšanas pētnieks:

reģistrējas;
pieņem papildu noteikumus;
norāda kontaktinformāciju;
saņem testa identifikatoru;
izmanto piešķirtus kontus vai test data;
ievēro rate limits un konkrētu test window.

Tas palielina operacionālo kontroli, vēl nepadarot procesu par tradicionālu pentestu.

4. Vetted / invitation-only research

Piekļuve sensitīvākam scope tiek dota pētniekiem, kuru:

identitāte pārbaudīta;
pieredze vai kompetence ir zināma;
iepriekšējā darba kvalitāte ir pierādīta;
noteikumi un evidence handling ir skaidri pieņemti.

Tas var būt private bounty vai cita kontrolēta pētniecības programma.

5. Controlled professional testing

Augsta riska darbībām:

iepriekš apstiprināts test plan;
noteikts laika logs;
test accounts / synthetic data;
monitoring;
control team;
emergency stop;
explicit escalation;
rollback/recovery readiness;
pēc testa cleanup un retest.

Finanšu sektorā DORA TLPT ir īpašs, daudz formalizētāks šādas loģikas piemērs, nevis universāla šī profila definīcija.3 4

Kritiska sistēma var izmantot vairākus profilus vienlaikus

Svarīgākais ir neklasificēt visu organizāciju ar vienu režīmu.

Piemēram:

Šis modelis ir daudz precīzāks par:

“kritiskai infrastruktūrai bounty ir par bīstamu”

vai

“ja sistēma ir internetā, researchers drīkst testēt visu”.

Abi apgalvojumi ir pārāk plaši.

public information website
→ public low-impact CVD

customer self-service portal
→ registered/private bounty

administrative back office
→ invitation-only testing

core transaction / control system
→ controlled professional test

unexpected vulnerability anywhere
→ report channel always available

Test window ir kontrole, ne formalitāte

Augsta riska production sistēmā testēšanas laiks var būt tikpat svarīgs kā metode.

Piemēram, finanšu vai transporta sistēmā nav viens un tas pats:

testēt zemas slodzes periodā;
testēt payroll/settlement/booking maksimumā;
testēt laikā, kad notiek infrastruktūras migrācija;
testēt incidenta laikā.

Kontrolēts test window ļauj:

nodrošināt vajadzīgo personālu;
uzraudzīt sistēmas veselību;
atšķirt testēšanas telemetry no īsta uzbrukuma;
ātri apturēt darbu;
atjaunot stāvokli.

Tas nenozīmē, ka katrs security test ir jāizziņo visai blue team.

Dažiem red-team scenārijiem slepenība ir daļa no testa.

Bet arī tad jābūt kontroles funkcijai, kura zina, ka tests eksistē un var to apturēt.

DORA TLPT parāda, cik nopietni jāuztver testēšanas radītais risks

Komisijas Deleģētā regula (ES) 2025/1190 paredz, ka TLPT control team jau sagatavošanas fāzē novērtē riskus, kas rodas, testējot live production sistēmas, tostarp iespējamo ietekmi uz finanšu vienību, trešajām pusēm un finanšu sektoru.4

Regula tieši aptver riskus, kas saistīti ar:

sensitīvas informācijas nodošanu testerim;
incidentu un krīzes eskalāciju;
kritisku darbību pārtraukumu;
datu bojāšanu;
ietekmi uz trešajām pusēm;
nepilnīgu sistēmu atjaunošanu pēc testa.4

Ārkārtas risku gadījumā testu var apturēt; noteiktos apstākļos iespējams pāriet uz ierobežotu purple-team režīmu.4

Šeit ir vispārināms princips:

augsta realism testam vajag tikpat nopietnu safety engineering kā pašam testējamajam pakalpojumam.

Emergency stop jābūt tehniskam, ne tikai juridiskam

Rules of engagement var rakstīt:

“testu nekavējoties pārtrauc pēc organizācijas pieprasījuma”.

Tas ir nepieciešams.

Bet nepietiekams.

Jābūt skaidram:

kurš drīkst dot stop komandu;
kā testeris to saņem;
cik ātri viņš to pamanīs;
ko tieši aptur;
vai jāatsauc sessions/tokens;
kā tiek izņemta persistence;
kā tiek atjaunoti mainītie dati;
kas pārbauda, ka cleanup pabeigts.

Augsta riska testā emergency stop ir operacionāls protokols.

Ne līguma teikums.

Identitātes pārbaude nav quality proof

Vetted programme var prasīt:

identitātes pārbaudi;
iepriekšēju pieredzi;
platformas reputāciju;
references;
NDA;
specifisku kompetenci.

Tas var samazināt dažus riskus.

Taču:

Vetting palīdz izlemt, kam uzticēt sensitīvāku darbības brīvību.

Findinga patiesumu joprojām nosaka evidence.

Testera drošumu — konkrēta uzvedība un rules of engagement ievērošana.

verified identity
≠ competent researcher

high reputation
≠ safe behaviour in every environment

known researcher
≠ technically correct finding

Sandbox un digital twin ir vērtīgi, bet ne perfekti

Augsta riska funkciju var mēģināt pārvietot uz:

staging;
dedicated test environment;
synthetic dataset;
hardware-in-the-loop vidi;
digital twin;
isolated tenant.

Tas bieži ir pareizi.

Taču laboratorijai ir fidelity problēma.

Tā var neatkārtot:

production routing;
reālu IAM konfigurāciju;
third-party integrations;
slodzi;
cache;
edge controls;
timing;
konkrētu firmware kombināciju;
operational workarounds.

Tāpēc:

Nobriedis modelis nesaka “staging vai production”.

Tas mēģina noteikt, kuru hipotēzi var droši pārbaudīt katrā vidē.

safe test environment
→ lower operational risk

but

lower fidelity
→ possibility of missing production-only vulnerabilities

Synthetic data jāizmanto, kad vulnerability neprasa reālu cilvēku datus

Ja vulnerability var pierādīt ar:

diviem test accounts;
fake patient record;
synthetic payment;
test booking;
dummy identifier;

nav profesionāla iemesla izmantot reālu cilvēku datus tikai tāpēc, ka tie ir pieejami.

Kritiskā sistēmā evidence minimisation vienlaikus samazina:

privātuma risku;
incidenta risku;
regulatoro risku;
testēšanas seku smagumu.

Ja reāli dati parādās negaidīti, stop rule ir īpaši svarīgs.

Latvijas Bankas VDP tieši prasa pārtraukt testēšanu, saskaroties ar personu identificējošu, finanšu vai komercnoslēpuma informāciju.7

Third-party boundary ir kritiskāka nekā parastā SaaS produktā

Kritiskie pakalpojumi parasti ir piegādes ķēdes.

Slimnīcas sistēmā var būt:

medical device vendor;
laboratorija;
identity provider;
valsts reģistrs;
cloud;
telekomunikāciju operators.

Enerģētikā:

OT vendors;
telecom;
remote maintenance;
SCADA integrators;
cloud analytics.

Finansēs:

cloud;
payment schemes;
market infrastructure;
fintech integration;
outsourcing provider.

Vienas organizācijas atļauja ne vienmēr dod tiesības testēt visas šīs tehniskās atkarības.

Tāpēc scope vajag ne tikai:

bet arī:

Kas drīkst autorizēt testu katram tehniskajam slānim?

IP / domain list

authority map

Kaskādes sekas maina pieļaujamo PoC

CER uzsver nozaru savstarpējo atkarību un risku, ka viena būtiska pakalpojuma traucējums var radīt plašākas kaskādes sekas citās nozarēs un valstīs.2

Tas ir nozīmīgi arī security research.

Piemēram, PoC, kas lokāli izskatās kā:

“restartējas viens serviss”

var reāli izraisīt:

failover;
queue backlog;
downstream timeout;
partnera retry storm;
sinhronizācijas kļūdu;
manuāla recovery ķēdi.

Kritiskā vidē testēšanas samērīgumu tāpēc nedrīkst vērtēt tikai pēc vienas komponentes tūlītējās reakcijas.

Jāskatās sistēma.

Disclosure arī var prasīt diferencētu režīmu

Atbildīga disclosure mērķis nav noslēpt vulnerability uz visiem laikiem.

Taču kritiskā sistēmā publiskošanas lēmums var prasīt:

koordināciju ar vendoru;
downstream operatoriem;
CSIRT;
nozaru regulatoru;
vairāku valstu iestādēm;
patch deployment logu;
compensating controls.

NIS2 CVD modelis tieši paredz CSIRT koordināciju un pārrobežu sadarbību multi-party gadījumos.1

Tāpēc:

public test permission un public disclosure timing

ir divi atsevišķi policy parametri.

“Security through obscurity” nav arguments pret CVD

Kritisko sistēmu operatoram var būt pamatoti iemesli:

nepubliskot pilnu arhitektūru;
slēpt operacionālas detaļas;
limitēt testēšanas metodes;
prasīt identitātes pārbaudi;
koordinēt disclosure.

Tas nav automātiski “security through obscurity”.

Obscurity kļūst par problēmu tad, ja organizācija uzskata:

“ja neviens nedrīkst skatīties, vulnerability nepastāv”.

Kontrolēta izpēte ir tieši pretēja pieeja.

Tā atzīst, ka neatkarīgs adversarial skatījums ir vajadzīgs, bet testēšanas brīvība tiek pielāgota potenciālā kaitējuma robežām.

Aizliegts scope nedrīkst nozīmēt aizliegtu ziņošanu

Ļoti svarīga politika:

Out of scope for testing nedrīkst automātiski nozīmēt out of scope for reporting.

Ja pētnieks:

nejauši konstatē problēmu;
atrod public data exposure;
pamana noplūdušu credential;
saņem pierādījumu bez aktīvas ekspluatācijas;

organizācijai joprojām vajag ceļu šo informāciju droši saņemt.

Tas ir viens no iemesliem, kāpēc CVD kanāls jānošķir no test-permission policy.

Riskā balstīts research profile

Pirms piešķirt aktīvas testēšanas tiesības, es vērtētu vismaz šādus parametrus:

Jo vairāk labās kolonnas, jo mazāk pamatots ir nekontrolēts publisks aktīvais tests.

Riskā balstīts research profile
Jautājums	Zemāks risks	Augstāks risks
Pieejamība	kļūme lokāla un viegli atjaunojama	pakalpojuma pārtraukums ietekmē būtisku funkciju
Datu integritāte	disposable/synthetic	ārstniecības, finanšu, kontroles dati
Konfidencialitāte	publiski vai testa dati	veselības, finanšu, valsts/sensitīvi dati
Fiziskā ietekme	nav	iespējama ietekme uz fizisku procesu
Blast radius	viens tenant/tests	vairāki operatori/klienti/nozares
Reversējamība	tūlītēja	sarežģīta vai neskaidra
Third parties	nav	shared/cloud/supply-chain dependencies
Observability	pilna monitoring iespēja	testu grūti atšķirt no incidenta
Recovery	pārbaudīts	recovery nav droši verificēts

Minimālais controlled-research record

Sensitīvākai programmai es saglabātu:

Tas nav normatīvs standarts.

Tas ir autora praktisks kontrolētas testēšanas minimums.

researcher:
  identity_verified:
  competence_basis:
  contact:

authorization:
  assets:
  methods_allowed:
  methods_prohibited:
  third_party_boundaries:

safety:
  test_window:
  rate_limits:
  test_accounts:
  synthetic_data:
  monitoring_owner:
  emergency_stop_contact:
  rollback_or_cleanup:

evidence:
  storage:
  encryption:
  retention:
  personal_data_stop_rule:

coordination:
  incident_escalation:
  disclosure_route:
  regulator_or_csirt_contact_if_needed:

closure:
  cleanup_verified:
  finding_owner:
  retest:

Labs modelis nedrīkst nogalināt spontānu pētniecību

Kontroles var aiziet pārāk tālu.

Ja katram low-impact web request vajag:

identitātes pārbaudi;
NDA;
iepriekšēju approval;
konkrētu test window;
nedēļām ilgu reģistrāciju;

kvalitatīvi ārējie pētnieki vienkārši nepiedalīsies.

Tāpēc mērķis nav visu pārvērst par pentestu.

Mērķis ir:

zemāka riska izpētei saglabāt zemu berzi, bet augstāka riska darbībām pievienot kontroli tieši tur, kur tā samazina reālu kaitējumu.

Tas ir proporcionalitātes jautājums.

Secinājums

Kritiskā infrastruktūra nav parasta mājaslapa.

Taču no tā neizriet, ka neatkarīgai drošības izpētei tajā nav vietas.

Pareizāks secinājums ir:

jo lielāks potenciālais kaitējums, jo precīzāk jāprojektē atļaujas, metodes, vide, cilvēki un emergency controls.

Publiska CVD adrese var pastāvēt arī ļoti sensitīvā organizācijā.

Publiski testējams scope var būt tikai neliela daļa no tās infrastruktūras.

Dziļāku piekļuvi var dot reģistrētiem vai vetted pētniekiem.

Visaugstākā riska darbībām var būt vajadzīga profesionāli kontrolēta testēšana ar monitoring, test windows, synthetic data, stop protocol un recovery plānu.

Tātad izvēle nav:

Tā ir:

Tādā modelī drošības pētnieks nekļūst ne par nekontrolētu risku, ne par aizliegtu ārēju novērotāju.

Viņš kļūst par vienu no assurance slāņiem sistēmā, kur testēšanas brīvība un testēšanas drošība tiek projektētas kopā.

open research
OR
no research

open reporting
+
risk-proportionate testing authority
+
stronger controls as potential harm increases

Biežāk uzdotie jautājumi

Vai kritiskai infrastruktūrai vispār vajag publisku CVD?

Jā, publisks ziņošanas kanāls var būt ļoti vērtīgs arī augsta riska organizācijā. Tas nenozīmē, ka viss tehniskais scope automātiski ir publiski atļauts aktīvai testēšanai.

Vai public CVD nozīmē atļauju skenēt visu organizāciju?

Nē. Atļauto aktīvu un metožu scope jālasa konkrētās programmas noteikumos. Latvijas Bankas VDP, piemēram, nosauc trīs publiski testējamas vietnes un tieši aizliedz šīs iniciatīvas ietvaros testēt citus bankas resursus.7

Vai vetted researchers atrisina drošības risku?

Nē. Vetting samazina dažus identitātes un uzticamības riskus, bet neaizvieto scope, monitoring, minimālas ietekmes prasības, evidence kontroli un emergency stop.

Vai kritiskas sistēmas jātestē tikai staging vidē?

Ne vienmēr. Staging samazina operational risk, bet var neatkārtot production-only konfigurāciju un integrācijas. Augstāka fidelity testiem var būt vajadzīga kontrolēta production testēšana ar daudz stingrākām drošības kontrolēm.

Vai TLPT ir modelis visām kritiskajām nozarēm?

Nē. TLPT ir konkrēts DORA advanced-testing režīms finanšu sektorā izraudzītām vienībām. Tā risk-management principi ir ilustratīvi, bet tos nedrīkst pasniegt kā universāli saistošu modeli veselībai, enerģētikai vai transportam.

Ko darīt, ja aizliegtā scope sistēmā vulnerability tiek pamanīta nejauši?

Nepalielināt ietekmi tikai tāpēc, lai iegūtu “labāku PoC”. Fiksēt minimālo evidence un izmantot organizācijas CVD/CSIRT ziņošanas ceļu. “Nav atļauts aktīvi testēt” nav tas pats, kas “nedrīkst ziņot”.

Avotu statuss

ES un Latvijas avotu statuss pārbaudīts 2026. gada 25. septembrī. Rakstā lietotie pieci ārējās izpētes profili, risku tabula un controlled-research record ir autora analītisks modelis, ne NIS2, CER, DORA, CERT.LV vai Latvijas Bankas oficiāla klasifikācija.

Šis raksts ir drošības izpētes un testing-governance modeļu analīze. Konkrētas sistēmas juridiskais statuss un atļautās darbības jāvērtē pēc tai piemērojamajiem normatīvajiem aktiem un testēšanas noteikumiem.