Sérülékenységek javítására vonatkozó SLA-k NIS2 és DORA megfeleléshez

2026 elején, egy keddi reggelen 08:17-kor Anna, egy gyorsan növekvő fintech vállalat információbiztonsági vezetője, még a kávéja befejezése előtt megkapja az első üzenetet.

A SOC aktív kihasználásra utaló kommunikációt jelzett egy ügyféloldali API-átjáró sérülékenysége kapcsán. A mérnöki csapat szerint a javítás elérhető, de kockázatos, mert az átjáró fizetési munkafolyamatok előtt helyezkedik el. A megfelelőségi vezető továbbít egy nemzeti illetékes hatóságtól érkezett formális megkeresést, amely „sérülékenységkezelésre és közzétételre” vonatkozó bizonyítékokat, valamint annak igazolását kéri, hogy a folyamat az elmúlt 12 hónapban hatékonyan működött. A beszerzés egy harmadik problémát is hozzátesz: az átjárót egy MSP kezeli, a szerződés pedig csak annyit mond, hogy a szolgáltató „időben” alkalmazza a biztonsági frissítéseket.

09:00-ra ez már nem pusztán javításkezelési kérdés. ISO/IEC 27001:2022 szerinti bizonyítékkérdés, NIS2 kiberhigiéniai kérdés, DORA IKT-kockázatkezelési kérdés, beszállítóirányítási kérdés, és akár incidensbejelentési kérdés is lehet, ha a kihasználás a szolgáltatásfolytonosságot vagy a személyes adatokat érinti.

Ez az a gyakorlati megfelelőségi hiányosság, amellyel sok szervezet szembesül 2026-ban. Vannak vizsgálóeszközeik, irányítópultjaik, jegyeik és javításkezelési eszközeik, de nem tudnak egyértelműen válaszolni az auditkérdésekre:

• Ki hagyta jóvá a javítási SLA-t?
• Hogyan biztosított az SLA kockázatalapúsága?
• Mi történik, ha egy kritikus javítás határidőn túlra kerül?
• Hogyan priorizálják az internet felől elérhető eszközöket?
• Hogyan kötik a beszállítókat ugyanazokhoz a határidőkhöz?
• Hol található a kockázatelfogadási nyilvántartás a nem javított rendszerhez?
• Mely bizonyíték igazolja, hogy a kontroll működött, és nem csupán létezett?

A válasz nem egy újabb határidő-táblázat. A sérülékenységjavítási SLA-kat élő kontrollrendszerként kell kezelni, amely összekapcsolja az eszköztulajdonosi felelősséget, a sérülékenységi pontozást, a fenyegetettségi információkat, a változáskezelést, a beszállítói SLA-kat, a kivételkezelést, a felügyeletet, az incidensreagálást és a vezetőségi átvizsgálást.

Itt válnak hasznossá a Clarysec vállalati Sérülékenység- és javításkezelési szabályzata (VPMP), KKV-knak készült Sérülékenység- és javításkezelési szabályzata (VPMP-SME), Harmadik félre és beszállítókra vonatkozó biztonsági szabályzata KKV-k számára (TPSSP-SME), Zenith Blueprint (ZB) és Zenith Controls (ZC) megoldásai. Ezek együtt a „gyorsabb javítás” elvárását védhető irányítási folyamattá alakítják, amely megállja a helyét az ISO, NIS2, DORA, GDPR, NIST és ISACA jellegű auditvizsgálatok során.

Miért váltak a sérülékenységjavítási SLA-k igazgatósági szintű bizonyítékká

A sérülékenységek javítását korábban IT-higiéniai mutatóként kezelték. 2026-ban ez már sokkal inkább szabályozott operatív reziliencia-vállalás.

A NIS2 a kiberbiztonságot vezetői elszámoltathatósági kérdéssé teszi. Az alapvető és fontos szervezeteknél az irányító testületeknek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell azok végrehajtását, és képzésben kell részesülniük, hogy megértsék a kockázatokat és a biztonsági gyakorlatok szolgáltatásokra gyakorolt hatását. A NIS2 Article 21 megfelelő és arányos műszaki, operatív és szervezeti intézkedéseket ír elő, ideé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 és karbantartást, a sérülékenységkezelést és közzétételt, a kiberhigiéniát, a képzést, a hozzáférés-szabályozást, az eszközkezelést és a hitelesítést.

Pénzügyi szervezetek esetén a DORA a speciális operatív reziliencia-rendszer. Irányítási és kontrollrendszert ír elő az IKT-kockázatokhoz, ahol az irányító testület meghatározza, jóváhagyja és felügyeli az IKT-kockázatkezelést, valamint felelős marad érte. Előírja továbbá az IKT-eszközök és függőségek azonosítását, a védelmi és megelőző kontrollokat, például a javításkezelést és változáskezelést, az IKT-val kapcsolatos incidenskezelést, a digitális operatív reziliencia tesztelését és az IKT harmadik fél kockázatainak kezelését.

A gyakorlati hatás jelentős. Egy elmulasztott javítási határidő hibát jelezhet az alábbi területeken:

