NIS2 beszállítói szerződések ISO 27001 szerinti bizonyítékokkal

Hétfő reggel 07:40 van. Egy felhőalapú logisztikai platform CISO-ja e-mailt nyit meg egy menedzselt észlelési és reagálási szolgáltatást nyújtó beszállítótól. Az üzenet rövid, óvatos és kellemetlen: a beszállító gyanús hozzáférést észlelt egy több ügyfél által használt támogatási környezetben. A részletek korlátozottak. A beszállító frissítést ígér „amint az gyakorlatilag lehetséges”.

08:15-kor a megfelelőségi vezető már azt kérdezi, kiválthat-e ez NIS2 szerinti jelentéstételt. 08:40-kor a beszerzés a szerződést keresi. 09:10-kor az igazgatósági titkár vezetői elszámoltathatóságról szóló tájékoztatót kér. 10:00-kor a jogi terület azt kérdezi, tartalmaz-e a szerződés 24 órás értesítést, auditálási jogot, alvállalkozói kontrollokat, bizonyíték-hozzáférést, üzletmenet-folytonossági kötelezettségeket, adatvisszaadási és törlési rendelkezéseket.

Senki sem szeretné éles incidens közben felfedezni, hogy egy kritikus beszállítói megállapodás mindössze „észszerű biztonsági intézkedéseket” említ.

Itt válnak a NIS2 beszállítói szerződéses záradékai jogi sablonszövegből operatív kontrollokká. Az alapvető és fontos szervezetek esetében a beszállítói irányítás ma már az igazgatósági elszámoltathatóság, a felügyeleti bizonyítékok, az incidensre való felkészültség, az ügyfélbizonyosság, az adatvédelmi megfelelés és a rezilienciatervezés része. Az aláírt szerződés önmagában nem elegendő. A szervezetnek bizonyítania kell, hogy a beszállítói kockázatokat azonosította, jóváhagyta, kezelte, nyomon követi és bizonyítékokkal alátámasztja.

A Clarysec megközelítése egyszerű alapelvből indul ki: ha egy beszállítói záradék nem monitorozható, nem bizonyítható és nem tesztelhető, akkor nem kontroll.

A Zenith Blueprint: auditori 30 lépéses ütemterv a beszállítói kapcsolatokat a „Controls in Action” fázis 23. lépésébe helyezi, ahol a megállapodások, a monitorozás, a beléptetés, az újraértékelés és az auditbizonyíték gyakorlati IBIR-tevékenységekké alakulnak. A Zenith Controls: megfelelőségi keretrendszerek közötti útmutató ezt követően az ISO/IEC 27002:2022 beszállítói kontrolljait megfelelteti a NIS2, DORA, GDPR, NIST, COBIT 2019, a támogató ISO-szabványok és az auditmódszertanok követelményeinek.

Az eredmény olyan beszállítói irányítási modell, amelyet a beszerzés, a jogi terület, a biztonsági terület, az adatvédelem és az igazgatóság egyaránt használni tud.

Miért alakítja a NIS2 a beszállítói szerződéseket bizonyítékként szolgáló feljegyzésekké

A NIS2 Article 20 előírja, hogy az alapvető és fontos szervezetek vezető testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását, és felelősséggel tartozzanak a jogsértésekért. 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 és karbantartást, az eredményesség értékelését, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést és adott esetben az MFA-t.

Az Article 21(3) kifejezetten megjeleníti a beszállítói kellő gondosságot. A szervezeteknek figyelembe kell venniük a közvetlen beszállítókra és szolgáltatókra jellemző sérülékenységeket, a termékek általános minőségét és kiberbiztonsági gyakorlatát, valamint a biztonságos fejlesztési eljárásokat.

Ez a megfogalmazás gyakorlati kötelezettséget teremt: a beszállítói kapcsolatoknak kockázatalapúnak, szerződésben érvényesíthetőnek és felülvizsgálhatónak kell lenniük. Egy mappában tárolt beszállítói kérdőív nem elegendő. Egy általános szerződés incidenshatáridő, bizonyíték-hozzáférési jog és alvállalkozói átláthatóság nélkül nem elegendő. Egy olyan beszállítói tanúsítás, amelyet senki nem vizsgált felül, nem elegendő.

