Fenyegetésmodellezés ISO 27001, NIS2 és DORA környezetben

Anya, egy gyorsan növekvő fintech vállalat CISO-ja, azt a feladatot kapta, hogy hagyja jóvá egy új B2B fizetésikockázat-kezelő platform bevezetési tervét. Az igazgatóság a negyedév vége előtt piacra akart lépni. Az értékesítés már előkészítette a banki ügyfeleket. A mérnöki csapat felhőnatív architektúrát vázolt fel identitásattribútumokkal, eszközjelekkel, tranzakciós metaadatokkal, viselkedési kockázati pontszámokkal, menedzselt adatbázissal és egy külső analitikai szolgáltatóval.

Papíron a platform üzleti áttörésnek tűnt. Anya számára inkább öt megfelelési egyeztetés egyidejű elindulását jelentette.

Pénzügyi technológiai szolgáltatóként a vállalatra DORA-nyomás nehezedett. Felhőszolgáltatásként és digitális platformszolgáltatóként értenie kellett a NIS2 szerinti kitettséget. Mivel a platform EU-s természetes személyekre vonatkozó személyes adatokat kezelt, a GDPR is alkalmazandó volt. A nagyvállalati ügyfelek ISO/IEC 27001:2022 tanúsítást vártak el. Ha a szolgáltatás összekapcsolt szoftvertermék részévé válik, a Cyber Resilience Act elvárásai további, a tervezésbe épített termékbiztonsági bizonyítékokat követelnek meg.

A fejlesztőcsapat a szokásos biztonsági tervet javasolta: függőségek vizsgálata, sérülékenységvizsgálat futtatása, penetrációs teszt lefoglalása, majd a kritikus megállapítások javítása az éles indulás előtt. Anya tudta, hogy ez nem elegendő. Ezek a tevékenységek azt tesztelik, ami már elkészült. Nem igazolják, hogy az architektúra tervezésénél fogva biztonságos volt, hogy a bizalmi határok érthetők voltak, hogy a személyes adatok áramlását minimalizálták, hogy a beszállítói feltételezéseket felülvizsgálták, vagy hogy a szolgáltatáskimaradási forgatókönyveket a bevezetés előtt mérlegelték.

Ezért négy kérdéssel lassította le a megbeszélést:

1. Hol vannak a bizalmi határok?
2. Mely visszaélési forgatókönyvek vezethetnek csaláshoz, adatkitettséghez vagy szolgáltatáskimaradáshoz?
3. Mely tervezési döntések csökkentik a kockázatot még a kód megírása előtt?
4. Milyen bizonyítékok felelnek majd meg az ISO 27001, NIS2, DORA, CRA és GDPR felülvizsgálóinak hat hónap múlva?

Sok szervezet ennél a negyedik kérdésnél bukik el. A fenyegetésmodellezést gyakran hasznos mérnöki workshopként kezelik, majd eltemetik egy wikioldalon. 2026-ban ez már nem elég. SaaS-szolgáltatók, fintech vállalatok, felhőplatformok, MSP-k, MSSP-k, digitális infrastruktúra-üzemeltetők és szoftvergyártók számára a fenyegetésmodellezés megfelelési bizonyítékokat előállító működési mechanizmussá vált.

Egy érett fenyegetésmodellezési folyamat a STRIDE-megállapításokat, a visszaélési forgatókönyveket és az architekturális döntéseket kockázati nyilvántartási bejegyzésekké, biztonsági követelményekké, kockázatkezelési tervekké, tesztesetekké, beszállítói bizonyossági feladatokká, beépített adatvédelmi bizonyítékokká és az alkalmazhatósági nyilatkozat szerinti visszakövethetőséggé alakítja.

Miért fontos most a tervezésbe épített biztonság bizonyítéka?

A modern szabályozások ugyanazon elvárás köré rendeződnek: a szervezeteknek korán kell azonosítaniuk a biztonsági és adatvédelmi kockázatokat, felelőst kell kijelölniük, arányos kontrollokat kell bevezetniük, és meg kell őrizniük a bizonyítékokat.

