Modeliranje groženj za ISO 27001, NIS2 in DORA

Anya, vodja informacijske varnosti v hitro rastočem fintech podjetju, je morala odobriti načrt uvedbe nove B2B platforme za ocenjevanje plačilnih tveganj. Upravni odbor je želel vstop na trg še pred koncem četrtletja. Prodaja je že pridobila bančne stranke. Inženiring je zasnoval izvorno oblačno arhitekturo z atributi identitete, signali naprav, metapodatki transakcij, vedenjskimi ocenami tveganja, upravljano podatkovno bazo in zunanjim ponudnikom analitike.

Na papirju je platforma delovala kot komercialni preboj. Za Anyo pa je pomenila pet vzporednih pogovorov o skladnosti.

Kot ponudnik finančne tehnologije je bilo podjetje pod pritiskom DORA. Kot ponudnik storitev v oblaku in digitalne platforme je moralo razumeti svojo izpostavljenost po NIS2. Ker je platforma obdelovala osebne podatke posameznikov iz EU, se je uporabljal GDPR. Podjetniški naročniki so pričakovali certifikacijo ISO/IEC 27001:2022. Če bi storitev postala del povezanega programskega izdelka, bi pričakovanja Cyber Resilience Act dodala še dokazila o vgrajeni varnosti izdelka.

Razvojna ekipa je predlagala običajen varnostni načrt: pregled odvisnosti, skeniranje ranljivosti, naročilo penetracijskega testiranja in namestitev popravkov za kritične ugotovitve pred prehodom v produkcijo. Anya je vedela, da to ni dovolj. Te dejavnosti preverjajo, kar je že zgrajeno. Ne dokazujejo, da je bila arhitektura zasnovana varno, da so bile meje zaupanja razumljene, da so bili tokovi osebnih podatkov minimizirani, da so bile predpostavke o dobaviteljih pregledane ali da so bili scenariji motenj storitve obravnavani pred uvedbo.

Zato je sestanek upočasnila s štirimi vprašanji:

1. Kje so meje zaupanja?
2. Kateri primeri zlorabe bi lahko povzročili goljufijo, razkritje podatkov ali motnjo storitve?
3. Katere odločitve v zasnovi zmanjšajo tveganje še pred pisanjem kode?
4. Katera dokazila bodo čez šest mesecev zadovoljila presojevalce za ISO 27001, NIS2, DORA, CRA in GDPR?

Pri četrtem vprašanju veliko organizacij odpove. Modeliranje groženj se pogosto obravnava kot koristen inženirski delovni sestanek, nato pa se zakoplje na wiki strani. V letu 2026 to ne zadostuje. Za ponudnike SaaS, fintech podjetja, oblačne platforme, ponudnike upravljanih storitev (MSP), ponudnike upravljanih varnostnih storitev (MSSP), upravljavce digitalne infrastrukture in proizvajalce programske opreme je modeliranje groženj postalo mehanizem za dokazovanje skladnosti.

Zrel proces modeliranja groženj pretvori ugotovitve STRIDE, primere zlorabe in arhitekturne odločitve v vnose v register tveganj, varnostne zahteve, načrte obravnave tveganj, testne primere, naloge zagotavljanja zaupanja pri dobaviteljih, dokazila o vgrajenem varstvu zasebnosti in sledljivost do izjave o uporabnosti.

Zakaj so dokazila o vgrajeni varnosti zdaj pomembna

Sodobni predpisi se zbližujejo okoli istega pričakovanja: organizacije morajo zgodaj prepoznati varnostna tveganja in tveganja za zasebnost, določiti lastništvo, implementirati sorazmerne kontrole in hraniti dokazila.

ISO/IEC 27001:2022 zahteva sistem upravljanja informacijske varnosti (ISMS), ki temelji na tveganjih. Točki 6.1.2 in 6.1.3 zahtevata oceno tveganj informacijske varnosti in obravnavo tveganj. Točka 8.1 zahteva operativno načrtovanje in nadzor. Priloga A določa kontrole, ki jih je treba izbrati prek izjave o uporabnosti na podlagi tveganj, zakonskih zahtev in poslovnih potreb.

