Grėsmių modeliavimas ISO 27001, NIS2 ir DORA kontekste

Anya, sparčiai augančios finansinių technologijų įmonės CISO, buvo paprašyta patvirtinti naujos B2B mokėjimų rizikos platformos išleidimo planą. Valdyba norėjo patekti į rinką iki ketvirčio pabaigos. Pardavimų komanda jau buvo parengusi bankų klientų sąrašą. Inžinerijos komanda buvo nubraižiusi debesijos principu suprojektuotą architektūrą su tapatybės atributais, įrenginių signalais, operacijų metaduomenimis, elgsenos rizikos balais, valdoma duomenų baze ir trečiosios šalies analitikos teikėju.

Popieriuje platforma atrodė kaip komercinis proveržis. Anyai ji atrodė kaip penkios atitikties diskusijos vienu metu.

Kaip finansinių technologijų paslaugų teikėja, įmonė jautė DORA spaudimą. Kaip debesijos paslaugų ir skaitmeninės platformos teikėja, ji turėjo įvertinti NIS2 taikymo riziką. Kadangi platforma tvarkė su ES asmenimis susijusius asmens duomenis, buvo taikomas GDPR. Įmonių klientai tikėjosi ISO/IEC 27001:2022 sertifikavimo. Jei paslauga taptų susieto programinės įrangos produkto dalimi, Kibernetinio atsparumo akto (CRA) lūkesčiai papildomai pareikalautų produkto saugumo pagal projektą įrodymų.

Kūrimo komanda pasiūlė įprastą saugumo planą: nuskenuoti priklausomybes, atlikti pažeidžiamumų skenavimą, suplanuoti įsiskverbimo testavimą ir prieš diegiant į produkcinę aplinką ištaisyti kritines išvadas. Anya žinojo, kad to nepakanka. Šios veiklos tikrina tai, kas jau sukurta. Jos neįrodo, kad architektūra buvo saugi pagal projektą, kad pasitikėjimo ribos buvo suprastos, kad asmens duomenų srautai buvo minimizuoti, kad tiekėjų prielaidos buvo peržiūrėtos arba kad paslaugos sutrikimo scenarijai buvo įvertinti prieš išleidimą.

Todėl ji sulėtino susitikimo tempą keturiais klausimais:

1. Kur yra pasitikėjimo ribos?
2. Kurie piktnaudžiavimo scenarijai gali lemti sukčiavimą, duomenų atskleidimą arba paslaugos sutrikimą?
3. Kurie projektavimo sprendimai sumažina riziką dar prieš parašant kodą?
4. Kokie įrodymai po šešių mėnesių tenkins ISO 27001, NIS2, DORA, CRA ir GDPR vertintojus?

Būtent ties ketvirtuoju klausimu daugelis organizacijų suklumpa. Grėsmių modeliavimas dažnai laikomas naudingu inžineriniu seminaru, o vėliau palaidojamas wiki puslapyje. 2026 m. to nepakanka. SaaS teikėjams, finansinių technologijų įmonėms, debesijos platformoms, MSP, MSSP, skaitmeninės infrastruktūros operatoriams ir programinės įrangos gamintojams grėsmių modeliavimas tapo atitikties įrodymų kūrimo mechanizmu.

Brandus grėsmių modeliavimo procesas STRIDE išvadas, piktnaudžiavimo scenarijus ir architektūrinius sprendimus paverčia rizikų registro įrašais, saugumo reikalavimais, rizikos tvarkymo planais, testavimo atvejais, tiekėjų patikinimo užduotimis, privatumo pagal projektą įrodymais ir Taikomumo pareiškimo atsekamumu.

Kodėl saugumo pagal projektą įrodymai dabar svarbūs

Šiuolaikiniai reglamentai artėja prie to paties lūkesčio: organizacijos turi anksti nustatyti saugumo ir privatumo rizikas, priskirti atsakomybę, įgyvendinti proporcingas kontrolės priemones ir išsaugoti įrodymus.

ISO/IEC 27001:2022 reikalauja rizika grindžiamos informacijos saugumo valdymo sistemos. 6.1.2 ir 6.1.3 punktai reikalauja informacijos saugumo rizikos vertinimo ir tvarkymo. 8.1 punktas reikalauja veiklos planavimo ir kontrolės. A priede pateikiamos kontrolės priemonės, kurios per Taikomumo pareiškimą turi būti parinktos pagal riziką, teisinius reikalavimus ir verslo poreikius.