Az ISO/IEC 27001:2022 kockázatalapú információbiztonság-irányítási rendszer működtetését írja elő. A 6.1.2 és 6.1.3 pontok információbiztonsági kockázatértékelést és kockázatkezelést követelnek meg. A 8.1 pont működéstervezést és -szabályozást ír elő. Az A melléklet olyan kontrollokat tartalmaz, amelyeket az alkalmazhatósági nyilatkozaton keresztül, kockázat, jogi követelmények és üzleti igények alapján kell kiválasztani.

A NIS2 ugyanezt az elvet emeli be a kiberbiztonsági irányításba. Article 20 előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, és felügyeljék azok végrehajtását. Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket követel meg, ideértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a beszerzés, fejlesztés és karbantartás biztonságát, a sérülékenységek kezelését, a kiberhigiéniát, a titkosítást, a hozzáférés-szabályozást, az eszközkezelést és adott esetben a többtényezős hitelesítést.

A DORA 2025. január 17-től a pénzügyi szektor operatív rezilienciájának szemszögéből alkalmazandó. Megköveteli az érintett pénzügyi szervezetektől, hogy megalapozott, átfogó és dokumentált IKT-kockázatkezelési keretrendszert tartsanak fenn, azonosítsák az IKT-eszközöket és függőségeket, alkalmazzanak védelmi és megelőző intézkedéseket, észleljék a rendellenes tevékenységeket, teszteljék a digitális működési rezilienciát, kezeljék a harmadik félhez kapcsolódó IKT-kockázatokat, valamint készítsék elő a reagálási és helyreállítási képességeket. Az érintett pénzügyi szervezetek esetében a DORA az átfedő NIS2-kötelezettségek ágazatspecifikus uniós jogi aktusa.

A GDPR ehhez elszámoltathatóságot, valamint beépített és alapértelmezett adatvédelmet ad. Minden személyes adatot kezelő rendszernek képesnek kell lennie igazolni a jogszerű, tisztességes, átlátható, célhoz kötött, adattakarékos, tárolási időben korlátozott és biztonságos adatkezelést. Az a fenyegetési modell, amely feltérképezi a személyes adatok áramlását, a hozzáférési útvonalakat, a naplókat, a megőrzést, a törlést és a harmadik feleknek történő adattovábbítást, közvetlenül releváns a GDPR Articles 5, 25, 32 and 35 szempontjából.

A Cyber Resilience Act további nyomást helyez a digitális elemeket tartalmazó termékekre. A termékcsapatoknak életciklus-bizonyítékokra van szükségük annak igazolására, hogy a kiberbiztonsági kockázatokat, az előre látható visszaélést, az interfészeket, a frissítési mechanizmusokat, a hitelesítési folyamatokat és a sérülékenységkezelési feltételezéseket korán mérlegelték.

A tanulság egyértelmű: ha egy architektúra-felülvizsgálat nem köthető vissza kockázatokhoz, kontrollokhoz, felelősökhöz, kockázatcsökkentő intézkedésekhez és tesztekhez, akkor azt nehéz lesz megvédeni egy 2026-os audit vagy szabályozói felülvizsgálat során.

A Clarysec modellje: egy fenyegetési modell, több kimenet

A Clarysec megközelítése egy gyakorlati elvből indul ki: a fenyegetési modell addig nem teljes, amíg nem eredményez auditálható döntéseket.

A Zenith Blueprint: auditori 30 lépéses ütemterv [ZB] Kockázatkezelés szakaszának 9. lépése egyszerű formátumot ad a csapatoknak a technikai észrevételek kockázati nyelvre történő átalakításához:

„Most kapcsolja össze az eszközt, a fenyegetést és a sérülékenységet egy tömör kockázati forgatókönyv-leírássá. Lényegében írja le a lehetséges incidenst. Ez később sorbejegyzés lesz a kockázati nyilvántartásban. Használjon egyszerű formátumot: »[Fenyegetés] kihasználja a(z) [sérülékenység] sérülékenységet a(z) [eszköz] esetében, ami [hatás] következménnyel jár.«”

Ez a mondat teremti meg a hidat a mérnöki munka és a megfelelés között.

