A vizsgálatoktól a bizonyítékokig: ISO 27001:2022, NIS2, DORA

Hétfő reggel 08:16 van. Egy internet felől elérhető alkalmazásszerveren éppen most jelent meg egy kritikus távoli kódfuttatási sérülékenység az irányítópulton. Az infrastruktúra-csapat szerint a gyártói javítás elérhető. Az alkalmazástulajdonos figyelmeztet, hogy a szerver bevétel szempontjából kritikus ügyfélfolyamatot támogat. A jogi terület azt kérdezi, hogy az esetleges kihasználás kiválthat-e NIS2, DORA vagy GDPR szerinti jelentéstételi kötelezettséget. Maria, a CISO, megnyitja az auditnaptárt, és látja a valódi problémát: az ISO 27001:2022 felügyeleti audit a jövő héten kezdődik, a NIS2 felkészültségi felülvizsgálat már folyamatban van, egy jelentős fintech ügyfél pedig DORA-bizonyítékokat kért.

A sérülékenységvizsgáló piros jelzést mutat. A jegykezelő tábla aktivitást mutat. A táblázat erőfeszítést mutat. De ezek egyike sem igazolja automatikusan a kontroll működését.

Ez az a hiányosság, amelyet sok szervezet túl későn ismer fel. A sérülékenységvizsgálat nem azonos a sérülékenységkezelés auditfelkészültségével. Egy vizsgálat azt jelzi, hogy valami hibás lehet. Az auditbizonyíték azt igazolja, hogy a szervezet tudta, milyen eszközökkel rendelkezik, értékelte a kockázatot, kijelölte a felelőst, a szabályzat szerint járt el, kontrolláltan kezelte a változást, dokumentálta a kivételeket, ellenőrizte az eredményeket és felülvizsgálta a kimenetet.

Az ISO/IEC 27001:2022, a NIS2 és a DORA esetében ez a bizonyítéklánc ugyanolyan fontos, mint a technikai javítás. A történet a sérülékenységvizsgálóval kezdődik. Az eszköznyilvántartás, a sérülékenységi nyilvántartás, a jegy, a kockázati döntés, a változásnyilvántartás, a javítási napló, az ellenőrzési bizonyíték, a kivétel-jóváhagyás és a vezetőségi felülvizsgálat teszi teljessé.

A Clarysec megközelítése egyszerű: a sérülékenységkezelést nem havi technikai rituáléként kell kezelni. Irányított bizonyíték-előállítási munkafolyamatként kell működtetni.

Miért nem elegendők a vizsgálati jelentések auditbizonyítékként

A sérülékenységvizsgálat időponthoz kötött technikai megállapítás. Azonosíthat CVE-t, hiányzó javítást, már nem támogatott könyvtárat, kitett szolgáltatást vagy gyenge konfigurációt. Ez hasznos, de nem teljes körű.

Az auditor más kérdéseket fog feltenni:

• Az érintett eszköz a hatókörbe tartozott?
• Ki az eszköz és az üzleti szolgáltatás felelőse?
• A sérülékenységet a kitettség, a kihasználhatóság, az üzleti hatás és az adatérzékenység alapján értékelték?
• A helyesbítő intézkedés az előírt határidőn belül lezárult?
• Ha a helyesbítő intézkedés késett, ki fogadta el a maradványkockázatot?
• A javítást kontrollált változáskezelés keretében telepítették?
• A javítást ismételt vizsgálattal vagy technikai ellenőrzéssel megerősítették?
• A bizonyítékot megőrizték, és a vezetés felülvizsgálta?

A sérülékenységvizsgálati exportokat tartalmazó mappa ritkán válaszolja meg ezeket a kérdéseket. Egy ISO 27001:2022 audit során az auditor azt vizsgálja, hogy az IBIR a tervezett módon működik-e. A NIS2 alapján a vezető testületeknek jóvá kell hagyniuk és felügyelniük kell a kiberbiztonsági kockázatkezelési intézkedéseket. A DORA alapján a pénzügyi szervezeteknek dokumentált IKT-kockázatkezelési keretrendszerre, incidens-életciklusra, rezilienciatesztelésre és IKT harmadik fél kockázati kontrollokra van szükségük. A GDPR alapján a kérdés az, hogy megfelelő technikai és szervezési intézkedések védték-e a személyes adatokat, és igazolható-e az elszámoltathatóság.