NIS2 tą patį principą perkelia į kibernetinio saugumo valdyseną. Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones ir prižiūrėtų jų įgyvendinimą. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugumą įsigijimo, kūrimo ir priežiūros metu, pažeidžiamumų tvarkymą, bazinę kibernetinę higieną, šifravimą, prieigos kontrolę, turto valdymą ir, kai tinkama, MFA.

DORA nuo 2025 m. sausio 17 d. taiko finansų sektoriaus skaitmeninio operacinio atsparumo perspektyvą. Ji reikalauja, kad į taikymo sritį patenkantys finansų subjektai palaikytų patikimą, visapusišką ir dokumentuotą IRT rizikos valdymo sistemą, identifikuotų IRT turtą ir priklausomybes, taikytų apsaugos ir prevencijos priemones, aptiktų anomalią veiklą, testuotų skaitmeninį operacinį atsparumą, valdytų IRT trečiųjų šalių riziką ir parengtų reagavimo bei atkūrimo pajėgumus. Į taikymo sritį patenkantiems finansų subjektams DORA yra sektoriui skirtas Sąjungos teisės aktas, taikomas persidengiantiems NIS2 įpareigojimams.

GDPR prideda atskaitomybę ir duomenų apsaugą pagal projektą bei pagal numatytuosius nustatymus. Bet kuri asmens duomenis tvarkanti sistema turi gebėti įrodyti teisėtą, sąžiningą, skaidrų, tikslu apribotą, minimizuotą, saugojimo trukme apribotą ir saugų tvarkymą. Grėsmių modelis, kuris susieja asmens duomenų srautus, prieigos kelius, žurnalus, saugojimą, ištrynimą ir perdavimus trečiosioms šalims, yra tiesiogiai aktualus GDPR Articles 5, 25, 32 ir 35.

Kibernetinio atsparumo aktas didina spaudimą produktams su skaitmeniniais elementais. Produktų komandoms reikia gyvavimo ciklo įrodymų, patvirtinančių, kad kibernetinio saugumo rizikos, numatomas netinkamas naudojimas, sąsajos, atnaujinimo mechanizmai, autentifikavimo srautai ir pažeidžiamumų tvarkymo prielaidos buvo įvertinti ankstyvame etape.

Pamoka aiški: jei architektūros peržiūros negalima susieti su rizikomis, kontrolės priemonėmis, savininkais, rizikos mažinimo priemonėmis ir testais, ją bus sunku pagrįsti 2026 m. audito arba priežiūros institucijų vertinimo metu.

Clarysec modelis: vienas grėsmių modelis, daug rezultatų

Clarysec požiūris prasideda nuo praktinio principo: grėsmių modelis nėra baigtas, kol jis nesukuria audituojamų sprendimų.

Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] rizikos valdymo etapo 9 žingsnyje komandoms pateikiamas paprastas formatas, kaip technines pastabas paversti rizikos kalba:

„Dabar sujunkite turtą + grėsmę + pažeidžiamumą į glaustą rizikos scenarijaus aprašymą. Iš esmės aprašykite galimą incidentą. Vėliau tai taps eilutės įrašu jūsų rizikų registre. Naudokite paprastą formatą: „[Grėsmė] išnaudoja [pažeidžiamumą] [turte], todėl atsiranda [poveikis].““

Šis sakinys yra tiltas tarp inžinerijos ir atitikties.

Užrašų lentoje esanti pastaba, pvz., „partnerio API apsimetimo rizika“, tampa:

„Atakuotojas išnaudoja silpną partnerio API autentifikavimą operacijų rizikos API, todėl atsiranda neautorizuota prieiga prie mokėjimų rizikos sprendimų ir asmens duomenų atskleidimas.“

Dabar išvada turi turtą, grėsmę, pažeidžiamumą ir poveikį. Ją galima įvertinti, priskirti, tvarkyti, testuoti ir priimti.

Politikos lygmuo padaro tai pakartojama. P24 Secure Development Policy [P24] nustato:

„Visoms naujoms taikomosioms programoms ir reikšmingiems pakeitimams prieš pradedant kūrimą privaloma atlikti saugios architektūros peržiūrą ir grėsmių modeliavimą.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.1 punktas.