Egy táblára írt megjegyzés, például „partner API megszemélyesítési kockázat”, így alakul át:

„Egy támadó kihasználja a gyenge partner API-hitelesítést a tranzakciós kockázati API-n, ami jogosulatlan hozzáférést eredményez a fizetésikockázat-döntésekhez és személyes adatok kitettségéhez vezet.”

A megállapításnak így már van eszköze, fenyegetése, sérülékenysége és hatása. Értékelhető, kijelölhető hozzá felelős, kezelhető, tesztelhető és elfogadható.

A szabályzati réteg teszi ezt ismételhetővé. A P24 Biztonságos fejlesztési szabályzat [P24] kimondja:

„Minden új alkalmazásnak és jelentős változtatásnak biztonsági architektúra-felülvizsgálaton és fenyegetésmodellezésen kell átesnie a fejlesztés megkezdése előtt.”
A „A szabályzat végrehajtásának követelményei” szakaszból, a szabályzat 6.1.1 pontja.

A szabályzat azt is előírja:

„A tervezési felülvizsgálatoknak dokumentálniuk kell az adatáramlási diagramokat, a bizalmi határokat és az azonosított kockázatokra vonatkozó kockázatcsökkentő intézkedéseket.”
A „A szabályzat végrehajtásának követelményei” szakaszból, a szabályzat 6.1.2 pontja.

Ez a két pont erős audithivatkozási alap. Megmutatja, hogy a fenyegetésmodellezés nem opcionális, és hogy a tervezési bizonyítékoknak tartalmazniuk kell a diagramokat, a határokat és a kockázatcsökkentési döntéseket.

A P06 Kockázatkezelési szabályzat [P06] a fenyegetésmodellezést összeköti a vállalati kockázatkezeléssel:

„Valamennyi üzleti egység köteles proaktívan azonosítani a kockázatokat az ISO/IEC 27005:2024-ből származtatott strukturált technikákkal, ideértve a fenyegetésmodellezést, az eszközfüggőségek feltérképezését és a forgatókönyv-alapú azonosítást.”
A „A szabályzat végrehajtásának követelményei” szakaszból, a szabályzat 6.1.1 pontja.

A szabályzat továbbá kimondja:

„Az azonosított kockázatokat dokumentálni kell az eszközfelelősre, a fenyegető szereplőre, a sérülékenységre, valamint a bizalmasságra, sértetlenségre és rendelkezésre állásra (CIA) gyakorolt lehetséges hatásra hivatkozással.”
A „A szabályzat végrehajtásának követelményei” szakaszból, a szabályzat 6.1.4 pontja.

Ez az a bizonyítéklánc, amelyet az auditorok látni akarnak: szabályzati követelmény, tervezési tevékenység, kockázati forgatókönyv, kontrollkiválasztás, megvalósítás, tesztelés és jóváhagyás.

A STRIDE rendszerezi a lefedettséget, a visszaélési esetek valószerűvé teszik azt

A STRIDE továbbra is az egyik leghasznosabb módszer a tervezési szakaszban végzett fenyegetésmodellezéshez, mert hat gyakori hibamód mérlegelésére kényszeríti a csapatokat:

• Megszemélyesítés
• Manipuláció
• Letagadhatóság
• Információk nyilvánosságra kerülése
• Szolgáltatásmegtagadás
• Jogosultságkiterjesztés

Anya fizetésikockázat-kezelő platformjánál a csapat a STRIDE-ot minden komponensre, adatáramlásra és bizalmi határra alkalmazta.

A megszemélyesítés felvetette azt a kérdést, hogy egy partner API-kliens képes lehet-e egy banki ügyfél nevében fellépni, ha a kölcsönös hitelesítés gyenge. A manipuláció feltárta annak kockázatát, hogy az eszközjelek vagy a tranzakciós összegek a betöltés előtt módosíthatók. A letagadhatóság rámutatott az adminisztrátori és tranzakciós auditnaplók szükségességére. Az információk nyilvánosságra kerülése a naplókon, analitikai exportokon, támogatási eszközökön és jelentéskészítő API-kon keresztüli kiszivárgásra összpontosított. A szolgáltatásmegtagadás arra kényszerítette a csapatot, hogy mérlegelje a csúcsterhelésű tranzakciós időablakokat és a hibásan formázott kérések áradatát. A jogosultságkiterjesztés a támogatási szerepkörökben, munkamenet-tokenekben és adminisztratív funkciókban rejlő kockázatokat tárt fel.

