⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

ENISA EUVD 2026: ISO 27001 a NIS2 és a CRA támogatására

Igor Petreski
14 min read
ENISA EUVD ISO 27001 NIS2 CRA sérülékenységkezelési munkafolyamat

2026 egyik keddjén 08:17 van. Maria, egy gyorsan növekvő fintech SaaS platform CISO-ja, perceken belül két jelzést kap. Először a SOC egy ENISA EU Vulnerability Database-riasztást tesz közzé az incidenscsatornában. Az érintett komponens nem közvetlenül Maria saját kódbázisában található. Egy harmadik féltől származó hitelesítési SDK-ban van, amelyet egy kiszervezett fejlesztési partner által karbantartott mobilalkalmazásba építettek be.

Ezután egy biztonsági kutató e-mailt küld a nyilvános biztonsági kapcsolattartónak a következő tárggyal: „Vulnerability Disclosure - Your SaaS Product”. A kutató azt állítja, hogy meghatározott feltételek mellett a hiba nem kritikus ügyfél-metaadatokat tehet hozzáférhetővé.

Nincs megerősített adatsértés. Egyetlen ügyfél sem jelzett kárt. A vizsgálati irányítópult sem piros. A kérdések azonban azonnal megérkeznek.

Érintettek vagyunk? Mely ügyféloldali szolgáltatások használják az SDK-t? Ez NIS2 szerinti jelentős incidens, DORA szerinti IKT-vonatkozású incidens, GDPR szerinti személyesadat-sértés, vagy a Cyber Resilience Act hatálya alá tartozó termékbiztonsági ügy? Értesítenünk kell beszállítót, ügyfelet, illetékes hatóságot vagy az ENISA-t? És ami a legfontosabb: tudjuk bizonyítani, mikor szereztünk róla tudomást?

Sok szervezet ilyenkor szembesül azzal, hogy a fenyegetettségi információk kezelése nem hírcsatorna-probléma. Működési modell probléma.

Az ENISA EUVD gyakorlati hivatkozási ponttá válik az uniós sérülékenységi információk, a koordinált sérülékenység-feltárás és a termékbiztonsági átláthatóság területén. Maga az adatbázis azonban nem fogja megmondani Mariának, hogy az érintett szolgáltatás a NIS2 hatálya alá tartozik-e, a DORA alkalmazandó-e a pénzügyi szolgáltatási tevékenységek miatt, valószínű-e a személyes adatok kitettsége, vagy aktiválódik-e a CRA szerinti jelentési felkészülés. Ezeknek a döntéseknek irányított, dokumentált és auditálható információbiztonság-irányítási rendszeren belül kell megszületniük.

A Clarysec megközelítése az EUVD operacionalizálása ISO/IEC 27001:2022 szerinti irányítással, ISO/IEC 27002:2022 kontrollbevezetéssel, szabályzatgazdai felelősséggel és több követelményrendszert lefedő megfelelőségi bizonyítékokkal. A cél nem egy újabb „EUVD tracker” nevű táblázat létrehozása. A cél olyan igazolható sérülékenységi információs és jelentési modell kialakítása, amely megállja a helyét szabályozó hatósági kérdések, ügyfélauditok, ISO 27001 tanúsítási auditok és igazgatósági felülvizsgálat során.

Miért változtatja meg az ENISA EUVD a sérülékenységkezelést 2026-ban

Éveken át sok biztonsági csapat a fenyegetettségi információkat a javításkezelés bemeneteként kezelte. Megjelenik egy CVE, egy vizsgálóeszköz kitettséget észlel, az üzemeltetés telepíti a javítást, a jegyet pedig lezárják. Ez a modell már nem elegendő az EU-ban szabályozott szervezetek számára.

A NIS2 a kiberbiztonsági kockázatkezelést az irányítás részévé teszi. Article 20 előírja, hogy az alapvető és fontos szervezetek irányító testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását, és kiberbiztonsági képzésben részesüljenek. Article 21 arányos technikai, operatív és szervezeti intézkedéseket ír elő, ideértve a szabályzatokat, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést és karbantartást, a sérülékenységkezelést és -feltárást, az eredményességértékelést, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést, valamint adott esetben a többtényezős hitelesítést vagy a folyamatos hitelesítést.

Article 23 szakaszos jelentést vezet be a jelentős incidensekre, beleértve a tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az egy hónapon belüli zárójelentést. Ha egy EUVD-riasztás kihasznált szolgáltatáskimaradássá válik, a szervezetnek bizonyítékokra van szüksége a tudomásszerzésről, a triage-ról, a hatásvizsgálatról, a kockázatcsökkentésről és a jelentési döntésekről.

A DORA párhuzamos, de ágazatspecifikus rendszert hoz létre a pénzügyi szervezetek számára. Belső irányítási és kontrollrendszereket ír elő az IKT-kockázatokra, az irányító testület elszámoltathatóságát, incidenskezelési folyamatokat, harmadik félhez kapcsolódó IKT-kockázatkezelést, tesztelést, rezilienciát, szerződéses kontrollokat, valamint a jelentős IKT-vonatkozású incidensek jelentését a DORA Article 19 alapján. A hatálya alá tartozó pénzügyi szervezetek esetében a DORA az IKT-kockázatok és az incidensjelentés ágazatspecifikus keretrendszereként működik.

A GDPR további dimenziót ad. Ha a kihasználás személyes adatokhoz való jogosulatlan hozzáférést, azok közlését, elvesztését, megváltoztatását vagy megsemmisítését okozhatja, a sérülékenységkezelési munkafolyamatot össze kell kapcsolni a személyesadat-sértés értékelésével. A GDPR elszámoltathatósági elve azt jelenti, hogy az adatkezelőnek bizonyítania kell a megfelelést; nem elegendő csupán azt állítani, hogy észszerűen járt el.