Az ISO/IEC 27001:2022 4.1–4.4 pontjai előírják, hogy a szervezet értse a környezetét, az érdekelt feleket, a követelményeket és az IBIR alkalmazási területét. A sérülékenység- és javításkezelés nem tervezhető elszigetelten. Tükröznie kell az ügyfélszerződéseket, a szabályozói elvárásokat, a felhőfüggőségeket, a kiszervezett IKT-szolgáltatásokat, az adatvédelmi kötelezettségeket és a kritikus szolgáltatásokat.

Az ISO/IEC 27001:2022 6.1.1–6.1.3 pontjai kockázatértékelést, kockázatkezelést, kontrollkiválasztást, alkalmazhatósági nyilatkozatot és kockázatgazdai jóváhagyást írnak elő a maradványkockázatra. Ez azt jelenti, hogy a sérülékenységi bizonyítékoknak kapcsolódniuk kell a kockázati nyilvántartáshoz, a kockázatkezelési tervhez és az SoA-hoz.

Az ISO/IEC 27005:2022 megerősíti ezt a modellt azzal, hogy a szervezeteket az Annex A, az ágazati kötelezettségek, a jogszabályok, a szerződések, a belső szabályok és a meglévő kontrollok követelményeinek egységes kockázatértékelési alapba rendezésére ösztönzi. Hangsúlyozza továbbá a valószínűségre, a következményre, a jogi kötelezettségekre, a beszállítói kapcsolatokra, az adatvédelmi hatásra és a harmadik felekre gyakorolt hatásra vonatkozó kritériumokat. Gyakorlati értelemben egy sérülékenység nem pusztán CVSS-pontszám. Olyan kockázati esemény, amely eszközökhöz, kötelezettségekhez, érdekelt felekhez és üzleti következményekhez kapcsolódik.

A javítási bizonyítékok mögötti szabályozási nyomás

A modern kiberbiztonsági szabályozás egyre kevésbé tűri az informális javításkezelést.

A NIS2 számos közepes és nagy szervezetre alkalmazandó a magas kritikalitású és kritikus ágazatokban, és bizonyos szervezeteket mérettől függetlenül is érinthet. Hatálya kiterjed a digitális infrastruktúra szolgáltatóira, például a felhőszolgáltatásokra, adatközponti szolgáltatásokra, tartalomszolgáltató hálózatokra, nyilvános elektronikus hírközlési szolgáltatókra, bizalmi szolgáltatásokra, DNS- és TLD-szolgáltatásokra, valamint az IKT-szolgáltatásmenedzsment-szolgáltatókra, így a menedzselt szolgáltatókra és a menedzselt biztonsági szolgáltatókra. Fontos digitális szolgáltatókat is lefed, például online piactereket, online keresőmotorokat és közösségi hálózati platformokat.

A NIS2 Article 20 a kiberbiztonságot a vezető testület felelősségévé teszi. Az Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést, a biztonságos fejlesztést, a biztonságos karbantartást, a sérülékenységkezelést és -közzétételt, az eredményesség értékelését, a kiberhigiéniát, a hozzáférés-szabályozást, az eszközkezelést és a hitelesítést. Az Article 23 lépcsőzetes, jelentős incidensekre vonatkozó bejelentési folyamatot hoz létre, amely adott esetben 24 órán belüli korai figyelmeztetést, 72 órán belüli bejelentést és egy hónapon belüli zárójelentést tartalmaz.

A DORA 2025. január 17-től közvetlenül alkalmazandó digitális működési rezilienciára vonatkozó szabályrendszert hoz létre a pénzügyi szervezetek számára. Lefedi az IKT-kockázatkezelést, a jelentős IKT-incidensek bejelentését, az operatív reziliencia tesztelését, a kiberfenyegetettségi információk megosztását, az IKT harmadik fél kockázatkezelését és a kritikus IKT harmadik fél szolgáltatók felügyeletét. Az Articles 5 and 6 az IKT-kockázatok irányítását a vezető testület felelősségi körébe helyezik, és dokumentált, integrált, rendszeresen felülvizsgált IKT-kockázatkezelési keretrendszert írnak elő. Az Article 8 megerősíti az IKT által támogatott üzleti funkciók, információs vagyon, IKT-eszközök és függőségek azonosításának szükségességét. Az Articles 17 to 20 az IKT-vel kapcsolatos incidensek észlelését, rögzítését, osztályozását, eszkalációját, jelentését, kommunikációját, helyesbítését és a tanulságok levonását írják elő. Az Articles 28 to 30 megkövetelik, hogy az IKT harmadik fél kockázatokat nyilvántartásokkal, kellő gondossággal, szerződéses védelmi intézkedésekkel, auditálási jogokkal, kilépési tervezéssel és felügyelettel kontrollálják.