NIS2 isto načelo prenaša v upravljanje kibernetske varnosti. Article 20 zahteva, da organi upravljanja odobrijo ukrepe za upravljanje kibernetskih tveganj in nadzirajo njihovo izvajanje. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varnostjo pri nabavi, razvoju in vzdrževanju, obravnavo ranljivosti, kibernetsko higieno, šifriranjem, nadzorom dostopa, upravljanjem sredstev in večfaktorsko avtentikacijo, kjer je to primerno.

DORA od 17. januarja 2025 uporablja pogled operativne odpornosti finančnega sektorja. Zajetim finančnim subjektom nalaga vzpostavitev zanesljivega, celovitega in dokumentiranega okvira upravljanja IKT-tveganj, identifikacijo IKT-sredstev in odvisnosti, uporabo zaščitnih in preventivnih ukrepov, zaznavanje anomalnih dejavnosti, testiranje digitalne operativne odpornosti, upravljanje tveganj tretjih ponudnikov storitev IKT ter vzpostavitev zmogljivosti za odziv in obnovitev. Za zajete finančne subjekte je DORA sektorski pravni akt Unije za prekrivajoče se obveznosti NIS2.

GDPR dodaja odgovornost ter vgrajeno in privzeto varstvo podatkov. Vsak sistem, ki obdeluje osebne podatke, mora biti sposoben dokazati zakonito, pošteno, pregledno, namensko omejeno, minimizirano, časovno omejeno in varno obdelavo. Model groženj, ki mapira tokove osebnih podatkov, poti dostopa, dnevnike, hrambo, brisanje in prenose tretjim osebam, je neposredno relevanten za GDPR Articles 5, 25, 32 in 35.

Cyber Resilience Act povečuje pritisk za izdelke z digitalnimi elementi. Produktne ekipe potrebujejo dokazila skozi življenjski cikel, ki kažejo, da so bila kibernetska tveganja, predvidljiva neustrezna uporaba, vmesniki, mehanizmi posodabljanja, tokovi avtentikacije in predpostavke o obravnavi ranljivosti obravnavani zgodaj.

Pouček je jasen: če arhitekturnega pregleda ni mogoče sledljivo povezati s tveganji, kontrolami, lastniki, ukrepi za ublažitev in testi, ga bo težko zagovarjati pri reviziji ali regulativnem pregledu v letu 2026.

Model Clarysec: en model groženj, več izhodov

Pristop Clarysec se začne s praktičnim načelom: model groženj ni dokončan, dokler ne ustvari odločitev, primernih za revizijo.

V Zenith Blueprint: 30-koračni načrt presojevalca [ZB] faza upravljanja tveganj, korak 9, ekipam daje enostaven format za pretvorbo tehničnih opažanj v jezik tveganj:

»Zdaj združite sredstvo + grožnjo + ranljivost v kratek opis scenarija tveganja. V bistvu opišite potencialni incident. To bo pozneje vrstična postavka v vašem registru tveganj. Uporabite preprost format: ‘[Grožnja] izkoristi [ranljivost] na [sredstvu], kar povzroči [vpliv].’«

Ta stavek je most med inženiringom in skladnostjo.

Zapis na beli tabli, kot je »tveganje lažnega predstavljanja partnerskega API«, postane:

»Napadalec izkoristi šibko avtentikacijo partnerskega API na API-ju za ocenjevanje transakcijskih tveganj, kar povzroči nepooblaščen dostop do odločitev o plačilnih tveganjih in razkritje osebnih podatkov.«

Ugotovitev ima zdaj sredstvo, grožnjo, ranljivost in vpliv. Lahko se oceni, dodeli, obravnava, testira in sprejme.

Sloj politik omogoča ponovljivost. P24 Politika varnega razvoja [P24] določa:

»Vse nove aplikacije in večje spremembe morajo pred začetkom razvoja prestati pregled varne arhitekture in modeliranje groženj.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.

Zahteva tudi:

»Pregledi zasnove morajo dokumentirati diagrame tokov podatkov, meje zaupanja in ukrepe za ublažitev za ugotovljena tveganja.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.2.

Ti dve klavzuli sta močni revizijski sidri. Kažeta, da modeliranje groženj ni izbirno in da morajo dokazila o zasnovi vključevati diagrame, meje in odločitve o ublažitvi.

P06 Politika upravljanja tveganj [P06] povezuje modeliranje groženj s korporativnim upravljanjem tveganj:

»Vse poslovne enote morajo proaktivno identificirati tveganja z uporabo strukturiranih tehnik, izpeljanih iz ISO/IEC 27005:2024, vključno z modeliranjem groženj, mapiranjem odvisnosti sredstev in identifikacijo na podlagi scenarijev.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.

Določa tudi:

»Ugotovljena tveganja morajo biti dokumentirana s sklicem na lastnika sredstva, akterja grožnje, ranljivost in možni vpliv na zaupnost, celovitost in razpoložljivost (CIA).«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.4.

To je veriga dokazil, ki jo želijo videti presojevalci: zahteva politike, dejavnost zasnove, scenarij tveganja, izbira kontrol, implementacija, testiranje in odobritev.

STRIDE zagotovi sistematično pokritost, primeri zlorabe pa realnost

STRIDE ostaja ena najbolj uporabnih metod za modeliranje groženj v fazi zasnove, ker ekipe prisili k obravnavi šestih pogostih načinov odpovedi:

• Lažno predstavljanje
• Poseganje
• Zanikanje dejanj
• Razkritje informacij
• Zavrnitev storitve
• Povišanje privilegijev

Za Anyino platformo za ocenjevanje plačilnih tveganj je ekipa uporabila STRIDE za vsako komponento, tok podatkov in mejo zaupanja.

Lažno predstavljanje je odprlo vprašanje, ali bi se odjemalec partnerskega API-ja lahko izdajal za bančno stranko, če bi bila vzajemna avtentikacija šibka. Poseganje je razkrilo tveganje, da bi bilo mogoče signale naprav ali zneske transakcij spremeniti pred zajemom. Zanikanje dejanj je poudarilo potrebo po administratorskih dnevnikih in revizijskih dnevnikih transakcij. Razkritje informacij se je osredotočilo na uhajanje prek dnevnikov, izvozov analitike, orodij za podporo in poročevalskih API-jev. Zavrnitev storitve je ekipo prisilila k obravnavi konic transakcij in poplav nepravilno oblikovanih zahtevkov. Povišanje privilegijev je razkrilo tveganja v podpornih vlogah, sejnih žetonih in administratorskih funkcijah.

Primeri zlorabe so te kategorije pretvorili v realne scenarije:

• Goljuf naloži manipulirane signale naprave, da vpliva na oceno tveganja.
• Kompromitirana partnerska poverilnica preplavi API z goljufivimi zahtevki.
• Razvijalec uporabi produkcijske osebne podatke v testnem okolju.
• Zlonamerni notranji uporabnik izvozi identifikatorje strank in logiko točkovanja.
• Izpad dobavitelja oblačne analitike blokira odločitve o tveganju med plačilnim oknom.
• Napačna konfiguracija shrambe izpostavi naložene identifikacijske dokumente.
• Delovni tok brisanja odstrani zapis aplikacije, vendar pusti varnostne kopije in kopije pri dobavitelju.

Vsak primer zlorabe je postal zapis o zasnovnem tveganju z zadevnim sredstvom, akterjem grožnje, ranljivostjo, vplivom, obstoječimi predpostavkami, zahtevanim ukrepom za ublažitev, lastnikom preostalega tveganja, testnimi dokazili in regulativno relevantnostjo.

Takšna struktura preprečuje nejasne ugotovitve, kot je »tveganje varnosti API«. Ustvari izjave o tveganju na ravni dokazil, na primer:

