No pentesta līdz TLPT: kā veidot slāņotu kiberdrošības assurance

NIST SP 800-115 jau sen nošķir dažādas tehniskās pārbaudes metodes un uzsver, ka katrai ir savi ieguvumi un ierobežojumi.1

Mūsdienu vidē šis princips kļūst vēl svarīgāks.

Vienā organizācijā var vienlaikus eksistēt:

• vulnerability scanning;
• source-code review;
• penetration testing;
• red-team exercise;
• purple-team session;
• CVD;
• bug bounty;
• incident simulations;
• resilience testing;
• finanšu sektorā — DORA TLPT.

Neviena no šīm darbībām pati par sevi nav “assurance”.

Assurance rodas no tā, ka organizācija spēj sasaistīt:

Ja trūkst šīs ķēdes, testēšana var kļūt par aktivitātes pierādījumu, ne drošības pierādījumu.

Dažādiem assurance režīmiem ir dažādi pamatjautājumi.

Šīs rindas nav brieduma kāpne.

Red team nav “pentest plus”.

Bug bounty nav “outsourced pentest”.

TLPT nav vienkārši “ļoti dziļš pentest”.

Scanneris var ļoti efektīvi palīdzēt atrast:

• zināmas CVE;
• versiju ekspozīcijas;
• atvērtus servisus;
• konfigurācijas problēmas;
• TLS vai header problēmas;
• atkārtojamu tehnisku patternu.

Tā stiprā puse ir mērogs.

Tas var periodiski pārbaudīt tūkstošiem aktīvu.

Taču scanneris parasti ir vājš jautājumos par:

• business logic;
• sarežģītu autorizāciju;
• vairāku sistēmu attack chain;
• reālu exploitability konkrētā konfigurācijā;
• cilvēka un procesu kontroles apiešanu.

Tāpēc:

Tas ir exposure inventory signāls, ne pilns adversarial proof.

Pentests parasti ir iepriekš autorizēts, time-boxed engagement ar:

• noteiktu scope;
• rules of engagement;
• testēšanas metodēm;
• sākuma/beigu laiku;
• deliverables;
• remediation/retest plūsmu.

NIST SP 800-115 penetrācijas testēšanu apraksta kā vienu no tehniskās drošības testēšanas metodēm, kas palīdz identificēt ievainojamības un pārbaudīt, cik praktiski tās iespējams izmantot.1

Pentesta stiprums ir kontrolēta dziļuma iespēja.

Labs pentests var pārbaudīt:

• web/API authorization;
• privilege escalation;
• network segmentation;
• credential abuse;
• business logic;
• kombinējamus findings.

Taču pentesta scope un laiks ir vienlaikus tā ierobežojums.

Ja engagement ir:

tad gala reports ir pierādījums par šo testēto robežu.

Tas nav garantija par:

• visu organizāciju;
• nākamajā dienā izlaistu kodu;
• neiekļautiem cloud aktīviem;
• nezināmu trešās puses dependency;
• uzbrucēja sešu mēnešu kampaņu.

Red-team engagementa pamatvienība nav vulnerability saraksts.

Tā parasti ir objective.

Piemēram:

iegūt kontrolētu piekļuvi noteiktai kritiskai informācijai;

vai:

sasniegt privilēģētu pozīciju, nepārsniedzot definētās drošības robežas.

Red team var kombinēt:

• tehniskus vektorus;
• identitāti;
• cloud;
• endpointus;
• fizisko piekļuvi;
• social engineering, ja tas ir autorizēts;
• persistence simulāciju;
• detection avoidance.

Rezultāts nav tikai:

“atradām 12 vulnerabilities”.

Daudz vērtīgāki jautājumi ir:

• kuri attack paths strādāja;
• kur aizsardzība pamanīja darbību;
• kur nepamanīja;
• kas apturēja progresu;
• vai incident response rīkojās pareizi;
• kādas telemetry vai process plaisas pastāvēja.