• Irányítás, ha a vezetés nem hagyott jóvá kockázatalapú SLA-kat
• Eszközkezelés, ha az érintett rendszergazda ismeretlen
• Változáskezelés, ha a sürgősségi javításkezelés nincs szabályozva
• Beszállítókezelés, ha a szolgáltató határidői homályosak
• Incidensreagálás, ha a kihasználásra utaló jeleket nem triázsolják
• Bizonyítékkezelés, ha a jegyek és naplók nem igazolják a lezárást
• Kockázatkezelés, ha a kivételeket nem hagyják jóvá és nem vizsgálják felül

Az ISO/IEC 27001:2022 adja az irányítási rendszer gerincét. A 4.1–4.3 pontok előírják, hogy a szervezeteknek meg kell érteniük a belső és külső körülményeket, az érdekelt felek követelményeit, a jogi és szerződéses kötelezettségeket, valamint a más szervezetekkel fennálló kapcsolódási felületeket. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, alkalmazhatósági nyilatkozatot és a maradványkockázat kockázatgazda általi jóváhagyását írják elő. A 9.1, 9.2, 9.3, 10.1 és 10.2 pontok megkövetelik a nyomon követést, a belső auditot, a vezetőségi átvizsgálást, a folyamatos fejlesztést, a helyesbítő intézkedést és a megőrzött bizonyítékokat.

Egyszerűen fogalmazva: ha azt szeretné, hogy a sérülékenységjavítási SLA-k auditra felkészítettek legyenek, azoknak az IBIR részét kell képezniük, nem maradhatnak pusztán DevOps-mutatók.

Az SLA-modell, amelyet az auditorok látni akarnak

A sérülékenységjavítási SLA-nak három kérdésre kell választ adnia:

1. Milyen gyorsan kell intézkednünk?
2. Ki az elszámoltatható felelős?
3. Milyen bizonyíték igazolja az eredményt?

A Sérülékenység- és javításkezelési szabályzat gyakorlati kiindulópontot ad a kockázatalapú javítási határidőkhöz:

A szervezetnek minden észlelt sérülékenységet szabványosított módszertan alapján kell besorolnia (pl. CVSS v3.x), és az üzleti kritikussággal összhangban álló javítási határidőket kell alkalmaznia: 5.2.1 Kritikus (CVSS 9.0-10.0): azonnali felülvizsgálat; legfeljebb 72 órás javítási határidő. 5.2.2 Magas (7.0-8.9): reagálás 48 órán belül; javítási határidő 7 naptári nap. 5.2.3 Közepes (4.0-6.9): reagálás 5 napon belül; javítási határidő 30 naptári nap. 5.2.4 Alacsony (<4.0): reagálás 10 napon belül; javítási határidő 60 naptári nap.

Ez a pont azért erős, mert elkülöníti a reagálási időt a javítási határidőtől. Egy magas besorolású sérülékenység nem maradhat hat napig észrevétlenül azért, hogy aztán a hetedik napon javítsák. A reagálási óra igazolja a triázst, a felelősség kijelölését, a hatásvizsgálatot és a javítás megtervezését. A javítási határidő a technikai lezárást vagy a jóváhagyott kivételt igazolja.

Kisebb szervezetek számára a Sérülékenység- és javításkezelési szabályzat KKV-k számára egyszerűbb, de továbbra is auditálható megfogalmazást használ:

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

A teljesebb javításkezelési környezetre pedig:

Minden egyéb javítást 30 napon belül alkalmazni kell, kivéve, ha érvényes kivételt dokumentáltak

A lényeg nem az, hogy minden szervezetnek azonos határidőket kell használnia. Az ISO/IEC 27001:2022, a NIS2 és a DORA egyaránt támogatja az arányosságot. A lényeg az, hogy a javítási SLA-kat meg kell határozni, jóvá kell hagyni, kockázatalapúvá kell tenni, nyomon kell követni és bizonyítékokkal kell alátámasztani.

Sok vállalat itt bukik el. Meghatározzák az SLA-t, de nem határozzák meg a bizonyítékokat. Auditori szemszögből az operatív nyilvántartások nélküli szabályzat ígéret, nem kontroll.

Az eszköztulajdonosi felelősség a rejtett függőség

Egy vizsgálóeszköz meg tudja mondani, hogy egy szerveren létezik egy CVE. Azt viszont nem tudja megmondani, hogy a szerver kritikus fizetési folyamatot támogat-e, különleges kategóriájú személyes adatokat tárol-e, elszámolási szolgáltatóhoz kapcsolódik-e, vagy kivonásra van-e ütemezve.

Ezt a kontextust az eszközkezelés, az adatosztályozás, a beszállítói nyilvántartás és a kockázatértékelés adja.

Az ISO/IEC 27001:2022 Annex A 8.8 kontrollja, a technikai sérülékenységek kezelése központi elem, de nem működik önmagában. Erősen függ a konfigurációkezeléstől, a változáskezeléstől, a beszállítói felügyelettől, a felhőirányítástól, a naplózástól, a felügyelettől és a kockázatkezeléstől.