A Cyber Resilience Act a digitális elemeket tartalmazó termékek esetében termékbiztonsági kötelezettséggé teszi a sérülékenységek kezelését és a koordinált közzétételt. Emellett adott esetben jelentési elvárásokat állít fel az aktívan kihasznált sérülékenységekre és a súlyos biztonsági incidensekre. Még ha a végső jogi jelentési döntés szakértői felülvizsgálatot igényel is, az operatív bizonyíték biztonsági bizonyíték: érintett termék, érintett verzió, kihasználhatóság, kockázatcsökkentés, közzétételi státusz, ügyfélhatás, beszállítói koordináció és idővonal.

Amint egy sérülékenység az EUVD-n keresztül nyilvánosan láthatóvá válik, az auditorok és a szabályozó hatóságok megkérdezhetik, miért nem értékelték, miért nem azonosították az érintett eszközöket, miért nem vették fel a kapcsolatot a beszállítókkal, vagy miért nem mérlegelték a jelentést. A legerősebb szervezetek hat kérdésre tudnak bizonyítékokkal válaszolni:

  1. Mely EUVD-riasztások relevánsak számunkra?
  2. Mely eszközök, termékek, beszállítók és ügyfelek érintettek?
  3. Ki a döntés felelőse?
  4. Milyen helyesbítési vagy kockázatcsökkentési határidő alkalmazandó?
  5. Mikor válik a sérülékenységkezelés incidensjelentéssé?
  6. Hogyan bizonyítjuk a lezárást és a vezetői felügyeletet?

Az ISO 27001:2022 alapja az EUVD-bizonyítékokhoz

Az ISO/IEC 27001:2022 természetes irányítási rendszerbeli gerincet ad az EUVD operacionalizálásához, mert a kontextusból, az érdekelt felekből, a hatályból, a kockázatból és a bizonyítékokból indul ki.

A 4.1–4.4 pontok előírják, hogy a szervezet határozza meg a belső és külső tényezőket, az érdekelt feleket, a jogi, szabályozási és szerződéses követelményeket, az IBIR alkalmazási területét, az interfészeket és a függőségeket. Az EUVD-re való felkészültség esetén az IBIR alkalmazási területe nem állhat meg a belső szervereknél. Figyelembe kell vennie a SaaS termékeket, a felhőszolgáltatásokat, a kiszervezett fejlesztést, a menedzselt szolgáltatókat, az IKT-beszállítókat, az ügyfélvállalásokat, a szabályozási kötelezettségeket és a terméksérülékenységekkel kapcsolatos elvárásokat.

Az 5.1–5.3 pontok vezetői szerepvállalást, szabályzati összhangot, erőforrásokat, kommunikációt, elszámoltathatóságot és jelentési felelősségeket írnak elő. Itt fogadja el a felső vezetés, hogy a fenyegetettségi információ nem technikai udvariasság. Üzleti kockázati jelzés.

A 6.1.1–6.1.3 pontok adják a kockázatértékelés, a kockázatkezelés, a kontrollkiválasztás, az A melléklet szerinti összevetés, az alkalmazhatósági nyilatkozat, a maradványkockázat jóváhagyása és a kezelési tervezés mechanizmusát. Amikor egy EUVD-bejegyzés érinti a környezetet, a válasznak megismételhető kockázati munkafolyamatot kell indítania, amely összekapcsolja az érintett eszközöket, a valószínűséget, a hatást, a meglévő kontrollokat, a kezelési lehetőségeket és a kockázatgazda jóváhagyását.

A 8.1–8.3 és 9.1–9.3 pontok ezt a modellt működési ciklussá alakítják. A szervezeteknek meg kell tervezniük és szabályozniuk kell az IBIR-folyamatokat, meg kell őrizniük a dokumentált információkat, ellenőrzés alatt kell tartaniuk a külsőleg biztosított folyamatokat, újra kell értékelniük a kockázatokat, végre kell hajtaniuk a kockázatkezelési terveket, figyelemmel kell kísérniük és mérniük kell a teljesítményt, belső auditokat kell végezniük, és vezetőségi felülvizsgálatokat kell tartaniuk.

Gyakorlati szinten a Clarysec az EUVD-t három rétegbe illeszti:

RétegISO 27001:2022 szerinti célEUVD működési kérdésBizonyítéki artefaktum
IrányításHatály, érdekelt felek, elszámoltathatóság, jogi kötelezettségekAzonosították a NIS2, DORA, GDPR, ügyfél- és CRA-kapcsolódó elvárásokat?IBIR alkalmazási területe, jogi nyilvántartás, szerepkörmátrix, szabályzat-jóváhagyások
Kockázat és kontrollokKockázatértékelés, kockázatkezelés, alkalmazhatósági nyilatkozatReleváns, priorizált és felelőshöz rendelt a sérülékenység?Sérülékenységi kockázati bejegyzés, SoA-megfeleltetés, kockázatkezelési terv
BizonyosságMegfigyelés, belső audit, vezetőségi felülvizsgálatTudjuk bizonyítani az időben történő reagálást és fejlesztést?Javítási naplók, beszállítói bizonyítékok, incidensdöntések, auditmegállapítások, vezetőségi felülvizsgálati jegyzőkönyvek

Az alapelv egyszerű. Az EUVD-riasztásoknak az IBIR-en belüli nyilvántartásokká kell válniuk, nem pedig informális csevegőüzenetekké, amelyek a javítás telepítése után eltűnnek.

Az ISO 27001 kontrollkészlet, amely az EUVD-t cselekvőképessé teszi

Az EUVD-működés szempontjából az ISO/IEC 27001:2022 A mellékletének legfontosabb kontrolljai az 5.7 Fenyegetettségi információk, 8.8 Technikai sérülékenységek kezelése, 5.21 Információbiztonság kezelése az IKT-ellátási láncban, valamint 5.31 Jogi, jogszabályi, szabályozói és szerződéses követelmények.