Az ISO/IEC 27001:2022 biztosítja a működési modellt. A 4.1–4.4 pontok előírják a szervezet számára a kontextus, az érdekelt felek, a jogi és szerződéses kötelezettségek, az IBIR alkalmazási területe és a függőségek megértését. Az 5.1–5.3 pontok vezetést, szabályzatot, szerepköröket és jelentéstételt írnak elő. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést és alkalmazhatósági nyilatkozatot írnak elő. A 8.1–8.3 pontok operatív kontrollt, ismételt kockázatértékeléseket és dokumentált eredményeket követelnek meg.

A beszállítói irányítás szempontjából a legfontosabb ISO/IEC 27002:2022 A melléklet szerinti kontrollok a következők:

• A.5.19 Információbiztonság a beszállítói kapcsolatokban
• A.5.20 Az információbiztonság kezelése a beszállítói megállapodásokban
• A.5.21 Információbiztonság kezelése az IKT-ellátási láncban
• A.5.22 A beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése
• A.5.24 Incidenskezelés tervezése és előkészítése
• A.5.25 Információbiztonsági események értékelése és döntéshozatal
• A.5.26 Reagálás információbiztonsági incidensekre
• A.5.27 Tanulás az információbiztonsági incidensekből
• A.5.28 Bizonyítékok gyűjtése
• A.5.29 Információbiztonság zavarhelyzetben
• A.5.30 IKT-felkészültség az üzletmenet-folytonosságra
• A.5.31 Jogi, törvényi, szabályozási és szerződéses követelmények
• A.5.34 A magánszféra és a PII védelme
• A.8.8 Technikai sérülékenységek kezelése
• A.8.13 Információk biztonsági mentése
• A.8.15 Naplózás
• A.8.16 Monitorozási tevékenységek
• A.8.24 Kriptográfia használata
• A.8.32 Változáskezelés

A lényeg a tulajdonosi felelősség. Egy záradék értéke csekély, ha nincs, aki a kockázatért felel, aki a bizonyítékokat felülvizsgálja, aki a kivételeket nyomon követi, és aki a meg nem felelést eszkalálja.

Az Enterprise Harmadik fél és beszállítói biztonsági szabályzat ezt egyértelművé teszi:

„Auditálási, ellenőrzési és biztonsági bizonyítékok bekérésére vonatkozó jogok”

Az „Irányítási követelmények” szakasz 5.3.4 szabályzati záradékából.

A KKV-k számára készült Harmadik fél és beszállítói biztonsági szabályzat-sme ugyanezt a gyakorlati elvárást rögzíti:

„Auditálási jogok vagy megfelelési bizonyítékok rendelkezésre állása”

Az „Irányítási követelmények” szakasz 5.3.4 szabályzati záradékából.

Ez a különbség lényeges. Egy kisebb szervezet nem feltétlenül képes minden jelentős felhőszolgáltatót helyszínen auditálni, de előírhat hozzáférést a bizonyossági bizonyítékokhoz, például az ISO/IEC 27001:2022 tanúsítás alkalmazási területéhez, SOC-jelentésekhez, penetrációs tesztelési összefoglalókhoz, sérülékenység-helyesbítési nyilatkozatokhoz, incidens-összefoglalókhoz, üzletmenet-folytonossági tesztjelentésekhez és adattörlési igazolásokhoz.

A NIS2 beszállítói bizonyosság három kontrollból álló gerince

A Clarysec megfelelőségi keretrendszerek közötti modelljében három ISO/IEC 27002:2022 kontroll alkotja a NIS2 beszállítói irányítás gerincét: 5.19, 5.20 és 5.22.

Az A.5.19 azonosítja a beszállítói kockázatot

Az A.5.19, Információbiztonság a beszállítói kapcsolatokban kontroll az alap. Megköveteli, hogy a szervezetek védjék azokat az információkat és eszközöket, amelyekhez a beszállítók hozzáférnek, amelyeket feldolgoznak, tárolnak vagy kezelnek.

A Zenith Controls ezt megelőző kontrollként sorolja be, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást fedi le, a „Identify” kiberbiztonsági koncepcióval és a „Supplier Relationships Security” operatív képességgel. Az A.5.19-et összekapcsolja az A.5.20, A.5.21, A.5.14, A.5.36 és A.5.10 kontrollokkal. Gyakorlati értelemben a szervezet azonosítja a beszállítói kockázatot, meghatározza a biztonsági elvárásokat, kontrollálja az IKT-ellátási lánc kitettségét, védi az információátvitelt, nyomon követi a megfelelést, és az elfogadható használati kötelezettségeket kiterjeszti a külső felekre.