A DORA hatálya alá tartozó pénzügyi szervezetek esetében a DORA általában felülírja az egyenértékű NIS2 kockázatkezelési és jelentéstételi kötelezettségeket. A NIS2 azonban továbbra is fontos az ökoszisztéma-szintű koordináció és a DORA hatályán kívüli szervezetek szempontjából. A pénzügyi ügyfeleket kiszolgáló SaaS-, MSP- és MSSP-szolgáltatók számára a gyakorlati helyzet egyértelmű: az ügyfelek kérhetik az Ön sérülékenységi bizonyítékait saját DORA-kötelezettségeik teljesítéséhez.

A GDPR további réteget ad hozzá. Az Articles 2 and 3 alkalmazhatók az EU-ban letelepedett szervezetekre és az EU-n kívüli szervezetekre is, ha árukat vagy szolgáltatásokat kínálnak az EU-ban élő személyeknek, vagy megfigyelik a viselkedésüket. Az Article 5 megköveteli a személyes adatok védelmét és a megfelelésért való elszámoltathatóságot. Az Article 4 a személyesadat-sértést olyan biztonsági incidensként határozza meg, amely a személyes adatok véletlen vagy jogellenes elvesztéséhez, megsemmisüléséhez, megváltoztatásához, jogosulatlan közléséhez vagy hozzáféréséhez vezet. Egy adatbázison, identitásplatformon vagy ügyfélportálon késve telepített javítás adatvédelmi elszámoltathatósági kérdéssé válhat.

A szabályzattól a bizonyításig

Az első lépés a szabályok meghatározása. Egy erős sérülékenység- és javításkezelési szabályzat nem csupán auditdokumentum. Ez a kontroll működési alapszabálya.

Vállalati környezetekben a Sérülékenység- és javításkezelési szabályzat kifejezetten összekapcsolja a technikai javításkezelést a több szabályozási környezetre kiterjedő megfeleléssel:

Ez a szabályzat támogatja az ISO/IEC 27001 Annex A Control 8.8 és az ISO/IEC 27002 útmutatása szerinti megfelelést, és kezeli a DORA Article 8, NIS2 Article 21, GDPR Article 32, valamint a COBIT 2019 DSS és APO domainek szerinti szabályozási követelményeket.

A „Cél” szakaszból.

Ugyanez a szabályzat meghatározza a központi bizonyítékként szolgáló nyilvántartással kapcsolatos irányítási elvárást:

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 hatáskörrel rendelkező személy havonta felülvizsgál.

Az „Irányítási követelmények” szakaszból, 5.1 szabályzati pont.

Meghatározza a vizsgálati gyakoriságot is:

Valamennyi rendszert legalább havonta vizsgálni kell; a magas kockázatú vagy külső kitettségű vagyonelemeket hetente kell vizsgálni.

„A szabályzat végrehajtásának követelményei” szakaszból, 6.1.1 szabályzati pont.

És megakadályozza, hogy a sürgős javítás kontrollálatlan technikai tevékenységgé váljon:

Valamennyi helyesbítő intézkedést a Változáskezelési folyamaton keresztül kell koordinálni (a P5 - Változáskezelési szabályzat szerint) a stabilitás és az auditnyom megőrzése érdekében.

Az „Irányítási követelmények” szakaszból, 5.5 szabályzati pont.

KKV-k esetében ugyanezek a bizonyítékelvek egyszerűbben is megvalósíthatók. A Vulnerability and Patch Management Policy-sme kimondja:

Pontos nyilvántartásokat kell vezetni az alkalmazott javításokról, a nyitott problémákról és a kivételekről az auditfelkészültség biztosítása érdekében

A „Célkitűzések” szakaszból, 3.4 szabályzati pont.

Ezután auditbizonyítékként határozza meg a javítási naplót:

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

Az „Irányítási követelmények” szakaszból, 5.4.1 szabályzati pont.

És meghatározza a minimális tartalmat:

A naplóknak tartalmazniuk kell az eszköz nevét, az alkalmazott frissítést, a javítás dátumát és az esetleges késedelem okát

Az „Irányítási követelmények” szakaszból, 5.4.2 szabályzati pont.

Sürgős, internet felől elérhető kitettség esetén a KKV-szabályzat mérhető követelményt állapít meg:

A kritikus javításokat a kiadástól számított 3 napon belül kell alkalmazni, különösen internet felől elérhető rendszerek esetén

A Vulnerability and Patch Management Policy-sme, „A szabályzat végrehajtásának követelményei” szakaszából, 6.1.1 szabályzati pont.