Tāpēc red team var dot ļoti lielu assurance value arī tad, ja gala reportā ir salīdzinoši maz “bugs”.

Šo robežu bieži pārprot.

Ja red team atrada vienu ceļu līdz mērķim, tas var apzināti netērēt laiku, lai atrastu vēl 20 neatkarīgas ievainojamības citā aplikācijas daļā.

Tas optimizē attack objective.

Pentests biežāk optimizē definētā scope drošības trūkumu atklāšanu.

Tāpēc:

Red team var neizdoties izvēlētā scenārija, laika, threat intelligence vai rules-of-engagement dēļ.

Tas joprojām rada evidence.

Tikai jāpasaka, ko tieši.

Purple team nav obligāti atsevišķa komanda.

Praksē tas bieži nozīmē sadarbību starp offensive/red un defensive/blue funkcijām.

Mērķis var būt:

• atkārtot uzbrukuma tehniku;
• pārbaudīt telemetry;
• uzrakstīt detection;
• pielāgot alert;
• validēt response playbook;
• saprast, kāpēc uzbrukums netika pamanīts.

Šeit slepenība vairs nav galvenā vērtība.

Galvenā vērtība ir ātra feedback loop.

DORA TLPT regulējumā purple teaming tagad ir arī formāli definēts konkrētā kontekstā: Komisijas Deleģētā regula (ES) 2025/1190 to definē kā testētāju un blue team kopīgu testēšanas darbību, bet TLPT closure fāzē paredz attack replay un purple-team vingrinājumu.4

Tas nenozīmē, ka visas nozares purple-team prakse ir definēta ar DORA.

Tas nozīmē, ka finanšu sektora TLPT konkrētajā regulētajā procesā purple teaming ir ieguvis ļoti precīzu lomu.

CVD assurance vērtība ir gandrīz pretēja pentestam.

Pentestā organizācija nosaka:

• kad;
• kur;
• kas;
• cik ilgi;
• ar kādām metodēm.

CVD gadījumā finding var ierasties:

• otrdien naktī;
• no nepazīstama pētnieka;
• aktīvā, kuru iekšējā komanda neuzskatīja par prioritāti;
• vulnerability klasē, kuru neviens nebija plānojis testēt.

Tas ir vērtīgi tieši tāpēc, ka nav pilnībā plānots.

FIRST PSIRT Services Framework ārēju finderu, vulnerability reporting un iekšēju product-security assessment skata kā papildinošus vulnerability-discovery avotus.2

Taču no tā neizriet:

nav reportu → nav ievainojamību.

CVD nedod coverage guarantee.

Tas dod opportunistic external discovery channel.

Bug bounty pievieno CVD vēl vienu dimensiju:

researcher attention var mēģināt virzīt ar ekonomiskiem stimuliem.

Programma var palielināt:

• bounty konkrētam assetam;
• atlīdzību jaunam scope;
• bonusu noteiktai vulnerability klasei;
• private invites;
• speciālu campaign.

Tas padara bounty par interesantu assurance instrumentu.

Taču arī šeit nav iespējams secināt:

“mums ir bounty, tātad viss scope ir testēts”.

Pētnieki paši izvēlas, kam veltīt laiku.

Tāpēc bounty coverage ir tirgus rezultāts, ne test plan.

Par programmas dizainu detalizēti: Bug bounty programma: ko patiesībā optimizē laba programma?.

DORA labi parāda, kāpēc nobriedusi assurance arhitektūra nevar balstīties vienā testā.

DORA 24. pants finanšu vienībām, izņemot noteiktos izņēmumus, prasa izveidot visaptverošu digitālās darbības noturības testēšanas programmu kā IKT risku pārvaldības daļu.3

25. pants uzskaita plašu testēšanas metožu klāstu, tostarp:

• vulnerability assessments un scans;
• network security assessments;
• source-code reviews, kur iespējams;
• scenario-based testing;
• end-to-end testing;
• penetration testing.3