A NIS2 esetében ez közvetlenül megfeleltethető az Article 21(2)(d) szerinti ellátási lánc biztonságának és az Article 21(3) szerinti beszállítói kellő gondosságnak. A GDPR esetében támogatja azt a követelményt, hogy az adatkezelők megfelelő garanciákat nyújtó adatfeldolgozókat vegyenek igénybe. A DORA esetében támogatja az IKT-harmadik fél kockázatkezelést, a szerződéskötés előtti kellő gondosságot, a kritikussági felülvizsgálatot, a koncentrációs kockázatot és az életciklus-felügyeletet.

Az A.5.20 érvényesíthetővé teszi a követelményt

Az A.5.20, Az információbiztonság kezelése a beszállítói megállapodásokban kontroll a biztonsági elvárásokat szerződéses kötelezettségekké alakítja. A Zenith Controls egyértelműen írja le az A.5.19 és az A.5.20 kapcsolatát:

„Az 5.20 az 5.19 alatt azonosított biztonsági igények és kockázatok szerződéses formalizálását szolgálja. Míg az 5.19 a harmadik felek kockázatainak értékelését és a biztonsági elvárások meghatározását foglalja magában, az 5.20 biztosítja, hogy ezek az elvárások szerződések vagy szolgáltatási szint megállapodások (SLA-k) útján jogilag kötelezőek legyenek. Az 5.20 nélkül az 5.19-ben azonosított biztonsági intézkedések érvényesíthetősége hiányozna.”

Itt válnak a NIS2 kockázati döntések záradékokká: adatsértési értesítés, auditálási és bizonyíték-hozzáférési jogok, titkosítás, hozzáférés-szabályozás, sérülékenységkezelés, alvállalkozói jóváhagyás, biztonságos átvitel, folytonosság, szabályozói együttműködés, kilépési támogatás és adattörlés.

Az A.5.22 bizonyítja, hogy a szerződés élő kontroll

Az A.5.22, A beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése kontroll megakadályozza, hogy a beszállítói bizonyosság egyszeri beléptetési gyakorlattá váljon. A Zenith Controls az A.5.22-t az A.5.19 és A.5.20 kontrollokhoz köti, de emellett az A.5.29 zavarhelyzet alatti információbiztonsághoz, az A.8.8 technikai sérülékenységek kezeléséhez, az A.5.36 információbiztonsági szabályzatoknak, szabályoknak és szabványoknak való megfeleléshez, az A.5.15 hozzáférés-szabályozáshoz és az A.8.27 biztonságos rendszerarchitektúra- és mérnöki elvekhez is.

Ez azért fontos, mert a beszállítói szolgáltatások változnak. Az adatok helye változik. Az al-adatfeldolgozók változnak. Sérülékenységek jelennek meg. A tanúsítások lejárnak. Incidensmintázatok rajzolódnak ki. Egy tavaly még elfogadható beszállító ma már túl kockázatos lehet.

Mit kell tartalmazniuk a NIS2 beszállítói szerződéses záradékainak

A Zenith Blueprint „Controls in Action” fázisának 23. lépése gyakorlati beszállítói megállapodási területeket ad meg:

„A beszállítói megállapodásokban jellemzően kezelt fő területek:

✓ Titoktartási kötelezettségek, beleértve a hatályt, az időtartamot és a harmadik félnek történő adatközlés korlátozásait; ✓ Hozzáférés-szabályozási felelősségek, például hogy ki férhet hozzá az adataihoz, hogyan kezelik a hitelesítő adatokat, és milyen monitorozás működik; ✓ Technikai és szervezeti intézkedések az adatvédelemre, titkosításra, biztonságos továbbításra, biztonsági mentésre és rendelkezésre állási vállalásokra; ✓ Incidensjelentési határidők és eljárások, gyakran meghatározott időkeretekkel (pl. „24 órán belüli értesítés”); ✓ Auditálási jog, beleértve a gyakoriságot, a hatályt és a releváns bizonyítékokhoz való hozzáférést (pl. penetrációs tesztjelentések, SoA, tanúsítások); ✓ Alvállalkozói kontrollok, amelyek előírják, hogy a beszállító egyenértékű biztonsági kötelezettségeket adjon tovább saját downstream partnereinek; ✓ Szerződés megszűnésére vonatkozó rendelkezések, például adatvisszaadás vagy megsemmisítés, eszközvisszaszerzés és fiókok deaktiválása.”

