Ohumodelleerimine ISO 27001, NIS2 ja DORA nõuete täitmiseks

Anya, kiiresti kasvava finantstehnoloogia ettevõtte infoturbejuht, pidi heaks kiitma uue B2B makseriski platvormi turuletoomise plaani. Juhatus soovis turule jõuda enne kvartali lõppu. Müügimeeskond oli pangakliendid juba ette valmistanud. Arendusmeeskond oli visandanud pilvepõhise arhitektuuri, mis kasutas identiteedi atribuute, seadmesignaale, tehingute metaandmeid, käitumuslikke riskiskoore, hallatavat andmebaasi ja kolmanda osapoole analüütikateenuse pakkujat.

Paberil näis platvorm ärilise läbimurdena. Anya jaoks tähendas see viit nõuetelevastavuse arutelu korraga.

Finantstehnoloogia teenusepakkujana oli ettevõttel surve seoses DORA-ga. Pilveteenuse ja digiplatvormi pakkujana pidi ta mõistma oma NIS2 riskikokkupuudet. Kuna platvorm töötles EL-i isikutega seotud isikuandmeid, kohaldus GDPR. Ärikliendid ootasid ISO/IEC 27001:2022 sertifitseerimist. Kui teenus muutuks digielementidega ühendatud tarkvaratoote osaks, lisanduksid küberkerksuse määruse ootused turvalisuse kavandamise põhimõtte tootetõendusmaterjali kohta.

Arendusmeeskond pakkus välja tavapärase turbeplaani: skannida sõltuvused, teha haavatavuse skannimine, tellida penetratsioonitest ja parandada kriitilised leiud enne tootmiskeskkonda kasutuselevõttu. Anya teadis, et sellest ei piisa. Need tegevused testivad seda, mis on juba valmis ehitatud. Need ei tõenda, et arhitektuur kavandati turvaliselt, et usalduspiirid olid mõistetud, et isikuandmete vood olid minimeeritud, et tarnijaeeldused olid läbi vaadatud või et teenusekatkestuse stsenaariume oli enne turuletoomist käsitletud.

Seetõttu peatas ta koosoleku nelja küsimusega:

1. Kus asuvad usalduspiirid?
2. Millised väärkasutusstsenaariumid võivad viia pettuse, andmete avalikustumise või teenusekatkestuseni?
3. Millised arhitektuuriotsused vähendavad riski enne koodi kirjutamist?
4. Milline tõendusmaterjal rahuldab ISO 27001, NIS2, DORA, CRA ja GDPR läbivaatajaid kuue kuu pärast?

Just neljas küsimus on koht, kus paljud organisatsioonid läbi kukuvad. Ohumodelleerimist käsitletakse sageli kasuliku inseneritöö töötoana ja seejärel maetakse see wiki-lehele. 2026. aastal sellest enam ei piisa. SaaS-i pakkujate, finantstehnoloogia ettevõtete, pilveplatvormide, MSP-de, MSSP-de, digitaristu operaatorite ja tarkvaratootjate jaoks on ohumodelleerimisest saanud nõuetelevastavuse tõendusmaterjali loomise mootor.

Küps ohumodelleerimise protsess muudab STRIDE-i leiud, väärkasutusstsenaariumid ja arhitektuuriotsused riskiregistri kirjeteks, turbenõueteks, käsitlusplaanideks, testjuhtumiteks, tarnija kinnitustaotlusteks, lõimitud andmekaitse tõendusmaterjaliks ja kohaldatavusdeklaratsiooni jälgitavuseks.

Miks turvalisuse kavandamise põhimõtte tõendusmaterjal on nüüd oluline

Kaasaegsed regulatsioonid koonduvad sama ootuse ümber: organisatsioonid peavad turbe- ja privaatsusriskid varakult tuvastama, määrama vastutuse, rakendama proportsionaalseid kontrollimeetmeid ja säilitama tõendusmaterjali.

