ISO 27001 szerinti fenyegetettségi információk a NIS2 és a DORA követelményeihez

Kedd reggel 07:42-kor egy európai fintech információbiztonsági vezetője még az első kávé előtt négy üzenetet kap.

Az első egy nemzeti CERT-riasztás, amely arra figyelmeztet, hogy egy távoli hozzáférési sérülékenységet aktívan kihasználnak. A második egy beszállítói közlemény, amely megerősíti, hogy az érintett komponens egy menedzselt fájlátviteli szolgáltatásban is használatban van. A harmadik egy menedzselt észlelési és reagálási szolgáltatás (MDR) értesítése, amely szokatlan kimenő forgalmat jelez egy nem éles alhálózatból. A negyedik a pénzügyi igazgatótól érkezik: „Ez érinti a DORA felkészültségi csomagunkat, és kell bárkit értesítenünk a NIS2 alapján?”

Ez a fenyegetettségi információk problémája 2026-ban. Nem arról szól, hogy még több hírcsatornát kell gyűjteni. Arról szól, hogy igazolható legyen: a releváns kiberfenyegetettségi információkat a szervezet megkapja, ellenőrzi, a megfelelő felelősökhöz irányítja, intézkedéssé alakítja, majd kockázati, észlelési, sérülékenységkezelési, incidenskezelési, beszállítói és vezető testületi bizonyítékokká alakítja.

Sok szervezet már előfizet beszállítói tájékoztatókra, CISA-riasztásokra, ENISA-frissítésekre, nemzeti CERT-értesítésekre, ISAC-közleményekre, felhőszolgáltatói biztonsági értesítésekre, CVE-hírcsatornákra, MDR-jelentésekre, kihasználhatósági adatbázisokra és sötét webes monitorozásra. Amikor azonban valódi riasztás érkezik, a csapatok még mindig kapkodnak. A SOC ír egy észlelési szabályt. Az infrastruktúra-csapat olyan eszköznyilvántartásokban keres, amelyek nem biztos, hogy naprakészek. A megfelelőségi terület azt kérdezi, hogy az esemény érinti-e a NIS2-t vagy a DORA-t. A vezetés egyértelmű választ vár, még mielőtt a szervezet egyáltalán tudná, hogy a sérülékeny komponens éles környezetben fut-e.

A probléma nem az adathiány. A probléma az auditálható működési modell hiánya.

Az a fenyegetettségi hírcsatorna, amelyet senki nem használ, nem kontroll. Az a sérülékenységi értesítés, amely nem módosítja a javítási prioritást, nem bizonyíték. Az a beszállítói értesítés, amely soha nem jut el a kockázati nyilvántartásba, nem ellátásilánc-biztonság. Az a CSIRT-riasztás, amely nem frissíti a felügyeletet, az incidensek elsődleges értékelését vagy a vezetői jelentéstételt, csak postaládazaj.

A Clarysec megközelítése egyszerű: a fenyegetettségi információknak a kockázati döntések működési rendszerévé kell válniuk. Be kell épülniük az IBIR alkalmazási területébe, a kockázatértékelésbe, az alkalmazhatósági nyilatkozatba, az incidenskezelési forgatókönyvekbe, a sérülékenységek elsődleges értékelésébe, a naplózásba és felügyeletbe, a beszállítói irányításba, a vezetői jelentéstételbe és az auditbizonyíték-csomagba.

Miért váltak a fenyegetettségi információk vezető testületi szintű kontrollá

A NIS2 megváltoztatta a kiberbiztonsági irányítás hangnemét. Számos SaaS-szolgáltatót, felhőszolgáltatót, menedzselt szolgáltatót, menedzselt biztonsági szolgáltatót, digitális infrastruktúra-szervezetet és digitális szolgáltatót von a hatálya alá alapvető vagy fontos szervezetként, az ágazattól, a mérettől és a tagállami kijelöléstől függően.