A „Controls in Action” fázis 23. lépéséből: szervezeti kontrollok.

Egy erős NIS2 beszállítói záradék kellően konkrét ahhoz, hogy tesztelhető legyen. A „A beszállító megfelelő biztonságot tart fenn” megfogalmazás gyenge. A „A beszállító a megerősített vagy gyanított, ügyfélrendszereket, ügyféladatokat, szolgáltatás-rendelkezésre állást vagy szabályozói jelentéstételi kötelezettségeket érintő incidensekről 24 órán belül értesíti az ügyfél biztonsági kapcsolattartóját” megfogalmazás auditálható.

Az incidenszáradékoknak illeszkedniük kell a NIS2 jelentéstételi határidőihez

A NIS2 Article 23 több szakaszból álló jelentéstételi modellt hoz létre jelentős incidensekre: korai figyelmeztetés a tudomásszerzéstől számított 24 órán belül, incidensbejelentés 72 órán belül, közbenső jelentések kérés esetén, valamint végső jelentés az incidensbejelentéstől számított egy hónapon belül. Jelentős incidens az, amely súlyos működési zavart, pénzügyi veszteséget vagy mások számára jelentős vagyoni vagy nem vagyoni kárt okozott, illetve ilyen hatás kiváltására alkalmas.

A beszállítói szerződéseknek támogatniuk kell ezt az ütemezést. Ha egy kritikus menedzselt szolgáltató négy nap alatt erősíti meg, hogy az ügyfélkörnyezetek érintettek-e, az ügyfél elmulaszthatja a saját szabályozói határidejét.

Az Enterprise Harmadik fél és beszállítói biztonsági szabályzat előírja:

„Adatsértési értesítési határidők (pl. 24 vagy 72 órán belül, a kritikusságtól és a szabályozási követelményektől függően)”

Az „Irányítási követelmények” szakasz 5.3.3 szabályzati záradékából.

A KKV Harmadik fél és beszállítói biztonsági szabályzat-sme szintén meghatározott adatsértési értesítési határidőket ír elő az „Irányítási követelmények” szakasz 5.3.3 szabályzati záradékában.

PII-incidensek esetén az Enterprise PII incidens- és adatsértés-kezelési szabályzat összekapcsolja a kiberbiztonsági, pénzügyi szektorbeli, ügyfél- és szolgáltatásigénybevevői jelentéstételt:

„[Feltételes] Az adatvédelmi vezető / PIMS-vezető KÖTELES koordinálni minden szükséges ágazati, kiberbiztonsági, pénzügyi szektorbeli, ügyfél- vagy szolgáltatásigénybevevői incidensjelentést, amikor egy nagy hatású PII-incidens eléri az alkalmazandó jelentéstételi küszöbértéket, továbbá KÖTELES rögzíteni a hatóságot, címzettet, határidőt, benyújtást és tudomásulvételi bizonyítékot a REG01 és REG10 nyilvántartásban.”

Az „Értesítés és kommunikáció” szakasz 4.4.6 szabályzati záradékából.

Ez az érett NIS2 bizonyíték: nem csupán egy értesítő e-mail, hanem a hatóság, címzett, határidő, benyújtás, visszaigazolás, hatás, gyökérok és utánkövetési intézkedések nyilvántartása.

Adatvédelmi és DORA-összhang párhuzamos beszállítói programok nélkül

Sok NIS2 beszállító személyes adatokat is kezel. A GDPR Article 28 előírja, hogy az adatkezelők megfelelő garanciákat nyújtó adatfeldolgozókat vegyenek igénybe, és az adatfeldolgozói kötelezettségeket írásbeli szerződésben határozzák meg. A GDPR Article 5 elszámoltathatóságot követel meg a biztonságos és jogszerű adatkezelés tekintetében. A GDPR adatsértési kötelezettségei gyors együttműködést is megkövetelnek, ha a beszállítói incidensek személyes adatokat érintenek.

Az Enterprise Adatfeldolgozói, al-adatfeldolgozói és harmadik fél adatvédelmi kezelési szabályzat meghatározza a jóváhagyási kaput:

„[Mindkettő] A beszállító / beszerzési felelős KÖTELES biztosítani, hogy az adatfeldolgozói és al-adatfeldolgozói szerződések a jóváhagyás előtt tartalmazzák az adatvédelmi segítségnyújtást, a biztonsági bizonyosságot, a PII15-ön keresztüli incidenskapcsolódási felületet, a PII10 szerinti visszaadást vagy törlést, a PII13 szerinti adattovábbítási kapcsolódást, valamint az auditálási vagy bizonyossági együttműködést.”

