Draudu modelēšana ISO 27001, NIS2 un DORA atbilstībai

Ānijai, strauji augoša finanšu tehnoloģiju uzņēmuma CISO, tika lūgts apstiprināt jaunas B2B maksājumu riska platformas palaišanas plānu. Valde vēlējās ieiet tirgū pirms ceturkšņa beigām. Pārdošanas komanda jau bija piesaistījusi banku klientus. Inženierijas komanda bija ieskicējusi mākoņvides arhitektūru ar identitātes atribūtiem, ierīču signāliem, darījumu metadatiem, uzvedības riska vērtējumiem, pārvaldītu datubāzi un trešās puses analītikas pakalpojumu sniedzēju.

Uz papīra platforma izskatījās pēc komerciāla izrāviena. Ānijai tā izskatījās pēc piecām atbilstības sarunām, kas pienākušas vienlaikus.

Kā finanšu tehnoloģiju pakalpojumu sniedzējam uzņēmumam bija DORA spiediens. Kā mākoņpakalpojumu un digitālās platformas nodrošinātājam tam bija jāsaprot NIS2 ietekme. Tā kā platforma apstrādāja personas datus par ES fiziskām personām, bija piemērojams GDPR. Uzņēmumu klienti sagaidīja ISO/IEC 27001:2022 sertifikāciju. Ja pakalpojums kļūtu par daļu no savienota programmatūras produkta, Cyber Resilience Act prasības papildus prasītu produkta drošas projektēšanas pierādījumus.

Izstrādes komanda piedāvāja ierasto drošības plānu: skenēt atkarības, veikt ievainojamību skenēšanu, ieplānot ielaušanās testēšanu un pirms nodošanas ražošanas vidē novērst kritiskos konstatējumus. Ānija zināja, ka ar to nepietiek. Šīs darbības pārbauda to, kas jau ir uzbūvēts. Tās nepierāda, ka arhitektūra ir droša jau projektēšanas posmā, ka uzticamības robežas ir saprastas, ka personas datu plūsmas ir minimizētas, ka piegādātāju pieņēmumi ir pārskatīti vai ka pakalpojuma darbības traucējumu scenāriji ir izvērtēti pirms palaišanas.

Tāpēc viņa palēnināja sanāksmi ar četriem jautājumiem:

1. Kur ir uzticamības robežas?
2. Kuri ļaunprātīgas izmantošanas scenāriji var izraisīt krāpšanu, datu ekspozīciju vai pakalpojuma darbības traucējumus?
3. Kuri projektēšanas lēmumi samazina risku pirms koda rakstīšanas?
4. Kādi pierādījumi pēc sešiem mēnešiem apmierinās ISO 27001, NIS2, DORA, CRA un GDPR pārskatītājus?

Tieši ceturtajā jautājumā daudzas organizācijas izgāžas. Draudu modelēšanu bieži uztver kā noderīgu inženierijas darbnīcu un pēc tam aprok wiki lapā. 2026. gadā ar to nepietiek. SaaS pakalpojumu sniedzējiem, finanšu tehnoloģiju uzņēmumiem, mākoņplatformām, MSP, MSSP, digitālās infrastruktūras operatoriem un programmatūras ražotājiem draudu modelēšana ir kļuvusi par atbilstības pierādījumu dzinēju.

Nobriedis draudu modelēšanas process pārvērš STRIDE konstatējumus, ļaunprātīgas izmantošanas scenārijus un arhitektūras lēmumus riska reģistra ierakstos, drošības prasībās, risku apstrādes plānos, testēšanas gadījumos, piegādātāju apliecinājuma uzdevumos, integrētas datu aizsardzības pierādījumos un piemērojamības deklarācijas (SoA) izsekojamībā.

Kāpēc drošas projektēšanas pierādījumi tagad ir būtiski

Mūsdienu regulējumi virzās uz vienu un to pašu prasību: organizācijām savlaicīgi jāidentificē drošības un privātuma riski, jāpiešķir atbildība, jāievieš samērīgi kontroles pasākumi un jāsaglabā pierādījumi.

ISO/IEC 27001:2022 prasa uz risku balstītu informācijas drošības pārvaldības sistēmu. Punkti 6.1.2 un 6.1.3 prasa informācijas drošības risku novērtēšanu un risku apstrādi. Punkts 8.1 prasa darbības plānošanu un kontroli. A pielikums nodrošina kontroles pasākumus, kas, pamatojoties uz riskiem, juridiskajām prasībām un biznesa vajadzībām, jāatlasa piemērojamības deklarācijā.

