NIS2 2024/2690 és ISO 27001 megfeleltetési térkép felhőszolgáltatók számára
Kedden 08:17-kor Maria, egy európai menedzselt szolgáltató információbiztonsági vezetője (CISO), megkapja azt a riasztást, amelytől minden MSP tart. Egy kiemelt jogosultságú távoli felügyeleti fiók földrajzilag lehetetlen bejelentkezésre utaló riasztást váltott ki. Két ügyfél-bérlői környezetben rendellenes adminisztratív műveletek láthatók. A SOC már megnyitotta a kritikus incidenshez tartozó koordinációs csatornát.
09:00-kor a vezérigazgató is csatlakozik a híváshoz. A kérdések azonnal megváltoznak.
Az NIS2 hatálya alá tartozunk? Alkalmazandó ránk a Bizottság (EU) 2024/2690 végrehajtási rendelete? Kell 24 órán belüli korai figyelmeztetést küldenünk? Mely ügyfeleket kell értesíteni? Tudjuk igazolni, hogy a többtényezős hitelesítés, a naplózás, a szegmentálás, a sérülékenységkezelés, a beszállítói kontrollok és az incidenseszkaláció már az incidens előtt is működtek?
Maria vállalata ISO/IEC 27001:2022 tanúsítással rendelkezik. Felhőmenedzsmentet, adatközponti szolgáltatásokat és menedzselt biztonsági támogatást nyújt ügyfeleknek, köztük egy logisztikai szolgáltatónak és egy regionális banknak. A tanúsítvány fontos, de önmagában nem válaszolja meg az operatív kérdéseket. A jogi csapatnak van egy értesítési folyamatra vonatkozó tervezete. A megfelelési vezetőnek van egy táblázata. Az auditor bekérte az alkalmazhatósági nyilatkozatot, az incidensreagálási tesztek eredményeit, a kiemelt jogosultságú hozzáférési naplókat, a beszállítói átvilágítást, a felhőszolgáltatások megosztott felelősségére vonatkozó bizonyítékokat és az üzletmenet-folytonossági feltételezéseket.
Ez az a pillanat, amikor az NIS2 megszűnik pusztán jogszabályszöveg lenni, és operatív kontrollproblémává válik.
A felhőszolgáltatók, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók és adatközpont-szolgáltatók számára az NIS2 és a 2024/2690 végrehajtási rendelet az általános biztonsági szándék szintjéről az ellenőrizhető kontrollbizonyítékok szintjére emeli az elvárást. Az irányításnak, a kockázatkezelésnek, a hozzáférés-szabályozásnak, az eszközkezelésnek, a sérülékenységkezelésnek, az incidensreagálásnak, a beszállítói biztonságnak, a naplózásnak, a felügyeletnek, a titkosításnak, az üzletmenet-folytonosságnak és a fizikai rezilienciának egyetlen rendszerként kell működnie.
Az ISO/IEC 27001:2022 ehhez a rendszerhez a legjobb gerincet adja, de csak akkor, ha a szervezet az NIS2 követelményeit beépíti az IBIR-be, a kockázati nyilvántartásba, az alkalmazhatósági nyilatkozatba, a szabályzatokba és a bizonyítékmodellbe. A falon lévő tanúsítvány nem elég. A valódi feladat az auditálható kapcsolat kiépítése a jogszabálytól a kockázatig, a kockázattól a kontrollig, a kontrolltól a szabályzatig, a szabályzattól pedig a működési bizonyítékig.
Miért változtatja meg az NIS2 2024/2690 a felhő- és MSP-megfelelési párbeszédet
Az NIS2 ágazat- és méretalapú modellt alkalmaz, de a digitális infrastruktúrára és az IKT-szolgáltatásmenedzsmentre vonatkozó kategóriái szándékosan tágak. Az NIS2 Article 2 és Article 3 alapján, az Annex I és Annex II rendelkezéseivel együtt értelmezve, számos szervezet minősülhet alapvető vagy fontos szervezetnek, ideértve a felhőszolgáltatókat, adatközpont-szolgáltatókat, menedzselt szolgáltatókat, menedzselt biztonsági szolgáltatókat, DNS-szolgáltatókat, TLD-nyilvántartásokat, tartalomszolgáltató hálózatokat és bizalmi szolgáltatókat. A tagállamoknak létre kell hozniuk és időszakosan felül kell vizsgálniuk az alapvető és fontos szervezetek listáit; az első lista határideje 2025. április 17.
Ez azért lényeges, mert a felhő-, MSP-, MSSP- és adatközpont-szolgáltatók más szervezetek kockázati láncaiban helyezkednek el. Egy felhőbeli vezérlősík kompromittálódása több ezer ügyfélrendszert érinthet. Egy adatközpont-kiesés továbbgyűrűzhet a bankszektorba, az egészségügybe, a logisztikába és a közigazgatásba. Egy MSP hitelesítőadat-sértése több ügyfelet érintő zsarolóvírus-eseménnyé válhat. Egy MSSP észlelési hibája késleltetheti az elszigetelést a szabályozott ügyfeleknél.
Az NIS2 Article 20 előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, és felügyeljék azok bevezetését. Az Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, minden veszélyt figyelembe vevő megközelítés alapján. Az alapkövetelmények közé tartozik a kockázatelemzés, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés és fejlesztés, a sérülékenységek kezelése és feltárása, az eredményesség értékelése, a kiberhigiénia, a képzés, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás, az eszközkezelés, a többtényezős hitelesítés vagy folyamatos hitelesítés, a biztonságos kommunikáció és a vészhelyzeti kommunikáció.
Az Article 23 szakaszos jelentéstételt vezet be a jelentős incidensekre, ideértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést, kérés esetén a közbenső jelentéseket, valamint a végleges jelentést az értesítéstől számított egy hónapon belül, illetve folyamatban lévő incidens esetén az incidens lezárását követően.
A 2024/2690 végrehajtási rendelet ezeket az elvárásokat konkrétabbá teszi az érintett digitális szolgáltatók számára. A gyakorlatban a hatóságok, ügyfelek és auditorok nemcsak azt fogják megkérdezni, hogy léteznek-e szabályzatok. Azt is vizsgálni fogják, hogy a kontrollok megfeleltetettek-e, van-e gazdájuk, tesztelték-e őket, és rendelkezésre állnak-e a bizonyítékok.
Az ISO/IEC 27001:2022 az NIS2-t az IBIR működési kontextusává alakítja
Gyakori NIS2-felkészültségi hiba, hogy a szervezet egy nagy ellenőrzőlistával indul, majd feladatokat oszt szét az IT, a jogi terület, a SOC, az infrastruktúra, a beszállítókezelés és a megfelelési funkció között. Ez ugyan aktivitást eredményezhet, de audit során gyakran megbukik, mert senki sem tudja megmutatni, miért éppen az adott kontrollokat választották, hogyan kapcsolódnak a kockázatokhoz, ki fogadta el a maradványkockázatot, és milyen bizonyíték igazolja az eredményességet.
Az ISO/IEC 27001:2022 azt a struktúrát adja meg a szolgáltatóknak, amellyel ez a hiba elkerülhető.
A 4.1–4.4 pontok előírják, hogy a szervezet határozza meg a belső és külső tényezőket, azonosítsa az érdekelt feleket és követelményeiket, döntse el, mely követelményeket kezeli az IBIR-en keresztül, és határozza meg az IBIR alkalmazási területét, beleértve az interfészeket és függőségeket. Egy felhő- vagy MSP-szolgáltató esetében az alkalmazási területnek kifejezetten figyelembe kell vennie az NIS2-t, a 2024/2690 végrehajtási rendeletet, az ügyfélbiztonsági mellékleteket, a DORA által meghatározott ügyfélkövetelményeket, a felhőrégiókat, az alvállalkozókat, az adatközponti függőségeket, a távoli felügyeleti platformokat, a kiemelt jogosultságú hozzáférési útvonalakat és az incidensbejelentési kötelezettségeket.
Az 5.1–5.3 pontok vezetést, a szabályzatokkal való összhangot, erőforrásokat, kommunikációt, kijelölt felelősségi köröket és vezetői elszámoltathatóságot írnak elő. Ez közvetlenül támogatja az NIS2 Article 20 követelményét.
A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, kockázatgazdákat, valószínűség- és következményelemzést, kontrollkiválasztást, az A melléklettel való összevetést, alkalmazhatósági nyilatkozatot, kockázatkezelési tervet és formális maradványkockázat-elfogadást írnak elő. Itt válik az NIS2 operatívvá. Minden szabályozási követelmény kockázati tényezővé, megfelelési kötelezettséggé, kontrollkövetelménnyé vagy bizonyítékkövetelménnyé válik.
A Clarysec ezt a munkát a Zenith Blueprint: Auditorok 30 lépéses ütemterve Zenith Blueprint alapján kezdi, különösen a kockázatkezelési fázisban.
A 13. lépéstől, a kockázatkezelési tervezéstől és az alkalmazhatósági nyilatkozattól kezdve a Zenith Blueprint arra utasítja a csapatokat, hogy alakítsanak ki visszakövethetőséget a kockázatok, kontrollok és szabályozási mozgatórugók között:
„Szabályozások kereszthivatkozása: Ha bizonyos kontrollokat kifejezetten a GDPR, az NIS2 vagy a DORA követelményeinek való megfelelés érdekében vezettek be, ezt rögzítheti akár a kockázati nyilvántartásban, akár az SoA megjegyzéseiben. Például a 8.27 kontroll (adatok biztonságos törlése) nagyon releváns lehet a GDPR személyes adatok megsemmisítésére vonatkozó követelménye szempontjából; megjegyezheti: „Alkalmazandó – támogatja a GDPR Art.32-t (az adatkezelés biztonsága)”. Ezt az ISO nem írja elő, de segít igazolni, hogy figyelembe vette ezeket a keretrendszereket.”
A 14. lépés, a kockázatkezelési szabályzatok és szabályozási kereszthivatkozások, hozzáadja a gyakorlati megfeleltetési fegyelmet:
„Minden szabályozás esetében, ha alkalmazandó, létrehozhat egy egyszerű megfeleltetési táblázatot, amely felsorolja az adott szabályozás fő biztonsági követelményeit és az IBIR-ben szereplő megfelelő kontrollokat/szabályzatokat. Ez az ISO 27001 szerint nem kötelező, de hasznos belső gyakorlat annak biztosítására, hogy semmi se maradjon ki.”
Ez a különbség aközött, hogy „ISO-tanúsítottak vagyunk”, illetve aközött, hogy igazolni tudjuk: „az ISO/IEC 27001:2022 szerinti IBIR-ünk kezeli az NIS2 2024/2690 végrehajtási rendeletének követelményeit.”
Egységes NIS2–ISO/IEC 27001:2022 kontrollmegfeleltetési térkép
Az alábbi megfeleltetés nem jogi tanácsadás, és nem helyettesíti a nemzeti átültetés elemzését. Gyakorlati kontrollarchitektúrát ad azoknak a szolgáltatóknak, amelyeknek auditra alkalmas ISO/IEC 27001:2022 útvonalra van szükségük az NIS2-re való felkészültséghez.
| NIS2 és végrehajtási rendeleti téma | ISO/IEC 27001:2022 IBIR-mechanizmus | Fő A melléklet szerinti kontrollterületek | Clarysec bevezetési bizonyíték |
|---|---|---|---|
| Irányítás és vezetői elszámoltathatóság | A 4., 5., 6. és 9. pont meghatározza a kontextust, a vezetést, a kockázattervezést és a teljesítmény felülvizsgálatát | 5.1 Információbiztonsági szabályzatok, 5.2 Információbiztonsági szerepkörök és felelősségek, 5.31 Jogi, törvényi, szabályozási és szerződéses követelmények | IBIR alkalmazási területe, érdekelt felek nyilvántartása, igazgatósági jóváhagyás, kockázati nyilvántartás, SoA, vezetőségi átvizsgálási jegyzőkönyvek |
| Felhőszolgáltatások irányítása | Kockázatértékelés, beszállítói átvilágítás, megosztott felelősség és kontrollkiválasztás | 5.23 Információbiztonság felhőszolgáltatások használata esetén, 5.19 Információbiztonság a beszállítói kapcsolatokban, 5.22 Beszállítói szolgáltatások felügyelete, átvizsgálása és változáskezelése | Felhőleltár, szolgáltatói kockázatértékelés, megosztott felelősségi mátrix, szerződéses kikötések, felhőalapú naplózási bizonyítékok |
| MSP- és MSSP-kiemelt jogosultságú hozzáférés | Kockázatkezelés ügyfélkörnyezetekre, adminisztrációs platformokra és támogatási eszközökre | 5.15 Hozzáférés-szabályozás, 5.16 Identitáskezelés, 5.18 Hozzáférési jogosultságok, 8.2 Kiemelt hozzáférési jogosultságok, 8.5 Biztonságos hitelesítés | PAM-nyilvántartások, MFA-jelentések, távoli hozzáférési naplók, ugrószerver- vagy Zero Trust átjárókonfiguráció, hozzáférés-felülvizsgálatok |
| Adatközponti reziliencia | Üzleti hatásvizsgálat, folytonossági tervezés és függőségek kezelése | 5.30 IKT-felkészültség az üzletmenet-folytonosságra, 7.1 Fizikai biztonsági peremek, 7.2 Fizikai belépés, 8.13 Információmentés, 8.14 Redundancia | BIA, RTO- és RPO-nyilvántartások, DR-tesztjelentés, fizikai hozzáférési naplók, energiaellátási és hűtési tesztek bizonyítékai |
| Incidensjelentés és eszkaláció | Jogi, szerződéses és ügyfélértesítési kiváltó feltételekhez kapcsolt incidensfolyamat | 5.24 Információbiztonsági incidenskezelés tervezése és előkészítése, 5.25 Információbiztonsági események értékelése és döntés, 5.26 Válasz az információbiztonsági incidensekre, 5.27 Tanulás az információbiztonsági incidensekből | 24 órás korai figyelmeztetési forgatókönyv, 72 órás értesítési munkafolyamat, incidensnyilvántartás, incidens utáni felülvizsgálat |
| Sérülékenységkezelés és feltárás | Kockázatalapú sérülékenységkezelés, kivételkezelés és eredményességértékelés | 8.8 Technikai sérülékenységek kezelése, 8.9 Konfigurációkezelés, 8.32 Változáskezelés, 8.16 Monitorozási tevékenységek | Vizsgálati eredmények, javítási SLA-k, kivétel-jóváhagyások, javítási jelentések, fenyegetettségi információk bemenetei |
| Ellátási lánc biztonsága | Az érdekelt felek követelményei és a beszállítói kockázat integrálása az IBIR-be | 5.19 Információbiztonság a beszállítói kapcsolatokban, 5.20 Információbiztonság kezelése beszállítói megállapodásokban, 5.21 Információbiztonság kezelése az IKT-ellátási láncban, 5.22 Beszállítói szolgáltatások felügyelete, átvizsgálása és változáskezelése | Beszállítói besorolás, átvilágítási kérdőívek, szerződéses kikötések, auditálási jog, alvállalkozói nyilvántartás, kilépési tervek |
| Naplózás, felügyelet és kivizsgálás | Észlelés, bizonyítékok, időkorreláció és incidenskezelési támogatás | 8.15 Naplózás, 8.16 Monitorozási tevékenységek, 8.17 Óraszinkronizálás, 5.25 Információbiztonsági események értékelése és döntés | SIEM-lefedettségi térkép, naplómegőrzés igazolása, riasztáshangolási bejegyzések, óraszinkronizálási bejegyzések, incidenskorrelációs bizonyítékok |
| Hálózati és bérlői környezetek közötti elkülönítés | Biztonságos architektúra, szegmentálás és korlátozott adminisztratív útvonalak | 8.20 Hálózatbiztonság, 8.22 Hálózatok elkülönítése, 8.23 Webszűrés, 8.24 Kriptográfia használata | Hálózati diagramok, tűzfalszabályok, felhőbiztonsági csoportok, VPC- vagy alhálózati szabályok, szegmentálási teszteredmények |
Ez a megfeleltetés akkor válik igazán erőssé, ha beépül a kockázati nyilvántartásba és az alkalmazhatósági nyilatkozatba. Egy szolgáltató például létrehozhat egy olyan kockázati forgatókönyvet, hogy „A távoli felügyeleti platform kompromittálódása jogosulatlan műveletekhez vezet az ügyfélkörnyezetekben.” A kontrollok közé tartozik a többtényezős hitelesítés, a kiemelt jogosultságú hozzáférések kezelése, a szegmentálás, a naplózás, a sérülékenységkezelés, a beszállítói biztonság, az incidenskezelési tervezés és az ügyfélértesítési eljárások. Az SoA megjegyzései hivatkozhatnak az NIS2 Article 21-re, az Article 23-ra, a 2024/2690 végrehajtási rendeletre, az ügyfélszerződésekre és adott esetben a DORA szerinti ügyfél-átvilágítási követelményekre.
Felhőirányítás: az ISO 5.23 kontroll az NIS2 egyik horgonya
Azoknál a felhőszolgáltatóknál és MSP-knél, amelyek felhőszolgáltatásokat használnak ügyfélszolgáltatásaik nyújtásához, az ISO/IEC 27001:2022 A mellékletének 5.23 kontrollja, az információbiztonság felhőszolgáltatások használata esetén, az egyik legfontosabb horgony.
A Zenith Controls: Keresztmegfelelési útmutató Zenith Controls az 5.23 kontrollt megelőző kontrollként foglalja össze, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást támogatja, és kapcsolódik a beszállítói kapcsolatok biztonságához, az irányításhoz, az ökoszisztéma-kockázathoz és a védelemhez. Lefedi a felhőszolgáltatások irányítását, a megosztott felelősséget, a szolgáltató értékelését, a leltárakat, az adatok helyét, a naplózást, a titkosítást, az identitásszerepköröket, a felügyeletet, a szerződéses kikötéseket, a beszállítói kockázatot, a felhőből való kilépést és a rezilienciatervezést.
A Zenith Blueprint „Kontrollok működés közben” fázisának 23. lépése így magyarázza a gyakorlati indokot:
„A felhő már nem célállomás, hanem az alapértelmezett működési mód. Az 5.23 kontroll felismeri ezt a valóságot, és előírja, hogy az információbiztonságot kifejezetten kezelni kell a felhőszolgáltatások kiválasztása, használata és menedzselése során; nem utólagos gondolatként, hanem kezdettől fogva tervezési elvként.”
Egy MSP esetében minden távoli monitorozási és menedzsmentplatformot, ügyfélportált, jegykezelő eszközt, biztonsági telemetriai platformot, biztonsági mentési szolgáltatást, felhőalapú címtárat és SaaS adminisztrációs konzolt irányítás alá kell vonni. Egy adatközpont-szolgáltató esetében a felhőirányítás kiterjedhet a monitorozási platformokra, a látogatókezelő rendszerekre, a fizikai hozzáférés-szabályozási integrációkra, a távoli felügyeleti rendszerekre és az ügyfélportál-infrastruktúrára.
A Clarysec vállalati Felhőszolgáltatások használatára vonatkozó szabályzata Felhőszolgáltatások használatára vonatkozó szabályzat kötelezővé teszi az aktiválás előtti kellő gondossági vizsgálatot:
„Minden felhőhasználatot az aktiválás előtt kockázatalapú kellő gondossági vizsgálatnak kell alávetni, beleértve a szolgáltató értékelését, a jogi megfelelés ellenőrzését és a kontrollok ellenőrzését.”
A „Irányítási követelmények” szakasz 5.2 szabályzati pontjából.
Kisebb szolgáltatók számára a Cloud Usage Policy-sme Cloud Usage Policy-sme - SME egyszerűsített jóváhagyási modellt hoz létre:
„A felhőszolgáltatások minden használatát a bevezetés vagy előfizetés előtt az ügyvezetőnek (GM) felül kell vizsgálnia és jóvá kell hagynia.”
A „Irányítási követelmények” szakasz 5.1 szabályzati pontjából.
Mindkét megközelítés ugyanazt az NIS2-elvárást támogatja: a felhőfüggőségi kockázatot még azelőtt meg kell érteni, hogy a szolgáltatás a szolgáltatásnyújtási lánc részévé válik.
Incidensreagálás: a 24 órás óra a jelentés megírása előtt elindul
Az NIS2 Article 23 azért könyörtelen, mert a jelentéstételi határidő a jelentős incidensről való tudomásszerzéstől indul, nem attól a pillanattól, amikor rendelkezésre áll a teljes gyökérok-elemzés. A szolgáltatók kihívása az, hogy gyorsan meghatározzák, jelentős-e az esemény, mely ügyfelek érintettek, érint-e személyes adatokat, fennáll-e határokon átnyúló szolgáltatási hatás, és mely szerződéses határidők indultak el.
Az ISO/IEC 27001:2022 A mellékletének 5.24 kontrollja, az információbiztonsági incidenskezelés tervezése és előkészítése, a tervezési kontroll. A Zenith Controls ezt helyesbítő kontrollként foglalja össze, amely a bizalmasságot, sértetlenséget és rendelkezésre állást támogatja, és kapcsolódik a reagálási és helyreállítási koncepciókhoz, az irányításhoz, az eseménykezeléshez és a védelemhez. Tartalmazza a szerepköröket, felelősségeket, eszkalációs útvonalakat, kommunikációs előírásokat, a szabályozói értesítésekre való felkészültséget, a naplózással és felügyelettel való összhangot, az üzletmenet-folytonossággal és katasztrófa utáni helyreállítással való integrációt, az incidens utáni tanulást, valamint az NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 és COBIT 2019 szerinti megfeleltetést.
A Clarysec Incident Response Policy-sme Incident Response Policy-sme - SME az első döntést időkorlátos követelménnyé alakítja:
„Az ügyvezetőnek az IT-szolgáltató bevonásával az értesítéstől számított egy órán belül súlyosság szerint osztályoznia kell minden incidenst.”
A „Irányítási követelmények” szakasz 5.3.1 szabályzati pontjából.
Ez az egyórás besorolás támogatja azt az operatív fegyelmet, amely az NIS2 24 órás korai figyelmeztetési elemzéséhez, a GDPR szerinti személyesadat-sértési értékeléshez, a DORA szerinti ügyféleszkalációhoz és a szerződéses értesítési triázshoz szükséges.
Egy szolgáltató incidensdöntési fájának négy kérdésre kell választ adnia:
- Megerősített vagy feltételezett kompromittálódás történt a bizalmasság, a sértetlenség vagy a rendelkezésre állás tekintetében?
- Az esemény érinti a szolgáltatásnyújtást, az ügyfélkörnyezeteket, a szabályozott ügyfeleket, a személyes adatokat vagy a kritikus funkciókat?
- Okozhat súlyos működési zavart, pénzügyi veszteséget vagy vagyoni, illetve nem vagyoni kárt?
- Mely értesítési kötelezettségek alkalmazandók: NIS2, GDPR, DORA szerinti ügyfélkötelezettségek, szerződéses SLA-k vagy nemzeti szabályozó hatósági elvárások?
A döntési fát valós incidens előtt asztali gyakorlatokon kell tesztelni.
Sérülékenységkezelés: a hatás előtt igazolni kell a kockázatcsökkentést
Az NIS2 előírja a sérülékenységek kezelését és feltárását. Az ügyfelek és a szabályozó hatóságok számára a sérülékenységkezelés az egyik legkönnyebben mérhető kontrollterület, mert egyértelmű bizonyítékokat állít elő: vizsgálati lefedettséget, javítási határidőket, kivétel-jóváhagyásokat, kihasznált sérülékenységek elemzését és helyesbítő intézkedési bejegyzéseket.
Az ISO/IEC 27001:2022 A mellékletének 8.8 kontrollját, a technikai sérülékenységek kezelését, a Zenith Controls megelőző kontrollként foglalja össze a bizalmasság, sértetlenség és rendelkezésre állás teljes körében, az azonosítás és védelem, a fenyegetés- és sérülékenységkezelés, az irányítás, az ökoszisztéma, a védelem és az elhárítás témáihoz kapcsolva. Tartalmazza a sérülékenységek azonosítását, értékelését, priorizálását, a javítások telepítését, a kompenzáló kontrollokat, a fenyegetettségi információk integrációját, a sérülékenységek feltárását, a felhő- és alkalmazássérülékenységi felelősségeket, az auditbizonyítékokat és a helyesbítési határidőket.
A Clarysec vállalati Sérülékenység- és javításkezelési szabályzata Sérülékenység- és javításkezelési szabályzat konkrét, auditálható modellt ad az auditoroknak:
„A szervezetnek minden észlelt sérülékenységet szabványos módszertannal (pl. CVSS v3.x) kell besorolnia, és az üzletmenet-kritikussággal összhangban álló helyesbítési határidőket kell alkalmaznia: 5.2.1 Kritikus (CVSS 9.0–10.0): azonnali felülvizsgálat; a javítás telepítésének határideje legfeljebb 72 óra. 5.2.2 Magas (7.0–8.9): reagálás 48 órán belül; a javítás telepítésének határideje 7 naptári nap. 5.2.3 Közepes (4.0–6.9): reagálás 5 napon belül; a javítás telepítésének határideje 30 naptári nap. 5.2.4 Alacsony (<4.0): reagálás 10 napon belül; a javítás telepítésének határideje 60 naptári nap.”
A „Irányítási követelmények” szakasz 5.2 szabályzati pontjából.
Felhőszolgáltató esetében ennek le kell fednie a hipervizor-komponenseket, a konténerképeket, az orchestrációs rétegeket, az ügyféloldali API-kat, a CI/CD pipeline-okat, az adminisztrációs konzolokat és a harmadik féltől származó könyvtárakat. MSP esetében a kulcskérdés az, hogy a belső sérülékenységek elkülönülnek-e az ügyfél által kezelt sérülékenységektől, és hogy a szerződések meghatározzák-e a felelősséget. Adatközpont-szolgáltató esetében a hatókörbe tartozhatnak az épületfelügyeleti rendszerek, a hozzáférés-szabályozási rendszerek, a monitorozási platformok, a távoli helyszíni támogatási eszközök és a hálózati infrastruktúra.
A megosztott felelősségi modellt dokumentálni kell. Egy szolgáltató nem feltétlenül tulajdonosa minden javításnak, de a kockázatot akkor is kezelnie kell, szükség esetén értesítenie kell az ügyfelet, és igazolnia kell, hogy a felelősségi határok tisztázottak.
A naplózás, a felügyelet és a szegmentálás teszi kivizsgálhatóvá az incidenseket
Amikor egy szolgáltatói incidens ügyfélhatásúvá válik, az első bizonyítékkérdések egyszerűek: ki jelentkezett be, honnan, milyen jogosultsággal, melyik bérlői környezetbe, mi változott, milyen naplók állnak rendelkezésre, és szegmentáltak voltak-e az adminisztratív útvonalak.
A Clarysec vállalati Naplózási és felügyeleti szabályzata Naplózási és felügyeleti szabályzat előírja, hogy a hatály alá tartozó rendszerek állítsák elő a reagálók és auditorok számára szükséges naplókat:
„Minden hatály alá tartozó rendszernek olyan naplókat kell előállítania, amelyek rögzítik: 6.1.1.1 Felhasználói hitelesítési és hozzáférési kísérletek 6.1.1.2 Kiemelt jogosultságú felhasználói tevékenységek 6.1.1.3 Konfigurációváltozások 6.1.1.4 Sikertelen hozzáférési kísérletek vagy rendszeresemények 6.1.1.5 Malware-észlelések és biztonsági riasztások 6.1.1.6 Külső kommunikációk és tűzfalszabály-kiváltások”
A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1 szabályzati pontjából.
A külső szolgáltatókra támaszkodó KKV-k számára a Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME szerződéses követelményt ad hozzá:
„A szerződéseknek elő kell írniuk, hogy a szolgáltatók legalább 12 hónapig megőrizzék a naplókat, és kérésre hozzáférést biztosítsanak azokhoz.”
A „Irányítási követelmények” szakasz 5.5.1.3 szabályzati pontjából.
A szegmentálás ugyanilyen fontos. A Network Security Policy-sme Network Security Policy-sme - SME kimondja:
„A belső hálózatokat funkció szerint kell szegmentálni (pl. pénzügy, vendéghálózat, IoT, adminisztratív rendszerek).”
A „A szabályzat végrehajtásának követelményei” szakasz 6.2.1 szabályzati pontjából.
A Zenith Blueprint „Kontrollok működés közben” fázisának 20. lépése gyakorlati audit eljárást ad a hálózati architektúrához és szegmentáláshoz. A csapatokat arra utasítja, hogy vizsgálják felül és dokumentálják a hálózati topológiai információkat, ellenőrizzék a tűzfalszabályokat, az IPS/IDS és távoli hozzáférési konfigurációkat, erősítsék meg, hogy a felhőbiztonsági csoportok és a VPC- vagy alhálózati szabályok megfelelnek a tervezett architektúrának, sorolják fel a belső és külső hálózati szolgáltatásokat, és ellenőrizzék, hogy az érzékeny rendszerek nem érhetők el általános felhasználói VLAN-okból vagy vendéghálózatokból.
Egy MSP esetében a távoli felügyeleti eszközök nem helyezkedhetnek el lapos irodai hálózaton. Egy adatközpont-szolgáltató esetében az energiaellátás, a hűtés, a hozzáférés-szabályozás és az ügyfélhálózati szolgáltatások felügyeleti interfészeit el kell különíteni és felügyelni kell. Egy felhőszolgáltató esetében a vezérlősíkhoz való hozzáférést identitás-, hálózati, eszközállapot- és kiemelt jogosultságú munkafolyamat-kontrollokkal kell korlátozni.
Beszállítói biztonság: a szolgáltató maga is ügyfél
A felhő-, MSP-, MSSP- és adatközpont-szolgáltatók beszállítók a szabályozott ügyfelek számára, de egyben szoftverbeszállítók, távközlési szolgáltatók, identitásszolgáltatók, SaaS-platformok, hardverbeszállítók, alvállalkozók és infrastruktúra-üzemeltetők ügyfelei is.
Az NIS2 az ellátási lánc biztonságát alapkövetelménnyé teszi. A DORA, amely 2025. január 17-től alkalmazandó, központi követelménnyé teszi az IKT-harmadikfél-kockázatkezelést a pénzügyi szervezetek számára. Az NIS2 Article 4 és Recital 28 elismeri a DORA-t ágazatspecifikus uniós jogi aktusként a pénzügyi szervezetek esetében ott, ahol a követelmények átfednek. Ez nem csökkenti a felhő- és MSP-szolgáltatókra nehezedő nyomást. Éppen növeli, mert a pénzügyi ügyfelek DORA-szintű szerződéses követelményeket, auditálási jogot, rezilienciatesztelést, kilépési stratégiákat és incidensjelentési elvárásokat építenek be a beszállítói szerződésekbe.
A Clarysec vállalati Third party and supplier security policy Third party and supplier security policy szabályozott harmadik fél hozzáférést ír elő:
„Minden harmadik fél hozzáférését naplózni és felügyelni kell, és ahol megvalósítható, ugrószervereken, VPN-eken vagy Zero Trust átjárókon keresztül kell szegmentálni.”
A „A szabályzat végrehajtásának követelményei” szakasz 6.3.2 szabályzati pontjából.
A Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME közvetlenül fogalmazza meg a legkisebb jogosultság elvét:
„A beszállítók csak azokhoz a minimálisan szükséges rendszerekhez és adatokhoz kaphatnak hozzáférést, amelyek feladatuk ellátásához szükségesek.”
A „A szabályzat végrehajtásának követelményei” szakasz 6.2.1 szabályzati pontjából.
Ezek a pontok természetesen megfeleltethetők az ISO/IEC 27001:2022 A mellékletének 5.19, 5.20, 5.21 és 5.22 kontrolljainak. Támogatják továbbá a GDPR szerinti adatfeldolgozói és al-adatfeldolgozói irányítást, a DORA szerinti harmadikfél-kockázati felülvizsgálatokat és az ügyféloldali auditkérdőíveket.
Üzletmenet-folytonosság és adatközponti reziliencia: a feltételezéseket igazolni kell
Az NIS2 Article 21 magában foglalja az üzletmenet-folytonosságot, a biztonsági mentések kezelését, a katasztrófa utáni helyreállítást és a válságkezelést. A DORA Articles 11 to 14 IKT üzletmenet-folytonossági szabályzatokat, reagálási és helyreállítási terveket, üzleti hatásvizsgálatot, biztonsági mentési szabályzatokat, helyreállítási eljárásokat, helyreállítási célokat, tesztelést, incidens utáni felülvizsgálatokat és válságkommunikációt ír elő a pénzügyi szervezetek számára.
Felhő- és adatközpont-szolgáltatóknál a folytonosság nem egy iratgyűjtő. Architektúrát, kapacitást, szerződéseket, függőségeket, helyreállítási bizonyítékokat és tesztelt feltételezéseket jelent.
A Clarysec vállalati Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzata Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat éves BIA-t és jelentős változások utáni felülvizsgálatot ír elő:
„Az üzleti hatásvizsgálatot (BIA) legalább évente el kell végezni minden kritikus üzleti egységre, és felül kell vizsgálni a rendszerekben, folyamatokban vagy függőségekben bekövetkező jelentős változások esetén. A BIA-kimeneteknek meg kell határozniuk: 5.2.1. Legnagyobb tolerálható kiesési idő (MTD) 5.2.2. Helyreállítási időcélok (RTO-k) 5.2.3. Helyreállítási pont célértékek (RPO-k) 5.2.4. Kritikus függőségek (rendszerek, beszállítók, személyzet)”
A „Irányítási követelmények” szakasz 5.2 szabályzati pontjából.
Adatközponti forgatókönyvben a BIA-nak le kell fednie az áramellátási betáplálásokat, UPS-eket, generátorokat, üzemanyag-szerződéseket, hűtést, tűzoltást, hálózati szolgáltatókat, fizikai hozzáférési rendszereket, távoli helyszíni támogatást, monitorozást, tartalék hardvereket és ügyfélkommunikációs csatornákat. Felhőforgatókönyvben le kell fednie a régiókat, rendelkezésre állási zónákat, replikációt, biztonsági mentések módosíthatatlanságát, identitásfüggőségeket, DNS-t, hitelesítésszolgáltatókat, API-átjárókat és támogatási rendszereket. MSP-forgatókönyvben le kell fednie a távoli felügyeleti eszközöket, a kiemelt jogosultságú hozzáférési páncéltermeket, az EDR-konzolokat, a jegykezelést, a dokumentumtárakat és a vészhelyzeti kommunikációt.
Az ISO 22301 erősítheti az üzletmenet-folytonossági irányítási fegyelmet, míg az ISO/IEC 27005:2022 támogatja a kockázati kritériumokat, a kezelési tervezést, a felügyeletet, a bizonyítékokat és a folyamatos fejlesztést. Ez azért hasznos, mert az NIS2-re való felkészültség megköveteli, hogy a szervezet a jogi, szerződéses, operatív, beszállítói, technológiai, pénzügyi, folyamati és emberi tényezőket egyetlen kockázatkezelési folyamatba konszolidálja.
Gyakorlati kockázati visszakövetés egy MSP távoli hozzáférési incidenséhez
Egy gyakorlati workshop egyetlen forgatókönyvvel kezdődhet:
„A kiemelt jogosultságú távoli hozzáférés kompromittálódása jogosulatlan hozzáférést eredményez az ügyfélrendszerekhez, szolgáltatáskimaradást okoz, lehetséges személyesadat-kitettséggel és szabályozói értesítési kötelezettségekkel jár.”
Hozzon létre egy sort a kockázati nyilvántartásban, és töltse ki a visszakövetést.
| Mező | Példabejegyzés |
|---|---|
| Kockázatgazda | Menedzselt szolgáltatások vezetője |
| Eszközök és folyamatok | Távoli felügyeleti platform, ügyfél-adminisztrátori fiókok, kiemelt jogosultságú hozzáférési páncélterem, jegykezelés, SIEM, ügyfélkörnyezetek |
| Fenyegetési esemény | Hitelesítő adatok ellopása, MFA fatigue, tokenlopás, kihasznált RMM-sérülékenység, rosszindulatú belső szereplő |
| Hatás | Ügyfél kompromittálódása, szolgáltatáskimaradás, szerződésszegés, NIS2 szerinti jelentős incidens, GDPR szerinti személyesadat-sértés, DORA szerinti ügyféleszkaláció |
| Meglévő kontrollok | MFA, PAM, legkisebb jogosultság elve, szegmentálás, naplózás, sérülékenységvizsgálat, incidensreagálási terv |
| Szükséges kezelés | Feltételes hozzáférés szigorítása, just-in-time adminisztrátori hozzáférés kikényszerítése, bérlői környezetek elkülönítésének javítása, naplómegőrzés növelése, értesítési forgatókönyv tesztelése |
| ISO/IEC 27001:2022 bizonyíték | Kockázatértékelés, SoA, hozzáférési felülvizsgálat, naplóminták, sérülékenységi jelentések, asztali gyakorlat, vezetőségi átvizsgálás |
| NIS2-megfeleltetés | Article 21 kockázatkezelés és Article 23 incidensjelentés, valamint a végrehajtási rendelet operatív intézkedései |
| Ügyfélmegfeleltetés | Szerződéses értesítés, auditálási jog, biztonsági melléklet, DORA-val összhangban álló kérdőívek, ahol alkalmazandó |
| Maradványkockázati döntés | A kockázatgazda a kezelés után elfogadta, negyedévente felülvizsgálva |
Ezután frissíteni kell az alkalmazhatósági nyilatkozatot. Minden releváns A melléklet szerinti kontrollnál magyarázza el, miért alkalmazandó, és mely NIS2-témát támogatja. Végül gyűjtse össze az audit előtti bizonyítékokat: MFA-kikényszerítési jelentések, kiemelt jogosultságú fióklisták, naplómegőrzési beállítások, RMM javításkezelési állapot, SIEM-riasztások, incidensbesorolási bejegyzések, beszállítói hozzáférés-jóváhagyások és asztali gyakorlatok eredményei.
Hogyan tesztelik a különböző auditorok ugyanazt a kontrollkörnyezetet
Egy integrált IBIR-nek különböző bizonyossági nézőpontokat kell kiszolgálnia anélkül, hogy minden keretrendszerhez külön bizonyítékcsomagot hozna létre.
| Auditori nézőpont | Mire fókuszálnak | Tipikusan kért bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Az NIS2, DORA és GDPR követelményei megjelennek-e a kontextusban, a hatókörben, a kockázatértékelésben, az SoA-ban, a belső auditban és a vezetőségi átvizsgálásban | IBIR alkalmazási területe, érdekelt felek nyilvántartása, kockázati módszertan, kockázati nyilvántartás, SoA, kezelési terv, szabályzatok, belső auditjelentés, vezetőségi átvizsgálás |
| NIS2 illetékes hatóság vagy megbízott értékelő | A kiberbiztonsági kockázatkezelési intézkedések megfelelőek és arányosak-e, valamint a jelentős incidensek jelentése operatívan működik-e | NIS2-megfeleltetés, incidensbesorolási eljárás, 24 és 72 órás munkafolyamat, igazgatósági felügyelet, technikai kontrollbizonyítékok, beszállítói biztonsági bizonyítékok |
| DORA ügyféloldali értékelő | Az IKT-harmadikfél-kockázat, a rezilienciatesztelés, az incidensjelentés, az auditálási jog és a kilépési tervezés megfelel-e a pénzügyi szektori elvárásoknak | Szerződéses kikötések, alvállalkozói nyilvántartás, rezilienciatesztek, incidens-SLA-k, kilépési terv, auditjelentések, koncentrációs kockázati támogatás |
| GDPR auditor vagy DPO-felülvizsgálat | A személyesadat-sértési kockázatot, az adatfeldolgozói kötelezettségeket, a bizalmasságot, a sértetlenséget és az elszámoltathatóságot kezelték-e | Adatkezelési tevékenységek nyilvántartása, DPA-feltételek, adatsértés-értékelési munkafolyamat, hozzáférési naplók, titkosítási bizonyítékok, megőrzési és törlési kontrollok |
| NIST-orientált értékelő | Az azonosítási, védelmi, észlelési, reagálási és helyreállítási képességek bevezetettek és mértek-e | Eszköznyilvántartás, hozzáférés-szabályozás, sérülékenységi adatok, SIEM-lefedettség, reagálási forgatókönyvek, helyreállítási tesztek, mutatók |
| COBIT 2019 vagy ISACA auditor | Létrejöttek-e az irányítási célkitűzések, felelősségek, kockázattulajdonosi felelősség, kontrollfelügyelet és bizonyossági folyamatok | Irányítási charták, RACI, kockázatvállalási hajlandóság, kontrolltulajdonosi felelősség, KPI/KRI-jelentés, bizonyossági terv, helyesbítő intézkedések nyomon követése |
Itt segít a Zenith Controls keresztmegfelelési útmutatóként. Az olyan kontrolloknál, mint az 5.23, 5.24 és 8.8, összekapcsolja az ISO/IEC 27001:2022 kontrollvárakozásait az NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF és ISO 22301 témáival. A cél nem külön megfelelési programok létrehozása. A cél egyetlen bizonyítékarchitektúra, amely kontroll, kockázat, szabályozási mozgatórugó és felelős szerint címkézett.
A Clarysec bevezetési mintája
Felhő-, MSP-, MSSP- és adatközpont-szolgáltatók esetében a munkát öt rétegben kell elvégezni.
Először meg kell erősíteni a hatókört. Meg kell határozni, hogy a szervezet és szolgáltatásai az NIS2 hatálya alá tartoznak-e, mely tagállami szabályok alkalmazandók, a 2024/2690 végrehajtási rendelet alkalmazandó-e a szolgáltatói kategóriára, és az ügyfelek előírnak-e DORA, GDPR, NIST vagy ágazatspecifikus kötelezettségeket.
Másodszor fel kell építeni az IBIR kontextusát. Az ISO/IEC 27001:2022 4. és 5. pontja alapján azonosítani kell az érdekelt feleket, a jogi kötelezettségeket, az ügyfélvállalásokat, a beszállítói függőségeket, a szolgáltatáshatárokat és a vezetői felelősségeket.
Harmadszor kockázatértékelést és kockázatkezelést kell végezni az ISO/IEC 27005:2022 elvei alapján. Az NIS2, DORA, GDPR, szerződések, belső szabályzatok és szolgáltatási kockázatok követelményeit egyetlen előírt alapkövetelmény-nyilvántartásba kell konszolidálni. Meg kell határozni a kockázati kritériumokat, gazdákat, valószínűséget, hatást, kezelési lehetőségeket, kontrollválasztásokat és maradványkockázat-jóváhagyásokat.
Negyedszer a kontrollokat be kell térképezni az alkalmazhatósági nyilatkozatba. A Zenith Blueprint 13. és 14. lépésével visszakövetést kell létrehozni a kockázatoktól az A melléklet szerinti kontrollokig és a szabályozási elvárásokig. A Zenith Controls segítségével meg kell érteni, hogyan feleltethetők meg az olyan kontrollok, mint az 5.23, 5.24, 8.8, 5.20 és 5.30 a különböző keretrendszerek és auditori nézőpontok között.
Ötödször működésbe kell helyezni a bizonyítékokat. A szabályzatok önmagukban nem elegendők. A Clarysec szabályzattára kikényszeríthető követelményeket ad a felhőhasználat jóváhagyására, a beszállítói hozzáférésre, a naplózásra, a sérülékenységek helyesbítésére, a hálózati szegmentálásra, az incidensbesorolásra és a folytonossági tervezésre. A bizonyítékcsomag igazolja, hogy ezek a követelmények működnek.
Következő lépés: az NIS2-nyomás átalakítása auditra felkészült rezilienciává
Az NIS2 2024/2690 végrehajtási rendelete nem káoszt követel. Visszakövethetőséget, felelősségi köröket és bizonyítékot követel.
Ha Ön felhőszolgáltató, MSP, MSSP vagy adatközpont-üzemeltető, kezdje a szolgáltatásaival, ügyfeleivel, függőségeivel, incidensforgatókönyveivel és bizonyítékkötelezettségeivel. Ezután végezzen strukturált NIS2–ISO/IEC 27001:2022 megfeleltetési gyakorlatot:
- Erősítse meg, hogy a szervezet és a szolgáltatások a hatály alá tartoznak-e.
- Térképezze be az NIS2 és a végrehajtási rendelet témáit az IBIR alkalmazási területébe.
- Frissítse a kockázati nyilvántartást és az alkalmazhatósági nyilatkozatot.
- Alkalmazza a Clarysec szabályzatait a felhőhasználatra, a beszállítói biztonságra, a naplózásra, a sérülékenységkezelésre, az incidensreagálásra, a hálózatbiztonságra és a folytonosságra.
- Használja a Zenith Blueprint Zenith Blueprint 13., 14., 20. és 23. lépését a visszakövethetőség és a működési bizonyítékok létrehozására.
- Használja a Zenith Controls Zenith Controls útmutatót az ISO/IEC 27001:2022 kontrollok NIS2, DORA, GDPR, NIST és COBIT 2019 elvárásokkal való keresztmegfeleltetéséhez.
- Tesztelje a bizonyítékokat auditszimulációval, mielőtt egy ügyfél, szabályozó hatóság vagy tanúsító auditor bekéri őket.
A Clarysec segíthet túllépni az ellenőrzőlista-alapú megfelelésen, és olyan integrált IBIR-t kialakítani, amely ellenáll az NIS2, DORA, GDPR és ügyfélauditok nyomásának. Töltse le a releváns Clarysec eszközkészleteket, foglaljon megfeleltetési workshopot, vagy kérjen auditra való felkészültségi értékelést, hogy a szabályozási komplexitást igazolható biztonsági irányítássá és operatív rezilienciává alakítsa.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