Ezek a pontok a technikai munkát bizonyítékká alakítják. A szabályzat meghatározza az elvárásokat. A nyilvántartás rögzíti a megállapításokat. A jegy kijelöli a feladatot. A változásnyilvántartás kontrollálja a telepítést. A javítási napló igazolja a végrehajtást. A kockázati nyilvántartás rögzíti a kivételeket. A felülvizsgálati jegyzőkönyvek igazolják a felügyeletet.

A Clarysec bizonyítékközpontú modellje

A Clarysec bizonyítékközpontú modellje egy alapelvből indul ki: minden sérülékenységi megállapításnak visszakövethetőnek kell lennie a felfedezéstől a döntésig.

A Zenith Blueprint: egy auditor 30 lépéses ütemterve „Kontrollok működés közben” fázisában a 19. lépés, „Technikai kontrollok I” a sérülékenységkezelést ismételhető kontrollként kezeli, nem elméleti követelményként:

A sérülékenységek kezelése a modern kiberhigiénia egyik legkritikusabb területe. Bár a tűzfal és a vírusirtó eszközök védelmet nyújtanak, ez a védelem aláásható, ha nem javított rendszerek vagy hibásan konfigurált szolgáltatások maradnak kitetten.

Ugyanez a lépés kifejti, hogy a szervezeteknek rendszeres javítási ütemezéseket, sérülékenységvizsgálókat, triázst, hozzárendelést, helyesbítő intézkedések nyomon követését, kompenzáló kontrollokat és maradványkockázat-elfogadást kell alkalmazniuk. A legfontosabb, hogy helyesen keretezi az auditori szemléletet:

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

Az auditorok számára ez a különbség lényeges. Egy érett szervezetnek lehetnek nyitott sérülékenységei, és ettől még igazolhatja a kontroll működését, ha kockázatalapú prioritáskezeléssel, dokumentált felelősségi körökkel, jóváhagyott kivételekkel, kompenzáló kontrollokkal és ellenőrzött helyesbítő intézkedésekkel rendelkezik.

A Zenith Blueprint arra is figyelmeztet, hogy az auditorok ezt a területet alaposan vizsgálni fogják:

Ez az auditorok számára kiemelt prioritású kontroll, és általában mélyen belemennek a részletekbe. Számítson arra, hogy megkérdezik, milyen gyakran történik a rendszerek javítása, milyen folyamatot követnek egy zero-day bejelentésekor, és mely rendszereket a legnehezebb javítani.

Ezért a CISO nem léphet be egy auditba pusztán egy sérülékenységvizsgálói irányítópulttal. A bizonyítékcsomagnak irányítást, folyamatot, végrehajtást, ellenőrzést és fejlesztést kell bemutatnia.

ISO 27002 kontrollok leképezése auditbizonyítékokra

A Zenith Controls: megfelelési útmutató több keretrendszerhez megfelelési iránytűként működik: leképezi az ISO/IEC 27002:2022 kontrollokat, és megmutatja, hogyan kapcsolódnak az audit elvárásaihoz. A sérülékenység- és javításkezelés esetében három ISO/IEC 27002:2022 kontroll alkotja a működési háromszöget.

Az ISO/IEC 27002:2022 8.8 kontroll, a technikai sérülékenységek kezelése, a központi kontroll. Megelőző jellegű, támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, összhangban áll az azonosítási és védelmi kiberbiztonsági koncepciókkal, és kapcsolódik a fenyegetés- és sérülékenységkezeléshez.

Az ISO/IEC 27002:2022 8.32 kontroll, a változáskezelés, szintén megelőző jellegű. A javításkezelést kontrollált telepítéshez, teszteléshez, jóváhagyáshoz, visszaállításhoz és ellenőrizhetőséghez kapcsolja.

Az ISO/IEC 27002:2022 5.36 kontroll, az információbiztonsági szabályzatoknak, szabályoknak és szabványoknak való megfelelés biztosítja, hogy a folyamat ne legyen opcionális, és ne egyéni erőfeszítésektől függjön. A sérülékenységkezelést a szabályzatok betartásához, a bizonyossághoz és a felügyelethez kapcsolja.

Ez a leképezés elkerül egy gyakori audithibát. A biztonsági terület azt mondja: „Telepítettük a javítást.” Az üzemeltetés azt mondja: „Élesbe állítottuk.” A megfelelési terület azt mondja: „Nem tudjuk igazolni a sorrendet.” A leképezett bizonyítéklánc mindhárom csapat számára ugyanazt a történetet adja.

A bizonyítéklánc, amelyet az auditorok látni akarnak

Egy igazolható sérülékenységkezelési bizonyítékláncnak hét szakasza van.