A NIS2 Article 21 megfelelő és arányos műszaki, operatív és szervezeti intézkedéseket ír elő a kockázatok kezelésére. Ezek közé tartozik a kockázatelemzés, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a beszerzés, fejlesztés és karbantartás biztonsága, beleértve a sérülékenységkezelést és a sérülékenységek közzétételét, az eredményesség értékelése, az alapvető kiberhigiénia és képzés, a kriptográfia, a humánerőforrás-biztonság, a hozzáférés-szabályozás, az eszközkezelés, valamint adott esetben a többtényezős hitelesítés vagy a folyamatos hitelesítés.

A NIS2 Article 20 azt is előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását, és részesüljenek képzésben. Alapvető szervezetek esetében a maximális közigazgatási bírság elérheti legalább a 10 millió EUR-t vagy a teljes világpiaci éves árbevétel 2 százalékát, attól függően, melyik a magasabb. Fontos szervezetek esetében ez legalább 7 millió EUR vagy 1,4 százalék lehet.

A fenyegetettségi információk esetében a vezető testületi szintű kérdés így hangzik: honnan tudjuk, hogy a kialakuló fenyegetések még az incidens bekövetkezése előtt módosítják a kontrolljainkat?

A DORA további réteget ad a pénzügyi szervezetek és az érintett harmadik fél IKT-szolgáltatók számára. 2025. január 17-től alkalmazandó, és megbízható, átfogó és jól dokumentált IKT-kockázatkezelési keretrendszert követel meg, amely beépül az általános kockázatkezelési rendszerbe. A DORA keretrendszere elvárja, hogy a szervezetek azonosítsák és osztályozzák az IKT-val támogatott üzleti funkciókat és eszközöket, védelmi és megelőző intézkedéseket működtessenek, észleljék a rendellenes tevékenységeket, reagáljanak és helyreállítsanak, kezeljék a biztonsági mentéseket és a visszaállítást, tanuljanak az IKT-incidensekből, válsághelyzetben kommunikáljanak, és kezeljék a harmadik fél IKT-kockázatokat.

A DORA az IKT-val kapcsolatos incidensek kezelését, osztályozását és jelentését is előírja. Article 17, Article 18 és Article 19 az incidenskezelési folyamatokat, az IKT-val kapcsolatos incidensek és kiberfenyegetések osztályozását, valamint a jelentős IKT-val kapcsolatos incidensek jelentését fedik le. Article 10 a rendellenes tevékenységek észlelésére fókuszál. Article 6–11 az IKT-kockázatkezelési keretrendszert, valamint az azonosítási, védelmi, megelőzési, észlelési, reagálási és helyreállítási elvárásokat írják le.

Egyszerűen fogalmazva: a DORA fenyegetésalapú rezilienciát vár el. Nem statikus rezilienciát. Nem éves szabályzatokra épülő rezilienciát. Fenyegetésalapú rezilienciát.

Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszermotort, amely ezeket az elvárásokat összekapcsolja. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg belső és külső környezetét, az érdekelt feleket, a jogi és szabályozási kötelezettségeket, az IBIR alkalmazási területét, a függőségeket és az egymással kölcsönhatásban álló folyamatokat. A 6.1.1–6.1.3 pontok ismételhető kockázatértékelési és kockázatkezelési folyamatot, kontrollkiválasztást, az A melléklettel való összevetést, alkalmazhatósági nyilatkozatot, kezelési tervezést és a maradványkockázat kockázatgazda általi jóváhagyását követelik meg.

A fenyegetettségi információknak itt van a helyük: nem egy mellékes irányítópulton, hanem a környezet, a kockázat, a kontrollkiválasztás, a kezelés, a felügyelet, a vezetőségi felülvizsgálat és a folyamatos fejlesztés bemeneteként.

A megfelelési csapda: fenyegetettségi hírcsatornák döntési visszakövethetőség nélkül

A leggyakoribb hibaminta megtévesztően egyszerű: a szervezet megkapja a fenyegetettségi információkat, de nem tudja igazolni, hogyan változtatják meg a döntéseket.

Egy gyenge bizonyítéklánc általában így néz ki:

Itt segít a Clarysec bevezetési módszere abban, hogy a szervezetek a „kapunk információkat” állapottól eljussanak a „működésbe építjük az információkat” állapotig.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint anyagban a Controls in Action fázis kifejezetten auditálható gyakorlattá alakítja a fenyegetettségi információkat. A 22. lépés, szervezeti kontrollok, így fogalmaz:

Hozzon létre dokumentált listát a fenyegetettségi információs forrásokról (5.7), például beszállítóktól, ISAC-ektől vagy nyílt forrásokból, és határozza meg, hogyan történik az információk ellenőrzése és beépítése a döntéshozatalba. Határozza meg, ki kapja meg a fenyegetettségi frissítéseket, és hogyan alkalmazzák azokat (például javítások priorizálása, tudatossági képzés). Készítsen rövid fenyegetettségi trendtájékoztatót, amelyet negyedévente meg kell osztani a kulcsfontosságú érdekelt felekkel.

Ez az utasítás hidat képez a fenyegetettségi adatok és a megfelelési bizonyítékok között. A fenyegetettségi információs nyilvántartás nem pusztán forráslista. Igazolja a relevanciát, a felelősséget, az ellenőrzést, az irányítást, az integrációt és az üzleti felhasználást.

ISO 27001 kontrolllogika: a fenyegetettségi információs lánc

Az ISO/IEC 27002:2022 5.7 kontrollja, a fenyegetettségi információk, előírja, hogy a szervezetek gyűjtsék és elemezzék az információbiztonsági fenyegetésekkel kapcsolatos információkat, és használják fel azokat fenyegetettségi információk előállítására. A Zenith Controls: The Cross-Compliance Guide Zenith Controls anyagban az 5.7 kontroll megelőző, észlelő és helyesbítő kontrollként szerepel. Támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, összhangban áll az Identify, Detect és Respond kiberbiztonsági koncepciókkal, és operatív képességként a fenyegetés- és sérülékenységkezelés része.

Ez a besorolás lényeges. A fenyegetettségi információk a biztonsági megerősítés, a javításkezelés, a képzés és a beszállítói kontrollok támogatásával megelőző hatást fejtenek ki. A felügyelet, a SIEM-szabályok és a fenyegetésvadászati feladatok alakításával támogatják az észlelést. Az incidensreagálás, a levont tanulságok és a kockázatkezelés javításával helyesbítő hatást biztosítanak.

A Zenith Controls az ISO/IEC 27002:2022 5.7 kontrollját támogató kontrollokhoz is kapcsolja:

A sérülékenységi kapcsolat különösen fontos. A Zenith Controls a 8.8, műszaki sérülékenységek kezelése kontrollt megelőző kontrollként kezeli, és közvetlenül kapcsolja az 5.7 kontrollhoz, mivel a valós fenyegetettségi információk mutatják meg, mely sérülékenységeket használják ki aktívan. A 8.8 kontrollt a 8.16 felügyeleti tevékenységekhez is kapcsolja, mert a megfigyelt kihasználási kísérleteknek növelniük kell a javítás sürgősségét.

Ez gyakorlati fenyegetettségi információs láncot hoz létre:

1. Külső vagy belső információ érkezik.
2. A relevanciát eszközök, beszállítók, földrajzi kitettség, ágazat, üzleti szolgáltatások és adatok alapján ellenőrzik.
3. A kockázat frissül.
4. A javítási és konfigurációs prioritások módosulnak.
5. Az észlelési logikát finomhangolják.
6. Az incidenskezelési forgatókönyveket és az osztályozási küszöbértékeket felülvizsgálják.
7. A beszállítói és felhőfüggőségeket ellenőrzik.
8. A vezetés trendjelentést kap.
9. A bizonyítékokat megőrzik auditorok, szabályozó hatóságok és ügyfelek számára.

Szabályzatok, amelyek elszámoltatható magatartássá alakítják az információkat

A szabályzatok azok a pontok, ahol a kontrolllogika szerepkör-alapú elszámoltathatósággá válik. A Clarysec KKV- és vállalati szabályzatcsomagjai a kockázatkezelés, a végpontvédelem, a sérülékenységkezelés, a naplózás, a felügyelet és az auditbizonyítékok területén is tartalmaznak fenyegetettségi információs kapcsolódásokat.