Ji taip pat reikalauja:

„Projektavimo peržiūros turi dokumentuoti duomenų srautų diagramas, pasitikėjimo ribas ir nustatytų rizikų mažinimo priemones.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.2 punktas.

Šie du punktai yra stiprūs audito atramos taškai. Jie parodo, kad grėsmių modeliavimas nėra pasirenkamas ir kad projektavimo įrodymai turi apimti diagramas, ribas ir rizikos mažinimo sprendimus.

P06 Risk Management Policy [P06] susieja grėsmių modeliavimą su įmonės rizikos valdymu:

„Visi verslo padaliniai turi proaktyviai identifikuoti rizikas naudodami struktūruotus metodus, išvestus iš ISO/IEC 27005:2024, įskaitant grėsmių modeliavimą, turto priklausomybių atvaizdavimą ir scenarijais pagrįstą identifikavimą.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.1 punktas.

Joje taip pat nustatyta:

„Nustatytos rizikos turi būti dokumentuojamos nurodant turto savininką, grėsmės veikėją, pažeidžiamumą ir galimą poveikį konfidencialumui, vientisumui ir prieinamumui (KVP).“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.4 punktas.

Tai yra įrodymų grandinė, kurią auditoriai nori matyti: politikos reikalavimas, projektavimo veikla, rizikos scenarijus, kontrolės priemonių parinkimas, įgyvendinimas, testavimas ir patvirtinimas.

STRIDE užtikrina sistemingą aprėptį, piktnaudžiavimo scenarijai – realistiškumą

STRIDE išlieka vienu naudingiausių metodų projektavimo etapo grėsmių modeliavimui, nes priverčia komandas įvertinti šešis dažnus nesėkmės tipus:

• Apsimetimas
• Klastojimas
• Veiksmų neigimas
• Informacijos atskleidimas
• Paslaugos trikdymas
• Privilegijų padidinimas

Anyos mokėjimų rizikos platformai komanda taikė STRIDE kiekvienam komponentui, duomenų srautui ir pasitikėjimo ribai.

Apsimetimas iškėlė klausimą, ar partnerio API klientas galėtų apsimesti banko klientu, jei abipusis autentifikavimas būtų silpnas. Klastojimas atskleidė riziką, kad įrenginių signalai arba operacijų sumos gali būti pakeistos prieš jų įtraukimą. Veiksmų neigimas parodė administratoriaus ir operacijų audito žurnalų poreikį. Informacijos atskleidimas sutelkė dėmesį į nutekėjimą per žurnalus, analitikos eksportus, pagalbos priemones ir ataskaitų API. Paslaugos trikdymas privertė komandą įvertinti piko operacijų langus ir netaisyklingų užklausų srautus. Privilegijų padidinimas atskleidė rizikas pagalbos vaidmenyse, sesijos žetonuose ir administravimo funkcijose.

Piktnaudžiavimo scenarijai šias kategorijas pavertė realiomis istorijomis:

• Sukčius įkelia manipuliuotus įrenginio signalus, kad paveiktų rizikos balą.
• Kompromituoti partnerio prisijungimo duomenys užtvindo API sukčiavimo užklausomis.
• Kūrėjas naudoja produkcinius asmens duomenis testavimo aplinkoje.
• Piktavališkas vidinis asmuo eksportuoja klientų identifikatorius ir vertinimo logiką.
• Debesijos analitikos tiekėjo paslaugų nepasiekiamumas blokuoja rizikos sprendimus mokėjimo lango metu.
• Netinkama saugyklos konfigūracija atskleidžia įkeltus tapatybės dokumentus.
• Ištrynimo darbo eiga pašalina taikomosios programos įrašą, bet palieka atsargines kopijas ir tiekėjo kopijas.

Kiekvienas piktnaudžiavimo scenarijus tapo projektavimo rizikos įrašu su paveiktu turtu, grėsmės veikėju, pažeidžiamumu, poveikiu, esamomis prielaidomis, reikiama rizikos mažinimo priemone, liekamosios rizikos savininku, testavimo įrodymais ir reglamentavimo aktualumu.

Tokia struktūra neleidžia apsiriboti neaiškiomis išvadomis, pvz., „API saugumo rizika“. Ji sukuria įrodymų lygio rizikos teiginius, pvz.:

„Atakuotojas naudoja pavogtus partnerio prisijungimo duomenis sukčiavimo vertinimo užklausoms teikti per operacijų rizikos API, todėl kompromituojamas rizikos sprendimų vientisumas, galimas klientų finansinis nuostolis ir neautorizuotas asmens duomenų tvarkymas.“

Grėsmių modeliavimo susiejimas su ISO/IEC 27001:2022 ir ISO/IEC 27002:2022

ISO/IEC 27001:2022 tiesiogiai neįvardija grėsmių modeliavimo kaip privalomo reikalavimo. Jis reikalauja nuoseklaus, dokumentuoto rizikos vertinimo ir rizikos tvarkymo. Grėsmių modeliavimas yra vienas stipriausių metodų tokiems įrodymams kurti programinės įrangos, debesijos ir produktų aplinkose.

Svarbiausia yra atsekamumas. ZB rizikos valdymo etapo 13 žingsnyje rekomenduojama susieti kontrolės priemones su rizikomis ir punktais, įtraukti A priedo nuorodas į rizikos tvarkymo planus ir pažymėti, kur kontrolės priemonės palaiko GDPR, NIS2 arba DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] padeda struktūruoti šį atsekamumą susiejant ISO/IEC 27002:2022 kontrolės priemones su susijusiomis kontrolės priemonėmis, audito lūkesčiais ir išorinėmis sistemomis.

Grėsmių modeliavimo atveju ISO/IEC 27002:2022 kontrolė 5.8, informacijos saugumas projektų valdyme, yra projektų valdysenos atrama. Ji parodo, kad saugumas integruotas į projekto inicijavimą, planavimą, vykdymą ir priėmimą.

Kontrolė 8.25, saugaus kūrimo gyvavimo ciklas, yra SDLC atrama. ZC susieja 8.25 su palaikančiomis kontrolės priemonėmis, tokiomis kaip 8.26 taikomųjų programų saugumo reikalavimai, 8.27 saugios sistemos architektūros ir inžinerijos principai, 8.28 saugus programavimas, 8.29 saugumo testavimas kūrimo ir priėmimo metu, 8.30 išorinis kūrimas ir 8.31 kūrimo, testavimo ir produkcinių aplinkų atskyrimas.

Šis susiejimas padeda projektavimo seminarą paversti Taikomumo pareiškimo įrodymais. Jis taip pat palaiko ISO/IEC 27001:2022 4–6 punktus, nes suinteresuotųjų šalių reikalavimai, ISVS taikymo sritis, vadovybės įsipareigojimai ir rizikos tvarkymo sprendimai tampa matomi.

Kryžminės atitikties žemėlapis NIS2, DORA, CRA, GDPR ir NIST CSF kontekste

Gerai atliktas grėsmių modelis neturėtų sukurti penkių atsietų atitikties darbo srautų. Jis turėtų sukurti vieną projektavimo rizikos įrodymų paketą, kurį galima pakartotinai naudoti skirtingose sistemose.

NIST CSF 2.0 ypač naudinga vadovybės komunikacijai. Jos GOVERN funkcija palaiko teisines, reglamentavimo, sutartines ir privatumo prievoles, o tiekimo grandinės rezultatai padeda susieti tiekėjų kritiškumą, sutartinius reikalavimus, deramą patikrinimą, stebėseną ir incidentų planavimą su tais pačiais grėsmių modelio įrodymais.

GDPR reikalauja ypatingo dėmesio, nes grėsmių modeliavimas ir DPIA veikla turėtų viena kitą sustiprinti. P17 Data Protection and Privacy Policy [P17] nustato:

„Grėsmių modeliavimas ir poveikio duomenų apsaugai vertinimai (DPIA) yra privalomi didelės rizikos tvarkymo sistemoms.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.3.4 punktas.

Mažesnėms komandoms P17S Data Protection and Privacy Policy - SME [P17S] nustato:

„Privatumas pagal projektą ir pagal numatytuosius nustatymus turi būti užtikrinamas visose naujose sistemose ir paslaugose“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.3.1 punktas.

Rezultatas – praktinis veikimo modelis: tas pačias duomenų srautų diagramas, pasitikėjimo ribas ir piktnaudžiavimo scenarijus naudokite saugumo rizikai, privatumo rizikai, tiekėjų peržiūrai ir reglamentavimo įrodymams.