A NIST CSF 2.0 ugyanezt a problémát eredményalapú nyelven írja le. A GOVERN funkció elvárja a jogi, szabályozói és szerződéses kiberbiztonsági követelmények megértését és kezelését, a kockázatvállalási hajlandóság és kockázattűrés dokumentálását, a szerepkörök és erőforrások kijelölését, valamint a kiberbiztonsági szabályzatok létrehozását, betartatását, felülvizsgálatát és frissítését. Az IDENTIFY eredmények hardver-, szoftver-, szolgáltatás-, rendszer-, adat- és életciklus-nyilvántartásokat, valamint sérülékenységazonosítást, kockázatelemzést, kivételkezelést és sérülékenység-feltárási folyamatokat foglalnak magukban.

Anna keddi reggeli forgatókönyvében az első technikai kérdés: „hol található a sérülékeny komponens?” Az első irányítási kérdés pedig: „melyik szolgáltatást és kockázatot érinti?”

A Zenith Blueprint kockázatkezelési szakaszának 13. lépése, a kockázatkezelési tervezés és alkalmazhatósági nyilatkozat, ezt úgy kezeli, hogy összekapcsolja a kockázatokat a kontrollokkal, tulajdonosokkal és határidőkkel:

Továbbá rendeljen hozzá Tulajdonost és Határidőt minden intézkedéshez (akár külön oszlopban vagy a megjegyzésekben). Pl. „Tulajdonos: informatikai vezető, határidő: 2025 harmadik negyedévéig.” Ettől válik valódi tervvé.

Pontosan erre van szükség a sérülékenységek javításánál. A tulajdonos nélküli megállapítás backlog-zajjá válik. A tulajdonossal, határidővel, kockázatkezelési döntéssel és bizonyítéklánccal rendelkező megállapítás auditálható kontrollá válik.

Hogyan képezi le a Zenith Controls a kontrollkapcsolatokat

A Zenith Controls az ISO/IEC 27002:2022 8.8 kontrollját, a technikai sérülékenységek kezelését megelőző kontrollként kezeli, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást. Összekapcsolja az Identify és Protect kiberbiztonsági koncepciókkal, a fenyegetés- és sérülékenységkezelés operatív képességével, valamint az irányítás, ökoszisztéma, védelem és elhárítás biztonsági területeivel.

Ez azért fontos, mert a javítási SLA-k nem csupán védelmi mechanizmusok. Egyben irányítási és ökoszisztéma-mechanizmusok is. A kitettséget a beszállítók, felhőplatformok, menedzselt szolgáltatások, nyílt forráskódú komponensek és internet felől elérhető függőségek alakítják.

A Zenith Controls a 8.8 kontrollt több támogató kontrollhoz kapcsolja:

A Zenith Controls a sérülékenységkezelést az ISO/IEC 27005:2024 szabvánnyal is összekapcsolja, különösen a sérülékenységazonosítással és a nem javított rendszereket érintő kockázati forgatókönyvekkel. Ez megerősíti azt az érvet, hogy a javítási határidőknek kockázatalapúnak, nem önkényesnek kell lenniük. A beszállítói felügyeletet az ISO/IEC 27036-4:2016 szabvánnyal is összeköti a felhőszolgáltatási megállapodások biztonsági szintjeihez, valamint az ISO/IEC 20000-1:2018 szabvánnyal a szolgáltatásnyújtás tervezéséhez és a változáskezeléshez.

Ez a több szabványt átfogó struktúra audit során lényeges. Ha egy szervezet azt állítja, hogy „a kritikus sérülékenységeket 72 órán belül javítjuk”, az auditor ellenőrizni fogja, hogy ezt az állítást kockázatértékelés, eszközosztályozás, beszállítói kötelezettségek, változásnyilvántartások és felügyeleti bizonyítékok támasztják-e alá.

NIS2 kiberhigiénia: a sérülékenységkezeléstől a helyesbítő intézkedésig

A NIS2 Article 21 minden veszélyre kiterjedő megközelítést ír elő a hálózati és információs rendszerekre. A sérülékenységjavítási SLA-k szempontjából több Article 21 elem közvetlenül releváns:

• Kockázatelemzés és információsrendszer-biztonsági szabályzatok
• Incidenskezelés
• Üzletmenet-folytonosság és válságkezelés
• Ellátási lánc biztonsága
• Biztonságos beszerzés, fejlesztés és karbantartás, beleértve a sérülékenységkezelést és közzétételt
• Eljárások a kiberbiztonság eredményességének értékelésére
• Alapvető kiberhigiénia és képzés
• Hozzáférés-szabályozás és eszközkezelés
• Többtényezős hitelesítés vagy folyamatos hitelesítés, ahol indokolt

A NIS2 Article 20 az irányító testületeket teszi elszámoltathatóvá a kiberbiztonsági kockázatkezelési intézkedések jóváhagyásáért és felügyeletéért. Ez azt jelenti, hogy a sérülékenységjavítási mutatók nem maradhatnak kizárólag egy mérnöki irányítópulton. Meg kell jelenniük a vezetői jelentésekben, kockázati bizottsági anyagokban vagy az IBIR vezetőségi átvizsgálási nyilvántartásaiban.