A „vizsgálatokat futtatunk” és az „auditkészek vagyunk” közötti gyakorlati különbség a folytonosság. Ha egy sérülékenység nem követhető vissza a felfedezéstől a lezárásig, a kontroll gyenge. Ha vannak kivételek, de senki sem hagyta jóvá őket, a folyamat gyenge. Ha a javítások megkerülik a változáskezelést, az auditnyom gyenge. Ha kritikus sérülékenységek kompenzáló kontrollok nélkül maradnak nyitva, az irányítás gyenge.

Az Audit- és megfelelésfelügyeleti szabályzat támogatja az automatizálást ennek a modellnek a részeként:

Automatizált eszközöket kell bevezetni a konfigurációs megfelelés, a sérülékenységkezelés, a javításkezelési állapot és az emelt jogosultságú hozzáférés nyomon követésére.

„A szabályzat végrehajtásának követelményei” szakaszból, 6.4.1 szabályzati pont.

KKV-k számára az Audit and Compliance Monitoring Policy-sme gyakorlati módon határozza meg a technikai kontrollok ellenőrzését:

Technikai kontrollok ellenőrzése (pl. biztonsági mentési állapot, hozzáférés-szabályozási konfiguráció, javítási bejegyzések)

„A szabályzat végrehajtásának követelményei” szakaszból, 6.1.1.2 szabályzati pont.

A kisebb szervezeteknek nincs szükségük vállalati szintű eszközkészletre ahhoz, hogy auditkészek legyenek. Következetes bizonyítékokra van szükségük. Egy egyszerűsített nyilvántartás, jegykezelő tábla, javítási napló és havi felülvizsgálat elegendő lehet, ha teljes körű, naprakész és kockázathoz kötött.

Példa: egy kritikus megállapítás teljes auditfelkészítése

Maria heti külső vizsgálata CVE-2026-12345 sérülékenységet azonosít egy internet felől elérhető fizetési API-átjárón. A sérülékenységvizsgáló kritikusnak minősíti. A szolgáltatás ügyfélazonosító és tranzakciós metaadatokat kezel, ezért GDPR és DORA vonatkozásai is lehetnek. Az átjáró felelőse a Platform Engineering, de a javítás rövid kiesést igényel.

Az auditálható munkafolyamat a következő.

1. Sérülékenységi nyilvántartási bejegyzés létrehozása

A biztonsági csapat rögzíti a megállapítást a központi nyilvántartásban:

• Megállapítás azonosítója: VULN-2026-0142
• Forrás: heti külső vizsgálat
• Felfedezés dátuma és ideje
• Eszköz: api-gw-prod-01
• Felelős: Platform Engineering
• Kitettség: internet felől elérhető
• Adatkörnyezet: ügyfélazonosító és tranzakciós metaadatok
• Súlyosság: kritikus
• SLA: 72 óra vagy a szabályzat alapján szigorúbb
• Jegy: SEC-4821
• Változásnyilvántartási bejegyzés: CHG-10988
• Állapot: helyesbítő intézkedés tervezve

2. Triázs üzleti és szabályozási kontextus alapján

A csapat ellenőrzi az exploit elérhetőségét, a támadási felületet, a hitelesítési követelményeket, az üzleti hatást és az adatérzékenységet. Mivel a rendszer internet felől elérhető és ügyfélfolyamatokat támogat, a sérülékenység kritikus marad. A kockázatgazda a platformvezető, és a CISO értesítést kap a lehetséges NIS2, DORA és GDPR vonatkozások miatt.

Az ISO/IEC 27005:2022 7.1–7.4 pontjai támogatják a kockázatazonosítást, a felelősséget, a következményt, a valószínűséget és a prioritáskezelést. A 8.2–8.6 pontok támogatják a kezelés kiválasztását, a kontroll meghatározását, az SoA-kapcsolódást, a kezelési tervet és a maradványkockázat jóváhagyását.

3. Kontrollált sürgősségi változtatás megnyitása

A javítást ugyanarra az estére ütemezik. A változásnyilvántartási bejegyzés tartalmazza a gyártói hivatkozást, az érintett szolgáltatásokat, a teszttervet, a visszaállítási tervet, a karbantartási ablakot, az ügyfélkommunikációra vonatkozó döntést, a jóváhagyásokat és a telepítés utáni ellenőrzési követelményt.

Ez közvetlenül támogatja az ISO/IEC 27002:2022 8.32 kontrollt és a vállalati szabályzati követelményt, amely szerint a helyesbítő intézkedéseket változáskezelésen keresztül kell koordinálni.

4. A javítás alkalmazása és a javítási napló frissítése