A Clarysec ezeket a Zenith Controls: The Cross-Compliance Guide Zenith Controls segítségével felelteti meg, amely több követelményrendszert átfogó megfelelési iránytűként működik az ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF és az auditbizonyíték-tervezés számára.

A Zenith Controls ISO/IEC 27002:2022 5.7, Fenyegetettségi információk kontrollra vonatkozó megfeleltetése megelőző, észlelő és helyesbítő kontrollként jelöli, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és összhangban áll az Identify, Detect és Respond kiberbiztonsági koncepciókkal. Operatív képessége a fenyegetés- és sérülékenységkezelés, biztonsági területei pedig a védelem és a reziliencia.

A Zenith Controls ISO/IEC 27002:2022 8.8, Technikai sérülékenységek kezelése kontrollra vonatkozó megfeleltetése megelőző kontrollként jelöli, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és összhangban áll az Identify és Protect koncepciókkal. Operatív képessége a fenyegetés- és sérülékenységkezelés, biztonsági területei pedig az irányítás, az ökoszisztéma, a védelem és az elhárítás.

A Zenith Controls ISO/IEC 27002:2022 5.21, Információbiztonság kezelése az IKT-ellátási láncban kontrollra vonatkozó megfeleltetése megelőző kontrollként jelöli, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és összhangban áll az Identify koncepcióval. Operatív képessége a beszállítói kapcsolatok biztonsága, irányítási, ökoszisztéma- és védelmi területekkel.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a 23. lépésben, a Jogi, jogszabályi, szabályozói és szerződéses követelményeknél szintén kiemeli az 5.31 kontrollt:

A biztonság nem légüres térben létezik. Kötelezettségek hálójában működik: egyeseket jogszabály határoz meg, másokat szerződés, megint másokat ágazatspecifikus szabályozás.

Ez az irányítási híd az EUVD és a szabályozói jelentés között. Egy sérülékenységi bejegyzés indulhat fenyegetettségi információként, technikai sérülékenységi jeggyé válhat, beszállítói együttműködést indíthat, majd incidenssé vagy jogi értesítési döntéssé alakulhat.

ISO/IEC 27002:2022 kontrollEUVD-szerepTámogató ISO 27001:2022 mechanizmusTöbb követelményrendszert lefedő megfelelési relevancia
5.7 Fenyegetettségi információkEUVD-, CERT-, beszállítói és ágazati információk befogadása, majd kontextusba helyezése4., 6., 8. és 9. pont a hatályra, kockázatra, működésre és felülvizsgálatraNIS2 kockázati intézkedések, NIST CSF Identify és Detect, DORA szerinti fenyegetés- és incidenstudatosság
8.8 Technikai sérülékenységek kezeléseKitettség ellenőrzése, súlyosság hozzárendelése, helyesbítés vagy kockázatcsökkentés, lezárás rögzítéseKockázatkezelés, operatív kontroll, felügyelet és bizonyítékmegőrzésNIS2 sérülékenységkezelés, CRA terméksérülékenységi munkafolyamat, NIST CSF sérülékenységkezelés
5.21 Információbiztonság kezelése az IKT-ellátási láncbanÉrintett beszállítók, szerződéses kötelezettségek, beszállítói helyesbítő intézkedések és bizonyítékok visszakövetéseKülsőleg biztosított folyamatok, beszállítói kockázatkezelés, vezetőségi felülvizsgálatNIS2 ellátásilánc-biztonság, DORA harmadik félhez kapcsolódó IKT-kockázat, NIST CSF GV.SC
5.31 Jogi, jogszabályi, szabályozói és szerződéses követelményekNIS2, DORA, GDPR, CRA, ügyfél- és ágazati kötelezettségek eljárásokba illesztéseÉrdekelt felek, jogi nyilvántartás, kockázatkezelés, belső audit és vezetőségi felülvizsgálatSzabályozói elszámoltathatóság, auditra való felkészültség, ügyfélbizonyosság és igazgatósági felügyelet

Ezért az EUVD-t nem szabad egyszerűen egy újabb hírcsatornaként kezelni. Kontrollintegrációs pont.

A Clarysec szabályzati modellje: riasztástól az elszámoltatható döntésig

Egy érett EUVD működési modellnek olyan szabályzati nyelvezetre van szüksége, amely még az első kritikus riasztás előtt megmondja a csapatoknak, mit kell tenniük.

A Clarysec Vulnerability and Patch Management Policy Sérülékenység- és javításkezelési szabályzat egyértelmű megfigyelési és eszkalációs mandátumot ad a vállalati csapatoknak:

Figyelni kell a fenyegetettségi tájékoztatókat (pl. CVE, CISA KEV, beszállítói közlemények), és eszkalálni kell a kritikus sérülékenységeket.

Ugyanez a szabályzat központi bizonyítékalapot ír elő:

A Biztonsági üzemeltetés csapatnak központi Sérülékenységkezelési nyilvántartást kell fenntartania, amelyet a CISO vagy a kijelölt helyettes havonta felülvizsgál.

A KKV-k számára a Clarysec Vulnerability and Patch Management Policy - SME Sérülékenység- és javításkezelési szabályzat – KKV a forrásmodellt is egyértelművé teszi az alábbiak beemelésével:

Megbízható fenyegetettségi információs tájékoztatók (pl. CISA, ENISA, nemzeti CERT-riasztások)

Az auditnyomot is megőrzi:

Javítási naplót kell vezetni, és azt auditok és incidensreagálási tevékenységek során felül kell vizsgálni.

Ezek a rendelkezések megelőznek egy gyakori hibát. Ha beérkezik egy EUVD-riasztás, és senki sem tudja, hogy sérülékenységi nyilvántartásba, incidensorba, beszállítói nyomonkövetőbe vagy jogi értékelésbe tartozik-e, a szervezet időt veszít. A szabályzati nyelvezet automatikussá teszi az első lépést.