A visszaélési esetek ezeket a kategóriákat valós történetekké alakították:

• Egy csaló manipulált eszközjeleket tölt fel egy kockázati pontszám befolyásolására.
• Egy kompromittálódott partneri hitelesítő adat csalárd kérésekkel árasztja el az API-t.
• Egy fejlesztő éles személyes adatokat használ tesztkörnyezetben.
• Egy rosszindulatú belső szereplő ügyfélazonosítókat és pontozási logikát exportál.
• Egy felhőalapú analitikai beszállító kiesése blokkolja a kockázati döntéseket egy fizetési időablakban.
• Egy tárolási hibás konfiguráció kiteszi a feltöltött személyazonosító dokumentumokat.
• Egy törlési munkafolyamat eltávolítja az alkalmazásrekordot, de hátrahagyja a biztonsági mentéseket és a beszállítói másolatokat.

Minden visszaélési esetből tervezési kockázati bejegyzés lett, amely tartalmazta az érintett eszközt, a fenyegető szereplőt, a sérülékenységet, a hatást, a meglévő feltételezéseket, a szükséges kockázatcsökkentő intézkedést, a maradványkockázat felelősét, a tesztbizonyítékot és a szabályozási relevanciát.

Ez a struktúra megakadályozza az olyan homályos megállapításokat, mint „API-biztonsági kockázat”. Ehelyett bizonyítékértékű kockázati állításokat eredményez, például:

„Egy támadó ellopott partneri hitelesítő adatokkal csalárd pontozási kéréseket küld a tranzakciós kockázati API-n keresztül, ami a kockázati döntések sértetlenségének sérüléséhez, az ügyfelek lehetséges pénzügyi veszteségéhez és személyes adatok jogosulatlan kezeléséhez vezet.”

A fenyegetésmodellezés megfeleltetése az ISO/IEC 27001:2022 és ISO/IEC 27002:2022 követelményeinek

Az ISO/IEC 27001:2022 név szerint nem írja elő a fenyegetésmodellezést. Következetes, dokumentált kockázatértékelést és kockázatkezelést követel meg. A fenyegetésmodellezés az egyik legerősebb módszer e bizonyítékok előállítására szoftveres, felhőalapú és termékkörnyezetekben.

A kulcs a visszakövethetőség. A ZB Kockázatkezelés szakaszának 13. lépése javasolja a kontrollok kockázatokhoz és pontokhoz történő hozzárendelését, beleértve az A melléklet hivatkozásait a kockázatkezelési tervekben, valamint annak jelölését, hogy a kontrollok hol támogatják a GDPR, NIS2 vagy DORA megfelelést.

A Zenith Controls: keresztmegfelelési útmutató [ZC] segít ennek a visszakövethetőségnek a strukturálásában azáltal, hogy az ISO/IEC 27002:2022 kontrollokat kapcsolódó kontrollokhoz, auditelvárásokhoz és külső keretrendszerekhez rendeli.

A fenyegetésmodellezés esetében az ISO/IEC 27002:2022 5.8 kontrollja, az Információbiztonság a projektmenedzsmentben, a projektirányítási horgony. Megmutatja, hogy a biztonság beépül a projektindításba, tervezésbe, végrehajtásba és elfogadásba.

A 8.25 kontroll, a Biztonságos fejlesztési életciklus, az SDLC-horgony. A ZC a 8.25 kontrollt olyan támogató kontrollokhoz kapcsolja, mint a 8.26 alkalmazásbiztonsági követelmények, a 8.27 biztonságos rendszerarchitektúra és mérnöki alapelvek, a 8.28 biztonságos kódolás, a 8.29 biztonsági tesztelés fejlesztés és elfogadás során, a 8.30 kiszervezett fejlesztés, valamint a 8.31 fejlesztési, teszt- és éles környezetek szétválasztása.