NIS2 šo pašu principu ievieš kiberdrošības pārvaldībā. Article 20 prasa, lai vadības struktūras apstiprinātu kiberdrošības riska pārvaldības pasākumus un pārraudzītu to ieviešanu. Article 21 prasa atbilstošus un samērīgus tehniskus, operacionālus un organizatoriskus pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošību iegādē, izstrādē un uzturēšanā, ievainojamību apstrādi, kiberdrošības higiēnu, šifrēšanu, piekļuves kontroli, aktīvu pārvaldību un MFA, kur tas ir piemēroti.

DORA no 2025. gada 17. janvāra piemēro finanšu sektoram digitālās darbības noturības skatījumu. Tas prasa aptvertajām finanšu iestādēm uzturēt pamatotu, visaptverošu un dokumentētu IKT risku pārvaldības ietvaru, identificēt IKT aktīvus un atkarības, piemērot aizsardzības un preventīvos pasākumus, atklāt anomālu darbību, testēt digitālo darbības noturību, pārvaldīt IKT trešo pušu risku un sagatavot reaģēšanas un atjaunošanas spējas. Aptvertajām finanšu iestādēm DORA ir nozares specifisks Savienības tiesību akts attiecībā uz pārklājošiem NIS2 pienākumiem.

GDPR pievieno pārskatatbildību un integrētu datu aizsardzību un datu aizsardzību pēc noklusējuma. Jebkurai sistēmai, kas apstrādā personas datus, jāspēj pierādīt likumīgu, godprātīgu, pārredzamu, nolūkam ierobežotu, minimizētu, glabāšanas termiņā ierobežotu un drošu apstrādi. Draudu modelis, kas kartē personas datu plūsmas, piekļuves ceļus, žurnālus, glabāšanu, dzēšanu un nosūtīšanu trešajām pusēm, ir tieši attiecināms uz GDPR Articles 5, 25, 32 un 35.

Cyber Resilience Act palielina spiedienu uz produktiem ar digitāliem elementiem. Produktu komandām ir nepieciešami dzīves cikla pierādījumi, kas apliecina, ka kiberdrošības riski, paredzama nepareiza lietošana, saskarnes, atjaunināšanas mehānismi, autentifikācijas plūsmas un ievainojamību apstrādes pieņēmumi tika izvērtēti savlaicīgi.

Secinājums ir skaidrs: ja arhitektūras izvērtēšanu nevar sasaistīt ar riskiem, kontroles pasākumiem, īpašniekiem, mazināšanas pasākumiem un testiem, to būs grūti aizstāvēt 2026. gada auditā vai regulatīvā pārskatīšanā.

Clarysec modelis: viens draudu modelis, daudzi rezultāti

Clarysec pieeja sākas ar praktisku principu: draudu modelis nav pabeigts, kamēr tas nerada auditējamus lēmumus.

Zenith Blueprint: auditora 30 soļu ceļvedis [ZB] risku pārvaldības fāzes 9. solī komandām sniedz vienkāršu formātu tehnisku novērojumu pārvēršanai risku valodā:

“Tagad apvienojiet aktīvu + apdraudējumu + ievainojamību īsā riska scenārija aprakstā. Būtībā aprakstiet iespējamo incidentu. Vēlāk tas kļūs par atsevišķu ierakstu jūsu riska reģistrā. Izmantojiet vienkāršu formātu: ‘[Apdraudējums] izmanto [ievainojamību] uz [aktīva], kā rezultātā rodas [ietekme].’”

Šis teikums ir tilts starp inženieriju un atbilstību.

Piezīme uz tāfeles, piemēram, “partnera API identitātes viltošanas risks”, kļūst par:

“Uzbrucējs izmanto vāju partnera API autentifikāciju darījumu riska API, kā rezultātā rodas nesankcionēta piekļuve maksājumu riska lēmumiem un personas datu ekspozīcija.”

Tagad konstatējumam ir aktīvs, apdraudējums, ievainojamība un ietekme. To var novērtēt, piešķirt īpašniekam, apstrādāt, testēt un akceptēt.

Politikas slānis padara to atkārtojamu. P24 Drošas izstrādes politika [P24] nosaka:

“Visām jaunām lietojumprogrammām un būtiskām izmaiņām pirms izstrādes sākuma jāveic drošības arhitektūras izvērtēšana un draudu modelēšana.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

Tā arī prasa:

“Projektēšanas pārskatīšanā jādokumentē datu plūsmas diagrammas, uzticamības robežas un mazināšanas pasākumi identificētajiem riskiem.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.2.

Šie divi punkti ir spēcīgi audita balsti. Tie pierāda, ka draudu modelēšana nav izvēles darbība un ka projektēšanas pierādījumos jāiekļauj diagrammas, robežas un mazināšanas lēmumi.

P06 Risku pārvaldības politika [P06] sasaista draudu modelēšanu ar uzņēmuma risku pārvaldību:

“Visām biznesa struktūrvienībām proaktīvi jāidentificē riski, izmantojot strukturētas metodes, kas izriet no ISO/IEC 27005:2024, tostarp draudu modelēšanu, aktīvu atkarību kartēšanu un scenārijos balstītu identifikāciju.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

Tā arī nosaka:

“Identificētie riski jādokumentē, atsaucoties uz aktīva īpašnieku, apdraudējuma avotu, ievainojamību un iespējamo ietekmi uz konfidencialitāti, integritāti un pieejamību (CIA).”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.4.

Šī ir pierādījumu ķēde, ko auditori vēlas redzēt: politikas prasība, projektēšanas darbība, riska scenārijs, kontroles pasākumu atlase, ieviešana, testēšana un apstiprināšana.

STRIDE nodrošina sistemātisku pārklājumu, ļaunprātīgas izmantošanas scenāriji padara to reālu

STRIDE joprojām ir viena no noderīgākajām metodēm projektēšanas posma draudu modelēšanā, jo tā liek komandām izvērtēt sešus biežus atteices režīmus:

• Identitātes viltošana
• Manipulācijas
• Noliegšana
• Informācijas izpaušana
• Pakalpojuma atteice
• Privilēģiju paaugstināšana

Ānijas maksājumu riska platformai komanda izmantoja STRIDE katram komponentam, datu plūsmai un uzticamības robežai.

Identitātes viltošana radīja jautājumu, vai partnera API klients varētu uzdoties par bankas klientu, ja savstarpēja autentifikācija ir vāja. Manipulācijas atklāja risku, ka ierīču signāli vai darījumu summas varētu tikt mainītas pirms ievades sistēmā. Noliegšana izgaismoja nepieciešamību pēc administratoru un darījumu audita žurnāliem. Informācijas izpaušana koncentrējās uz noplūdi caur žurnāliem, analītikas eksportiem, atbalsta rīkiem un pārskatu API. Pakalpojuma atteice piespieda komandu izvērtēt darījumu maksimālās slodzes periodus un nekorektu pieprasījumu plūdus. Privilēģiju paaugstināšana atklāja riskus atbalsta lomās, sesiju marķieros un administratīvajās funkcijās.

Ļaunprātīgas izmantošanas scenāriji šīs kategorijas pārvērta reālos stāstos:

• Krāpnieks augšupielādē manipulētus ierīču signālus, lai ietekmētu riska vērtējumu.
• Kompromitēti partnera autentifikācijas dati pārpludina API ar krāpnieciskiem pieprasījumiem.
• Izstrādātājs izmanto ražošanas personas datus testa vidē.
• Ļaunprātīgs iekšējais lietotājs eksportē klientu identifikatorus un vērtēšanas loģiku.
• Mākoņanalītikas piegādātāja darbības pārtraukums bloķē riska lēmumus maksājumu logā.
• Krātuves nepareiza konfigurācija eksponē augšupielādētos identitātes dokumentus.
• Dzēšanas darbplūsma noņem lietojumprogrammas ierakstu, bet atstāj rezerves kopijas un piegādātāja kopijas.

Katrs ļaunprātīgas izmantošanas scenārijs kļuva par projektēšanas riska ierakstu ar skarto aktīvu, apdraudējuma avotu, ievainojamību, ietekmi, esošajiem pieņēmumiem, nepieciešamo mazināšanu, atlikušā riska īpašnieku, testēšanas pierādījumiem un regulatīvo nozīmīgumu.

Šāda struktūra novērš neskaidrus konstatējumus, piemēram, “API drošības risks”. Tā rada pierādījumu līmeņa riska formulējumus, piemēram:

“Uzbrucējs izmanto nozagtus partnera autentifikācijas datus, lai caur darījumu riska API iesniegtu krāpnieciskus vērtēšanas pieprasījumus, kā rezultātā tiek kompromitēta riska lēmumu integritāte, klientiem var rasties finanšu zaudējumi un notiek nesankcionēta personas datu apstrāde.”

Draudu modelēšanas sasaistīšana ar ISO/IEC 27001:2022 un ISO/IEC 27002:2022

ISO/IEC 27001:2022 neprasa draudu modelēšanu pēc nosaukuma. Tas prasa konsekventu, dokumentētu risku novērtēšanu un risku apstrādi. Draudu modelēšana ir viena no spēcīgākajām metodēm šādu pierādījumu sagatavošanai programmatūras, mākoņvides un produktu vidēs.

Galvenais ir izsekojamība. ZB risku pārvaldības fāzes 13. solī ir ieteikts kartēt kontroles pasākumus uz riskiem un punktiem, risku apstrādes plānos iekļaujot A pielikuma atsauces un norādot, kur kontroles pasākumi atbalsta GDPR, NIS2 vai DORA.

Zenith Controls: starpatbilstības ceļvedis [ZC] palīdz strukturēt šo izsekojamību, kartējot ISO/IEC 27002:2022 kontroles pasākumus uz saistītajiem kontroles pasākumiem, audita gaidām un ārējiem ietvariem.

Draudu modelēšanai ISO/IEC 27002:2022 kontroles pasākums 5.8 “Informācijas drošība projektu pārvaldībā” ir projektu pārvaldības balsts. Tas parāda, ka drošība ir integrēta projekta uzsākšanā, plānošanā, izpildē un pieņemšanā.

Kontroles pasākums 8.25 “Drošas izstrādes dzīves cikls” ir SDLC balsts. ZC sasaista 8.25 ar atbalstošiem kontroles pasākumiem, piemēram, 8.26 lietojumprogrammu drošības prasībām, 8.27 drošu sistēmu arhitektūru un inženierijas principiem, 8.28 drošu kodēšanu, 8.29 drošības testēšanu izstrādes un pieņemšanas laikā, 8.30 ārpakalpojuma izstrādi un 8.31 izstrādes, testēšanas un ražošanas vides nošķiršanu.

Šī kartēšana palīdz projektēšanas darbnīcu pārvērst piemērojamības deklarācijas pierādījumos. Tā atbalsta arī ISO/IEC 27001:2022 4. līdz 6. punktu, jo ir redzamas ieinteresēto pušu prasības, ISMS darbības joma, vadības apņemšanās un risku apstrādes lēmumi.

Starpatbilstības karte NIS2, DORA, CRA, GDPR un NIST CSF vajadzībām

Labi vadīts draudu modelis nedrīkst radīt piecas savstarpēji nesaistītas atbilstības darba plūsmas. Tam jārada viena projektēšanas risku pierādījumu pakete, ko var atkārtoti izmantot dažādos ietvaros.

NIST CSF 2.0 ir īpaši noderīgs komunikācijai ar augstāko vadību. Tā GOVERN funkcija atbalsta juridiskos, regulatīvos, līgumiskos un privātuma pienākumus, savukārt piegādes ķēdes rezultāti palīdz sasaistīt piegādātāju kritiskumu, līgumiskās prasības, sākotnējo izpēti, uzraudzību un incidentu plānošanu ar tiem pašiem draudu modeļa pierādījumiem.

GDPR prasa īpašu uzmanību, jo draudu modelēšanai un DPIA darbam ir savstarpēji jāpastiprina vienam otru. P17 Datu aizsardzības un privātuma politika [P17] nosaka:

“Draudu modelēšana un datu aizsardzības ietekmes novērtējumi (DPIA) ir obligāti augsta riska apstrādes sistēmām.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.3.4.

Mazākām komandām P17S Datu aizsardzības un privātuma politika - SME [P17S] nosaka:

“Integrēta datu aizsardzība un datu aizsardzība pēc noklusējuma jāpiemēro visās jaunajās sistēmās un pakalpojumos.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.1.

Rezultāts ir praktisks darbības modelis: izmantojiet tās pašas datu plūsmas diagrammas, uzticamības robežas un ļaunprātīgas izmantošanas scenārijus drošības riskam, privātuma riskam, piegādātāju pārskatīšanai un regulatīvajiem pierādījumiem.