ISO/IEC 27001:2022 nõuab riskipõhist infoturbe juhtimissüsteemi. Punktid 6.1.2 ja 6.1.3 nõuavad infoturbe riskihindamist ja riskikäsitlust. Punkt 8.1 nõuab tegevuse planeerimist ja ohjet. Lisa A sisaldab kontrollimeetmeid, mis tuleb valida kohaldatavusdeklaratsiooni kaudu riski, õiguslike nõuete ja ärivajaduste põhjal.

NIS2 toob sama põhimõtte küberturbe juhtimisse. Article 20 nõuab, et juhtorganid kiidaksid küberturvalisuse riskijuhtimismeetmed heaks ja teostaksid rakendamise üle järelevalvet. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvet hankimisel, arendamisel ja hooldusel, haavatavuste käsitlemist, küberhügieeni, krüptimist, juurdepääsukontrolli, varahaldust ja vajaduse korral MFA-d.

DORA rakendab finantssektorile digitaalse tegevuskerksuse vaadet alates 17. jaanuarist 2025. See nõuab hõlmatud finantsüksustelt usaldusväärse, tervikliku ja dokumenteeritud IKT-riski juhtimise raamistiku hoidmist, IKT-varade ja sõltuvuste tuvastamist, kaitsvate ja ennetavate meetmete rakendamist, anomaalse tegevuse tuvastamist, digitaalse tegevuskerksuse testimist, IKT kolmanda osapoole riski juhtimist ning reageerimis- ja taastevõimekuse ettevalmistamist. Hõlmatud finantsüksuste jaoks on DORA sektoripõhine liidu õigusakt NIS2 kattuvate kohustuste täitmiseks.

GDPR lisab vastutuse ning lõimitud andmekaitse ja vaikimisi andmekaitse. Iga isikuandmeid töötlev süsteem peab suutma tõendada seaduslikku, õiglast, läbipaistvat, eesmärgipõhist, minimaalse andmemahuga, säilitamispiiranguga ja turvalist töötlemist. Ohumudel, mis kaardistab isikuandmete vood, juurdepääsuteed, logid, säilitamise, kustutamise ja kolmandatele osapooltele edastamise, on otseselt asjakohane GDPR Articles 5, 25, 32 ja 35 kontekstis.

Küberkerksuse määrus lisab survet digielementidega toodetele. Tootemeeskonnad vajavad elutsüklipõhist tõendusmaterjali, mis näitab, et küberturberiske, ettenähtavat väärkasutust, liideseid, uuendusmehhanisme, autentimisvooge ja haavatavuste käsitlemise eeldusi kaaluti varakult.

Järeldus on selge: kui arhitektuuriülevaatust ei saa siduda riskide, kontrollimeetmete, omanike, maandamismeetmete ja testidega, on seda 2026. aasta auditis või regulatiivsel läbivaatamisel raske kaitsta.

Claryseci mudel: üks ohumudel, mitu väljundit

Claryseci lähenemine algab praktilisest põhimõttest: ohumudel ei ole valmis enne, kui see annab auditeerimiseks sobivad otsused.

Zenith Blueprint: audiitori 30-sammuline teekaart [ZB] annab riskijuhtimise etapis, sammus 9, meeskondadele lihtsa vormingu tehniliste tähelepanekute teisendamiseks riskikeelde:

„Nüüd ühenda vara + oht + haavatavus lühikeseks riskistsenaariumi kirjelduseks. Sisuliselt kirjelda võimalikku intsidenti. Hiljem saab sellest rida sinu riskiregistris. Kasuta lihtsat vormingut: „[Oht] kasutab ära [haavatavust] varal [vara], mille tulemuseks on [mõju].“”

See lause on sild inseneritöö ja nõuetelevastavuse vahel.

Tahvlimärkus, näiteks „partneri API identiteedi võltsimise risk“, muutub järgmiseks:

„Ründaja kasutab tehinguriski API-s ära nõrka partneri API autentimist, mille tulemuseks on loata juurdepääs makseriski otsustele ja isikuandmete avalikustumine.“

Nüüd on leiul vara, oht, haavatavus ja mõju. Seda saab hinnata, omanikule määrata, käsitleda, testida ja aktsepteerida.

Poliitikakiht muudab selle korratavaks. P24 Turvalise arenduse poliitika [P24] sätestab:

„Kõik uued rakendused ja olulised muudatused peavad enne arenduse algust läbima turvalise arhitektuuri ülevaatuse ja ohumodelleerimise.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.1.1.

See nõuab ka järgmist:

„Disainiülevaatused peavad dokumenteerima andmevoogude skeemid, usalduspiirid ja tuvastatud riskide maandamismeetmed.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.1.2.

Need kaks punkti on tugevad auditiankrud. Need näitavad, et ohumodelleerimine ei ole valikuline ning et disaini tõendusmaterjal peab sisaldama skeeme, piire ja maandamisotsuseid.

P06 Riskijuhtimise poliitika [P06] seob ohumodelleerimise ettevõtte riskijuhtimisega:

„Kõik äriüksused peavad proaktiivselt tuvastama riske ISO/IEC 27005:2024-st lähtuvate struktureeritud meetodite abil, sealhulgas ohumodelleerimise, varasõltuvuste kaardistamise ja stsenaariumipõhise tuvastamisega.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.1.1.

Samuti sätestab see:

„Tuvastatud riskid tuleb dokumenteerida viitega varaomanikule, ohutegijale, haavatavusele ning võimalikule mõjule konfidentsiaalsusele, terviklusele ja käideldavusele (CIA).“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.1.4.

See on tõendusahel, mida audiitorid soovivad näha: poliitikanõue, disainitegevus, riskistsenaarium, kontrollimeetmete valik, rakendamine, testimine ja heakskiit.

STRIDE muudab katvuse süsteemseks, väärkasutusstsenaariumid muudavad selle realistlikuks

STRIDE on jätkuvalt üks kasulikumaid meetodeid kavandamisetapi ohumodelleerimiseks, sest see sunnib meeskondi arvestama kuue levinud tõrkerežiimiga:

• identiteedi võltsimine
• volitamata muutmine
• salgamine
• teabe avalikustumine
• teenusetõkestus
• privileegide eskaleerimine

Anya makseriski platvormi puhul kasutas meeskond STRIDE-i iga komponendi, andmevoo ja usalduspiiri puhul.

Identiteedi võltsimine tõstatas küsimuse, kas partneri API klient saaks nõrga vastastikuse autentimise korral esineda pangakliendina. Volitamata muutmine tõi esile riski, et seadmesignaale või tehingusummasid võidakse enne sisestamist manipuleerida. Salgamine rõhutas administraatori- ja tehingute auditilogide vajadust. Teabe avalikustumine keskendus lekkimisele logide, analüütikaekspordi, tugivahendite ja aruandlus-API-de kaudu. Teenusetõkestus sundis meeskonda kaaluma tehingute tippkoormuse aknaid ja vigaste päringute tulva. Privileegide eskaleerimine tõi esile riskid tugirühmades, seansitokenites ja haldusfunktsioonides.

Väärkasutusstsenaariumid muutsid need kategooriad tegelikeks lugudeks:

• Pettur laadib üles manipuleeritud seadmesignaale, et mõjutada riskiskoori.
• Kompromiteeritud partneri autentimisandmed ujutavad API üle petturlike päringutega.
• Arendaja kasutab tootmiskeskkonna isikuandmeid testkeskkonnas.
• Pahatahtlik siseringi isik ekspordib kliendi identifikaatorid ja skoorimisloogika.
• Pilveanalüütika tarnija katkestus blokeerib makseakna ajal riskiotsused.
• Salvestusruumi väärkonfiguratsioon avalikustab üleslaaditud isikut tõendavad dokumendid.
• Kustutamise töövoog eemaldab rakenduse kirje, kuid jätab alles varukoopiad ja tarnija koopiad.

Iga väärkasutusstsenaarium muutus disainiriski kirjeks, mis sisaldas mõjutatud vara, ohutegijat, haavatavust, mõju, olemasolevaid eeldusi, nõutavat maandamismeedet, jääkriski omanikku, testitõendusmaterjali ja regulatiivset asjakohasust.

Selline struktuur väldib ebamääraseid leide nagu „API turberisk“. See loob tõenduskõlblikke riskilausungeid, näiteks:

„Ründaja kasutab varastatud partneri autentimisandmeid, et esitada tehinguriski API kaudu petturlikke skoorimispäringuid, mille tulemuseks on riskiotsuste tervikluse kompromiteerimine, võimalik rahaline kahju klientidele ja isikuandmete loata töötlemine.“

Ohumodelleerimise seostamine ISO/IEC 27001:2022 ja ISO/IEC 27002:2022-ga

ISO/IEC 27001:2022 ei nõua ohumodelleerimist nimeliselt. See nõuab järjepidevat ja dokumenteeritud riskihindamist ning riskikäsitlust. Ohumodelleerimine on üks tugevamaid meetodeid selle tõendusmaterjali loomiseks tarkvara-, pilve- ja tootekeskkondades.

Võti on jälgitavus. ZB riskijuhtimise etapis, sammus 13, soovitatakse kaardistada kontrollimeetmed riskide ja punktidega, sealhulgas lisada käsitlusplaanidesse Lisa A viited ning märkida, kus kontrollimeetmed toetavad GDPR, NIS2 või DORA nõudeid.

Zenith Controls: vastavusteülene juhend [ZC] aitab seda jälgitavust struktureerida, kaardistades ISO/IEC 27002:2022 kontrollimeetmed seotud kontrollimeetmete, auditiootuste ja väliste raamistikega.

Ohumodelleerimise puhul on ISO/IEC 27002:2022 kontroll 5.8 „Infoturve projektijuhtimises“ projektijuhtimise ankur. See näitab, et turve on integreeritud projekti algatamisse, planeerimisse, elluviimisse ja vastuvõtmisse.

Kontroll 8.25 „Turvaline arenduse elutsükkel“ on SDLC ankur. ZC seob 8.25 toetavate kontrollimeetmetega, nagu 8.26 rakendusturbe nõuded, 8.27 turvalise süsteemiarhitektuuri ja inseneritöö põhimõtted, 8.28 turvaline programmeerimine, 8.29 turbetestimine arenduses ja vastuvõtul, 8.30 allhankearendus ning 8.31 arendus-, test- ja tootmiskeskkondade eraldamine.

See kaardistus aitab muuta disainitöötoa kohaldatavusdeklaratsiooni tõendusmaterjaliks. Samuti toetab see ISO/IEC 27001:2022 punkte 4 kuni 6, sest huvitatud osapoolte nõuded, ISMS-i kohaldamisala, juhtkonna kohustused ja riskikäsitluse otsused on nähtavad.

NIS2, DORA, CRA, GDPR ja NIST CSF vastavusteülene kaart

Hästi juhitud ohumudel ei tohiks tekitada viit eraldiseisvat vastavustöövoogu. See peaks looma ühe disainiriskide tõendusmaterjali paketi, mida saab raamistike üleselt kasutada.

NIST CSF 2.0 on eriti kasulik juhtkonnaga suhtlemisel. Selle GOVERN-funktsioon toetab õiguslikke, regulatiivseid, lepingulisi ja privaatsuskohustusi, samal ajal kui tarneahela tulemused aitavad siduda tarnija kriitilisuse, lepingulised nõuded, taustakontrolli, seire ja intsidendiplaneerimise sama ohumudeli tõendusmaterjaliga.

GDPR nõuab eritähelepanu, sest ohumodelleerimine ja DPIA töö peaksid üksteist tugevdama. P17 Andmekaitse ja privaatsuspoliitika [P17] sätestab:

„Ohumodelleerimine ja andmekaitsealased mõjuhinnangud (DPIA-d) on suure riskiga töötlemissüsteemide puhul kohustuslikud.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.3.4.

Väiksemate meeskondade jaoks sätestab P17S Andmekaitse ja privaatsuspoliitika - VKE [P17S]:

„Lõimitud andmekaitse ja vaikimisi andmekaitse tuleb rakendada kõigis uutes süsteemides ja teenustes“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.3.1.

Tulemuseks on praktiline toimemudel: kasuta samu andmevoogude skeeme, usalduspiire ja väärkasutusstsenaariume turberiski, privaatsusriski, tarnija ülevaatuse ja regulatiivse tõendusmaterjali jaoks.