90 minučių projektavimo rizikos sprintas didelės rizikos funkcijoms

Grėsmių modeliavimas nebūtinai turi prasidėti kaip sudėtinga programa. Naujai mokėjimų API, naudotojų įtraukimo darbo eigai, DI įgalintai funkcijai, tapatybės paslaugai, debesijos migracijai arba išorinei integracijai 90 minučių projektavimo rizikos sprintas gali sukurti vertingus įrodymus.

1. Atidarykite projekto saugumo kontrolinį tašką

Naudokite P24 6.1.1 punktą kaip paleidiklį. Kiekvienai naujai taikomajai programai arba reikšmingam pakeitimui sukurkite įrodymų aplanką su:

• Architektūros diagrama
• Duomenų srautų diagrama
• Pasitikėjimo ribų žemėlapiu
• Turto sąrašu
• Pastabomis apie asmens duomenis
• Tiekėjų ir IRT priklausomybių sąrašu
• Pradiniais saugumo reikalavimais
• Grėsmių modelio darbalapiu
• Rizikų registro įrašais
• Rizikos mažinimo priemonių ir testų atsekamumu
• Patvirtinimo įrašu

Mažesnėms organizacijoms P24S Secure Development Policy - SME [P24S] palaiko tą pačią discipliną, susiedama saugaus kūrimo procesus su kūrėjų prieigos kontrole, testavimu, grėsmių modeliavimu ir dokumentacija. Ji taip pat reikalauja centralizuotai saugoti kontrolinius sąrašus, peržiūrų patvirtinimus, testavimo ataskaitas ir komponentų apskaitą audito tikslais. 11.3.1 punktas nurodo SA-3 iki SA-15, kad apibrėžtų saugaus kūrimo procesus, įskaitant grėsmių modeliavimą.

2. Nubraižykite minimalų pakankamą duomenų srautą

Nepradėkite nuo išbaigtos diagramos. Pradėkite nuo srautų, kurie sukuria riziką:

• Naudotojas įkelia tapatybės dokumentus arba operacijų duomenis.
• Žiniatinklio taikomoji programa siunčia užklausas į API.
• API rašo į valdomą saugyklą arba duomenų bazę.
• Tiekėjas gauna patikros arba analitikos duomenis.
• Vidinis analitiko portalas rodo rezultatus.
• Kliento sistema gauna būseną arba sprendimus.
• Žurnalai, stebėsenos priemonės ir atsarginės kopijos gauna kopijas.

Pažymėkite kiekvieną pasitikėjimo ribą: internetas į taikomąją programą, taikomoji programa į API, vidinė paslauga į tiekėją, produkcinė sistema į analitiką, administratorius į privilegijuotą funkciją ir produkcinė aplinka į neprodukcinę aplinką.

3. Taikykite STRIDE kartu su piktnaudžiavimo scenarijais

Kiekvienai ribai užduokite STRIDE klausimus ir rašykite piktnaudžiavimo scenarijus aiškia verslo kalba. Tikslas nėra išvardyti kiekvieną įsivaizduojamą ataką. Tikslas – nustatyti tikėtinus, reikšmingus scenarijus, kurie veikia konfidencialumą, vientisumą, prieinamumą, privatumą, atsparumą arba saugą.

4. Paverskite išvadas rizikos scenarijais

Naudokite ZB 9 žingsnio formulę:

„[Grėsmė] išnaudoja [pažeidžiamumą] [turte], todėl atsiranda [poveikis].“

Pavyzdžiui:

„Atakuotojas išnaudoja silpnas objektinės saugyklos prieigos kontrolės priemones tapatybės dokumentų saugykloje, todėl neautorizuotai atskleidžiami asmens duomenys ir atsiranda reguliuotojo informavimo rizika.“

Tada pridėkite savininką, tikimybę, poveikį, prigimtinę riziką, tvarkymo parinktį, tikslinę kontrolės priemonę, liekamąją riziką ir įrodymus.

5. Išveskite reikalavimus ir testus

Grėsmių modelis nėra baigtas, kai rizikos tik išvardijamos. Jis baigtas tada, kai rizikos mažinimo priemonės įgyvendinamos, testuojamos arba formaliai priimamos.

Change Management Policy - SME pateikia praktinį paleidiklį:

„Jei pakeitimas apima jautrius duomenis, sistemos prieigos teises arba išorines integracijas, reikalinga saugumo poveikio peržiūra. Paskirtas saugos arba atitikties kontaktinis asmuo turi įvertinti, ar pakeitimas sukuria papildomų rizikų, ir rekomenduoti papildomas apsaugos priemones.“
Iš skyriaus „Rizikos tvarkymas ir išimtys“, politikos 7.5.1 punktas.

Jautrūs duomenys, prieigos teisės ir išorinės integracijos yra būtent tie pakeitimai, kuriems būtina projektavimo rizikos peržiūra.

Ko klaus skirtingi auditoriai

ISO/IEC 27001:2022 auditorius klaus, ar grėsmių modeliavimas yra apibrėžto rizikos vertinimo proceso dalis, ar kriterijai nuoseklūs, ar rizikos savininkai patvirtino liekamąsias rizikas, ar rizikos tvarkymo planai susieti su SoA ir ar įrodymai saugomi. Jie ieškos pakartojamumo, versijų istorijos, matomumo vadovybės peržiūrose ir vidaus audito aprėpties.

A priedo atžvilgiu jie susies jūsų įrodymus su 5.8, 8.25, 8.26, 8.27 ir 8.29. ZB 21 žingsnis „Kontrolės priemonės praktikoje“ pabrėžia saugios sistemos architektūros ir inžinerijos principus klausdamas, kokie principai nukreipia saugią architektūrą. Auditoriai gali klausti, ar grėsmių modeliavimas atliekamas projektavimo metu naudojant tokius metodus kaip STRIDE arba atakų medžiai, ir ar architektūriniai sprendimai peržiūrimi prieš įgyvendinimą.

NIS2 vertintojas sutelks dėmesį į valdyseną ir proporcingumą. Jis gali klausti, ar vadovybė patvirtino kibernetinio saugumo rizikos valdymo požiūrį, ar apimtas saugus įsigijimas, kūrimas ir priežiūra, ar įvertinami tiekėjų pažeidžiamumai, ar incidentų scenarijai susieti su pranešimų darbo eiga ir ar analizuojami veiklos tęstinumo scenarijai. NIS2 Article 23 etapinis reikšmingų incidentų pranešimas, įskaitant ankstyvą įspėjimą per 24 valandas, pranešimą per 72 valandas ir galutinę ataskaitą per vieną mėnesį, scenarijų aiškumą daro ypač vertingą.

DORA vertintojas sutelks dėmesį į IRT rizikos valdyseną, kritines funkcijas, IRT turtą, išorines priklausomybes, atsparumo testavimą ir IRT trečiųjų šalių paslaugas. Jei sistema palaiko kritinę arba svarbią funkciją, bus tikimasi stipresnių įrodymų, susiejančių grėsmių scenarijus su turto apskaita, priklausomybių žemėlapiais, testavimo planais, trečiųjų šalių sutartimis ir atkūrimo priemonėmis.

Privatumo vertintojas tikrins duomenų srautus ir klaus, ar asmens duomenų tvarkymas yra būtinas, teisėtas, minimizuotas ir apsaugotas. Jis klaus, ar tvarkomi specialių kategorijų duomenys, ar naudojamas pseudonimizavimas arba šifravimas, ar saugojimas pagrįstas ir ar reikalingas DPIA. Grėsmių modeliavimas ir DPIA yra skirtingos veiklos, tačiau jos turėtų naudoti tas pačias diagramas, scenarijus ir rizikos mažinimo priemones.

NIST CSF arba COBIT 2019 orientuotas vertintojas ieškos valdysenos, proceso savininkystės, veiklos, atskaitomybės ir nuolatinio tobulinimo. Jam gali būti mažiau svarbus pats STRIDE darbalapis, o labiau tai, ar procesas yra patikimas, matuojamas, patvirtintas ir tobulinamas.

Dažnos grėsmių modeliavimo įrodymų klaidos

Dažniausios klaidos nėra techninės. Tai įrodymų klaidos.

Komandos grėsmių modeliavimą atlieka per vėlai, kai sistema jau sukurta. Tuomet seminaras tampa instruktažu prieš įsiskverbimo testavimą, o ne projektavimo kontrole.

Išvados nepaverčiamos rizikos kalba. „Pridėti autentifikavimą“ arba „žurnalavimo problema“ gali padėti inžinieriams, tačiau auditoriams reikia turto, grėsmės, pažeidžiamumo, poveikio, savininko, tvarkymo ir liekamosios rizikos.