A CVD-dimenziót a Clarysec Coordinated Vulnerability Disclosure Policy Koordinált sérülékenység-feltárási szabályzat kezeli, amely biztosítja a befogadási, visszaigazolási, súlyosságértékelési és ellenőrzési munkafolyamatot:

A bejelentés kézhezvételekor a VRT köteles azt rögzíteni, és 2 munkanapon belül visszaigazolást küldeni a bejelentőnek, nyomonkövetési hivatkozás hozzárendelésével. A VRT köteles előzetes súlyosságértékelést végezni, például CVSS-pontozás alkalmazásával, és az ügyet ellenőrizni, szükség esetén az IT- és fejlesztői csapatok támogatásával, 5 munkanapos célhatáridőn belül. A kritikus sérülékenységeket, például a távoli kódfuttatást vagy jelentős adatsértést lehetővé tevő sérülékenységeket gyorsított eljárásban kell kezelni.

A harmadik féltől származó sérülékenységeket is összekapcsolja a beszállítói együttműködéssel:

Minden megerősített kritikus vagy magas kockázatú sérülékenység esetén a CISO köteles haladéktalanul tájékoztatni a felső vezetést és az érintett rendszergazdákat. Ha a sérülékenység beszállító vagy más harmadik fél által nyújtott termékeket vagy szolgáltatásokat érint, a VRT köteles indokolatlan késedelem nélkül értesíteni a beszállító biztonsági kapcsolattartóját, és együttműködést kérni a helyesbítésben.

A Clarysec Application Security Requirements Policy - SME Alkalmazásbiztonsági követelmények szabályzata – KKV megerősíti a termékekre és beszállítókra vonatkozó elvárásokat azzal, hogy előírja a csapatok számára:

meg kell határozniuk a sérülékenységek közzétételére, a válaszidőkre és a javításkezelésre vonatkozó kötelezettségeket.

A beszállítói szerződésekhez a Clarysec Third-Party and Supplier Security Policy - SME Harmadik félre és beszállítói biztonságra vonatkozó szabályzat – KKV a következőt tartalmazza:

Adatsértési bejelentési határidők (pl. 24–72 órán belül)

Végül a Clarysec Incident Response Policy Incidenskezelési szabályzat a 6.4.1 ponton keresztül összekapcsolja a szabályozott adatokat és az ágazati jelentést az incidensdöntéssel:

Szabályzati pontJelentési vagy értékelési területGyakorlati EUVD-relevancia
6.4.1.1GDPR Article 33, 72 órás bejelentés a felügyeleti hatóságnakAnnak értékelése, hogy a kihasználás személyesadat-sértést okozott-e
6.4.1.2GDPR Article 34, érintettek értesítése magas kockázat eseténAnnak értékelése, hogy az érintett személyeket tájékoztatni kell-e
6.4.1.3NIS2 Article 23, jelentős incidensek jelentési határidőiKorai figyelmeztetés, 72 órás bejelentés és zárójelentési kötelezettségek értékelése
6.4.1.4DORA Article 17 incidenskezelés és DORA Article 19 jelentős IKT-vonatkozású incidensek jelentésePénzügyi ágazati incidensbesorolás és jelentés értékelése

A KKV-verzió ugyanezt a gyakorlati kiváltó feltételt tartja meg. A Clarysec Incident Response Policy - SME Incidenskezelési szabályzat – KKV kimondja:

Ügyféladatok érintettsége esetén az ügyvezető köteles értékelni a jogi értesítési kötelezettségeket a GDPR, a NIS2 vagy a DORA alkalmazhatósága alapján.

Ez a híd a „láttunk egy sérülékenységet” és az „értékeltük, hogy bejelentésköteles-e” között.

Gyakorlati EUVD-befogadási bejegyzés

Tegyük fel, hogy az EUVD közzétesz vagy frissít egy sérülékenységi bejegyzést, amely Maria mobilalkalmazásának hitelesítési SDK-ját érinti. Az SDK-t egy beszállító tartja karban, egy kiszervezett fejlesztési partner integrálja, és olyan ügyfelek használják, akik egy fintech SaaS termékhez hitelesítik magukat. Nyilvános exploit-megbeszélés létezik, de a bérlői naplókban nincs megerősített kihasználás.

Egy igazolható befogadási bejegyzésnek mind a technikai, mind a szabályozói kontextust rögzítenie kell.

MezőPéldabejegyzésMiért fontos
Tudomásszerzési időbélyeg2026-02-10 08:17 CET, SOC-elemző által egyeztetett EUVD-riasztásTámogatja a jelentési idővonal elemzését és az auditbizonyítékot
ForrásENISA EUVD, beszállítói tájékoztató, nemzeti CERT-kereszthivatkozás, kutatói bejelentésMegmutatja a megbízható információforrást és a korrelációt
Érintett eszközÜgyféloldali mobilalkalmazás hitelesítési modulja, SDK 4.8.2 verzióÖsszekapcsolja a sérülékenységet a termék- és szolgáltatásfelelősséggel
Beszállítói függőségSDK-beszállító és kiszervezett mobilfejlesztési partnerBeszállítói kapcsolatfelvételt és szerződéses bizonyítékokat indít
AdatosztályozásÜgyfélazonosítók, munkamenet-tokenek, lehetséges személyes adatokÖsszekapcsolja a GDPR-ral és az incidens hatásvizsgálatával
Kezdeti súlyosságKritikus, ellenőrzés alatt; CVSS és üzleti hatás felülvizsgálvaTámogatja a priorizálást és az eszkalációt
Fenyegetési kontextusNyilvános exploit-megbeszélés, nincs megerősített kihasználás a naplókbanElválasztja a sérülékenységi kitettséget az incidens megerősítésétől
NIS2-értékelésLehetséges szolgáltatási hatás, megerősített kiesés még nincsMegőrzi az Article 23 szerinti eszkaláció döntési logikáját
DORA-értékelésAlkalmazandó, ha a szolgáltatás pénzügyi szervezeti hatályt vagy kritikus funkciókat támogatElkerüli az ismételt vagy elmulasztott ágazati jelentést
CRA-értékelésTerméksérülékenységi munkafolyamat indult az alkalmazhatóság vizsgálatáraÖsszekapcsolja a termékbiztonsági kötelezettségeket a sérülékenységi bizonyítékokkal
KezelésSDK frissítése, tokenrotáció kikényszerítése, megfigyelés erősítése, beszállítói megerősítésHelyesbítési és kockázatcsökkentési tervet hoz létre
MaradványkockázatA rendszergazda elfogadta 48 órás bevezetési ablakraMegmutatja a kockázattulajdonosi felelősséget és a kompenzáló kontrollokat
Lezárási bizonyítékJavítási napló, telepítési jegy, beszállítói nyilatkozat, vizsgálati eredmény, vezetői tájékoztatásAuditra kész bizonyítékot hoz létre