90-minutiline disainiriski sprint suure riskiga funktsioonide jaoks

Ohumodelleerimine ei pea algama raske programmina. Uue makse-API, kasutajaks registreerimise töövoo, AI-toega funktsiooni, identiteediteenuse, pilvemigreerimise või välise integratsiooni puhul võib 90-minutiline disainiriski sprint anda väärtuslikku tõendusmaterjali.

1. Ava projekti turbepunkt

Kasuta käivitajana P24 punkti 6.1.1. Iga uue rakenduse või olulise muudatuse puhul loo tõendusmaterjali kaust järgmisega:

• arhitektuuriskeem
• andmevoogude skeem
• usalduspiiride kaart
• varade loend
• isikuandmete märkused
• tarnijate ja IKT-sõltuvuste loend
• esmased turbenõuded
• ohumudeli tööleht
• riskiregistri kirjed
• maandamismeetmete ja testide jälgitavus
• heakskiidukirje

Väiksemate organisatsioonide puhul toetab P24S Turvalise arenduse poliitika - VKE [P24S] sama distsipliini, sidudes turvalise arenduse protsessid arendajate juurdepääsukontrolli, testimise, ohumodelleerimise ja dokumentatsiooniga. Samuti nõuab see kontroll-loendite, läbivaatamise heakskiitude, testimisaruannete ja komponentide registrite keskset säilitamist auditi jaoks. Punkt 11.3.1 viitab SA-3 kuni SA-15 nõuetele, et määratleda turvalise arenduse protsessid, sealhulgas ohumodelleerimine.

2. Joonista minimaalne toimiv andmevoog

Ära alusta viimistletud skeemist. Alusta voogudest, mis tekitavad riski:

• Kasutaja laadib üles isikut tõendavad dokumendid või tehinguandmed.
• Veebirakendus saadab päringuid API-le.
• API kirjutab hallatavasse salvestusse või andmebaasi.
• Tarnija saab kontrolli- või analüütikaandmeid.
• Sisemine analüütikuportaal kuvab tulemused.
• Kliendi süsteem pärib olekut või otsuseid.
• Logid, seirevahendid ja varukoopiad saavad koopiaid.

Märgi iga usalduspiir: internetist rakendusse, rakendusest API-sse, siseteenusest tarnijani, tootmissüsteemist analüütikasse, administraatorist privilegeeritud funktsioonini ja tootmiskeskkonnast tootmisvälisesse keskkonda.

3. Käivita STRIDE ja väärkasutusstsenaariumid koos

Küsi iga piiri kohta STRIDE-i küsimused ja kirjuta väärkasutusstsenaariumid lihtsas ärikeeles. Eesmärk ei ole loetleda iga mõeldavat rünnet. Eesmärk on tuvastada tõenäolised ja olulised stsenaariumid, mis mõjutavad konfidentsiaalsust, terviklust, käideldavust, privaatsust, toimepidevust või ohutust.

4. Teisenda leiud riskistsenaariumideks

Kasuta ZB sammu 9 vormelit:

„[Oht] kasutab ära [haavatavust] varal [vara], mille tulemuseks on [mõju].“

Näiteks:

„Ründaja kasutab isikut tõendavate dokumentide hoidlas ära nõrku objektisalvestuse juurdepääsukontrolle, mille tulemuseks on isikuandmete loata avalikustamine ja regulatiivse teavitamise risk.“

Seejärel lisa omanik, tõenäosus, mõju, olemuslik risk, käsitlusvalik, sihtkontroll, jääkrisk ja tõendusmaterjal.

5. Tuleta nõuded ja testid

Ohumudel ei ole valmis siis, kui riskid on loetletud. See on valmis siis, kui maandamismeetmed on rakendatud, testitud või ametlikult aktsepteeritud.

Muudatuste haldamise poliitika - VKE annab praktilise käivitustingimuse:

„Kui muudatus hõlmab tundlikke andmeid, süsteemi juurdepääsuõigusi või väliseid integratsioone, on nõutav turbemõju ülevaatus. Määratud turbe- või vastavuskontakt peab hindama, kas muudatus tekitab täiendavaid riske, ning soovitama täiendavaid kaitsemeetmeid.“
Jaotisest „Riskikäsitlus ja erandid“, poliitika punkt 7.5.1.