»Napadalec uporabi ukradene partnerske poverilnice za oddajo goljufivih zahtevkov za točkovanje prek API-ja za ocenjevanje transakcijskih tveganj, kar povzroči ogrožanje celovitosti odločitev o tveganju, možno finančno izgubo za stranke in nepooblaščeno obdelavo osebnih podatkov.«

Mapiranje modeliranja groženj na ISO/IEC 27001:2022 in ISO/IEC 27002:2022

ISO/IEC 27001:2022 modeliranja groženj ne zahteva izrecno po imenu. Zahteva dosledno, dokumentirano oceno tveganj in obravnavo tveganj. Modeliranje groženj je ena najmočnejših metod za ustvarjanje teh dokazil v okoljih programske opreme, oblaka in izdelkov.

Ključna je sledljivost. V ZB faza upravljanja tveganj, korak 13, priporoča mapiranje kontrol na tveganja in klavzule, vključno s sklici na Prilogo A v načrtih obravnave tveganj ter navedbo, kje kontrole podpirajo GDPR, NIS2 ali DORA.

Zenith Controls: vodnik za navzkrižno skladnost [ZC] pomaga strukturirati to sledljivost z mapiranjem kontrol ISO/IEC 27002:2022 na povezane kontrole, revizijska pričakovanja in zunanje okvire.

Za modeliranje groženj je kontrola ISO/IEC 27002:2022 5.8, informacijska varnost pri vodenju projektov, sidro projektnega upravljanja. Kaže, da je varnost vključena v začetek, načrtovanje, izvedbo in sprejem projekta.

Kontrola 8.25, varen življenjski cikel razvoja, je sidro SDLC. ZC povezuje 8.25 s podpornimi kontrolami, kot so 8.26 zahteve informacijske varnosti na ravni aplikacij, 8.27 načela varne sistemske arhitekture in inženiringa, 8.28 varno kodiranje, 8.29 varnostno testiranje pri razvoju in sprejemu, 8.30 zunanji razvoj in 8.31 ločitev razvojnih, testnih in produkcijskih okolij.

To mapiranje pomaga pretvoriti delavnico zasnove v dokazila za izjavo o uporabnosti. Podpira tudi točke ISO/IEC 27001:2022 od 4 do 6, ker so zahteve zainteresiranih strani, obseg ISMS, zaveze vodstva in odločitve o obravnavi tveganj vidne.

Zemljevid navzkrižne skladnosti za NIS2, DORA, CRA, GDPR in NIST CSF

Dobro izveden model groženj ne sme ustvariti petih nepovezanih tokov dela za skladnost. Ustvariti mora en paket dokazil o zasnovnih tveganjih, ki ga je mogoče ponovno uporabiti v različnih okvirih.

NIST CSF 2.0 je posebej uporaben za komuniciranje z izvršnim vodstvom. Njegova funkcija GOVERN podpira pravne, regulativne, pogodbene obveznosti in obveznosti glede zasebnosti, njegovi rezultati za dobavno verigo pa pomagajo povezati kritičnost dobaviteljev, pogodbene zahteve, skrbni pregled, spremljanje in načrtovanje incidentov z istimi dokazili modela groženj.

GDPR zahteva posebno pozornost, ker se morata modeliranje groženj in delo na DPIA medsebojno krepiti. P17 Politika varstva podatkov in zasebnosti [P17] določa:

»Modeliranje groženj in ocene učinka v zvezi z varstvom podatkov (DPIA) so obvezne za sisteme obdelave z visokim tveganjem.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.4.

Za manjše ekipe P17S Politika varstva podatkov in zasebnosti - SME [P17S] določa:

»Vgrajeno in privzeto varstvo zasebnosti mora biti uveljavljeno v vseh novih sistemih in storitvah«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.1.

Rezultat je praktičen operativni model: uporabite iste diagrame tokov podatkov, meje zaupanja in primere zlorabe za varnostno tveganje, tveganje za zasebnost, pregled dobaviteljev in regulativna dokazila.