A „Szerződéses és dokumentált utasítási kontrollok” szakasz 4.3.6 szabályzati záradékából.

A jóváhagyás előtt bizonyíték-felülvizsgálatot is előír:

„[Valamennyi] Az információbiztonsági vezető KÖTELES a jóváhagyás előtt felülvizsgálni a biztonsági bizonyossági bizonyítékokat minden olyan adatfeldolgozói, al-adatfeldolgozói vagy harmadik féllel fennálló kapcsolat esetében, amely PII-hozzáféréssel vagy -hosztolással jár, és KÖTELES az eredményt a REG08 vagy REG12 nyilvántartásban rögzíteni.”

A „Kellő gondosság és kockázatértékelés” szakasz 4.2.2 szabályzati záradékából.

A DORA további réteget ad, ha a beszállító pénzügyi szervezetet szolgál ki. A DORA Articles 28 to 30 IKT-harmadik fél irányítást, IKT-szolgáltatási szerződések nyilvántartását, kockázatalapú kellő gondosságot, kritikussági értékelést, koncentrációs kockázatelemzést, auditálási és ellenőrzési jogokat, felmondási jogokat, kilépési stratégiákat és kötelező szerződéses rendelkezéseket írnak elő. Az Article 30 különösen releváns, mert olyan szerződéses tartalmat követel meg, amely kiterjed a szolgáltatásleírásokra, helyszínekre, adatvédelemre, hozzáférésre és helyreállításra, szolgáltatási szintekre, incidenshez kapcsolódó segítségnyújtásra, hatóságokkal való együttműködésre, auditálási jogokra, alvállalkozásba adásra, vészhelyzeti intézkedésekre és átállási támogatásra.

A gyakorlati megoldás nem három külön beszállítói program a NIS2, GDPR és DORA számára. A megoldás egy harmonizált beszállítói bizonyítékmodell, amely több keretrendszerre van megfeleltetve.

A NIST CSF 2.0 azért hasznos, mert GOVERN funkciója megköveteli a függőségek, jogi kötelezettségek, szerződéses kötelezettségek, kockázatvállalási hajlandóság, szabályzatok, elszámoltathatóság és felügyelet megértését. Ellátási lánc kategóriája, a GV.SC, lefedi a beszállítói szerepköröket, kritikusságot, szerződéses követelményeket, kellő gondosságot, monitorozást, incidensbevonást, életciklus-monitorozást és a kapcsolat megszűnésére vonatkozó rendelkezéseket.

Clarysec munkafolyamat kritikus beszállító beléptetéséhez

Tegyük fel, hogy egy menedzselt biztonsági szolgáltatót léptet be, amely végponti telemetriát monitoroz, felhasználói azonosítókat tartalmazó riasztásokat fogad, és incidensek elsődleges értékelését támogatja egy NIS2 hatálya alá tartozó szervezetnél.

1. lépés: a beszállító besorolása

Rögzítse a beszállítót a beszállítói nyilvántartásban a szolgáltatásleírással, az elért rendszerekkel és adatokkal, a PII-érintettséggel, az alapvető vagy fontos szolgáltatások támogatásával, az emelt jogosultságú hozzáféréssel, a szolgáltatásnyújtás országaival, alvállalkozókkal, negyedik fél függőségekkel, kritikussági besorolással, kockázatgazdával, beszerzési felelőssel és információbiztonsági felülvizsgálóval.

Ez az ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 és 8.1 pontjait valósítja meg az érdekelt felek követelményeinek, a függőségeknek, a kockázattulajdonosi felelősségnek és az operatív kontrollnak az összekapcsolásával.

2. lépés: a kockázat megfeleltetése a SoA-hoz

A Zenith Blueprint kockázatkezelési fázisának 13. lépésében a Clarysec azt javasolja, hogy a jogszabályokat a kockázati nyilvántartásban vagy a SoA-ban kereszthivatkozásokkal jelöljék:

„Jogszabályok kereszthivatkozása: ha bizonyos kontrollokat kifejezetten a GDPR, NIS2 vagy DORA teljesítése érdekében vezettek be, ezt megjegyezheti a kockázati nyilvántartásban (a kockázati hatás indokolásának részeként) vagy a SoA megjegyzéseiben.”