KKV-k esetében az Endpoint Protection - Malware Policy Endpoint Protection - Malware Policy - SME a Governance Requirements 5.4.1 pontjában közvetlen elvárást határoz meg:

Az IT-támogatási szolgáltatónak figyelnie kell a hiteles fenyegetettségi információs forrásokat (például CISA, ENISA, jelentős vírusirtó gyártók), és biztosítania kell, hogy az észlelési szignatúrák naprakészek maradjanak.

Ennek a pontnak az értéke a felelősségkijelölés. A fenyegetettségi információk kezelése nem azt jelenti, hogy „valakinek az IT-nál meg kell néznie a riasztásokat”. Ez kifejezett szolgáltatói kötelezettség.

A Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy - SME ugyanezt a modellt erősíti meg a Roles and Responsibilities 4.2.1 pontjában:

Figyeli a rendszereket sérülékenységek és elérhető javítások szempontjából beszállítói riasztások, fenyegetettségi tájékoztatók és operációsrendszer-szintű értesítések alapján.

A Policy Implementation Requirements 6.2.1.3 pontjában azt is meghatározza, milyen típusú forrásnak kell intézkedést kiváltania:

Megbízható fenyegetettségi riasztások (például CISA, ENISA, nemzeti CERT-riasztások).

Vállalatok esetében a Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy a Roles and Responsibilities 4.5.1 pontjában így rendelkezik:

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

Az eszkalációs követelmény kulcsfontosságú. Egy sérülékenység akkor válik sürgőssé, amikor a kihasználhatóság, a kitettség, az üzleti kritikusság, az adatérzékenység és a fenyegetési aktivitás együtt jelentkezik.

A Risk Management Policy Risk Management Policy beépíti a fenyegetettségi információkat az elemzésbe. A Policy Implementation Requirements 6.2.2 pontja kimondja:

Az elemzésnek figyelembe kell vennie a meglévő kontrollok hatékonyságát, a releváns fenyegetettségi információkat, az eszközök kritikusságát és a sérülékenység súlyosságát.

Ez a pont az auditra alkalmas fenyegetettségi információk lényege. Bizonyítja, hogy a kockázatelemzés nem elméleti.

A Logging and Monitoring Policy Logging and Monitoring Policy az információkat észleléssé alakítja. Purpose 1.2 pontja kimondja:

Az auditnaplózás, a felügyelet és a fenyegetésészlelés kritikus fontosságú az anomáliadetektálás, a fenyegetésekre adott válasz, a forenzikus felülvizsgálat, az auditra való felkészültség és a jogszabályi megfelelés szempontjából. Ez a szabályzat biztosítja, hogy minden rendszer által generált eseményt megfelelően rögzítsenek, megőrizzenek, és időszinkronizált pontossággal korreláljanak.

Végül az Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy megmagyarázza, miért fontos a bizonyítékfegyelem. Objectives 3.4 pontja előírja a szervezet számára bizonyítékok előállítását:

Igazolható bizonyítékok és auditnyom létrehozása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.

Amikor a NIS2, a DORA, egy ügyfél vagy egy ISO auditor azt kérdezi, mit tudtak, mikor tudták, ki döntött, és mi változott, ez a bizonyítéknyom jelenti a különbséget az érett bizonyosság és a védekező kapkodás között.

A fenyegetettségi információs nyilvántartás kialakítása

Egy érett nyilvántartás két rétegből áll: forrásirányításból és eseménykövetésből. A forrásirányítás meghatározza, mit tekint a szervezet megbízhatónak, ki a felelőse, hogyan történik az ellenőrzése, és milyen intézkedést válthat ki.

Az eseménykövetés rögzíti, hogyan vált egy konkrét tájékoztató bizonyítékká. Visszatérve a keddi reggeli fájlátviteli forgatókönyvhöz, a nyilvántartási bejegyzésnek elegendő információt kell tartalmaznia a kockázati, reagálási és megfelelési döntések támogatásához.