Az Article 21 azt is elvárja, hogy azok a szervezetek, amelyek az előírt intézkedésekkel való meg nem felelést azonosítanak, indokolatlan késedelem nélkül helyesbítő intézkedést tegyenek. Ez a kifejezés fontos. Ha az irányítópult lejárt határidejű kritikus sérülékenységeket mutat, a megfelelőségi bizonyíték nem állhat meg annál, hogy „tudunk róla”. Mutatnia kell az eszkalációt, a kockázati felülvizsgálatot, a vezetői láthatóságot, a helyesbítő intézkedést és az újraértékelést.

A NIS2 Article 23 további dimenziót ad. Ha egy nem javított sérülékenység kihasználása súlyos működési zavart, pénzügyi veszteséget vagy más személyeknek okozott kárt eredményez, vagy ilyen hatás kiváltására alkalmas, az jelentős incidenssé válhat. A jelentéstételi életciklus magában foglalja a jelentős incidensről való tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést, kérésre közbenső jelentéseket, valamint az incidensbejelentést követő egy hónapon belüli zárójelentést. A zárójelentésnek tartalmaznia kell a súlyosságot, a hatást, a valószínű gyökérokot, a kockázatcsökkentő intézkedéseket és adott esetben a határokon átnyúló hatást.

Ezért az SLA-folyamatnak kapcsolódnia kell az incidensreagáláshoz. Az aktív kihasználási bizonyítékkal rendelkező kritikus sérülékenységnek biztonsági triázst, felügyeletet, bizonyítékmegőrzést és jelentéstételi értékelést kell kiváltania, nem csupán rutinszerű javítási jegyet.

DORA IKT-kockázat: javítási határidők mint reziliencia-bizonyítékok

Pénzügyi szervezetek esetén a DORA 2025. január 17-től alkalmazandó, és egységes követelményeket teremt az IKT-kockázatkezelés, a jelentős IKT-val kapcsolatos incidensek bejelentése, a digitális operatív reziliencia tesztelése, az információmegosztás és az IKT harmadik fél kockázatainak kezelése területén. A NIS2 nemzeti szabályai alapján azonosított érintett pénzügyi szervezetek esetében ágazatspecifikus uniós jogi aktusként kezelik.

A DORA működési modellje közel áll egy integrált IBIR-hez. Az Article 5 és Article 6 irányítást, szabályzatokat, eljárásokat, eszközöket, éves vagy időszakos felülvizsgálatot, auditot, a kritikus auditmegállapítások helyesbítését és digitális operatív reziliencia-stratégiát ír elő. Az Article 8 megköveteli az IKT-val támogatott üzleti funkciók, információs vagyon, IKT-eszközök, függőségek, harmadik fél folyamatai és örökölt IKT-kockázatok azonosítását és nyilvántartásba vételét. Az Article 9 védelmi és megelőző kontrollokat ír elő, beleértve a javításkezelést és a változáskezelést. Az Article 11 és Article 12 folytonosságot, reagálást, helyreállítást, biztonsági mentést, visszaállítást és helyreállítási célokat követel meg.

A DORA Article 17–19 olyan IKT-val kapcsolatos incidenskezelési folyamatot ír elő, amely észlel, kezel, rögzít, osztályoz, eszkalál, jelent, kommunikál, gyökérokot elemez és helyreállítja a biztonságos működést. Az Article 24–26 digitális operatív reziliencia tesztelést ír elő, beleértve az IKT-eszközök és rendszerek megfelelő tesztelését, sérülékenységértékeléseket, hálózatbiztonsági értékeléseket, hiányosságelemzéseket, ahol megvalósítható, forráskód-felülvizsgálatokat, penetrációs tesztelést és egyes pénzügyi szervezetek esetén fenyegetésvezérelt penetrációs tesztelést. Az Article 28 és Article 30 az IKT harmadik fél kockázatainak kezelését, az IKT-szolgáltatási szerződések nyilvántartását, a kellő gondosságot, az auditálási és ellenőrzési jogokat, a szolgáltatási szinteket, a szolgáltató incidens alatti támogatását, a felmondási jogokat és a kilépési megállapodásokat követeli meg.

A javítási SLA-k esetében a DORA három módon változtatja meg a bizonyítékelvárásokat.

Először, a tesztelésből származó sérülékenységi megállapításoknak priorizált javítási folyamatba kell bekerülniük. Egy vizsgálati jelentés önmagában nem elegendő.

Másodszor, a kritikus megállapítások javítását irányítási és auditterületen keresztül kell nyomon követni. A DORA a nem mikrovállalkozásoknál a kritikus auditmegállapítások formális javítását várja el.

Harmadszor, az IKT harmadik fél szolgáltatókat mérhető kötelezettségekhez kell kötni. Ha a javítási ablakot a felhő-, SaaS- vagy MSP-szolgáltató kontrollálja, a szerződésnek és a nyilvántartásnak meg kell mutatnia, hogyan támogatják az ő javítási határidőik az Ön reziliencia-kötelezettségeit.

A Sérülékenység- és javításkezelési szabályzat ezt közvetlenül kezeli:

Harmadik fél javításkezelése és SaaS-kockázati felügyelet 6.6.1 Minden harmadik fél rendszernek (SaaS, PaaS, MSP által kezelt) megfelelő sérülékenység- és javításkezelési kontrollokat kell igazolnia. 6.6.2 A beszállítói SLA-knak a belsőleg meghatározott, kritikusság alapú küszöbértékekkel egyenértékű javítási határidőket kell tartalmazniuk.

Ez a pont gyakran a hiányzó híd a belső ISO-bizonyítékok és a DORA szerinti beszállítói felügyelet között.

GDPR: amikor a javítási késedelmek személyesadat-kezelési elszámoltathatósági hibává válnak

A GDPR nem sérülékenységkezelési szabvány, de megváltoztatja a javítási hiba következményeit.

A GDPR Article 5 előírja a személyes adatok biztonságos kezelését, és megköveteli, hogy az adatkezelő képes legyen igazolni a megfelelést. Az Article 32 a kockázatnak megfelelő biztonsági szintet biztosító megfelelő technikai és szervezeti intézkedéseket ír elő. Amikor nem javított rendszerek személyes adatokat kezelnek, különösen személyazonosító adatokat, pénzügyi adatokat, biometrikus adatokat, egészségügyi adatokat, foglalkoztatási adatokat vagy KYC-információkat, a javítási SLA-k az adatkezelés biztonságához kapcsolódó elszámoltathatóság részévé válnak.

Egy késedelmes javítás védhető lehet, ha a kockázatot értékelték, kompenzáló kontrollokat alkalmaztak, és a maradványkockázatot a megfelelő személy elfogadta. Sokkal nehezebb megvédeni, ha a sérülékenység lejárt határidejű, internet felől elérhető és gazdátlan volt.

A Zenith Controls a sérülékenységkezelést a GDPR Article 32 és 5(1)(f) követelményeihez kapcsolja, mert az időben végzett javításkezelés csökkenti a személyes adatok bizalmasságát és sértetlenségét érintő kockázatokat. A változáskezelést a GDPR Article 24 és Article 32 követelményeihez is kapcsolja, mert a személyes adatokat kezelő rendszerek változtatásait kockázatértékelni, jóváhagyni, dokumentálni és felülvizsgálni kell.

A megfelelőségi tanulság egyértelmű: ha személyes adatok érintettek, a javítási bizonyítéknak tartalmaznia kell az adatkontextust. Az auditorok és szabályozó hatóságok nemcsak azt kérdezik majd, hogy „javították-e?”, hanem azt is, hogy „milyen adatok voltak kockázatnak kitéve, mennyi ideig, és milyen kontrollok csökkentették ezt a kockázatot?”

Gyakorlati Clarysec-munkafolyamat auditra alkalmas SLA-bizonyítékokhoz

Egy érett sérülékenységjavítási folyamat nem akkor kezdődik, amikor az auditor nyilvántartásokat kér. Úgy kell kialakítani, hogy minden hónapban nyilvántartásokat állítson elő.

1. lépés: Az SLA-szabályzat jóváhagyása

Induljon a Sérülékenység- és javításkezelési szabályzatból vagy a Sérülékenység- és javításkezelési szabályzat KKV-k számára dokumentumból, az Ön működési modelljétől függően. Igazítsa az SLA-küszöbértékeket a kockázatvállalási hajlandósághoz, a szabályozási hatókörhöz, a szolgáltatások kritikusságához, az adatok érzékenységéhez és a technikai korlátokhoz. Biztosítsa a jóváhagyást a CISO, a kockázati bizottság vagy az irányító testület részéről.

Vállalati környezetekben használja a CVSS-t, az eszközkritikusságot, a kihasználhatóságot, az internetes kitettséget, az adatérzékenységet és az üzleti hatást. KKV-k esetén tartsa a modellt egyszerűnek, de egyértelműnek: kritikus javítások három napon belül, egyéb javítások 30 napon belül, kivéve, ha érvényes kivétel áll fenn.

2. lépés: Eszközök hozzárendelése tulajdonosokhoz és kritikus szolgáltatásokhoz

Minden sérülékenységi megállapításnak visszavezethetőnek kell lennie az alábbiakra:

• Eszköz neve és egyedi azonosítója
• Üzleti szolgáltatás vagy alkalmazás
• Rendszergazda
• Műszaki tulajdonos
• Adatosztályozás
• Internetes kitettség
• Beszállítói függőség, ha alkalmazható
• A támogatott funkció kritikussága

Ez támogatja az ISO/IEC 27001:2022 szerinti kockázattulajdonosi felelősséget, a NIS2 eszközkezelést, a DORA IKT-eszköz- és függőségi nyilvántartását, valamint a NIST CSF IDENTIFY eredményeit.

3. lépés: A sérülékenység triázsa

Hozzon létre jegyet minden megállapításhoz vagy megállapításcsoporthoz. Tartalmazza a CVSS-pontszámot, a forrásként használt vizsgálóeszközt, az érintett eszközt, a kihasználási státuszt, a fenyegetettségi információkat, az üzleti kritikusságot és az előírt SLA-t. Ha kihasználás gyanúja merül fel, kapcsolja a jegyet incidensértékeléshez.

4. lépés: Végrehajtás változáskezelésen keresztül