A kockázatkezelési fázis 13. lépéséből: kockázatkezelési tervezés és alkalmazhatósági nyilatkozat.

Az MSSP esetében legalább az A.5.19, A.5.20, A.5.21, A.5.22, A.5.24–A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 és A.8.24 kontrollokat szerepeltesse.

3. lépés: érvényesíthető záradékok előírása

Alkalmazzon beszállítói biztonsági mellékletet, amely előírja a 24 órás kezdeti incidensbejelentést, a 72 órás részletes frissítést, a végső incidensjelentést, az emelt jogosultságú hozzáféréshez szükséges MFA-t, a névre szóló felhasználói fiókokat, az alvállalkozói kontrollokat, a biztonságos átvitelt, a titkosítást, a bizonyossági bizonyítékokat, a szabályozói együttműködést, a BCP- és DR-bizonyítékokat, a kilépési támogatást, az adatvisszaadást vagy törlést és a hozzáférés-visszavonást.

Az Enterprise Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat biztosítja a folytonossági követelményt:

„Adott esetben követelmény, hogy a beszállító saját üzletmenet-folytonossági terveket (BCP/DRP) és incidenskezelési terveket tartson fenn, ezeket tesztelje, és kérésre összefoglalókat vagy tesztjelentéseket bocsásson rendelkezésünkre.”

A „Végrehajtási követelmények” szakasz 6.8.4 szabályzati záradékából.

4. lépés: a bizonyossági bizonyítékcsomag összeállítása

Jóváhagyás előtt kérje be az aláírt megállapodást, SLA-t, biztonsági mellékletet, az ISO/IEC 27001:2022 tanúsítás alkalmazási területét vagy egyenértékű bizonyosságot, ahol elérhető, a SOC-jelentést, a penetrációs teszt vezetői összefoglalóját, a sérülékenységkezelési összefoglalót, az incidensreagálási eljárás összefoglalóját, a BCP- vagy DR-teszt összefoglalóját, a hozzáférés-szabályozási és MFA-nyilatkozatot, az alvállalkozói listát, az adattörlési és kilépési eljárást, valamint PII kezelése esetén a DPA-t.

A KKV Harmadik fél és beszállítói biztonsági szabályzat-sme mérhetővé teszi az alapvető szerződéses bizonyítékokat:

„Aláírt megállapodások és SLA-k”

A „Betartatás és megfelelés” szakasz 8.3.2.1 szabályzati záradékából.

Emellett az ismétlődő beszállítói bizonyítékokat is azonosítja:

„Érvényes biztonsági tanúsítások vagy frissített kontrollbizonyíték”

„A szabályzat végrehajtásának követelményei” szakasz 6.3.1.2 szabályzati záradékából.

A szélesebb körű beszállítói átvilágítás kapcsán az Audit- és megfelelésfelügyeleti szabályzat kimondja:

„A beszállítói átvilágításnak tartalmaznia kell a tanúsítások (pl. ISO 27001, SOC 2), biztonsági kérdőívek és incidensnyilvántartások felülvizsgálatát.”

5. lépés: kritikusság alapú monitorozás

Az Enterprise Adatfeldolgozói, al-adatfeldolgozói és harmadik fél adatvédelmi kezelési szabályzat negyedéves monitorozást ír elő magas kockázatú PII-kapcsolatokra:

„[Valamennyi] A beszállító / beszerzési felelős KÖTELES az aktív magas kockázatú adatfeldolgozói és al-adatfeldolgozói kapcsolatokat negyedévente, az egyéb aktív PII adatfeldolgozói és al-adatfeldolgozói kapcsolatokat pedig évente monitorozni a REG08 nyilvántartásban szereplő kellő gondossági feltételek, szerződéses státusz, bizonyossági státusz, nyitott ügyek és felülvizsgálati dátumok alapján.”

A „Folyamatos monitorozás, segítségnyújtás, adatközlési interfész és kilépés” szakasz 4.5.1 szabályzati záradékából.

Így válik az A.5.22 valós kontrollá. A felülvizsgálatnak meg kell állapítania, hogy a beszállító továbbra is a kockázatvállalási hajlandóságon belül marad-e, a bizonyítékok naprakészek-e, vannak-e nyitott ügyek, történt-e incidens, és a szolgáltatásváltozások szükségessé tesznek-e újraértékelést.

Hogyan tesztelik az auditorok a NIS2 beszállítói záradékokat