Ez a bejegyzés nem megfelelőségi díszlet. Ez a döntések kontrollközpontja.

Egy gyakorlati munkafolyamat így néz ki:

  1. A SOC megkapja az EUVD-riasztást, és sérülékenységi bejegyzést hoz létre.
  2. Az eszközfelelős megerősíti, hogy az érintett komponens jelen van-e az éles környezetben.
  3. A biztonsági csapat súlyosságértékelést végez a technikai súlyosság, a kihasználhatóság, a kitettség, az adatok érzékenysége és a szolgáltatáskritikusság alapján.
  4. A beszállítói felelős előre meghatározott biztonsági kapcsolattartókon keresztül felveszi a kapcsolatot az SDK-beszállítóval vagy a kiszervezett fejlesztési partnerrel.
  5. Az incidensreagálási vezető eldönti, van-e bizonyíték kihasználásra, szolgáltatási hatásra vagy ügyfélkárra.
  6. A jogi, DPO és megfelelőségi funkció értékeli, hogy aktiválódnak-e GDPR-, NIS2-, DORA- vagy CRA-kapcsolódó munkafolyamatok.
  7. A mérnöki csapat telepíti a javítást vagy a kockázatcsökkentő intézkedést.
  8. A biztonsági csapat vizsgálattal, verzióellenőrzéssel, naplófelülvizsgálattal vagy kompenzáló kontroll tesztjével ellenőrzi a helyesbítést.
  9. A CISO felülvizsgálja a kritikus és magas súlyosságú bejegyzéseket, és trendeket jelent a vezetőségi felülvizsgálat felé.

A Kontrollok a gyakorlatban szakasz 19. lépésében, a Technológiai kontrollok I részben a Zenith Blueprint közérthető auditori terminológiával magyarázza a technikai sérülékenységkezelést:

A kontroll nem a tökéletességről szól, hanem arról, hogy szervezett, átlátható és elszámoltatható folyamat működjön.

Ez a mondat fontos. A szabályozó hatóságok és az auditorok nem várják el, hogy minden sérülékenységet azonnal kijavítsanak. Azt várják el, hogy a szervezet tudja, mi létezik, priorizáljon, arányos intézkedést tegyen, rögzítse a kivételeket, és bizonyítsa a végrehajtást.

A fenyegetettségi információ döntési funkció, nem postafiók

Az EUVD-tervezés legnagyobb hibája az, ha a hírcsatornát egyetlen elemzőhöz rendelik, és ezt „fenyegetettségi információnak” nevezik. A Zenith Blueprint a Kontrollok a gyakorlatban szakasz 22. lépésében, a Szervezeti kontrollok résznél így magyarázza az ISO/IEC 27002:2022 5.7 kontrollját:

A legjobb fenyegetésintelligencia-források gyakran belső megfigyelés, külső partnerségek és közösségi részvétel kombinációjából állnak.

Arra is figyelmeztet, hogy az információnak cselekvéssé kell válnia:

Ez a kontroll a döntéshozatalban kel igazán életre. A fenyegetettségi információknak közvetlenül befolyásolniuk kell, mely kontrollokat erősítik meg, mely eszközöket sorolják át vagy különítik el, milyen forgatókönyveket tesztelnek asztali gyakorlatokon, és milyen gyorsan telepítik a javításokat vagy kockázatcsökkentő intézkedéseket.

Az EUVD esetében az információ felhasználóit szerepkör szerint kell meghatározni.

SzerepkörEUVD-felelősségElvárt bizonyíték
SOC-elemzőEUVD és kapcsolódó tájékoztatók figyelése, bejegyzések megnyitása, naplók korrelálásaRiasztási bejegyzés, IoC-keresés, észlelési jegyzetek
Sérülékenységkezelési vezetőKitettség ellenőrzése, kockázat pontozása, helyesbítés hozzárendeléseSérülékenységnyilvántartás, SLA, kivételbejegyzés
TerméktulajdonosÉrintett termékverziók és ügyfélhatás megerősítéseTermékfüggőségi bejegyzés, kiadási terv
BeszállítókezelőBeszállító megkeresése, helyesbítési bizonyíték beszerzése, szerződéses kötelezettségek nyomon követéseBeszállítói jegy, nyilatkozat, frissített szerződéses záradék
Incidensreagálási vezetőKihasználás, hatás és eszkaláció meghatározásaIncidens triage-bejegyzés, döntési napló
Jogi és DPOGDPR-, NIS2-, DORA- és CRA-kapcsolódó értesítések értékeléseJogi értékelés, jelentési döntés
CISOVezetés tájékoztatása, maradványkockázat elfogadása, erőforrások biztosításaVezetői jelentés, kockázatelfogadás