Ez nem bürokrácia. Ez az a tényszerű nyilvántartás, amely igazolja, hogy a szervezetnek meghatározott befogadási, ellenőrzési, elsődleges értékelési, eszkalációs és bizonyítékkezelési folyamata van.

Tájékoztatóból auditbizonyíték: gyakorlati munkafolyamat

A fenyegetettségi információs munkafolyamatnak hat kérdésre kell gyorsan választ adnia: érintettek vagyunk-e, mennyire súlyos, minek kell változnia, ki a felelős, kell-e jelentenünk, és milyen bizonyítékot kell megőrizni?

1. A kitettség és az üzleti hatás ellenőrzése

Az ISO/IEC 27001:2022 4.1–4.4 pontjai előírják, hogy az IBIR tükrözze a szervezet tényleges környezetét, kötelezettségeit és függőségeit. Az első feladat nem a vak javítás. Az első feladat a kitettség ellenőrzése.

Kérdések:

• Futtatjuk az érintett technológiát?
• Elérhető az internet felől?
• Kritikus üzleti szolgáltatás használja?
• Kezel személyes adatokat?
• Beszállító vagy menedzselt szolgáltató üzemelteti?
• Releváns-e valamely DORA szerinti kritikus vagy fontos funkcióhoz?
• Releváns-e a NIS2 hatálya alá tartozó szolgáltatásokhoz?
• Vannak-e ügyfélszerződésből eredő értesítési kötelezettségek?
• A naplók rendelkezésre állnak, teljesek és időszinkronizáltak?

Ha személyes adatok érintettek lehetnek, a GDPR szerinti elszámoltathatóság is belép az elemzésbe. A GDPR megfelelő adatkezelési biztonságot és igazolható elszámoltathatóságot ír elő, beleértve annak értékelését is, hogy történt-e személyesadat-sértés, és szükséges-e bejelentés.

2. A kockázati nyilvántartás frissítése

A Risk Management Policy Risk Management Policy - SME a Governance Requirements 5.1.3 pontjában egyszerű időzítési szabályt ad:

A kockázatokat negyedévente felül kell vizsgálni, és jelentős események bekövetkezésekor frissíteni kell.

Egy hiteles, aktív kihasználásról szóló tájékoztató jelentős esemény. A frissítés nem várhat a következő negyedéves felülvizsgálatig.

Ez közvetlenül kapcsolódik az ISO/IEC 27001:2022 6.1.1–6.1.3 pontjaihoz. A szervezet azonosítja a kockázatot, elemzi a valószínűséget és a következményeket, priorizálja a kezelést, kiválasztja a kontrollokat, fenntartja az alkalmazhatósági nyilatkozatot, kezelési tervet készít, és megszerzi a maradványkockázat jóváhagyását.

3. A sérülékenységkezelés priorizálása kihasználási információk alapján

A Zenith Blueprint Controls in Action fázisának 19. lépése, Technological Controls I, elmagyarázza, miért alapvető kiberhigiéniai terület a sérülékenységkezelés:

A sérülékenységek kezelése a modern kiberhigiénia egyik legkritikusabb területe. Bár a tűzfalak és a vírusvédelmi eszközök védelmet nyújtanak, ezek hatását alááshatja, ha nem javított rendszerek vagy hibásan konfigurált szolgáltatások maradnak kitetten. A kontroll teljesítéséhez a szervezeteknek strukturált és ismételhető folyamatot kell bevezetniük a sérülékenységek azonosítására, értékelésére és kezelésére.

A CVSS önmagában nem elég. Egy internet felől elérhető rendszeren aktívan kihasznált, közepes pontszámú sérülékenység sürgősebb lehet, mint egy szegmentált laborban rejtőző, magas pontszámú sérülékenység.

Ez igazolható döntést eredményez. Támogatja továbbá a NIS2 Article 21(2)(e) sérülékenységkezelési elvárásait, a NIS2 Article 21(2)(g) kiberhigiéniai elvárásait és a DORA IKT-kockázatkezelési követelményeit.

4. Az információk felügyeletté és észleléssé alakítása