A javítási napló rögzíti az eszköz nevét, az alkalmazott frissítést, a javítás dátumát és adott esetben a késedelem okát. Ha a javítás késett volna, a csapat dokumentálta volna a kompenzáló kontrollokat, például a webalkalmazás-tűzfalszabályokat, az ideiglenes hozzáférési korlátozásokat, a fokozott naplózást, az elkülönítést vagy a megerősített felügyeletet.

5. Ellenőrzés és lezárás

A biztonsági csapat újravizsgálja az API-átjárót. A sérülékenység már nem jelenik meg. A jegy frissül a tiszta vizsgálati bizonyítékkal, a javítás verziójával, a telepítési időbélyeggel és a változásnyilvántartási hivatkozással. A sérülékenységi nyilvántartás állapota „Lezárva, ellenőrizve” lesz.

6. A jelentéstételi hatás felülvizsgálata

Ha nem történt kihasználás és nem volt szolgáltatáskimaradás, a NIS2 vagy DORA szerinti incidensjelentés nem feltétlenül aktiválódik. Ha kompromittálódás indikátorai találhatók, az incidenskezelési folyamatnak osztályoznia kell a hatást és az eszkalációt. A NIS2 alapján egy jelentős incidens korai figyelmeztetést és lépcsőzetes jelentéstételt igényelhet. A DORA alapján egy jelentős IKT-vel kapcsolatos incidens osztályozást és jelentéstételt igényel az alkalmazandó illetékes hatósági folyamaton keresztül.

7. A tanulságok beépítése a vezetőségi felülvizsgálatba

A hónap végén a CISO felülvizsgálati jegyzőkönyve rögzíti, hogy a sérülékenységet heti külső vizsgálat észlelte, SLA-n belül helyesbítették, ismételt vizsgálattal ellenőrizték, és incidens nélkül lezárták. Ha hasonló problémák ismétlődnek, a kockázatkezelési terv tartalmazhat biztonságos konfigurációs alapbeállításokat, automatizált javítástelepítést, beszállítói eszkalációt vagy alkalmazásmodernizációt.

Amikor az auditor a CVE-2026-12345-ről kérdez, Maria e-mailek és képernyőképek helyett célzott bizonyítékcsomagot tud bemutatni.

Ez jelenti az auditfelkészültséget. Nem azért, mert a szervezetnek nem voltak sérülékenységei, hanem azért, mert kontroll alatt tartotta őket.

Egy bizonyítékkészlet, több kötelezettség

Egy jól kialakított sérülékenység- és javításkezelési program több keretrendszert is képes kiszolgálni párhuzamos munka nélkül.

Az ISO 27001:2022 esetében a bizonyíték támogatja a kockázatalapú IBIR-t, az Annex A kontrollok bevezetését, az alkalmazhatósági nyilatkozatot, a kockázatkezelési terveket, a belső auditot és a folyamatos fejlesztést. Ha az ISO/IEC 27002:2022 8.8 kontroll alkalmazandó az SoA-ban, a szervezetnek be kell tudnia mutatni a jogi, szabályozási, kockázati vagy üzleti indoklást. Ez az indoklás gyakran tartalmazza a NIS2 Article 21, a DORA IKT-kockázati kötelezettségeit, a GDPR szerinti elszámoltathatóságot, az ügyfélszerződéseket és az operatív reziliencia igényeit.

A NIS2 esetében ugyanez a bizonyíték segít igazolni az Article 21 szerinti intézkedéseket, beleértve a kockázatelemzést, a sérülékenységkezelést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a kiberhigiéniát, a hozzáférés-szabályozást és az eredményesség értékelését. Az Article 20 CISO-felülvizsgálattal, igazgatósági jelentéstétellel, vezetői jóváhagyással és kiberbiztonsági képzéssel igazolható. Az Article 23 akkor válik relevánssá, ha a kihasználás súlyos működési zavart, pénzügyi veszteséget vagy másoknak okozott kárt okoz vagy okozhat.

A DORA esetében a sérülékenységi és javítási bizonyíték támogatja az IKT-kockázatkezelési keretrendszert, a vezető testületi felügyeletet, a rezilienciastratégiát, az incidensészlelést és -osztályozást, a rezilienciatesztelést és az IKT harmadik fél felügyeletet. Ha egy IKT-szolgáltató üzemelteti vagy kezeli az érintett rendszert, az Articles 28 to 30 kellő gondosságot, szerződéses védelmet, auditálási jogokat, incidensekben nyújtott támogatást és kilépési szempontokat követel meg.