A javítás változtatás. Rutinszerű frissítésekhez használjon standard változást, kritikus kihasznált sérülékenységekhez pedig sürgősségi változtatást. Tartalmazza a tesztelési bizonyítékot, a jóváhagyást, a megvalósítás időbélyegét, a visszaállítási tervet és a változtatás utáni ellenőrzést.

Ez megfelel a Zenith Controls 8.8 és 8.32 közötti kapcsolatának, ahol a javítások alkalmazását változáskezelés szabályozza, hogy egyensúlyban legyen a sürgősség és az operatív stabilitás.

5. lépés: A lezárás ellenőrzése

Ne zárjon le jegyeket kizárólag a „javítás telepítve” állítás alapján. Követelje meg az ellenőrzést ismételt vizsgálattal, verziómegerősítéssel, konfiguráció-ellenőrzéssel vagy kompenzáló kontroll megerősítésével. Ha a javítás nem alkalmazható, nyisson kivételt.

6. lépés: Kivételek és maradványkockázat rögzítése

A Sérülékenység- és javításkezelési szabályzat meghatározza a kivételhez szükséges tartalmat:

A kivételkérelmeknek tartalmazniuk kell: 7.2.1 Üzleti indoklás a késedelemre vagy a javítás elmaradására 7.2.2 Kockázatértékelés (CVSS, eszközkritikusság, fenyegetettségi információk alapján) 7.2.3 Javasolt kompenzáló kontrollok 7.2.4 Javítási vagy újraértékelési határidő

Meghatározza a jóváhagyást és a felülvizsgálatot is:

A kivételeket a CISO-nak vagy a delegált kockázati bizottságnak kell jóváhagynia, és az IBIR kivételnyilvántartásában kell rögzíteni, legfeljebb 90 napos felülvizsgálati időközzel.

Ez a kivételnyilvántartás alapvető bizonyítékká válik az ISO/IEC 27001:2022 Clause 6.1.3 szerinti kockázatkezeléshez és maradványkockázat-elfogadáshoz, valamint a vezetőségi átvizsgáláshoz.

Ez a nyilvántartás igazolja, hogy a szervezet nem hagyta figyelmen kívül a sérülékenységet. Értékelte a kockázatot, kompenzáló kontrollokat alkalmazott, jóváhagyta a maradványkockázatot, és felülvizsgálati dátumot határozott meg.

7. lépés: Havi bizonyítékcsomag összeállítása

A havi sérülékenységjavítási bizonyítékcsomagnak tartalmaznia kell:

KKV-k esetén a bizonyíték lehet egyszerűbb, de továbbra is következetesnek kell lennie. A Sérülékenység- és javításkezelési szabályzat KKV-k számára visszakövethetőséget biztosító javítási naplókat ír elő:

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

Ez az egyetlen pont audit szempontból rendkívül értékes. A javításkezelést állításból nyilvántartássá alakítja.

Beszállítói javításkezelés: a szerződésnek illeszkednie kell az SLA-hoz

Ha egy MSP, SaaS-szolgáltató, PaaS-szolgáltató vagy felhőszolgáltató kontrollálja a javítások bevezetését, a belső SLA-k értéktelenek, ha a beszállítói kötelezettségek nem illeszkednek hozzájuk.

A Harmadik félre és beszállítókra vonatkozó biztonsági szabályzat KKV-k számára információbiztonsági kötelezettségeket tartalmaz irányítási követelményként. A sérülékenységek javításához ezeknek a kötelezettségeknek mérhető szerződéses nyelvvé kell válniuk:

• Kritikus sérülékenységekre vonatkozó értesítési ablakok
• Kritikus, magas, közepes és alacsony besorolású javítási határidők
• Sürgősségi változtatási folyamat
• Ügyféljóváhagyási követelmények kiesés esetén
• Bizonyítékformátum a javítás lezárásához
• Sérülékenység-feltárási folyamat
• Incidens alatti támogatási kötelezettségek
• Auditálási jog vagy bizonyossági jelentések fogadásának joga
• Al-adatfeldolgozói vagy alvállalkozói javítási kötelezettségek
• Kilépési és átmeneti támogatás kritikus szolgáltatásokhoz

A Zenith Blueprint Kontrollok működésben szakaszának 20. lépése, a 8.21 kontroll, Hálózati szolgáltatások biztonsága, egyértelműen megfogalmazza az elvet:

Ha a szolgáltatásokat külső felek nyújtják, beleértve az internetszolgáltatókat, SD-WAN beszállítókat vagy magánfelhő-szolgáltatókat, a biztonsági követelményeket szerződésekbe és SLA-kba kell beépíteni. Ez magában foglalja a rendelkezésre állási garanciákat, az incidensekre vonatkozó reagálási időket, a sérülékenységek javítására vagy mérséklésére vonatkozó kötelezettségeket és az egyértelmű adatkezelési határokat. Soha nem szabad feltételezni, hogy egy szolgáltató megfelel az elvárásoknak, hacsak ez nincs írásban rögzítve, mérhetően és auditálhatóan.