90-minutni sprint za zasnovna tveganja pri visoko tveganih funkcionalnostih

Modeliranje groženj se ne rabi začeti kot obsežen program. Za nov plačilni API, delovni tok uvajanja, funkcionalnost z umetno inteligenco, storitev identitete, migracijo v oblak ali zunanjo integracijo lahko 90-minutni sprint za zasnovna tveganja ustvari dragocena dokazila.

1. Odprite projektno varnostno kontrolno točko

Kot sprožilec uporabite klavzulo P24 6.1.1. Za vsako novo aplikacijo ali večjo spremembo ustvarite mapo z dokazili, ki vsebuje:

• Arhitekturni diagram
• Diagram tokov podatkov
• Zemljevid meja zaupanja
• Seznam sredstev
• Opombe o osebnih podatkih
• Seznam dobaviteljev in odvisnosti IKT
• Začetne varnostne zahteve
• Delovni list modela groženj
• Vnose v register tveganj
• Sledljivost ukrepov za ublažitev in testov
• Evidenco odobritve

Za manjše organizacije P24S Politika varnega razvoja - SME [P24S] podpira enako disciplino s povezovanjem procesov varnega razvoja z nadzorom dostopa razvijalcev, testiranjem, modeliranjem groženj in dokumentacijo. Zahteva tudi centralizirano hrambo kontrolnih seznamov, odobritev pregledov, poročil o testiranju in popisov komponent za potrebe revizije. Klavzula 11.3.1 se sklicuje na SA-3 do SA-15 za opredelitev procesov varnega razvoja, vključno z modeliranjem groženj.

2. Narišite minimalno izvedljiv tok podatkov

Ne začnite z izpiljenim diagramom. Začnite s tokovi, ki ustvarjajo tveganje:

• Uporabnik naloži identifikacijske dokumente ali transakcijske podatke.
• Spletna aplikacija pošlje zahtevke API-ju.
• API zapisuje v upravljano shrambo ali podatkovno bazo.
• Dobavitelj prejme podatke za preverjanje ali analitiko.
• Interni portal analitikov prikazuje rezultate.
• Sistem stranke pridobi status ali odločitve.
• Dnevniki, orodja za spremljanje in varnostne kopije prejmejo kopije.

Označite vsako mejo zaupanja: internet do aplikacije, aplikacija do API-ja, interna storitev do dobavitelja, produkcijski sistem do analitike, administrator do privilegirane funkcije in produkcija do neprodukcijskega okolja.

3. Izvajajte STRIDE in primere zlorabe skupaj

Za vsako mejo postavite vprašanja STRIDE in zapišite primere zlorabe v jasnem poslovnem jeziku. Cilj ni našteti vseh mogočih napadov. Cilj je identificirati verjetne, pomembne scenarije, ki vplivajo na zaupnost, celovitost, razpoložljivost, zasebnost, odpornost ali varnost.

4. Pretvorite ugotovitve v scenarije tveganj

Uporabite formulo iz ZB, korak 9:

»[Grožnja] izkoristi [ranljivost] na [sredstvu], kar povzroči [vpliv].«

Na primer:

»Napadalec izkoristi šibke kontrole dostopa do objektne shrambe na repozitoriju identifikacijskih dokumentov, kar povzroči nepooblaščeno razkritje osebnih podatkov in izpostavljenost regulatornemu obveščanju.«

Nato dodajte lastnika, verjetnost, vpliv, inherentno tveganje, možnost obravnave, ciljno kontrolo, preostalo tveganje in dokazila.

5. Izpeljite zahteve in teste

Model groženj ni končan, ko so tveganja navedena. Končan je, ko so ukrepi za ublažitev implementirani, testirani ali formalno sprejeti.

Politika upravljanja sprememb - SME daje praktičen sprožilec:

»Če sprememba vključuje občutljive podatke, pravice dostopa do sistema ali zunanje integracije, je potreben pregled varnostnega vpliva. Imenovana kontaktna oseba za varnost ali skladnost mora oceniti, ali sprememba uvaja dodatna tveganja, in priporočiti dodatne zaščitne ukrepe.«
Iz razdelka »Obravnava tveganj in izjeme«, klavzula politike 7.5.1.

Občutljivi podatki, pravice dostopa in zunanje integracije so prav tiste spremembe, ki zahtevajo pregled zasnovnih tveganj.

Kaj bodo vprašali različni presojevalci

Presojevalec ISO/IEC 27001:2022 bo vprašal, ali je modeliranje groženj del opredeljenega procesa ocenjevanja tveganj, ali so merila dosledna, ali so lastniki tveganj odobrili preostala tveganja, ali so načrti obravnave tveganj povezani z izjavo o uporabnosti in ali se dokazila hranijo. Iskal bo ponovljivost, evidenco različic, vidnost v vodstvenem pregledu in pokritost z notranjo revizijo.

Za Prilogo A bo dokazila povezal s 5.8, 8.25, 8.26, 8.27 in 8.29. ZB korak 21, Kontrole v praksi, poudarja načela varne sistemske arhitekture in inženiringa z vprašanjem, katera načela usmerjajo varno arhitekturo. Presojevalci lahko vprašajo, ali se modeliranje groženj izvaja med zasnovo z metodami, kot so STRIDE ali drevesa napadov, in ali se arhitekturne odločitve pregledajo pred implementacijo.

Pregledovalec NIS2 se bo osredotočil na upravljanje in sorazmernost. Lahko vpraša, ali je vodstvo odobrilo pristop k upravljanju kibernetskih tveganj, ali so zajeti varna nabava, razvoj in vzdrževanje, ali se upoštevajo ranljivosti dobaviteljev, ali so scenariji incidentov povezani z delovnimi tokovi poročanja in ali so analizirani scenariji neprekinjenega poslovanja. Zaradi faznega poročanja o pomembnih incidentih po NIS2 Article 23, vključno z zgodnjim opozorilom v 24 urah, obvestilom v 72 urah in končnim poročilom v enem mesecu, je jasnost scenarijev posebej dragocena.

Preiskovalec DORA se bo osredotočil na upravljanje IKT-tveganj, kritične funkcije, IKT-sredstva, zunanje odvisnosti, testiranje odpornosti in storitve tretjih ponudnikov storitev IKT. Če sistem podpira kritično ali pomembno funkcijo, bo pričakoval močnejša dokazila, ki povezujejo scenarije groženj s popisi sredstev, zemljevidi odvisnosti, načrti testiranja, pogodbami s tretjimi osebami in ukrepi obnovitve.

Pregledovalec zasebnosti bo pregledal tokove podatkov in vprašal, ali je obdelava osebnih podatkov potrebna, zakonita, minimizirana in zaščitena. Vprašal bo, ali so vključene posebne vrste podatkov, ali se uporablja psevdonimizacija ali šifriranje, ali je hramba utemeljena in ali je potrebna DPIA. Modeliranje groženj in DPIA sta različni dejavnosti, vendar si morata deliti diagrame, scenarije in ukrepe za ublažitev.

Pregledovalec, usmerjen v NIST CSF ali COBIT 2019, bo iskal upravljanje, lastništvo procesov, uspešnost, odgovornost in nenehno izboljševanje. Morda ga bo manj zanimal sam delovni list STRIDE, bolj pa to, ali je proces zanesljiv, merjen, odobren in izboljševan.

Pogoste napake pri dokazilih modeliranja groženj

Najpogostejše napake niso tehnične. So napake pri dokazilih.

Ekipe modeliranje groženj izvedejo prepozno, ko je sistem že zgrajen. Takrat delavnica postane priprava na penetracijsko testiranje, ne pa kontrola zasnove.

Ugotovitve niso pretvorjene v jezik tveganj. »Dodaj auth« ali »težava z beleženjem« lahko pomaga inženirjem, vendar presojevalci potrebujejo sredstvo, grožnjo, ranljivost, vpliv, lastnika, obravnavo in preostalo tveganje.