Tundlikud andmed, juurdepääsuõigused ja välised integratsioonid on just need muudatused, mis nõuavad disainiriski ülevaatust.

Mida eri audiitorid küsivad

ISO/IEC 27001:2022 audiitor küsib, kas ohumodelleerimine on osa määratletud riskihindamise protsessist, kas kriteeriumid on järjepidevad, kas riskiomanikud on jääkriskid heaks kiitnud, kas käsitlusplaanid seostuvad SoA-ga ja kas tõendusmaterjali säilitatakse. Ta otsib korratavust, versiooniajalugu, nähtavust juhtkonna läbivaatamisel ja siseauditi katvust.

Lisa A puhul seob audiitor tõendusmaterjali kontrollidega 5.8, 8.25, 8.26, 8.27 ja 8.29. ZB samm 21 „Kontrollimeetmed töös“ tõstab esile turvalise süsteemiarhitektuuri ja inseneritöö põhimõtted, küsides, millised põhimõtted juhivad turvalist arhitektuuri. Audiitorid võivad küsida, kas ohumodelleerimist tehakse disaini ajal selliste meetoditega nagu STRIDE või ründepuud ning kas arhitektuuriotsused vaadatakse enne rakendamist üle.

NIS2 läbivaataja keskendub juhtimisele ja proportsionaalsusele. Ta võib küsida, kas juhtkond kiitis küberturvalisuse riskijuhtimise käsitluse heaks, kas turvaline hankimine, arendamine ja hooldus on kaetud, kas tarnijate haavatavusi arvestatakse, kas intsidendistsenaariumid seostuvad teavitustöövoogudega ja kas talitluspidevuse stsenaariume analüüsitakse. NIS2 Article 23 etapiviisiline olulistest intsidentidest teatamine, sealhulgas varajane hoiatus 24 tunni jooksul, teavitus 72 tunni jooksul ja lõpparuanne ühe kuu jooksul, muudab stsenaariumide selguse eriti väärtuslikuks.

DORA kontrollija keskendub IKT-riski juhtimisele, kriitilistele funktsioonidele, IKT-varadele, välistele sõltuvustele, tegevuskerksuse testimisele ja IKT kolmanda osapoole teenustele. Kui süsteem toetab kriitilist või olulist funktsiooni, oodatakse tugevamat tõendusmaterjali, mis seob ohustsenaariumid vararegistrite, sõltuvuskaartide, testimisplaanide, kolmanda osapoole lepingute ja taastamismeetmetega.

Privaatsuse läbivaataja kontrollib andmevooge ja küsib, kas isikuandmete töötlemine on vajalik, seaduslik, minimeeritud ja kaitstud. Ta küsib, kas kaasatud on eriliiki isikuandmed, kas kasutatakse pseudonüümimist või krüptimist, kas säilitamine on põhjendatud ja kas DPIA on nõutav. Ohumodelleerimine ja DPIA on erinevad tegevused, kuid need peaksid jagama skeeme, stsenaariume ja maandamismeetmeid.

NIST CSF või COBIT 2019 suunitlusega läbivaataja otsib juhtimist, protsessi omamist, toimivust, vastutust ja pidevat täiustamist. STRIDE-i tööleht ise võib olla tema jaoks vähem oluline kui see, kas protsess on usaldusväärne, mõõdetud, heaks kiidetud ja täiustatud.

Levinud puudused ohumodelleerimise tõendusmaterjalis

Kõige levinumad puudused ei ole tehnilised. Need on tõendusmaterjali puudused.

Meeskonnad teevad ohumodelleerimist liiga hilja, pärast seda kui süsteem on juba valmis ehitatud. Sel hetkel muutub töötuba disainikontrolli asemel penetratsioonitesti eelseks briifinguks.

Leide ei teisendata riskikeelde. „Lisa autentimine“ või „logimisprobleem“ võib aidata insenere, kuid audiitorid vajavad vara, ohtu, haavatavust, mõju, omanikku, käsitlust ja jääkriski.