A DORA ezt különösen fontossá teszi a pénzügyi szervezetek számára. Az IKT harmadik fél megállapodásoknak tartalmazniuk kell a szolgáltatási szinteket, a szolgáltató támogatását IKT-incidensek során, az adatokhoz való hozzáférést és helyreállítást, a hatóságokkal való együttműködést, a felmondási jogokat, valamint erősebb rendelkezéseket a kritikus vagy fontos funkciókra, beleértve a felügyeletet, az auditálási jogokat, a vészhelyzeti terveket és a biztonsági intézkedéseket.

A NIST CSF 2.0 ugyanezt mondja ki az ellátási lánc kockázati eredményein keresztül: a beszállítókat ismerni kell, kritikusság szerint priorizálni kell, bevonás előtt értékelni kell, szerződéses követelményekkel kell irányítani, a kapcsolat teljes időtartama alatt nyomon kell követni, be kell vonni az incidenskezelési tervezésbe, és a lezáráskor kezelni kell.

Mit fognak ténylegesen kérdezni az auditorok

Az auditbeszélgetés az auditor hátterétől függően változik.

Egy ISO/IEC 27001:2022 auditor az IBIR-rel kezdi. Ellenőrizni fogja, hogy a sérülékenységkezelés szerepel-e az alkalmazhatósági nyilatkozatban, a kockázatértékelés azonosítja-e a nem javított rendszereket kockázatként, a kockázatkezelési terveknek vannak-e tulajdonosai és határidői, az Annex A 8.8 kontroll megvalósult-e, a bizonyítékokat megőrzik-e, valamint a belső audit és a vezetőségi átvizsgálás értékeli-e a teljesítményt.

A Zenith Blueprint Kontrollok működésben szakaszának 19. lépése egyértelművé teszi az auditelvárást:

Ez az auditorok számára magas prioritású kontroll, amelybe általában mélyen belemennek. Számítson arra, hogy megkérdezik, milyen gyakran javítják a rendszereket, milyen folyamatot követnek, amikor zero-day sérülékenységet jelentenek be, és mely rendszereket a legnehezebb javítani.

Gyakorlati bizonyítékelvárásokkal folytatja:

Az auditorok valószínűleg sérülékenységvizsgálati eredményeket fognak kérni. Ha Nessus, OpenVAS vagy Qualys jellegű eszközöket használnak, exportáljon jelentést, amely megmutatja a közelmúltban észlelt sérülékenységeket és azok kezelését. Ideális esetben ez tartalmazza a kockázati besorolásokat (CVSS) és a javítási határidőket.

Egy NIS2-fókuszú auditor vagy illetékes hatóság igazgatósági jóváhagyást, arányosságot, kiberhigiéniát, sérülékenységkezelést, beszállítói biztonságot, incidenskezelést, eredményességi értékelést, indokolatlan késedelem nélküli helyesbítő intézkedést és jelentéstételi döntési nyilvántartásokat keres, ha a kihasználás jelentős hatást okozott.

Egy DORA-felügyeleti szerv azt vizsgálja, hogy a sérülékenységi megállapítások integrálódnak-e az IKT-kockázatkezelésbe, a digitális operatív reziliencia tesztelésébe, az incidensosztályozásba, a gyökérok-elemzésbe, a harmadik fél nyilvántartásokba, a szerződéses kötelezettségekbe, az auditálási jogokba és a kritikus megállapítások javításába.

Egy NIST CSF értékelő valószínűleg a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER mentén szervezi a felülvizsgálatot. Meg fogja kérdezni, hogy a jogi és szerződéses követelmények érthetők-e, a kockázattűrés dokumentált-e, a sérülékenységek azonosítottak és priorizáltak-e, a kivételeket kezelik-e, a felügyelet észleli-e a kihasználást, valamint a reagálási és helyreállítási intézkedések összehangoltak-e.

Egy COBIT 2019 vagy ISACA jellegű auditor az irányítási célokra, a folyamatképességre, az irányítási gyakorlatokra, a mutatókra, a tulajdonosi felelősségre, a kontrolltervre, a kontroll működésére és a bizonyítékok megfelelőségére fókuszál. Megkérdezi majd, hogy a sérülékenységek javítása ismételhető, mérhető, eszkalált, fejlesztett és összhangban áll-e a vállalati célokkal és a kockázatvállalási hajlandósággal.

Eszkaláció és mutatók: hogyan igazolható, hogy az SLA-t kezelik

Az eszkaláció nélküli SLA csupán célérték. A védhető sérülékenységjavítási programnak eszkalációra van szüksége a határidő megsértése előtt, a határidő megsértésekor és az ismétlődő hibák után.

A Clarysec négyszintű eszkalációs modellt javasol:

1. Operatív eszkaláció, a jegy tulajdonosa és a műszaki vezető értesítést kap a határidő megsértése előtt.
2. Kockázati eszkaláció, az eszközfelelős és a kockázatgazda felülvizsgálja a hatást, amikor a határidő megsértése valószínű.
3. Biztonságirányítási eszkaláció, a CISO vagy a kockázati bizottság jóváhagyja a kivételt vagy a sürgősségi intézkedést.
4. Vezetői eszkaláció, az ismétlődő vagy kritikus SLA-sértések a vezetőségi átvizsgálás elé kerülnek helyesbítő intézkedésekkel.