Ez a megfeleltetés segít egy tervezési workshopot az alkalmazhatósági nyilatkozathoz kapcsolódó bizonyítékká alakítani. Támogatja az ISO/IEC 27001:2022 4–6. pontjait is, mert láthatóvá válnak az érdekelt felek követelményei, az IBIR alkalmazási területe, a vezetői kötelezettségvállalások és a kockázatkezelési döntések.

Keresztmegfelelési térkép NIS2, DORA, CRA, GDPR és NIST CSF céljára

Egy jól vezetett fenyegetési modell nem eredményezhet öt egymástól elszigetelt megfelelési munkafolyamatot. Egyetlen tervezési kockázati bizonyítékcsomagot kell létrehoznia, amely több keretrendszerben is újrahasznosítható.

A NIST CSF 2.0 különösen hasznos a felsővezetői kommunikációban. GOVERN funkciója támogatja a jogi, szabályozási, szerződéses és adatvédelmi kötelezettségeket, míg az ellátási láncra vonatkozó eredményei segítenek ugyanahhoz a fenyegetési modellhez kapcsolni a beszállítói kritikusságot, a szerződéses követelményeket, a kellő gondosságot, a nyomon követést és az incidens-tervezést.

A GDPR külön figyelmet igényel, mert a fenyegetésmodellezésnek és a DPIA-munkának egymást kell erősítenie. A P17 Adatvédelmi és magánszféra-védelmi szabályzat [P17] kimondja:

„A fenyegetésmodellezés és az adatvédelmi hatásvizsgálatok (DPIA) kötelezők a magas kockázatú adatkezelő rendszerek esetében.”
A „A szabályzat végrehajtásának követelményei” szakaszból, a szabályzat 6.3.4 pontja.

Kisebb csapatok esetében a P17S Adatvédelmi és magánszféra-védelmi szabályzat – KKV [P17S] kimondja:

„A beépített és alapértelmezett adatvédelmet minden új rendszerben és szolgáltatásban érvényesíteni kell”
Az „Irányítási követelmények” szakaszból, a szabályzat 5.3.1 pontja.

Az eredmény egy gyakorlati működési modell: ugyanazokat az adatáramlási diagramokat, bizalmi határokat és visszaélési eseteket kell használni biztonsági kockázat, adatvédelmi kockázat, beszállítói felülvizsgálat és szabályozási bizonyíték céljára.

90 perces tervezési kockázati sprint magas kockázatú funkciókhoz

A fenyegetésmodellezésnek nem kell nehézkes programként indulnia. Egy új fizetési API, beléptetési munkafolyamat, AI-alapú funkció, identitásszolgáltatás, felhőmigráció vagy külső integráció esetén egy 90 perces tervezési kockázati sprint is értékes bizonyítékot eredményezhet.

1. Projektbiztonsági ellenőrzési pont megnyitása

Használja a P24 6.1.1 pontját kiváltó feltételként. Minden új alkalmazáshoz vagy jelentős változtatáshoz hozzon létre bizonyítékmappát a következőkkel:

• Architektúradiagram
• Adatáramlási diagram
• Bizalmi határok térképe
• Eszközlista
• Személyes adatokra vonatkozó megjegyzések
• Beszállítói és IKT-függőségi lista
• Kezdeti biztonsági követelmények
• Fenyegetési modell munkalap
• Kockázati nyilvántartási bejegyzések
• Kockázatcsökkentési és tesztelési visszakövethetőség
• Jóváhagyási feljegyzés

Kisebb szervezetek esetében a P24S Biztonságos fejlesztési szabályzat – KKV [P24S] ugyanezt a fegyelmet támogatja azzal, hogy a biztonságos fejlesztési folyamatokat összekapcsolja a fejlesztői hozzáférés-szabályozással, a teszteléssel, a fenyegetésmodellezéssel és a dokumentációval. Emellett auditcélból előírja az ellenőrzőlisták, felülvizsgálati jóváhagyások, tesztelési jelentések és komponensnyilvántartások központi megőrzését. A 11.3.1 pont az SA-3 és SA-15 közötti hivatkozásokkal határozza meg a biztonságos fejlesztési folyamatokat, beleértve a fenyegetésmodellezést.