90 minūšu projektēšanas riska sprints augsta riska funkcijām

Draudu modelēšanai nav jāsākas kā smagai programmai. Jaunam maksājumu API, ievades darbplūsmai, AI iespējotai funkcijai, identitātes pakalpojumam, migrācijai uz mākoņvidi vai ārējai integrācijai 90 minūšu projektēšanas riska sprints var radīt vērtīgus pierādījumus.

1. Atveriet projekta drošības kontrolpunktu

Izmantojiet P24 punktu 6.1.1 kā trigeri. Katrai jaunai lietojumprogrammai vai būtiskai izmaiņai izveidojiet pierādījumu mapi ar:

• Arhitektūras diagrammu
• Datu plūsmas diagrammu
• Uzticamības robežu karti
• Aktīvu sarakstu
• Piezīmēm par personas datiem
• Piegādātāju un IKT atkarību sarakstu
• Sākotnējām drošības prasībām
• Draudu modeļa darba lapu
• Riska reģistra ierakstiem
• Mazināšanas un testēšanas izsekojamību
• Apstiprinājuma ierakstu

Mazākām organizācijām P24S Drošas izstrādes politika - SME [P24S] atbalsta tādu pašu disciplīnu, sasaistot drošas izstrādes procesus ar izstrādātāju piekļuves kontroli, testēšanu, draudu modelēšanu un dokumentāciju. Tā arī prasa centralizēti glabāt kontrolsarakstu, pārskatīšanas apstiprinājumu, testēšanas pārskatu un komponentu uzskaiti audita vajadzībām. Punkts 11.3.1 atsaucas uz SA-3 līdz SA-15, lai definētu drošas izstrādes procesus, tostarp draudu modelēšanu.

2. Uzzīmējiet minimāli nepieciešamo datu plūsmu

Nesāciet ar noslīpētu diagrammu. Sāciet ar plūsmām, kas rada risku:

• Lietotājs augšupielādē identitātes dokumentus vai darījumu datus.
• Tīmekļa lietojumprogramma nosūta pieprasījumus uz API.
• API ieraksta datus pārvaldītā krātuvē vai datubāzē.
• Piegādātājs saņem verifikācijas vai analītikas datus.
• Iekšējais analītiķu portāls attēlo rezultātus.
• Klienta sistēma izgūst statusu vai lēmumus.
• Žurnāli, uzraudzības rīki un rezerves kopijas saņem kopijas.

Atzīmējiet katru uzticamības robežu: internets uz lietojumprogrammu, lietojumprogramma uz API, iekšējais pakalpojums uz piegādātāju, ražošanas sistēma uz analītiku, administrators uz priviliģētu funkciju un ražošanas vide uz neprodukcijas vidi.

3. Izmantojiet STRIDE kopā ar ļaunprātīgas izmantošanas scenārijiem

Katrai robežai uzdodiet STRIDE jautājumus un rakstiet ļaunprātīgas izmantošanas scenārijus vienkāršā biznesa valodā. Mērķis nav uzskaitīt visus iedomājamos uzbrukumus. Mērķis ir identificēt ticamus, būtiskus scenārijus, kas ietekmē konfidencialitāti, integritāti, pieejamību, privātumu, noturību vai drošumu.

4. Pārvērtiet konstatējumus riska scenārijos

Izmantojiet ZB 9. soļa formulu:

“[Apdraudējums] izmanto [ievainojamību] uz [aktīva], kā rezultātā rodas [ietekme].”

Piemēram:

“Uzbrucējs izmanto vājus objektu krātuves piekļuves kontroles pasākumus identitātes dokumentu repozitorijā, kā rezultātā notiek nesankcionēta personas datu izpaušana un rodas regulatīvās paziņošanas risks.”

Pēc tam pievienojiet īpašnieku, varbūtību, ietekmi, sākotnējo risku, riska apstrādes variantu, mērķa kontroles pasākumu, atlikušā riska vērtējumu un pierādījumus.

5. Atvasiniet prasības un testus

Draudu modelis nav pabeigts, kad riski ir uzskaitīti. Tas ir pabeigts, kad mazināšanas pasākumi ir ieviesti, testēti vai formāli akceptēti.

Izmaiņu pārvaldības politika - SME dod praktisku trigeri:

“Ja izmaiņa ietver sensitīvus datus, sistēmas piekļuves tiesības vai ārējās integrācijas, ir nepieciešama drošības ietekmes pārskatīšana. Norīkotajai drošības vai atbilstības kontaktpersonai jāizvērtē, vai izmaiņa ievieš papildu riskus, un jāiesaka papildu drošības pasākumi.”
No sadaļas “Risku apstrāde un izņēmumi”, politikas punkts 7.5.1.

Sensitīvi dati, piekļuves tiesības un ārējās integrācijas ir tieši tās izmaiņas, kurām nepieciešama projektēšanas riska pārskatīšana.

Ko jautās dažādi auditori

ISO/IEC 27001:2022 auditors jautās, vai draudu modelēšana ir daļa no definēta risku novērtēšanas procesa, vai kritēriji ir konsekventi, vai riska īpašnieki apstiprināja atlikušos riskus, vai risku apstrādes plāni ir sasaistīti ar SoA un vai pierādījumi tiek glabāti. Viņš meklēs atkārtojamību, versiju vēsturi, redzamību vadības pārskatīšanā un iekšējā audita pārklājumu.

Attiecībā uz A pielikumu auditors sasaistīs jūsu pierādījumus ar 5.8, 8.25, 8.26, 8.27 un 8.29. ZB 21. solis “Kontroles pasākumi darbībā” izceļ drošu sistēmu arhitektūru un inženierijas principus, jautājot, kuri principi vada drošu arhitektūru. Auditori var jautāt, vai draudu modelēšana tiek veikta projektēšanas laikā, izmantojot tādas metodes kā STRIDE vai uzbrukumu koki, un vai arhitektūras lēmumi tiek pārskatīti pirms ieviešanas.

NIS2 pārskatītājs koncentrēsies uz pārvaldību un samērīgumu. Viņš var jautāt, vai vadība apstiprināja kiberdrošības riska pārvaldības pieeju, vai ir aptverta droša iegāde, izstrāde un uzturēšana, vai tiek ņemtas vērā piegādātāju ievainojamības, vai incidentu scenāriji ir sasaistīti ar ziņošanas darbplūsmām un vai tiek analizēti nepārtrauktības scenāriji. NIS2 Article 23 pakāpeniskā ziņošana par nozīmīgiem incidentiem, tostarp agrīnais brīdinājums 24 stundu laikā, paziņojums 72 stundu laikā un gala ziņojums viena mēneša laikā, padara scenāriju skaidrību īpaši vērtīgu.

DORA pārbaudītājs koncentrēsies uz IKT risku pārvaldību, kritiskajām funkcijām, IKT aktīviem, ārējām atkarībām, noturības testēšanu un IKT trešo pušu pakalpojumiem. Ja sistēma atbalsta kritisku vai svarīgu funkciju, tiks sagaidīti spēcīgāki pierādījumi, kas sasaista apdraudējumu scenārijus ar aktīvu uzskaitēm, atkarību kartēm, testēšanas plāniem, trešo pušu līgumiem un atjaunošanas pasākumiem.

Privātuma pārskatītājs pārbaudīs datu plūsmas un jautās, vai personas datu apstrāde ir nepieciešama, likumīga, minimizēta un aizsargāta. Viņš jautās, vai ir iesaistīti īpašu kategoriju personas dati, vai tiek izmantota pseidonimizācija vai šifrēšana, vai glabāšana ir pamatota un vai nepieciešams DPIA. Draudu modelēšana un DPIA ir dažādas darbības, taču tām jāizmanto kopīgas diagrammas, scenāriji un mazināšanas pasākumi.

NIST CSF vai COBIT 2019 orientēts pārskatītājs meklēs pārvaldību, procesa īpašumtiesības, veiktspēju, pārskatatbildību un nepārtrauktu uzlabošanu. Viņu var mazāk interesēt pati STRIDE darba lapa, bet vairāk tas, vai process ir uzticams, mērīts, apstiprināts un uzlabots.

Biežākās draudu modelēšanas pierādījumu kļūdas

Biežākās kļūdas nav tehniskas. Tās ir pierādījumu kļūdas.

Komandas veic draudu modelēšanu pārāk vēlu, kad sistēma jau ir uzbūvēta. Šajā brīdī darbnīca kļūst par instruktāžu pirms ielaušanās testēšanas, nevis par projektēšanas kontroles pasākumu.