24. pants papildus prasa identificētos testing findings prioritizēt, klasificēt, novērst un iekšēji validēt, ka konstatētās nepilnības ir pilnībā risinātas.3

Savukārt TLPT ir atsevišķs advanced-testing režīms izraudzītām finanšu vienībām.

DORA 26. pants paredz šīm vienībām TLPT vismaz reizi trijos gados, ja kompetentā iestāde atbilstoši riska profilam nenosaka citu biežumu. Tests aptver vairākas vai visas kritiskās vai svarīgās funkcijas un tiek veikts live production sistēmās, kas šīs funkcijas atbalsta.3

Tas ir daudz specifiskāks režīms nekā parasts pentests.

Komisijas Deleģētā regula (ES) 2025/1190 precizē:

• atlases kritērijus;
• scope specification;
• threat-intelligence fāzi;
• red-team test plan;
• aktīvo red-team fāzi;
• risk-management kontroli;
• closure;
• purple teaming;
• remediation plan;
• uzraudzības sadarbību.4

Aktīvās testēšanas laikā var rasties risks datiem, aktīviem vai kritisku funkciju darbībai. RTS tādēļ paredz iespēju testu apturēt un noteiktos ārkārtas apstākļos pāriet uz ierobežotu purple-team pieeju.4

Tas ir ļoti būtiski.

Realism nav absolūta vērtība.

Nobriedis assurance režīms mēģina iegūt pēc iespējas reālistiskāku evidence, vienlaikus kontrolējot paša testa radīto risku.

Pēc aktīvās red-team fāzes RTS nebeidzas ar PDF reportu.

Tas paredz:

• red-team reportu;
• blue-team reportu;
• uzbrukuma un aizsardzības darbību replay;
• purple-team vingrinājumu;
• feedback par pašu testēšanas procesu;
• kopsavilkuma reportu TLPT iestādei;
• remediation plan.4

Remediation plan katram findingam jāietver cita starpā:

• konstatētais trūkums;
• remediation darbības un prioritāte;
• paredzētais pabeigšanas termiņš;
• root-cause analysis;
• atbildīgā funkcija/personāls;
• riski, ja pasākumi netiek ieviesti.4

Tas ir labs assurance princips arī ārpus finanšu sektora:

testa kvalitāti nosaka ne tikai tas, ko tas atrod, bet arī tas, vai organizācija spēj findings pārvērst kontrolētā remediation un atkārtotā pārbaudē.

ECB 2025. gada februārī atjaunināja TIBER-EU, lai tas būtu saskaņots ar DORA TLPT RTS.5

Atjauninātajā modelī:

• procesa soļi salāgoti ar DORA deliverables;
• terminoloģija pielāgota DORA;
• closure ietver purple teaming;
• TIBER-EU dod detalizētu operacionālu guidance drošai un kontrolētai TLPT izpildei.5

Taču formulējums jāuztur precīzs.

DORA un Komisijas RTS ir saistošais regulatīvais pamats.

TIBER-EU ir operacionāls ietvars/guidance, ko var izmantot DORA TLPT izpildei tiktāl, ciktāl tas ir saderīgs ar DORA un RTS.

Tie nav viens juridiska līmeņa instruments.

Latvijas Banka savā aktuālajā DORA informācijā TLPT sasaista ar Komisijas RTS 2025/1190 un norāda, ka izraudzīšanā tiek ņemta vērā finanšu vienības IKT pārvaldības/procesu brieduma pakāpe un kritiskums finanšu sistēmai, primāri fokusējoties uz sistēmiski nozīmīgiem tirgus dalībniekiem.6

Tas nenozīmē, ka pārējām finanšu vienībām nav jātestējas.

DORA pamatmodelis ir pretējs:

TLPT ir slānis virs plašākas testēšanas programmas, ne tās aizvietotājs.

Assurance instrumentiem bieži ir kompromiss starp trim lietām.

Coverage

Cik lielu attack surface daļu var aptvert?