2. Minimálisan szükséges adatáramlás felrajzolása

Ne kifinomult diagrammal kezdjen. Kezdje azokkal az adatáramlásokkal, amelyek kockázatot teremtenek:

• A felhasználó személyazonosító dokumentumokat vagy tranzakciós adatokat tölt fel.
• A webalkalmazás kéréseket küld az API-nak.
• Az API menedzselt tárolóba vagy adatbázisba ír.
• A beszállító ellenőrzési vagy analitikai adatokat kap.
• A belső elemzői portál megjeleníti az eredményeket.
• Az ügyfélrendszer lekéri az állapotot vagy a döntéseket.
• A naplók, megfigyelőeszközök és biztonsági mentések másolatokat kapnak.

Jelölje meg az egyes bizalmi határokat: internet és alkalmazás, alkalmazás és API, belső szolgáltatás és beszállító, éles rendszer és analitika, adminisztrátor és emelt jogosultságú funkció, valamint éles és nem éles környezet között.

3. STRIDE és visszaélési esetek együttes alkalmazása

Minden határnál tegye fel a STRIDE-kérdéseket, és írja le a visszaélési eseteket közérthető üzleti nyelven. A cél nem minden elképzelhető támadás felsorolása. A cél olyan reális, lényeges forgatókönyvek azonosítása, amelyek a bizalmasságot, sértetlenséget, rendelkezésre állást, adatvédelmet, rezilienciát vagy biztonságkritikus működést érintik.

4. Megállapítások átalakítása kockázati forgatókönyvekké

Használja a ZB 9. lépésének képletét:

„[Fenyegetés] kihasználja a(z) [sérülékenység] sérülékenységet a(z) [eszköz] esetében, ami [hatás] következménnyel jár.”

Például:

„Egy támadó kihasználja a gyenge objektumtároló-hozzáférés-szabályozást a személyazonosító dokumentumok adattárán, ami személyes adatok jogosulatlan nyilvánosságra kerülését és szabályozói bejelentési kitettséget eredményez.”

Ezután adja hozzá a felelőst, a valószínűséget, a hatást, az inherens kockázatot, a kockázatkezelési opciót, a célkontrollt, a maradványkockázatot és a bizonyítékot.

5. Követelmények és tesztek levezetése

A fenyegetési modell nem akkor kész, amikor a kockázatokat felsorolták. Akkor kész, amikor a kockázatcsökkentő intézkedéseket bevezették, tesztelték vagy formálisan elfogadták.

A Változáskezelési szabályzat – KKV gyakorlati kiváltó feltételt ad:

„Ha egy változtatás érzékeny adatokat, rendszer-hozzáférési jogosultságokat vagy külső integrációkat érint, biztonsági hatáselemzés szükséges. A kijelölt biztonsági vagy megfelelési kapcsolattartónak értékelnie kell, hogy a változtatás további kockázatokat vezet-e be, és további védelmi intézkedéseket kell javasolnia.”
A „Kockázatkezelés és kivételek” szakaszból, a szabályzat 7.5.1 pontja.

Az érzékeny adatok, a hozzáférési jogosultságok és a külső integrációk pontosan azok a változások, amelyek tervezési kockázati felülvizsgálatot igényelnek.

Mit fognak kérdezni a különböző auditorok?

Egy ISO/IEC 27001:2022 auditor meg fogja kérdezni, hogy a fenyegetésmodellezés része-e egy meghatározott kockázatértékelési folyamatnak, következetesek-e a kritériumok, a kockázatgazdák jóváhagyták-e a maradványkockázatokat, a kockázatkezelési tervek kapcsolódnak-e az SoA-hoz, és megőrzik-e a bizonyítékokat. Az ismételhetőséget, a verzióelőzményeket, a vezetőségi felülvizsgálatokban való láthatóságot és a belső audit lefedettségét fogja keresni.