Privatumas ir saugumas atskiriami. Viena komanda dokumentuoja apsimetimo ir įterpimo riziką, o kita – saugojimą ir teisinį pagrindą. GDPR atskaitomybė veikia geriau, kai duomenų srautai, piktnaudžiavimo scenarijai ir DPIA paleidikliai yra susieti.

Tiekėjų prielaidos lieka nedokumentuotos. NIS2, DORA ir NIST CSF didina lūkesčius IRT tiekimo grandinės rizikai. Jei rizikos mažinimo priemonė priklauso nuo tiekėjo šifravimo, žurnalavimo, ištrynimo, atsparumo arba reagavimo į incidentus, surinkite įrodymus.

Testai nesusiejami atgal su grėsmėmis. Įsiskverbimo testavimo ataskaita gali būti naudinga, tačiau ji gali neįrodyti, kad konkrečios projektavimo rizikos buvo sumažintos. Kiekvienai reikšmingai grėsmės išvadai turėtų būti validavimo įrodymai.

Liekamosios rizikos priėmimas yra neformalus. „Priimame tai MVP etapui“ nepakanka. ISO/IEC 27001:2022 tikisi, kad tinkami rizikos savininkai priims liekamąją riziką kaip dokumentuotą informaciją.

Jūsų 2026 m. grėsmių modeliavimo įrodymų paketas

Kiekvienai reikšmingai sistemai arba reikšmingam pakeitimui saugokite standartinį įrodymų paketą, kuris gali palaikyti ISO 27001, NIS2, DORA, CRA, GDPR ir klientų patikinimą.

Risk Management Policy - SME gerai apibūdina veikimo modelį:

„Ji užtikrina, kad rizikos valdymas būtų aktyvus planavimo, projektų vykdymo, tiekėjų atrankos ir reagavimo į incidentus komponentas, suderintas su ISO 27001, ISO 31000 ir taikomais reglamentavimo reikalavimais.“
Iš skyriaus „Tikslas“, politikos 1.2 punktas.

Tai tinkamas tikslas. Grėsmių modeliavimas turi daryti įtaką planavimui, inžinerijai, tiekėjų atrankai, reagavimui į incidentus ir pasirengimui auditui.

Padarykite grėsmių modeliavimą tinkamą auditui prieš kitą išleidimą

Organizacijos, kurios geriausiai atlaikys 2026 m. atitikties spaudimą, nėra tos, kurios turi daugiausia diagramų. Tai organizacijos, galinčios įrodyti paprastą grandinę:

Projektavimo rizika buvo identifikuota. Rizika buvo įvertinta. Kontrolės priemonės buvo parinktos. Rizikos mažinimo priemonės buvo įgyvendintos. Testai patvirtino rizikos mažinimo priemones. Liekamoji rizika buvo patvirtinta. Įrodymai susieti su svarbiomis sistemomis.

Pradėkite nuo vieno didelės rizikos pakeitimo: mokėjimų integracijos, naujos API, DI įgalintos darbo eigos, tapatybės funkcijos, debesijos migracijos, klientams skirto produkto išleidimo arba su tiekėju susietos paslaugos. Atlikite 90 minučių projektavimo rizikos sprintą. Naudokite ZB, kad išvadas paverstumėte rizikos scenarijais, rizikos tvarkymo planais ir SoA atsekamumu. Naudokite ZC, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones, tokias kaip 5.8, 8.25, 8.26, 8.27 ir 8.29, su palaikančiomis kontrolės priemonėmis, tiekėjų rizika, privatumu, testavimu ir audito įrodymais. Suderinkite P24, P06, P17, P24S ir savo pakeitimų valdymo procedūrą taip, kad grėsmių modeliavimas taptų privalomas, pakartojamas ir peržiūrimas.

Jei norite, kad Clarysec padėtų, pradėkite nuo grėsmių modeliavimo įrodymų peržiūros. Įvertinsime vieną realų projektą, nustatysime spragas pagal ISO/IEC 27001:2022, NIS2, DORA, CRA ir GDPR lūkesčius ir pateiksime praktinį taisomųjų veiksmų planą, kurį supras jūsų inžinieriai, auditoriai ir valdyba.