A Sérülékenység- és javításkezelési szabályzat megerősíti ezt az auditelvárást:

Időszakos auditokat kell végeznie a belső auditnak vagy egy független harmadik félnek az alábbiak ellenőrzésére: 5.6.1 Megfelelés az SLA-knak 5.6.2 A kockázatalapú priorizálás bizonyítékai 5.6.3 A bevezetett javítások eredményessége 5.6.4 Kontrollok a nem javított rendszerek felett

A mutatóknak döntéseket kell támogatniuk, nem irányítópultokat díszíteniük. A legerősebb 2026-os mutatók közé tartoznak:

• Kritikus SLA-megfelelési arány
• Magas SLA-megfelelési arány
• Triázsig eltelt átlagos idő
• Eszközosztályonkénti javításig eltelt átlagos idő
• Lejárt határidejű kritikus sérülékenységek száma
• Elfogadott kivételek száma életkor szerint
• 90 napot meghaladó kivételek
• Internet felől elérhető kritikus kitettségek száma
• Beszállítói SLA-sértések
• Ellenőrzés után újranyitott sérülékenységek
• Kihasznált sérülékenységek miatt végrehajtott sürgősségi változtatások
• Javítási hibák platform vagy üzleti egység szerint

Kapcsolja ezeket a mutatókat az ISO/IEC 27001:2022 Clause 9.3 vezetőségi átvizsgálásához, a DORA irányítási jelentéstételhez és a NIS2 vezetői felügyeletéhez. A NIST CSF 2.0 esetén használja őket a Current és Target Profile-ok, a hiányosságelemzés és az intézkedési tervek frissítésére.

A Clarysec javítási SLA ellenőrzőlistája

Használja ezt az ellenőrzőlistát a jelenlegi program értékeléséhez:

• Van jóváhagyott sérülékenység- és javításkezelési szabályzat?
• Meghatározták a javítási SLA-kat súlyosság és üzleti kritikusság szerint?
• Gyorsított kezelés alá esnek az internet felől elérhető és kihasznált sérülékenységek?
• Az eszközök hozzá vannak rendelve tulajdonosokhoz, szolgáltatásokhoz, adatokhoz és beszállítókhoz?
• A vizsgálóeszközök megállapításai hozzárendelt jegyekké alakulnak?
• A javítások változáskezelésen keresztül történnek?
• A sürgősségi változtatásokat dokumentálják és felülvizsgálják?
• A javítási eredményeket ismételt vizsgálatokkal vagy verzióellenőrzésekkel megerősítik?
• A kivételeket kockázatértékelik, jóváhagyják és legalább 90 naponta felülvizsgálják?
• A kompenzáló kontrollokat dokumentálják a nem javítható rendszerekhez?
• A beszállítói szerződések összhangban vannak a belső javítási küszöbértékekkel?
• A javítási naplók elég teljesek ahhoz, hogy igazolják, mi és mikor történt?
• Az SLA-sértéseket eszkalálják és helyesbítik?
• A mutatókat a vezetés felülvizsgálja?
• Kihasználás gyanúja esetén elindulnak az incidens- és adatsértési értékelések?

Ha több válasz „nem”, a probléma nem az eszközökben van. A kontrolltervvel van gond.

Következő lépések: a javítási határidők átalakítása auditra kész rezilienciává

2026-ban a sérülékenységjavítási SLA-knak többet kell tenniük annál, mint hogy megfeleljenek egy vizsgálóeszköz irányítópultjának. Bizonyítaniuk kell, hogy a szervezet képes azonosítani a kitettséget, priorizálni a kockázatot, jóváhagyott határidőkön belül intézkedni, kontrollálni a kivételeket, irányítani a beszállítókat, és bizonyítékokkal alátámasztani döntéseit az ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT 2019 auditelvárásai szerint.

A Clarysec segíthet abban, hogy a töredezett javítási jegyektől integrált, bizonyítékalapú sérülékenységjavítási programig jusson az alábbiak használatával:

• Sérülékenység- és javításkezelési szabályzat
• Sérülékenység- és javításkezelési szabályzat KKV-k számára
• Harmadik félre és beszállítókra vonatkozó biztonsági szabályzat KKV-k számára
• Zenith Blueprint: egy auditor 30 lépéses ütemterve
• Zenith Controls: több megfelelési keretrendszert átfogó útmutató

Kezdje egy magas kockázatú szolgáltatással. Térképezze fel az eszközeit, beszállítóit, sérülékenységeit, jegyeit, változtatásait, kivételeit és bizonyítékait. Ezután futtassa le rajta az auditkérdéseket. Ha az SLA nem bizonyítható az észleléstől a lezárásig, ez az első javítási projekt.

A cél nem a tökéletes javításkezelés. A cél az irányított, kockázatalapú, mérhető és auditálható javítás. Töltse le a Clarysec szabályzatsablonjait, végezzen célzott hiányosságfelmérést, vagy foglaljon Clarysec demót, hogy a sérülékenységek javítását auditnyomásból operatív rezilienciává alakítsa.