A NIST CSF 2.0 segíthet ennek a modellnek a strukturálásában. GOVERN funkciója az érdekelt felek elvárásaira, a jogi és szabályozási kötelezettségekre, a kockázatvállalási hajlandóságra, a vezetői elszámoltathatóságra, a meghatározott szerepkörökre, a szabályzatokra, az erőforrásokra és a felügyeletre helyezi a hangsúlyt. Operatív funkciói segítik az eszköznyilvántartások, a sérülékenységazonosítás, a védelem, az észlelés, a reagálás, a helyreállítás és a fejlesztés rendszerezését. A NIST CSF Profile módszer használható az EUVD-működés aktuális és célállapotának meghatározására, majd a hiányosságok priorizált intézkedési tervvé alakítására.

Clarysec-megközelítésben a NIST CSF hasznos rendszerező réteg, az ISO/IEC 27001:2022 az auditálható irányítási rendszer, a Zenith Controls pedig az a több követelményrendszert átfogó megfelelési iránytű, amely koherensen tartja a megfeleltetéseket.

Beszállítói és terméksérülékenységek nyomon követése

A NIS2 Article 21 az ellátási lánc biztonságát a minimális kiberbiztonsági kockázatkezelési intézkedések részévé teszi. Az Article 21(3) előírja, hogy a szervezetek vegyék figyelembe az egyes közvetlen beszállítókra és szolgáltatókra jellemző sérülékenységeket, a termékek minőségét és a beszállítók kiberbiztonsági gyakorlatait, beleértve a biztonságos fejlesztési eljárásokat. A (85) és (86) preambulumbekezdések hangsúlyozzák az adatkezelésből, menedzselt szolgáltatásokból, szoftverszállítókból és menedzselt biztonsági szolgáltatókból eredő harmadik fél kockázatokat.

A DORA előíróbb a pénzügyi szervezetek számára. Előírja, hogy a harmadik félhez kapcsolódó IKT-kockázatot az IKT-kockázati keretrendszer részeként kell kezelni, információs nyilvántartásokkal, kellő gondossággal, koncentrációs kockázatelemzéssel, írásbeli szerződésekkel, audit- és ellenőrzési jogokkal, incidenssegítséggel, alvállalkozói átláthatósággal, biztonsági követelményekkel, megszüntetési jogokkal és tesztelt kilépési stratégiákkal.

Az EUVD fájdalmasan láthatóvá teszi a gyenge beszállítói átláthatóságot. Ha egy beszállítói komponens érintett, a szervezetnek többre van szüksége, mint egy beszerzési kapcsolattartóra. Szüksége van:

  1. név szerint kijelölt beszállítói biztonsági kapcsolattartóra;
  2. szerződéses sérülékenység-értesítési kötelezettségekre;
  3. termék- és verziónyilvántartásra;
  4. adott esetben SBOM-ra vagy komponensátláthatóságra;
  5. helyesbítési SLA-kra és kerülőmegoldási kötelezettségekre;
  6. audit- vagy bizonyossági jogokra;
  7. incidenstámogatási kötelezettségekre;
  8. kilépési vagy helyettesítési tervekre kritikus függőségek esetén.

Ezért felelteti meg a Clarysec az EUVD-működést az ISO/IEC 27002:2022 5.21 kontrollnak a Zenith Controls segítségével. Az irányítási, ökoszisztéma- és védelmi területek illeszkednek a gyakorlati beszállítói problémához: amit nem tud visszakövetni, azt nem tudja helyesbíteni; és amit nem írt elő szerződésben, azt nem tudja bizonyítani.

A CRA szerinti jelentésre való felkészültséghez ugyanez a beszállítói és terméksérülékenységi bejegyzés létfontosságúvá válik. Még ha a végső szabályozói döntés jogi elemzést igényel is, az operatív bizonyíték biztonsági és mérnöki bizonyítékokból származik.

Mikor válik egy EUVD-sérülékenység incidenssé

Nem minden sérülékenység incidens. De minden súlyos sérülékenységnek gyorsan incidensbejegyzéssé kell tudnia válni.

A gyakorlati kiváltó feltétel ez: ha az EUVD-információ lehetséges kitettséget jelez, nyisson sérülékenységi bejegyzést. Ha bizonyíték van kihasználásra, szolgáltatási hatásra, szabályozott adatok kitettségére, ügyfélkárra vagy működési zavarra, kapcsolja hozzá vagy alakítsa incidensbejegyzéssé.

A NIS2 Article 23 előírja a szolgáltatásnyújtást érintő jelentős incidensek bejelentését, beleértve azokat az incidenseket, amelyek súlyos működési zavart vagy pénzügyi veszteséget okoznak vagy okozhatnak, illetve másokat jelentős vagyoni vagy nem vagyoni kárral érintenek. A DORA előírja a pénzügyi szervezetek számára az IKT-vonatkozású incidensek és jelentős kiberfenyegetések rögzítését, a jelentős IKT-vonatkozású incidensek besorolását, szükség esetén Article 19 szerinti jelentését, az ügyfelek tájékoztatását, ha pénzügyi érdekeik érintettek, valamint a lezárást gyökérok-elemzéssel. A GDPR személyesadat-sértés értékelését írja elő, ha egy biztonsági incidens személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy azokhoz való hozzáférést okoz.

A Zenith Blueprint, Kontrollok a gyakorlatban szakasz, 16. lépés, Emberi kontrollok II, megerősíti a jelentési kultúra fontosságát:

Támogassa az „alacsony küszöbű jelentéstétel” szemléletét; az üzenet legyen: „Ha bizonytalan vagy, jelentsd.”

Az EUVD esetében ez ugyanúgy vonatkozik a mérnökökre és a beszállítókra, mint a munkavállalókra. Ha egy fejlesztő érintett függőséget lát, ha egy beszállító megerősíti a kihasználhatóságot, vagy ha az ügyféltámogatás gyanús ügyfélviselkedést észlel, a szervezetnek a késleltetett bizonyosság helyett a korai triage-t kell előnyben részesítenie.

Hogyan tesztelik az auditorok az EUVD-programot

Egy erős EUVD működési modellt többféle auditori nézőpontra kell tervezni. Ugyanaz a bizonyíték különböző elvárásoknak is megfelelhet, ha megfelelően strukturált.