A GDPR esetében ugyanez a bizonyíték támogatja az Article 5 szerinti elszámoltathatóságot és az Article 32 által elvárt biztonsági helyzetet. Ha egy sérülékenység jogosulatlan hozzáféréshez, módosításhoz, elvesztéshez vagy személyes adatok közléséhez vezet, a sérülékenységi idővonal, a javítási bejegyzések, a felügyeleti naplók és az adatsértési értékelési feljegyzések alapvetővé válnak.

A COBIT 2019 és ISACA-jellegű bizonyosság esetében a sérülékenységkezelést az üzemeltetési biztonságon, a kontrollok nyomon követésén, a változás-elősegítésen és az irányítási elszámoltathatóságon keresztül értékelik. A Zenith Blueprint több megfelelési környezetre vonatkozó hivatkozásai kiemelik a COBIT 2019 DSS05.04 és BAI09.02 elemeket, valamint az ITAF bizonyossági elvárásait a sérülékenységkezelés, a javításkezelés és a biztonságos változáskezelés felett.

A támogató ISO szabványok erősítik a működési modellt. Az ISO/IEC 27005:2022 támogatja a kockázatértékelést és a kockázatkezelést. Az ISO/IEC 27035:2023 támogatja az incidenskezelést, ha a sérülékenységeket kihasználják. Az ISO/IEC 30111 támogatja a sérülékenységkezelési folyamatokat. Az ISO/IEC 29147 támogatja a sérülékenységek közzétételét és a tájékoztatókat. Az ISO/IEC 27017 támogatja a felhőalapú sérülékenységkezelést. Az ISO 22301 támogatja a folytonossági tervezést, ha technikai sérülékenységek üzleti szolgáltatásokat zavarhatnak meg.

Hogyan tesztelik különböző auditorok ugyanazt a folyamatot

A különböző értékelők eltérő nézőpontokat alkalmaznak. A bizonyíték lehet ugyanaz, de a kérdések változnak.

A szabályzat azt mondja meg, minek kell történnie. Az operatív bizonyíték azt mutatja meg, mi történt ténylegesen. A felülvizsgálati bejegyzések azt igazolják, hogy a vezetés tudott róla, kérdéseket tett fel és intézkedett.

Gyakori okok, amiért a javításkezelés megbukik az auditon

A legtöbb megállapítást nem a sérülékenységvizsgáló hiánya okozza. A problémák forrása a megszakadt visszakövethetőség.

Az eszköznyilvántartás hiányos.
Ha a sérülékenységvizsgáló olyan eszközöket talál, amelyek hiányoznak a CMDB-ből vagy az eszköznyilvántartásból, a felelősség és az üzleti hatás nem értékelhető megbízhatóan. Ez aláássa az ISO 27001:2022 hatókört, a kockázatértékelést és a kockázatkezelést.

A sérülékenységeket csak a sérülékenységvizsgálóban követik.
A sérülékenységvizsgálói irányítópultok nem irányítási nyilvántartások. Gyakran hiányzik belőlük a kockázatgazdai jóváhagyás, a kivételek indoklása, a változáshivatkozás és az üzleti kontextus.

A kritikus megállapításokhoz nincs SLA-bizonyíték.
Egy szabályzat kimondhatja, hogy a kritikus sérülékenységeket három napon belül javítani kell. Az auditkérdés az, hogy a nyilvántartások igazolják-e ennek megtörténtét.

A kivételek informálisak.
Örökölt rendszerek, kiesési korlátok és beszállítói késedelmek előfordulnak. De a „nem tudtuk javítani” állításnak dokumentált kivétellé kell válnia kompenzáló kontrollokkal, lejárati dátummal és maradványkockázat-jóváhagyással.

A sürgősségi javítás megkerüli a változáskezelést.
A sürgősségi változtatások is változtatások. Ha nincs jóváhagyási, tesztelési vagy visszaállítási bizonyíték, az auditorok arra következtethetnek, hogy a helyesbítő intézkedés működési kockázatot hozott létre.

A harmadik fél rendszerek láthatatlanok.
A NIS2 és a DORA alapján a beszállítói és IKT harmadik fél kockázatok központi jelentőségűek. Ha egy szolgáltató javítja a platformot, akkor is szükség van bizonyítékra, szerződéses jogokra, szolgáltatási jelentésekre és eszkalációs útvonalakra.

Senki sem vizsgálja felül a trendeket.
Az ismétlődő sérülékenységek gyenge konfigurációkezelésre, hiányos biztonságos fejlesztési gyakorlatokra, már nem támogatott eszközökre vagy beszállítói hibára utalhatnak. A havi felülvizsgálat a technikai adatokat irányítási intézkedéssé alakítja.