Az A melléklet kapcsán a bizonyítékokat az 5.8, 8.25, 8.26, 8.27 és 8.29 kontrollokhoz fogja kapcsolni. A ZB 21. lépése, a Kontrollok működés közben, a biztonságos rendszerarchitektúra és mérnöki alapelvek fontosságát emeli ki azzal a kérdéssel, hogy milyen alapelvek irányítják a biztonságos architektúrát. Az auditorok megkérdezhetik, hogy a fenyegetésmodellezést a tervezés során végzik-e olyan módszerekkel, mint a STRIDE vagy a támadási fák, és hogy az architekturális döntéseket a megvalósítás előtt felülvizsgálják-e.

Egy NIS2-felülvizsgáló az irányításra és az arányosságra fog összpontosítani. Megkérdezheti, hogy a vezetés jóváhagyta-e a kiberbiztonsági kockázatkezelési megközelítést, lefedik-e a biztonságos beszerzést, fejlesztést és karbantartást, figyelembe veszik-e a beszállítói sérülékenységeket, az incidensforgatókönyvek kapcsolódnak-e a jelentéstételi munkafolyamatokhoz, és elemzik-e a folytonossági forgatókönyveket. A NIS2 Article 23 szerinti, jelentős incidensekre vonatkozó szakaszos jelentéstétel — beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli bejelentést és az egy hónapon belüli zárójelentést — különösen értékessé teszi a forgatókönyvek egyértelműségét.

Egy DORA-vizsgáló az IKT-kockázatirányításra, a kritikus funkciókra, az IKT-eszközökre, a külső függőségekre, a rezilienciatesztelésre és a harmadik fél által nyújtott IKT-szolgáltatásokra fog összpontosítani. Ha a rendszer kritikus vagy fontos funkciót támogat, erősebb bizonyítékokat fog elvárni a fenyegetési forgatókönyvek eszköznyilvántartásokhoz, függőségi térképekhez, tesztelési tervekhez, harmadik fél szerződésekhez és helyreállítási intézkedésekhez való kapcsolására.

Egy adatvédelmi felülvizsgáló megvizsgálja az adatáramlásokat, és megkérdezi, hogy a személyes adatok kezelése szükséges, jogszerű, adattakarékos és védett-e. Megkérdezi, hogy érintettek-e különleges adatkategóriák, alkalmaznak-e álnevesítést vagy titkosítást, indokolt-e a megőrzés, és szükséges-e DPIA. A fenyegetésmodellezés és a DPIA külön tevékenységek, de közös diagramokra, forgatókönyvekre és kockázatcsökkentő intézkedésekre kell épülniük.

Egy NIST CSF- vagy COBIT 2019-orientált felülvizsgáló az irányítást, a folyamatfelelősséget, a teljesítményt, az elszámoltathatóságot és a folyamatos fejlesztést fogja keresni. Lehet, hogy kevésbé érdekli maga a STRIDE-munkalap, és inkább az, hogy a folyamat megbízható, mérhető, jóváhagyott és fejlesztett-e.

Gyakori fenyegetésmodellezési bizonyítékhibák

A leggyakoribb hibák nem technikai hibák. Bizonyítékhibák.

A csapatok túl későn végzik el a fenyegetésmodellezést, amikor a rendszer már elkészült. Ekkor a workshop tervezési kontroll helyett penetrációs teszt előtti eligazítássá válik.

A megállapításokat nem alakítják át kockázati nyelvre. Az „auth hozzáadása” vagy a „naplózási probléma” segíthet a mérnököknek, de az auditoroknak eszközre, fenyegetésre, sérülékenységre, hatásra, felelősre, kockázatkezelésre és maradványkockázatra van szükségük.

Az adatvédelmet és a biztonságot szétválasztják. Az egyik csapat megszemélyesítési és injektálási kockázatot dokumentál, míg a másik megőrzést és jogalapot. A GDPR szerinti elszámoltathatóság jobban működik, ha az adatáramlások, a visszaélési esetek és a DPIA-kiváltó okok kapcsolódnak egymáshoz.