Auditori nézőpontMit fognak kérdezniErős bizonyíték
ISO 27001:2022 auditorAzonosították-e a jogi kötelezettségeket, értékelték-e a kockázatokat, kiválasztották-e a kontrollokat, bizonyított-e a működés, és elvégezték-e a felülvizsgálatokat?IBIR alkalmazási területe, jogi nyilvántartás, SoA, sérülékenységnyilvántartás, kockázatkezelési bejegyzések, belső audit, vezetőségi felülvizsgálat
NIS2 illetékes hatóság vagy bizonyossági felülvizsgálóJóváhagyta-e a vezetés az intézkedéseket, kezelték-e a sérülékenységeket és a beszállítókat, értékelték-e a jelentős incidens bejelentését?Igazgatósági jegyzőkönyvek, sérülékenységkezelési eljárás, beszállítói bizonyítékok, incidensdöntési napló, 24 és 72 órás értékelési bejegyzések
DORA auditor vagy felügyeletAz IKT-kockázat az igazgatóság felelőssége-e, besorolják-e az incidenseket, ellenőrzés alatt állnak-e a harmadik félhez kapcsolódó IKT-függőségek?IKT-kockázati keretrendszer, incidensbesorolás, IKT-szerződésnyilvántartás, beszállítói átvilágítás, kilépési tervek, gyökérok-jelentések
GDPR auditor vagy DPO-felülvizsgálatÉrtékelték-e a személyes adatok kitettségét, és bizonyították-e az elszámoltathatóságot?Adattérkép, adatsértési értékelés, DPO-felülvizsgálat, elszigetelési bizonyíték, kommunikációs döntés
NIST CSF értékelőMeghatározták-e az aktuális és célállapot szerinti eredményeket a Govern, Identify, Protect, Detect, Respond és Recover funkciók mentén?CSF-profil, hiányossági terv, eszköznyilvántartás, észlelési bizonyíték, reagálási forgatókönyvek, helyreállítási ellenőrzés
COBIT 2019 vagy ISACA-jellegű auditorMeghatározottak-e az irányítási célok, a kockázattulajdonosi felelősség, a folyamatteljesítmény és a kontrollok felügyelete?RACI, KRI-k, folyamatmutatók, vezetői jelentéstétel, kontrolltesztelés, fejlesztési intézkedések

Egy ISO 27001 auditor jellemzően mintát vesz egy magas súlyosságú, EUVD által kiváltott bejegyzésből, és megvizsgálja, kapcsolódik-e a hatályhoz, az érdekelt felek kötelezettségeihez, a kockázatértékeléshez, a kockázatkezeléshez, az A melléklet szerinti kontrollokhoz, az operatív bizonyítékokhoz és a felülvizsgálathoz. Egy NIST-orientált értékelő az eredményekre koncentrál. Egy COBIT-jellegű auditor az irányításra, a felelősségre, a teljesítményre és a bizonyosságra összpontosít. Egy DORA-felülvizsgáló különös figyelmet fordít a harmadik félhez kapcsolódó IKT-függőségekre, a szerződéses kontrollokra és az incidensbesorolásra.

Igazgatósági jelentés CVE-zaj nélkül

A NIS2 és a DORA az irányító testületeket a kiberbiztonsági elszámoltathatóság középpontjába helyezi. A vezetőknek azonban nincs szükségük EUVD-bejegyzések tömeges listájára. Döntésképes jelentésre van szükségük.

A havi sérülékenységi információs jelentésnek tartalmaznia kell:

  1. A hatályba tartozó eszközöket érintő kritikus és magas súlyosságú, EUVD-vel egyeztetett sérülékenységeket.
  2. A helyesbítési SLA-n kívül nyitott sérülékenységeket.
  3. Beszállítók okozta késedelmeket és szerződéses eszkalációkat.
  4. Incidensekhez vagy majdnem bekövetkezett eseményekhez kapcsolódó sérülékenységeket.
  5. CRA terméksérülékenységi munkafolyamat-kiváltókat és eredményeket.
  6. NIS2, DORA vagy GDPR szerinti jelentési értékeléseket.
  7. Elfogadott maradványkockázatokat és azok elfogadóit.
  8. Trendeket üzleti szolgáltatás, termék, beszállító és gyökérok szerint.
  9. Kontrollhatékonysági mutatókat és fejlesztési intézkedéseket.

Ez közvetlenül illeszkedik az ISO/IEC 27001:2022 9.3 pont szerinti vezetőségi felülvizsgálati elvárásokhoz, beleértve a kontextus változásait, az érdekelt felek igényeit, a teljesítménytrendeket, az auditeredményeket, a célkitűzések teljesülését, a visszajelzéseket, a kockázatértékelési eredményeket, a kezelési státuszt és a fejlesztési lehetőségeket.

Gyakori EUVD-felkészültségi hibák

Azok a szervezetek, amelyek küzdenek a fenyegetettségi információkkal, általában kiszámítható módon hibáznak.

Először: nincs megbízható eszköz- és szoftvernyilvántartásuk. Az EUVD relevanciája nem értékelhető terméknevek, verziók, könyvtárak, felhőszolgáltatások, beszállítók és adatáramlások nélkül.

Másodszor: elválasztják a sérülékenységkezelést az incidensreagálástól. A sérülékenységi csapat lezárja a jegyeket, miközben az incidenscsapat soha nem értékeli, történt-e kihasználás. Ez jelentési vakfoltokat hoz létre.

Harmadszor: a beszállítói szerződések hallgatnak. Ha a beszállítót nem kötelezik értesítésre, együttműködésre, javításra, bizonyítékszolgáltatásra vagy incidensreagálás támogatására, az ügyfélnek kevés mozgástere van a kritikus időablakban.

Negyedszer: a jogi és DPO-csapatokat túl későn vonják be. Ha a GDPR-, NIS2-, DORA- vagy CRA-kapcsolódó jelentési döntések azután kezdődnek, hogy a mérnöki csapat már javított és továbblépett, a tudomásszerzési idővonal bizonytalanná válik.