Konstatējumi netiek pārvērsti risku valodā. “Pievienot autentifikāciju” vai “žurnālfiksēšanas problēma” var palīdzēt inženieriem, bet auditoriem vajadzīgs aktīvs, apdraudējums, ievainojamība, ietekme, īpašnieks, apstrāde un atlikušais risks.

Privātums un drošība tiek nodalīti. Viena komanda dokumentē identitātes viltošanas un injekciju risku, bet cita dokumentē glabāšanu un tiesisko pamatu. GDPR pārskatatbildība darbojas labāk, ja datu plūsmas, ļaunprātīgas izmantošanas scenāriji un DPIA trigeri ir savienoti.

Piegādātāju pieņēmumi paliek nedokumentēti. NIS2, DORA un NIST CSF visi paaugstina gaidas attiecībā uz IKT piegādes ķēdes risku. Ja mazināšanas pasākums ir atkarīgs no piegādātāja šifrēšanas, žurnālfiksēšanas, dzēšanas, noturības vai incidentu reaģēšanas, savāciet pierādījumus.

Testi netiek kartēti atpakaļ uz apdraudējumiem. Ielaušanās testu pārskats var būt noderīgs, taču tas var nepierādīt, ka konkrētie projektēšanas riski tika mazināti. Katram būtiskam apdraudējuma konstatējumam jābūt validācijas pierādījumiem.

Atlikušā riska pieņemšana ir neformāla. “Pieņemam to MVP vajadzībām” nav pietiekami. ISO/IEC 27001:2022 sagaida, ka atbilstošie riska īpašnieki pieņem atlikušos riskus kā dokumentētu informāciju.

Jūsu 2026. gada draudu modelēšanas pierādījumu pakete

Katrai būtiskai sistēmai vai nozīmīgai izmaiņai uzturiet standarta pierādījumu paketi, kas var atbalstīt ISO 27001, NIS2, DORA, CRA, GDPR un klientu apliecinājumus.

Risku pārvaldības politika - SME labi atspoguļo darbības modeli:

“Tā nodrošina, ka risku pārvaldība ir aktīva plānošanas, projektu izpildes, piegādātāju atlases un incidentu reaģēšanas sastāvdaļa, saskaņā ar ISO 27001, ISO 31000 un piemērojamajām regulatīvajām prasībām.”
No sadaļas “Mērķis”, politikas punkts 1.2.

Tas ir pareizais mērķis. Draudu modelēšanai jāietekmē plānošana, inženierija, piegādātāju atlase, incidentu reaģēšana un gatavība auditam.

Padariet draudu modelēšanu auditam gatavu pirms nākamā laidiena

Organizācijas, kas vislabāk tiks galā ar 2026. gada atbilstības spiedienu, nav tās, kurām ir visvairāk diagrammu. Tās ir organizācijas, kas var pierādīt vienkāršu ķēdi:

Projektēšanas risks tika identificēts. Risks tika novērtēts. Kontroles pasākumi tika atlasīti. Mazināšanas pasākumi tika ieviesti. Testi validēja mazināšanas pasākumus. Atlikušais risks tika apstiprināts. Pierādījumi ir kartēti uz būtiskajiem ietvariem.

Sāciet ar vienu augsta riska izmaiņu: maksājumu integrāciju, jaunu API, AI iespējotu darbplūsmu, identitātes funkciju, migrāciju uz mākoņvidi, klientiem pieejamu produkta laidienu vai ar piegādātāju savienotu pakalpojumu. Veiciet 90 minūšu projektēšanas riska sprintu. Izmantojiet ZB, lai pārvērstu konstatējumus riska scenārijos, risku apstrādes plānos un SoA izsekojamībā. Izmantojiet ZC, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus, piemēram, 5.8, 8.25, 8.26, 8.27 un 8.29, uz atbalstošiem kontroles pasākumiem, piegādātāju risku, privātumu, testēšanu un audita pierādījumiem. Saskaņojiet P24, P06, P17, P24S un savu izmaiņu pārvaldības procedūru, lai draudu modelēšana kļūtu obligāta, atkārtojama un pārskatāma.

Ja vēlaties Clarysec atbalstu, sāciet ar draudu modelēšanas pierādījumu pārskatīšanu. Mēs izvērtēsim vienu reālu projektu, identificēsim trūkumus pret ISO/IEC 27001:2022, NIS2, DORA, CRA un GDPR gaidām un sniegsim praktisku trūkumu novēršanas ceļkarti, ko sapratīs gan jūsu inženieri, gan auditori, gan valde.