Zasebnost in varnost sta ločeni. Ena ekipa dokumentira tveganja lažnega predstavljanja in vrivanja, druga pa hrambo in pravno podlago. Odgovornost po GDPR deluje bolje, ko so tokovi podatkov, primeri zlorabe in sprožilci DPIA povezani.

Predpostavke o dobaviteljih ostanejo nedokumentirane. NIS2, DORA in NIST CSF vsi zvišujejo pričakovanja glede tveganj dobavne verige IKT. Če je ukrep za ublažitev odvisen od dobaviteljevega šifriranja, beleženja, brisanja, odpornosti ali odziva na incidente, zberite dokazila.

Testi niso povezani nazaj z grožnjami. Poročilo o penetracijskem testiranju je lahko koristno, vendar ne dokazuje nujno, da so bila specifična zasnovna tveganja ublažena. Vsaka večja ugotovitev o grožnji mora imeti validacijska dokazila.

Sprejem preostalega tveganja je neformalen. »To sprejmemo za MVP« ni dovolj. ISO/IEC 27001:2022 pričakuje sprejem preostalega tveganja s strani ustreznih lastnikov tveganj kot dokumentirane informacije.

Vaš paket dokazil modeliranja groženj za leto 2026

Za vsak večji sistem ali pomembno spremembo hranite standardni paket dokazil, ki lahko podpira ISO 27001, NIS2, DORA, CRA, GDPR in zagotavljanje zaupanja naročnikov.

Politika upravljanja tveganj - SME dobro povzema operativni model:

»Zagotavlja, da je upravljanje tveganj aktiven del načrtovanja, izvajanja projektov, izbire dobaviteljev in odzivanja na incidente, v skladu z ISO 27001, ISO 31000 in veljavnimi regulativnimi zahtevami.«
Iz razdelka »Namen«, klavzula politike 1.2.

To je pravi cilj. Modeliranje groženj mora vplivati na načrtovanje, inženiring, izbiro dobaviteljev, odziv na incidente in pripravljenost na revizijo.

Pred naslednjo izdajo pripravite modeliranje groženj na revizijo

Organizacije, ki bodo najbolje obvladale pritiske skladnosti v letu 2026, niso tiste z največ diagrami. To so organizacije, ki lahko dokažejo preprosto verigo:

Zasnovno tveganje je bilo identificirano. Tveganje je bilo ocenjeno. Kontrole so bile izbrane. Ukrepi za ublažitev so bili implementirani. Testi so validirali ukrepe za ublažitev. Preostalo tveganje je bilo odobreno. Dokazila so mapirana na relevantne okvire.

Začnite z eno visoko tvegano spremembo: plačilno integracijo, novim API-jem, delovnim tokom z umetno inteligenco, funkcionalnostjo identitete, migracijo v oblak, izdajo izdelka za stranke ali storitvijo, povezano z dobaviteljem. Izvedite 90-minutni sprint za zasnovna tveganja. Uporabite ZB za pretvorbo ugotovitev v scenarije tveganj, načrte obravnave tveganj in sledljivost izjave o uporabnosti. Uporabite ZC za mapiranje kontrol ISO/IEC 27002:2022, kot so 5.8, 8.25, 8.26, 8.27 in 8.29, na podporne kontrole, tveganje dobaviteljev, zasebnost, testiranje in revizijska dokazila. Uskladite P24, P06, P17, P24S in svoj postopek upravljanja sprememb, da modeliranje groženj postane obvezno, ponovljivo in preverljivo.

Če želite pomoč Clarysec, začnite s pregledom dokazil modeliranja groženj. Ocenili bomo en dejanski projekt, identificirali vrzeli glede na pričakovanja ISO/IEC 27001:2022, NIS2, DORA, CRA in GDPR ter vam pripravili praktičen časovni načrt odprave pomanjkljivosti, ki ga bodo razumeli vaši inženirji, presojevalci in upravni odbor.