Scannerim coverage var būt milzīgs.

Depth

Cik dziļi var izpētīt vienu boundary vai attack chain?

Labs pentests vai specializēta izpēte var iet daudz dziļāk.

Realism

Cik līdzīgs tests ir reālam pretiniekam un reālajai produkcijas videi?

Red team un TLPT var dot daudz augstāku realism.

Taču augstāks realism parasti palielina:

• testēšanas risku;
• koordinācijas sarežģītību;
• izmaksas;
• nepieciešamo kompetenci;
• drošības kontroles ap pašu testu.

Tāpēc nav viena instrumenta, kas optimāli maksimizē visus trīs.

Pentests dod plānotu assurance:

šajā datumā pārbaudīsim šo scope.

CVD dod neplānotu assurance:

ja kāds kaut ko atrod starp testiem, mums ir ceļš to saņemt.

Bug bounty mēģina neplānoto ārējo discovery padarīt aktīvāku.

Red team pārbauda pretinieka ceļu.

Purple team pārvērš to detection mācībās.

TLPT regulētā vidē savieno threat intelligence, live production, ofensīvo/difensīvo pārbaudi un uzraudzītu closure.

Tie ir papildinoši evidence avoti.

Pentesta reports noveco.

To var padarīt novecojušu:

• release;
• konfigurācijas maiņa;
• jauna dependency;
• cloud migration;
• IAM pārmaiņas;
• jauns API;
• piegādātāja update;
• jauna threat technique.

Tāpēc frāze:

“mums pirms gada bija pentests”

ir tikai datēts pierādījums.

Ne pašreizēja drošības īpašība.

Nepārtraukta assurance nenozīmē “pentest katru dienu”.

Tā nozīmē, ka organizācijai ir dažādi evidence avoti dažādos laika mērogos:

Dažos testos vajag neatkarību.

Ja tests tiek projektēts tikai tā, lai apstiprinātu komandas pieņēmumus, tas var radīt self-confirmation.

DORA 24. pants, piemēram, finanšu vienībām paredz testēšanu ar neatkarīgām pusēm — iekšējām vai ārējām, ar konfliktu novēršanu.3

Red team vērtība bieži palielinās, ja blue team nezina precīzu testu.

Taču pēc testa tieši sadarbība var radīt lielāko mācīšanos.

Purple team intentionally samazina neatkarību, lai palielinātu:

• detection tuning;
• telemetry coverage;
• playbook kvalitāti;
• kopīgu attack-path izpratni.

Tāpēc:

independence is not always better, and collaboration is not always weaker.

Tie rada atšķirīgu evidence.

“Pentests bija tīrs, tātad esam droši”

Nē.

Tas nozīmē, ka konkrētajā scope, laikā un metodoloģijā netika konstatēti vai apstiprināti noteikti findings.

“Bounty nav Critical reportu, tātad nav Critical bugs”

Nē.

Pētnieku uzmanības sadalījums nav pilnīgs coverage modelis.

“Red team neiekļuva, tātad uzbrukums neizdosies”

Nē.

Tests ir viens scenario/time-box ar noteiktām metodēm.

“Red team iekļuva, tātad aizsardzība nestrādā”

Arī ne obligāti.

Jāvērtē, kas tika pamanīts, cik ātri, kur tika apturēts progress un kādi control assumptions tika pārbaudīti.

“Mums ir sertifikāts, tātad kontroles strādā”

Sertifikācija var dot svarīgu assurance par definētu scope un shēmu, bet evidence par eksistenci vai atbilstību nav automātiski tas pats, kas pašreizēja operating effectiveness. Par to detalizēti: Kiberdrošības sertifikācijai jāpierāda efektivitāte, ne tikai aktivitāte.

“Mums ir TLPT, citi testi nav vajadzīgi”

DORA pati pasaka pretējo.

TLPT atrodas plašākā digital operational resilience testing programmā.3

Vienkāršots modelis var izskatīties šādi.

Design / build