Ötödször: a vezetői jelentés túl technikai. Az igazgatóságok hosszú CVE-listákat kapnak üzleti hatás, szabályozói relevancia, beszállítói trendek vagy maradványkockázati döntések nélkül.

A Clarysec módszertana ezt a kontrollok összekapcsolásával javítja. A Zenith Blueprint 19. lépése megerősíti a technikai sérülékenységkezelést, a 22. lépés operacionalizálja a fenyegetettségi információkat, a 16. lépés erősíti az incidensjelentési kultúrát, a 23. lépés pedig láthatóvá teszi a jogi, jogszabályi, szabályozói és szerződéses kötelezettségeket.

30 napos EUVD-felkészültségi sprint

Ha szervezetének gyors útvonalra van szüksége, kezdjen fókuszált 30 napos sprinttel.

Első hét: hatály és kötelezettségek meghatározása. Erősítse meg, hogy a szervezet potenciálisan alapvető vagy fontos szervezet-e a NIS2 alapján, alkalmazandó-e a DORA a pénzügyi tevékenységekre, alkalmazandó-e a GDPR a személyes adatok kezelésére, és hol lehetnek relevánsak a CRA-kapcsolódó terméksérülékenységi kötelezettségek. Frissítse az IBIR jogi és szerződéses nyilvántartását.

Második hét: a befogadási munkafolyamat kialakítása. Vegye fel az EUVD-t, a nemzeti CERT-eket, a beszállítói tájékoztatókat és az ágazati hírcsatornákat a sérülékenységi információforrások listájára. Határozza meg, ki nyit bejegyzéseket, ki ellenőrzi a kitettséget, ki veszi fel a kapcsolatot a beszállítókkal, ki értékeli a jelentést, és ki hagyja jóvá a maradványkockázatot.

Harmadik hét: beszállítók és termékek összekapcsolása. Azonosítsa a kritikus termékeket, ügyféloldali szolgáltatásokat, közvetlen IKT-beszállítókat, kiszervezett fejlesztőket, felhőszolgáltatókat és menedzselt biztonsági szolgáltatókat. Erősítse meg a biztonsági kapcsolattartókat, a szerződéses záradékokat, a sérülékenységre adott válasz kötelezettségeit és a bizonyítékkal kapcsolatos elvárásokat.

Negyedik hét: a munkafolyamat tesztelése. Futtasson asztali gyakorlatot valósághű EUVD-riasztással. Követelje meg, hogy a csapat sérülékenységi bejegyzést, beszállítói kommunikációt, incidensértékelést, jogi értesítési döntést, javítási naplót, maradványkockázat-jóváhagyást és vezetői összefoglalót készítsen.

Az eredmény nem diasor. Olyan bizonyítékcsomag, amelyből egy auditor mintát vehet.

Tegye az EUVD-t kontrollrendszerré, ne újabb hírcsatornává

2026-ra azok a szervezetek fogják jól kezelni az ENISA EUVD-t, amelyek nem csupán több riasztásra iratkoznak fel. Hanem azok, amelyek a nyilvános sérülékenységi információkat kockázatalapú intézkedéssé, beszállítói elszámoltathatósággá, koordinált közzététellé, jelentési döntésekké és auditbizonyítékokká alakítják.

A Clarysec segít ennek a modellnek a kialakításában a Zenith Blueprint Zenith Blueprint, a Clarysec szabályzati könyvtára és a Zenith Controls Zenith Controls segítségével. Az ISO/IEC 27001:2022 pontjait és az ISO/IEC 27002:2022 kontrolljait megfeleltetjük a NIS2, DORA, GDPR, NIST CSF és COBIT-jellegű auditelvárásoknak, majd a megfeleltetést gyakorlati nyilvántartásokká, forgatókönyvekké, beszállítói záradékokká és vezetői jelentéssé alakítjuk.

Ha csapata NIS2 szerinti sérülékenységkezelésre, CRA szerinti jelentési felkészülésre, CVD-működésre vagy EUVD-vezérelt sérülékenységi információkezelésre készül, kezdjen egy Clarysec EUVD-felkészültségi felülvizsgálattal. Segítünk azonosítani a hiányosságokat, priorizálni a kontrollokat, és felépíteni a bizonyítékláncot még azelőtt, hogy az első kritikus riasztás próbára tenné a programját.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

SBOM-ok ISO 27001, NIS2 és DORA szerinti bizonyosságszerzéshez

SBOM-ok ISO 27001, NIS2 és DORA szerinti bizonyosságszerzéshez

Az SBOM-ok ma már a szoftver-ellátási lánci bizonyosság alapvető bizonyítékai. Ez az útmutató bemutatja, hogyan lehet az SBOM-okat működésbe állítani ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 és Clarysec szabályzatok alapján.

CVD NIS2- és DORA-környezetben: ISO 27001 szerinti bizonyítéktérkép

CVD NIS2- és DORA-környezetben: ISO 27001 szerinti bizonyítéktérkép

Gyakorlati CISO-útmutató a koordinált sérülékenység-közzétételhez NIS2, DORA, GDPR és ISO/IEC 27001:2022 szerint: szabályzati megfogalmazásokkal, bejelentés-kezelési munkafolyamattal, beszállítói eszkalációval, auditbizonyítékokkal és kontrollmegfeleltetéssel.

ISO 27001 auditbizonyítékok NIS2- és DORA-megfelelőséghez

ISO 27001 auditbizonyítékok NIS2- és DORA-megfelelőséghez

Ismerje meg, hogyan használható az ISO/IEC 27001:2022 szerinti belső audit és vezetőségi átvizsgálás egységes bizonyítékmotorként a NIS2, DORA, GDPR, beszállítói kockázatkezelés, ügyfélbizonyosság és vezető testületi elszámoltathatóság támogatására.