A beszállítói feltételezések dokumentálatlanok maradnak. A NIS2, DORA és NIST CSF egyaránt magasabb elvárásokat támaszt az IKT-ellátási lánc kockázataival szemben. Ha egy kockázatcsökkentő intézkedés beszállítói titkosítástól, naplózástól, törléstől, rezilienciától vagy incidensreagálástól függ, gyűjtse be a bizonyítékokat.

A teszteket nem rendelik vissza a fenyegetésekhez. Egy penetrációs tesztjelentés hasznos lehet, de nem feltétlenül bizonyítja, hogy a konkrét tervezési kockázatokat kezelték. Minden jelentős fenyegetési megállapításhoz ellenőrzési bizonyítéknak kell tartoznia.

A maradványkockázat elfogadása informális. Az „MVP-re elfogadjuk” nem elegendő. Az ISO/IEC 27001:2022 dokumentált információként várja el a maradványkockázat megfelelő kockázatgazdák általi elfogadását.

A 2026-os fenyegetésmodellezési bizonyítékcsomag

Minden jelentős rendszerhez vagy lényeges változtatáshoz tartson fenn egységes bizonyítékcsomagot, amely támogatja az ISO 27001, NIS2, DORA, CRA, GDPR megfelelést és az ügyfélbizonyosságot.

A Kockázatkezelési szabályzat – KKV jól ragadja meg a működési modellt:

„Biztosítja, hogy a kockázatkezelés a tervezés, a projektvégrehajtás, a beszállító-kiválasztás és az incidensreagálás aktív eleme legyen, összhangban az ISO 27001, ISO 31000 és az alkalmazandó szabályozási követelményekkel.”
A „Cél” szakaszból, a szabályzat 1.2 pontja.

Ez a helyes célállapot. A fenyegetésmodellezésnek hatással kell lennie a tervezésre, a mérnöki munkára, a beszállító-kiválasztásra, az incidensreagálásra és az auditra való felkészültségre.

Tegye auditra alkalmassá a fenyegetésmodellezést a következő kiadás előtt

A 2026-os megfelelési nyomást nem azok a szervezetek kezelik majd a legjobban, amelyeknek a legtöbb diagramjuk van. Hanem azok, amelyek képesek igazolni egy egyszerű láncot:

A tervezési kockázatot azonosították. A kockázatot értékelték. A kontrollokat kiválasztották. A kockázatcsökkentő intézkedéseket bevezették. A tesztek ellenőrizték a kockázatcsökkentő intézkedéseket. A maradványkockázatot jóváhagyták. A bizonyítékok megfeleltethetők a releváns keretrendszereknek.

Kezdje egy magas kockázatú változással: fizetési integrációval, új API-val, AI-alapú munkafolyamattal, identitásfunkcióval, felhőmigrációval, ügyféloldali termékkiadással vagy beszállítóhoz kapcsolódó szolgáltatással. Futtasson le egy 90 perces tervezési kockázati sprintet. Használja a ZB-t a megállapítások kockázati forgatókönyvekké, kockázatkezelési tervekké és SoA-visszakövethetőséggé alakításához. Használja a ZC-t az ISO/IEC 27002:2022 olyan kontrolljainak megfeleltetésére, mint az 5.8, 8.25, 8.26, 8.27 és 8.29, a támogató kontrollokhoz, beszállítói kockázathoz, adatvédelemhez, teszteléshez és auditbizonyítékokhoz. Hangolja össze a P24, P06, P17, P24S dokumentumokat és a változáskezelési eljárást úgy, hogy a fenyegetésmodellezés kötelező, ismételhető és felülvizsgálható legyen.

Ha azt szeretné, hogy a Clarysec segítsen, kezdje fenyegetésmodellezési bizonyíték-felülvizsgálattal. Értékelünk egy valós projektet, azonosítjuk a hiányosságokat az ISO/IEC 27001:2022, NIS2, DORA, CRA és GDPR elvárásaihoz képest, és gyakorlati helyesbítő ütemtervet adunk, amelyet a mérnökök, auditorok és az igazgatóság egyaránt érteni fog.