A fenyegetettségi információknak el kell jutniuk a naplózáshoz és felügyelethez. A Logging and Monitoring Policy Logging and Monitoring Policy - SME a Policy Implementation Requirements 6.2.1 pontjában kimondja:

A biztonsági eszközöket (például vírusirtók, tűzfalak, VPN-ek) úgy kell konfigurálni, hogy riasztásokat generáljanak meghatározott fenyegetési forgatókönyvekre, beleértve:

A részlet egyértelműen meghatározza a kontroll célját: a meghatározott fenyegetési forgatókönyveknek kell vezérelniük a riasztásokat.

A Zenith Blueprint Controls in Action fázisának 19. lépése így írja le a felügyeleti tevékenységeket:

Ha a naplózás annak rögzítése, ami a környezetben történik, akkor a felügyelet ezeknek az eseményeknek a figyelése, megértése és megválaszolása. Ez a kontroll a hálózatok, rendszerek és alkalmazások aktív megfigyeléséről szól a szokatlan tevékenységek észlelése érdekében, nem csupán utólag, hanem ahol lehetséges, valós időben vagy közel valós időben.

A fájlátviteli forgatókönyv esetében a SOC-nak vagy az IT-szolgáltatónak:

• Hozzá kell adnia vagy ellenőriznie kell a CERT és a beszállítói tájékoztató IOC-it.
• Át kell keresnie a naplókat ismert kihasználási útvonalak, gyanús feltöltések, webshell-indikátorok, szokatlan folyamatvégrehajtás és váratlan kimenő kapcsolatok után.
• Meg kell erősítenie, hogy a hitelesítési, adminisztrátori tevékenységi, fájlhozzáférési, API- és hálózati naplók megőrzésre kerülnek.
• Finomhangolnia kell a SIEM-riasztásokat a kihasználási mintára.
• Ügyfeljegyzést kell készítenie arról, mit kerestek, mit találtak, és ki vizsgálta felül.
• Incidensosztályozásra kell eszkalálnia, ha az indikátorok kompromittálódást, adatkitettséget vagy szolgáltatáshatást jeleznek.

Itt válik gyakorlativá az incidensjelentés. A NIS2 Article 23 szakaszos jelentős incidensjelentést ír elő, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli értesítést, a kérésre adott közbenső frissítéseket és az értesítést követő legkésőbb egy hónapon belüli zárójelentést. A DORA előírja, hogy a pénzügyi szervezetek a rendeletben és a kapcsolódó technikai standardokban meghatározott szakaszos folyamat szerint észleljék, kezeljék, osztályozzák és jelentsék a jelentős IKT-val kapcsolatos incidenseket.

A fenyegetettségi információk segítenek meghatározni, hogy a szervezet még sérülékenységi válaszintézkedésnél, biztonsági esemény értékelésénél vagy szabályozott incidensjelentésnél tart-e.

Egy munkafolyamat, több megfelelési kötelezettség

A fenyegetettségi információk ideális integrált megfelelési munkafolyamatot alkotnak, mert ugyanazok a bizonyítékok több rezsimet is támogatnak.

A NIST CSF 2.0 különösen hasznos a felsővezetői kommunikációban. Alapfunkciói — Govern, Identify, Protect, Detect, Respond és Recover — a technikai információkat vezető testületi szinten érthető történetté alakítják:

• Govern: a fenyegetettségi információs források, felelősök és jelentési vonalak meghatározottak.
• Identify: az érintett eszközök, beszállítók, üzleti szolgáltatások és adatok feltérképezettek.
• Protect: a javításkezelés, a biztonsági megerősítés, a szegmentálás és a végponti szignatúrák frissülnek.
• Detect: a felügyeleti szabályok, IOC-k és fenyegetésvadászati feladatok bevezetésre kerülnek.
• Respond: az incidenskezelési forgatókönyvek, az elsődleges értékelési szabályok és az értesítési küszöbértékek felülvizsgálatra kerülnek.
• Recover: a biztonsági mentések, helyreállítási prioritások és levont tanulságok ellenőrzésre kerülnek.