Az auditorok ritkán kezdik azzal, hogy a szabályzatot önmagában olvassák. Mintát vesznek a beszállítókból, és végigkövetik a bizonyítékláncot.

Egy ISO/IEC 27001:2022 auditor a beszállítói nyilvántartást, a kockázati besorolást, a beszállítói kritériumokat, a kellő gondossági feljegyzéseket, a szerződéseket, a bizonyítékokat, a SoA-megfeleltetést és a monitorozási előzményeket fogja kérni. Az A melléklet 5.20 esetében az auditor ellenőrzi, hogy a mintába került szerződések tartalmaznak-e érvényesíthető záradékokat. Az A melléklet 5.22 esetében azt teszteli, hogy a jelentéseket felülvizsgálták-e, a kivételeket naplózták-e, és az intézkedéseket utánkövették-e.

Egy NIS2 illetékes hatóság arra összpontosíthat, hogy az Article 21(3) alapján értékelték-e a beszállítói kiberbiztonsági gyakorlatokat és a biztonságos fejlesztési eljárásokat. Egy DORA-központú felülvizsgáló IKT-szerződésnyilvántartási bejegyzéseket, kilépési stratégiákat, koncentrációs kockázatelemzést és az Article 30 szerinti kötelező rendelkezéseket kérhet. Egy adatvédelmi auditor az adatfeldolgozói szerződéseket, az al-adatfeldolgozókra továbbadott követelményeket, az adatsértési interfészeket és a megfelelő garanciák bizonyítékait tesztelheti.

Az Enterprise PII biztonsági és hozzáférés-szabályozási szabályzat megmutatja, hogyan kapcsolódik vissza a hozzáférés-szabályozás, a sérülékenység, a konfiguráció, a monitorozás és a kriptográfia az ISO/IEC 27001:2022-hez:

„ISO/IEC 27001:2022 — 6.1.3 pont; 8.1 pont; A melléklet kontrolljai: 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. A következő záradékok kezelik: [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

A „Hivatkozott szabványok és keretrendszerek” szakasz 13.9 szabályzati záradékából.

Ha egy beszállító PII-hez, emelt jogosultságú rendszerekhez vagy monitorozási adatokhoz fér hozzá, a hozzáférés-szabályozási bizonyíték nem különül el a beszállítói bizonyosságtól. Ugyanannak az auditnyomnak a része.

A beszerzési csapda: aláírt szerződések bizonyossági működés nélkül

A leggyakoribb NIS2 beszállítói irányítási hiba nem a szerződések hiánya. Hanem a szerződéses szöveg és a napi működés közötti szakadék.

A szerződés előírhat éves penetrációs tesztelési összefoglalókat, de nincs felelős, aki ezeket bekérje. Előírhat 24 órás incidensbejelentést, de a beszállítónak csak általános támogatási címe van. Előírhat alvállalkozói jóváhagyást, de a beszerzés soha nem kap változásértesítéseket. Tartalmazhat auditálási jogokat, de a szervezetnek nincs folyamata a SOC-jelentésben szereplő kivételek értékelésére. Előírhat kilépéskori adattörlést, de az IT soha nem ellenőrzi a fiókok deaktiválását.

A Zenith Blueprint „Controls in Action” fázisának 23. lépése bemutatja, hogyan kelnek életre a beszállítói kontrollok:

„A gyakorlatban ez a kontroll a következőkön keresztül működik:

✓ Beszállítói kockázatértékelések, ✓ Szerződéskötés előtti kellő gondossági kérdőívek, ✓ Beépített biztonsági feltételeket tartalmazó szerződéssablonok, ✓ Beszállítói beléptetési ellenőrzőlisták, amelyek tartalmazzák a hozzáférés-kiosztást és a monitorozás beállítását, ✓ Folyamatos újraértékelések, különösen akkor, ha a beszállítói hatály változik, incidensek történnek, vagy a megújítás esedékessé válik.

Ez a kontroll nem áll meg az első szintű beszállítóknál. A beszállítója saját szolgáltatókhoz szervezhet ki tevékenységeket, és a kockázat továbbra is Önt terhelheti.”

Ez az igazgatósági szintű NIS2 üzenet: a szolgáltatásnyújtás kiszervezése nem szervezi ki az elszámoltathatóságot.

NIS2 beszállítói szerződés-helyesbítési ellenőrzőlista

Kezdje a 20 legkritikusabb beszállítóval, és hajtson végre célzott helyesbítési gyakorlatot:

• Azonosítsa az alapvető vagy fontos szolgáltatásokat támogató beszállítókat.
• Erősítse meg, hogy az egyes beszállítók kezelnek-e PII-t, támogatnak-e szabályozott szolgáltatásokat, vagy rendelkeznek-e emelt jogosultságú hozzáféréssel.
• Jelöljön ki üzleti felelőst, beszerzési felelőst és biztonsági felülvizsgálót.
• Ellenőrizze, hogy a beszállítói kockázatértékelés naprakész-e és összhangban áll-e a tényleges szolgáltatási hatállyal.
• Erősítse meg, hogy a szerződés tartalmazza a biztonsági alapkövetelményeket, az incidensbejelentést, az auditálási vagy bizonyíték-hozzáférési jogokat, az alvállalkozói kontrollokat, a folytonosságot, a biztonságos átvitelt, a hozzáférés-szabályozást, a sérülékenységkezelési együttműködést és a kilépési záradékokat.
• Erősítse meg, hogy az adatsértési határidők adott esetben támogatják a 24 és 72 órás eszkalációs igényeket.
• Kérjen frissített bizonyossági bizonyítékokat, beleértve a tanúsításokat, SOC-jelentéseket, penetrációs tesztelési összefoglalókat, BCP- vagy DR-teszteket és incidenselőzményeket.
• Vizsgálja felül a bizonyítékokat, ne csak tárolja azokat.
• Naplózza a kivételeket, és rendeljen hozzájuk helyesbítő intézkedési felelősöket.
• Frissítse a SoA-t és a kockázati nyilvántartást ott, ahol a beszállítói kontrollok NIS2, GDPR, DORA vagy ügyfélvállalásokat támogatnak.
• Ütemezze a monitorozási gyakoriságot a beszállító kritikussága alapján.
• Teszteljen egy beszállítói incidens-eszkalációs útvonalat.
• Teszteljen egy beszállítói megszüntetési útvonalat, beleértve az adatvisszaadást, törlést, eszközvisszaszerzést és hozzáférés-visszavonást.

Ha ezeket a pontokat egy kritikus beszállító esetében nem tudja bizonyítani, a szerződés még nem auditálható.

Alakítsa a beszállítói záradékokat felügyeleti bizonyítékokká

A NIS2 beszállítói irányítás ma már élő operatív fegyelem. A felügyeleti hatóságok, ügyfelek, tanúsító auditorok, adatvédelmi csapatok, pénzügyi szektorbeli partnerek és igazgatóságok nemcsak azt fogják kérdezni, hogy léteznek-e beszállítói záradékok. Azt is meg fogják kérdezni, hogy a záradékok kockázatalapúak, érvényesíthetők, monitorozottak, bizonyítékokkal alátámasztottak-e, és kapcsolódnak-e az incidensjelentéshez, folytonossághoz, hozzáférés-szabályozáshoz, sérülékenységkezeléshez, az alvállalkozókra továbbadott követelményekhez és a kilépéshez.

A Clarysec a Zenith Blueprint segítségével támogatja a szervezeteket e rés lezárásában azáltal, hogy a beszállítói kontrollokat IBIR-fázisokká, kockázatkezeléssé, SoA-bejegyzésekké, beléptetési rutinokká és auditbizonyítékká alakítja. A Zenith Controls az ISO/IEC 27002:2022 A.5.19, A.5.20 és A.5.22 beszállítói kontrolljait megfelelteti a NIS2, DORA, GDPR, NIST, COBIT 2019, a támogató ISO-szabványok és az auditmódszertanok követelményeinek. A Clarysec beszállítói és adatvédelmi szabályzatai biztosítják azt a záradékszerkezetet, bizonyítékelvárást és monitorozási rutint, amely igazolhatóvá teszi a beszállítói bizonyosságot.

A következő lépés egyszerű: válasszon ki öt kritikus beszállítót, vegyen mintát a szerződéseikből, feleltessen meg minden záradékot az ISO/IEC 27001:2022 szerinti kockázatkezelésnek és az A melléklet kontrolljainak, kérjen friss bizonyossági bizonyítékokat, és futtasson le egy 24 órás incidensbejelentési asztali gyakorlatot. Ha a bizonyítéklánc megszakad, a Clarysec eszköztárai struktúrát adnak a helyreállításához, mielőtt ezt egy incidens, ügyfélfelülvizsgálat vagy felügyeleti megkeresés kényszerítené ki.