Privaatsus ja turve hoitakse lahus. Üks meeskond dokumenteerib identiteedi võltsimise ja sisestusründe riski, samal ajal kui teine dokumenteerib säilitamise ja õigusliku aluse. GDPR vastutus toimib paremini, kui andmevood, väärkasutusstsenaariumid ja DPIA käivitustingimused on omavahel seotud.

Tarnijaeeldused jäävad dokumenteerimata. NIS2, DORA ja NIST CSF tõstavad kõik ootusi IKT tarneahela riskile. Kui maandamismeede sõltub tarnija krüptimisest, logimisest, kustutamisest, toimepidevusest või intsidendihaldusest, kogu tõendusmaterjal kokku.

Teste ei seostata tagasi ohtudega. Penetratsioonitesti aruanne võib olla kasulik, kuid see ei pruugi tõendada, et konkreetsed disainiriskid on maandatud. Igal olulisel ohuleiul peab olema valideerimise tõendusmaterjal.

Jääkriski aktsepteerimine on mitteametlik. „Aktsepteerime selle MVP jaoks“ ei ole piisav. ISO/IEC 27001:2022 eeldab jääkriski aktsepteerimist asjakohaste riskiomanike poolt dokumenteeritud teabena.

Sinu 2026. aasta ohumodelleerimise tõendusmaterjali pakett

Iga olulise süsteemi või märkimisväärse muudatuse puhul hoia standardset tõendusmaterjali paketti, mis toetab ISO 27001, NIS2, DORA, CRA, GDPR ja kliendikindlust.

Riskijuhtimise poliitika - VKE võtab toimemudeli hästi kokku:

„See tagab, et riskijuhtimine on planeerimise, projekti elluviimise, tarnijate valiku ja intsidentidele reageerimise aktiivne osa kooskõlas ISO 27001, ISO 31000 ja kohaldatavate regulatiivsete nõuetega.“
Jaotisest „Eesmärk“, poliitika punkt 1.2.

See on õige siht. Ohumodelleerimine peaks mõjutama planeerimist, inseneritööd, tarnijate valikut, intsidentidele reageerimist ja auditeerimisvalmidust.

Muuda ohumodelleerimine auditeerimisvalmiks enne järgmist väljalaset

Organisatsioonid, kes tulevad 2026. aasta vastavussurvega kõige paremini toime, ei ole need, kellel on kõige rohkem skeeme. Need on organisatsioonid, kes suudavad tõendada lihtsat ahelat:

Disainirisk tuvastati. Riski hinnati. Kontrollimeetmed valiti. Maandamismeetmed rakendati. Testid valideerisid maandamismeetmed. Jääkrisk kiideti heaks. Tõendusmaterjal seostub oluliste raamistikega.

Alusta ühest suure riskiga muudatusest: makseintegratsioon, uus API, AI-toega töövoog, identiteedifunktsioon, pilvemigreerimine, kliendile suunatud tooteväljalase või tarnijaga ühendatud teenus. Vii läbi 90-minutiline disainiriski sprint. Kasuta ZB-d, et teisendada leiud riskistsenaariumideks, käsitlusplaanideks ja SoA jälgitavuseks. Kasuta ZC-d, et kaardistada ISO/IEC 27002:2022 kontrollimeetmed, nagu 5.8, 8.25, 8.26, 8.27 ja 8.29, toetavate kontrollimeetmete, tarnijariski, privaatsuse, testimise ja auditi tõendusmaterjaliga. Joonda P24, P06, P17, P24S ja oma muudatuste haldamise protseduur nii, et ohumodelleerimine muutuks nõutavaks, korratavaks ja läbivaadatavaks.

Kui soovid Claryseci abi, alusta ohumodelleerimise tõendusmaterjali ülevaatusest. Hindame üht tegelikku projekti, tuvastame puudujäägid võrreldes ISO/IEC 27001:2022, NIS2, DORA, CRA ja GDPR ootustega ning anname praktilise parandusmeetmete teekaardi, millest saavad aru nii sinu insenerid, audiitorid kui ka juhatus.