Ez a nyers kiberfenyegetettségi információkat kockázatirányítássá alakítja.

Az auditor nézőpontja: mit fognak kérni

Egy erős fenyegetettségi információs folyamatnak különböző auditstílusok mellett is meg kell állnia. Egy ISO auditor, NIS2-felülvizsgáló, DORA felügyeleti hatóság, NIST CSF-értékelő, COBIT 2019-orientált auditor, ISACA-szakember vagy adatvédelmi felülvizsgáló eltérő nyelvezetet használhat, de mindannyian a bizonyítékokhoz jutnak el.

A Zenith Controls biztosítja ezekhez a megbeszélésekhez a keresztmegfelelőségi értelmezést. A 8.16 kontroll, felügyeleti tevékenységek esetében az útmutató a felügyeletet a GDPR szerinti biztonsághoz és adatsértési elszámoltathatósághoz, a NIS2 incidenskezelési és jelentési elvárásaihoz, valamint a DORA észlelési és reagálási követelményeihez kapcsolja. A 8.8 kontroll, műszaki sérülékenységek kezelése esetében a sérülékenységkezelést a GDPR szerinti adatkezelési biztonsághoz, a NIS2 Article 21(2)(e) követelményeihez és a DORA proaktív IKT-kockázatkezeléséhez kapcsolja.

Ez az a bizonyítékkonvergencia, amelyet az auditorok látni akarnak.

Vezetői jelentéstétel: a negyedéves fenyegetettségi trendtájékoztató

A fenyegetettségi információs nyilvántartás nem maradhat a SOC-ban. A Zenith Blueprint rövid, negyedéves fenyegetettségi trendtájékoztatót javasol a kulcsfontosságú érdekelt felek számára. A Clarysec egyoldalas vezetői jelentést ajánl öt szekcióval:

1. A három legfontosabb releváns fenyegetettségi trend üzleti hatás szerint.
2. A leginkább kitett technológiák vagy beszállítók.
3. Javított, kockázatcsökkentett vagy elfogadott kritikus sérülékenységek.
4. Végrehajtott észlelési és reagálási fejlesztések.
5. Vezetői döntést igénylő kérdések.

Egy erős vezetői tájékoztató nem 400 CVE-t sorol fel. A kockázatmozgást magyarázza. Például:

• A menedzselt szolgáltatókat célzó zsarolóvírus növelte a beszállítói felülvizsgálatok prioritását.
• A fájlátviteli platformok kihasználása sürgősségi javítást és kompenzáló tűzfalszabályt váltott ki.
• A felhőidentitás elleni támadások MFA-kivételek felülvizsgálatát és feltételes hozzáférés megerősítését eredményezték.
• Az ágazati ISAC-információk új adathalászati szimulációkat indítottak a pénzügyi és támogatási csapatok számára.
• A DORA szerinti kritikus funkciók feltérképezése egy harmadik fél munkafolyamatában felügyeleti hiányosságot tárt fel.

Ez a tájékoztató támogatja a NIS2 szerinti vezetői elszámoltathatóságot, a DORA IKT-kockázati irányítást, az ISO/IEC 27001:2022 szerinti vezetőségi felülvizsgálatot és az ügyfélbizonyosságot.

Gyakori hibaminták

A fenyegetettségi információs programok gyakran érettnek tűnnek a prezentációkon, de audit alatt gyengének bizonyulnak. A leggyakoribb hibaminták:

• Túl sok hírcsatorna, ellenőrzési kritériumok nélkül.
• Nincs kapcsolat az információk és az eszköznyilvántartás között.
• Jelentős tájékoztatók után nincs dokumentált kockázati frissítés.
• A javítási prioritás kizárólag a vizsgálati súlyosságon alapul.
• A beszállítói tájékoztatók az IBIR-en kívül kerülnek kezelésre.
• A SOC-szabályok változásbejegyzések nélkül frissülnek.
• Az incidensküszöbértékek nincsenek összhangban a NIS2 vagy DORA jelentési munkafolyamatokkal.
• A vezető testületi jelentéstétel az üzleti kockázat helyett a riasztásmennyiségre fókuszál.
• Nincs bizonyíték arra, hogy a levont tanulságok módosították a kontrollokat.
• Nincs felelős a fenyegetettségi információs nyilvántartás fenntartására.