A Clarysec sérülékenységi auditcsomagja

Egy közelgő ISO 27001:2022, NIS2 vagy DORA felkészültségi felülvizsgálathoz a Clarysec a következő elemekből álló sérülékenység- és javításkezelési auditcsomag összeállításában támogatja a szervezeteket:

• Sérülékenység- és javításkezelési szabályzat, beleértve a hatókört, szerepköröket, vizsgálati gyakoriságot, javítási SLA-kat és kivételi szabályokat
• Eszköznyilvántartási kivonat, amely bemutatja a hatókörbe tartozó rendszereket, felelősöket, kritikalitást és kitettséget
• Legutóbbi belső és külső sérülékenységvizsgálati jelentések
• Központi sérülékenységkezelési nyilvántartás nyitott, lezárt és kivételként kezelt tételekkel
• Javítási naplók, amelyek bemutatják az eszközt, a frissítést, a javítás dátumát és a késedelem okait
• Változásnyilvántartások mintavételezett kritikus és magas súlyosságú sérülékenységekhez
• Ismételt vizsgálatok vagy helyesbítő intézkedés utáni ellenőrzés bizonyítékai
• Kivétel- és maradványkockázat-jóváhagyások késleltetett vagy nem javítható rendszerekhez
• Biztonsági tájékoztatók figyelésére szolgáló folyamat beszállítókhoz, könyvtárakhoz és felhőszolgáltatásokhoz
• Havi CISO vagy vezetőségi felülvizsgálati jegyzőkönyvek
• Megfelelőségi leképezés az ISO 27001:2022, NIS2, DORA, GDPR és COBIT 2019 kötelezettségeihez
• Belső audit vagy technikai kontroll-ellenőrzési eredmények

A Zenith Blueprint Audit, felülvizsgálat és fejlesztés fázisának 24. lépésében a Clarysec hangsúlyozza az alkalmazhatósági nyilatkozat, a kockázati nyilvántartás és a kockázatkezelési terv közötti visszakövethetőséget:

Az SoA-nak összhangban kell lennie a kockázati nyilvántartással és a kockázatkezelési tervvel. Ellenőrizze újra, hogy minden kontroll, amelyet kockázatkezelési intézkedésként választott, „Alkalmazandó” jelölést kapott-e az SoA-ban.

Ez különösen fontos a sérülékenységkezelés esetében. Ha a 8.8 kontroll alkalmazandó, az auditcsomagnak nemcsak azt kell bizonyítania, hogy vizsgálatok történnek, hanem azt is, hogy a megállapításokat kockázatkezelésen és folyamatos fejlesztésen keresztül irányítják.

30 napos felkészültségi sprint

Ha közel az audit, ne mindent újraírással kezdjen. Kezdje a bizonyítékok gyors felépítésével.

Ez a sprint nem szünteti meg az összes technikai adósságot. Megváltoztatja az auditbeszélgetést. Egy rendezetlen sérülékenységvizsgálói export védése helyett irányított folyamatot mutathat be felelősökkel, határidőkkel, intézkedésekkel, döntésekkel és felügyelettel.

A vizsgálatoktól az igazolható bizonyítékokig

A sérülékenység- és javításkezelés auditfelkészültsége nem arról szól, hogy be kell bizonyítani: nincsenek sérülékenységek. Arról szól, hogy bizonyítani kell: a szervezet képes megtalálni, megérteni, priorizálni és javítani őket, kontrollálni a kivételeket és igazolni a felügyeletet.

A Clarysec Zenith Blueprint, Zenith Controls, Sérülékenység- és javításkezelési szabályzat, Vulnerability and Patch Management Policy-sme, Audit- és megfelelésfelügyeleti szabályzat és Audit and Compliance Monitoring Policy-sme biztosítja azt a struktúrát, amelyre ez a bizonyíték-előállítási munkafolyamat felépíthető.

Ha szervezete ISO 27001:2022 tanúsításra, NIS2 felkészültségre, DORA szerinti digitális operatív rezilienciára, ügyféloldali kellő gondossági vizsgálatra vagy belső auditra készül, kezdje egy kérdéssel:

Minden kritikus sérülékenység visszakövethető a vizsgálattól a lezárásig?

Ha a válasz nem, a Clarysec segíthet felépíteni azt a nyilvántartást, szabályzatkészletet, több megfelelési környezetre kiterjedő leképezést, vezetőségi felülvizsgálati csomagot és auditálható bizonyíték-előállítási munkafolyamatot, amely a technikai vizsgálatot igazolható irányítássá alakítja.