• threat modelling;
• architecture review;
• secure coding;
• source-code analysis;
• dependency analysis;
• automated tests.

Pre-release / change

• targeted security review;
• vulnerability assessment;
• pentest, ja riska līmenis to prasa;
• regression/security tests.

Production continuous

• vulnerability monitoring;
• attack-surface monitoring;
• logging/detection;
• CVD;
• bug bounty, ja modelis piemērots.

Periodic adversarial

• pentest;
• red team;
• purple team;
• sector-specific scenario testing.

Advanced / regulated

• TLPT, kur tas ir piemērojams;
• citi kontrolēti augsta riska testing modeļi kritiskām sistēmām.

Closure

• root-cause analysis;
• remediation;
• deployment evidence;
• retest;
• residual-risk decision;
• regression control.

Tas nav normatīvs standarts.

Tas ir autora assurance architecture modelis.

Lai testēšana neradītu viltus drošības sajūtu, gala reportā būtu jāspēj pateikt ne tikai:

ko atradām.

Bet arī:

ko šis tests ļauj un neļauj secināt.

Piemēram:

Šāda sadaļa reportā var būt vērtīgāka par vēl vienu piecu krāsu risk matrix.

Nobriedušā organizācijā findings var ienākt no:

• scanner;
• SAST;
• pentest;
• red team;
• CVD;
• bug bounty;
• TLPT;
• incident response;
• supplier advisory.

Discovery process var atšķirties.

Pēc validācijas tiem vajadzētu nonākt saskaņotā lēmuma ķēdē:

Tas ļauj salīdzināt evidence un novērš situāciju, kur katra testēšanas komanda dzīvo savā ticket pasaulē.

Ne:

“Vai mums šogad bija pentests?”

Bet:

• kuras critical security claims mēs pārbaudām;
• ar kādu metodi;
• cik svaigs ir evidence;
• kas paliek netestēts;
• kuri findings atkārtojas;
• cik findings ir verificēti novērsti;
• ko red team iemācīja blue team;
• kur external research papildināja planned testing;
• kur testēšanas coverage neatbilst biznesa kritiskumam;
• kur mums ir tikai activity evidence, ne effectiveness evidence.

Tad assurance kļūst par pārvaldības instrumentu.

Ne kalendāra ierakstu.

Pentests ir vērtīgs.

Red team ir vērtīgs.

Purple team ir vērtīgs.

CVD un bug bounty ir vērtīgi.

Finanšu sektorā TLPT var būt īpaši spēcīgs un regulēts pārbaudes instruments.

Problēma sākas tikai tad, kad kādu no tiem pārvērš par universālu atbildi:

“mēs šo testu izdarījām, tātad esam droši”.

Security assurance nav viena pārbaude.

Tā ir sistēma, kurā dažādi evidence avoti apzināti pārbauda dažādas drošības hipotēzes un rezultāti nonāk vienā remediation un mācīšanās ciklā.

Īsāk:

Pentests ir point-in-time tests. Assurance ir pierādījumu sistēma laikā.

Labs assurance modelis necenšas pierādīt, ka ievainojamību nav.

Tas cenšas regulāri, ar atbilstošu metodi un pietiekamu neatkarību pārbaudīt svarīgākos apgalvojumus par to, kāpēc sistēmai vajadzētu būt drošai — un ko darīt, kad evidence parāda pretējo.

Avoti un DORA/TLPT juridiskais statuss pārbaudīti 2026. gada 25. septembrī. Raksta assurance map, claim boundary un slāņotais modelis ir autora praktiska metodika, ne NIST, DORA, ECB vai Latvijas Bankas oficiāla klasifikācija. TIBER-EU rakstā tiek nošķirts no saistošās DORA un Komisijas Deleģētās regulas (ES) 2025/1190.

Šis raksts ir security assurance un testēšanas arhitektūras analīze. Finanšu sektora DORA/TLPT daļa nav individuāls juridisks vai uzraudzības padoms.