A megoldás nem egy újabb hírcsatorna megvásárlása. A megoldás a kontrollok integrációja.

10 pontos felkészültségi ellenőrzőlista 2026-ra

Használja ezt az ellenőrzőlistát gyakorlati belső felülvizsgálatként.

Ha ezek bármelyikére a válasz „nem”, a szervezetnek nem pusztán fenyegetettségi információs problémája van. IBIR-integrációs problémája van.

Hogyan segít a Clarysec bizonyítékká alakítani a fenyegetettségi információkat

A Clarysec módszere olyan szervezetek számára készült, amelyeknek egyszerre van szükségük gyakorlati biztonságra és hiteles megfelelésre.

A Zenith Blueprint megadja a 30 lépéses bevezetési útvonalat, beleértve a 22. lépést a fenyegetettségi információs nyilvántartáshoz és a 19. lépést a sérülékenységkezeléshez és a felügyeleti tevékenységekhez. A Clarysec vállalati és KKV-szabályzatai ezeket az elvárásokat szerepkör-alapú eljárásokká alakítják a kockázatkezelés, a sérülékenységkezelés, a végpontvédelem, a naplózás, a felügyelet és az auditbizonyítékok területén. A Zenith Controls ezt követően keresztmegfelelőségi értelmezést ad, bemutatva, hogyan kapcsolódnak az ISO/IEC 27002:2022 kontrollok a NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 követelményeihez és az auditbizonyítékokhoz.

A keddi reggeli információbiztonsági vezető számára a pénzügyi igazgatónak adandó válasz egyértelművé válik:

„Megkaptuk a tájékoztatót, ellenőriztük a kitettséget, frissítettük a kockázati nyilvántartást, az aktív kihasználás alapján priorizáltuk a javítást, finomhangoltuk a felügyeletet, ellenőriztük a beszállítói függőséget, értékeltük az incidensjelentési küszöbértékeket, tájékoztattuk a vezetést, és megőriztük a bizonyítékokat. Nem találgatunk. Az IBIR szerint járunk el.”

Így kell kinéznie 2026-ban az ISO 27001 szerinti fenyegetettségi információknak a NIS2 kiberhigiénia és a DORA IKT-kockázati bizonyítékok támogatására.

Következő lépések

Ha a szervezete kap fenyegetettségi információkat, de nem tudja igazolni, hogyan változtatják meg a kockázati döntéseket, kontrollokat, észlelést, incidensreagálást, beszállító-kezelést és szabályozói bizonyítékokat, ezen a héten kezdje három intézkedéssel:

1. Hozza létre vagy frissítse a fenyegetettségi információs nyilvántartást a Zenith Blueprint Controls in Action fázisának 22. lépése alapján.
2. Térképezze fel jelenlegi folyamatát az ISO/IEC 27002:2022 5.7, 8.8, 8.15, 8.16, 8.7 és 5.25 kontrolljai alapján a Zenith Controls segítségével.
3. Hangolja össze szabályzatait, különösen a Risk Management Policy, a Vulnerability and Patch Management Policy, a Logging and Monitoring Policy és az Audit and Compliance Monitoring Policy szabályzatokat, hogy minden tájékoztató igazolható bizonyítékká válhasson.

A Clarysec segít a fenyegetettségi hírcsatornákat, tájékoztatókat, beszállítói értesítéseket, sérülékenységi információkat és észlelési jelzéseket ISO/IEC 27001:2022-vel összhangban álló, NIS2-re felkészült, DORA-tudatos működési modellé alakítani.

Töltse le a Clarysec eszközkészleteit, kérjen bemutatót, vagy foglaljon felkészültségi értékelést annak megtekintésére, hogyan állná meg a helyét jelenlegi fenyegetettségi információs folyamata egy ISO auditor, NIS2-felülvizsgáló, DORA felügyeleti hatóság vagy ügyfélbizonyossági igény előtt.